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