SharePoint Best Practice: Creating a dedicated Windows SharePoint Services environment


This is the first in my series of “Best Practices”, and this is one that I’m particularly keen on encouraging. I’m interested in your feedback.


The default implementation of SharePoint Portal Server creates Windows SharePoint Services team sites on the same IIS “Web Site” as the portal. This means the following:


Portal will be available on: http://portal (or whatever you choose)
Team Sites will be available on: http://portal/sites/<team site> (or whatever you choose)


While this works incredibly well, there are a couple of significant drawbacks, particularly for medium to large sites.



  • The number of options available to you from a “Scale Out” perspective are limited
  • Your overall top end scale is more limited
  • Less overall flexibility
  • Backup/Restore granularity is at the Portal level, meaning all databases have to be backed up and restored at the same time

My “Best Practice” proposal is to instead configure your Windows SharePoint Services environment on a separate IIS “Web Site” to your Portal environment. This is a relatively simple thing to do, requiring you to configure the portal on one IIS Web Site, then extending another with just Windows SharePoint Services. The result of this will be accessing SharePoint as follows:


Portal will be available on: http://portal (or whatever you choose)
Team Sites will be available on: http://wss/sites/<team site> (or whatever you choose)


The benefits of such a configuration are as follows:



  • The number of options you have for scaling out are increased. For example you can easily move the IIS “Web Site” onto another machine, or in fact onto an entirely new farm. This is especially important given that Portal and WSS Team Site are likely to have quite different usage profiles, and therefore place different demands on your server infrastructure. 
  • Your overall scale is significantly boosted, although agreed, there are not many customers out there that truly need it. With this configuration you can scale out the WSS farm to the limit, and at the same time scale out your Portal farm to the limit, plus traffic load is split with all portal traffic going just to the Portal farm, and all WSS traffic going just to the WSS farm. 
  •  Greater overall flexibility is also achieved. For example, do you want only your portal content to be accessible via SSL? Do you want one authentication method for Portal (integrated only) and then another for WSS (anonymous and authenticated)? Do you want your Portal to run in one Application Pool and your Team Sites to run in another? If so, then these things are much *easier* to achieve when you have created a separate dedicated WSS environment.
  • In a WSS environment, backup and restore can occur on a database by database basis, giving you many more options for the recovery of site data.

Now, I agree that this configuration is probably of most interest to medium and large sized customers, however given that the only real disadvantage is that you have to go through a couple of additional configuration steps, then I would even recommend it to our smaller customers. You just never know what might happen in the future, and it’s much harder to do this AFTER you have deployed.


So, how would you go about creating a separate WSS environment?


Check out the steps below, these should start immediately after you have created your first Portal.


Create a new IIS Web Site


a. Open IIS Manager
b. Right-Click on Webs Sites, New -> Web Site to open the Web Site Wizard
c. Enter a description of “WSS” and click “Next”
d. Leave IP Address and Port unchanged, but enter “WSS” in the Host Headers field and click “Next”
** This assumes you have a DNS record for WSS and the server IP
e. Click “Browse” then create a new folder under c:\inetpub called “WSS” and select it, then click “Next”
f.  On the screen title “Web Site Access Permissions” click “Next”
g. Click “Finish” to complete the Web Site creation


Extend the new IIS Web Site
By extending a virtual server we are effectively installing WSS onto the Web Site.


a. Open SharePoint Central Administration – Start -> Administrative Tools -> SharePoint Central Administration
b. Ensure Windows SharePoint Services administration is displayed, link in left column
c. Click on “Configure Virtual Server Settings”
d. Click on the “WSS” link
e. On the “Extend Virtual Server” page, click on “Extend and create a content database”
f.  On the “Extend and create content database” page, select “Use an existing application pool, and choose MSSharePointAppPool from the dropdown.
** Additional Application Pools can be configured to separate instances of WSS running on a single server and thereby ensuring a fault in one application does not affect another.
g. Enter and email address, for example administrator@localhost and click “OK”
** Extending the virtual server may take some time
h. When completed click on http://wss
i. When asked to select a template, chose whichever one suits, for example “Team Site”

Your new dedicated WSS “Team Site” farm as now been created, all that is needed it to connect it to the Portal


Configure the Portal to use the new Team Site Farm
Once the new WSS environment has been created, “Self Service Site Creation” must be enabled and the Portal used to create and manage the team sites needs to be informed of the location of the new environment.


a. Open SharePoint Central Administration – Start -> Administrative Tools -> SharePoint Central Administration
b. Click on the “Configure Virtual Server Settings” link
c. Click on the “WSS” link
d. Click on “Configure Self-Service Site Creation”
e.  Ensure the option is set to “On” and then click “OK”
f.  Open the Portal by browsing to http://portal
g.  Click on the “Site Settings” link
h.  Click on the “Change portal site properties and SharePoint site creation settings” link
i.   In the “Location for Creating SharePoint Sites” field enter:
http://WSS/_layouts/1033/scsignup.aspx
    And click “OK”


Create a new Team Site
With the portal now configured to use the new dedicated Team Site environment, we can create a new Team Site.


a. Click on the “Sites” link
b. Click on the “Create Site” link
c. Enter a “Title” (eg. Demo Site), URL and Owner for the site and click “OK”
d. On the “Add Link to Site” screen, which adds the new site to the “Site Registry”, leave as default and click on “OK”
e. Select a Template and click “OK”
f. Verify that your new Team Site has been successfully created on the “WSS” virtual server


Comments (8)

  1. Daniel McPherson beschreibt in seinem Artikel SharePoint Best Practice: Creating a dedicated Windows SharePoint Services environment , wie man SPS und WSS auf verschiedenen IIS-Website installiert.

  2. Mark Wilson says:

    We have found that when creating a new WSS site in a new web site on a server with SPS (SP1) already installed causes a problem.

    The web.config created for the WSS site has an entry called RunTimeFilter added to it which seems to be only for SPS and not WSS. This causes the WSS site to have an error the first time it is accessed on starting. You can get into the site after this but every time the app pool is recycled you will get the error on first access of the site.

  3. David says:

    Nice to see these instructions. I recently went through this exercise, discovered how to do this by trial and error. An additional note; if you are wanting to migrate an existing WSS site to the new stand alone WSS virtual site, then don’t do "h. When completed click on http://wss

    i. When asked to select a template, chose whichever one suits, for example “Team Site”". Instead, use either smigrate or FrontPage2003 to migrate the existing site (and content).

  4. Point2Share says:

    Well, it’s been 2 years of Point2Share!

    I’m a little late with the Anniversary, but it seems I started…