Setting up MOSS as a Single Web Front End Farm with a Remote SQL 2005 Database

In setting up the standalone version of MOSS what seems like hundreds of times - either for work, for personal curiosity, or for the SharePoint 2007 Development Unleashed book, I've noticed a couple of pecularities about the standalone installation. When I'm using it as a single user for my own personal testing, I don't normally have any trouble with this type of installation and in fact most of the time I have this installation running inside a Virtual Machine (I have run it under both Virtual PC and VMware).

What I notice is that once I start getting multiple users onto the system, more than 10 or so sites, and start generating any kind of approximation of real usage - the system comes to a grinding halt. SQL 2005 Express (or whatever they're calling MSDE these days) just takes a beating - it starts consuming a truckload of memory and over 20% of my processor. I've duplicated this scenario just by hitting refresh on a couple of PCs around the house on different sites within the portal.

Obviously this scenario is undesirable, so the next logical alternative was to install SharePoint using the next level up from Standalone - a single WFE farm. By this I mean that there is a single Web Front End server that runs all of the web applications, runs Excel Services, manages the Business Data Catalog, and runs the document conversion utilities, and handles incoming/outgoing e-mail. This sounds pretty similar to the default Standalone installation with a few exceptions: we have more control over the web application structure, and, most importantly, this scenario uses the full-blown version of SQL Server 2005 and runs it on a different box. By running SQL 2005 on a different box, that 25% processor load and huge memory load won't impact the SharePoint box and in fact - I have yet to see the load get that high using the "real" version of SQL 2005. My hunch is that there are serious multi-user access problems with the standalone version of SQL.

To install using the single-WFE farm scenario, the first thing you need to do is install SQL Server 2005 on a fresh box. Secondly, you will need two (you can get away with one, but you really should have two) domain accounts. The first domain account is a service account with a password that does not change that is in the administrator's group of the SQL box. This is the account that will be used to access the configuration/content databases in SharePoint. The second account (or first if you just want one universal do-all account) is another fixed-password service account that is used as the credentials through which all crawled content is accessed. As a result, make sure this account has sufficient privileges to access content you need crawled.

When installing MOSS, pick the Complete installation option. This is a little misleading, since you're not installing the desktop version of SQL, but its what you need. When the installation is done and you run the configuration wizard, it will prompt you for the server name/instance of the SQL 2005 box you just set up. Go through the standard process and grab some coffee while the wizard runs.

When you're done with the configuration wizard - this is where a lot of people get worried. The standalone installation does a LOT of work for you, whereas the Complete installation does very little. You have no web applications configured, nor do you have shared services configured, nor do you have any site collections configured. To make your administrative life easier, perform the following tasks, in the following order:

1. Create a new web application for your Shared Services web application. I typically call mine PortalName - SharedServices where portal name is the name of your portal or intranet or, more accurately, your farm. Pick any random port it assigns you, but don't pick 80. Create a new IIS application pool and a new IIS web site. Do not re-use any existing IIS sites or application pools.
2. Create a new web application for your My Site storage. Just a recommendation, but I follow the convention PortalName - My Sites. Again, take any port number other than 80. Create a new IIS web site and application pool.
   
3. Create a new web application for your actual portal content (the one that will reside on port 80). Create a new IIS site and application pool.

When you're done you might end up with web applications at the following URLs (non-80 ports are random and yours will be different)

http://server (default port 80)
http://server:20000  (My Site storage)
http://server:30000  (Central Administration - this was created for you automatically during the wizard)
http://server:40000  (Shared Services)

Using the magic of host headers, it makes things a lot easier for your users to remember if you give them non-port URLs like:

http://intranet.mycorp.com
http://personal.intranet.mycorp.com (My Site storage, port XXXXX)
http://admin.intranet.mycorp.com (Central Administration, port XXXXX)
http://ssp.intranet.mycorp.com (Shared Services Provider for the farm, port XXXXX) 

So now you have a bunch of web applications and absolutely no useful site collections, and you have no shared services provider defined. In short, your portal isn't doing anything useful whatsoever right now. Ignoring the task list of administrative tasks, perform the following actions:

1. Configure Shared Services. This action will set up a shared services provider and let you get into shared services admin, which is where your user profiles are, your BDC configuration is, your search configuration, etc. Basically your site won't do jack without an SSP. When it asks you for the web application to use for shared services, make sure you select the shared services one you created earlier. This same screen will also ask you for a web application to use for hosting personal storage such as My Sites. Make sure you select the my site web application you created earlier.
2. Create a new Site Collection for your port 80 (home) web application. This site collection should be a template under Publishing, either a Collaboration Portal or a Publishing Portal. If you do anything other than a portal for your root site collection, you either know exactly what you're doing, or you're going to hose your entire installation :) Let's hope its the former.
3. Note that you don't need to create a site collection for the My Site host - that was created automatically for you when you provisioned the Shared Services Provider site.
4. Go to the Shared Services site and turn all the services on and do all the necessary configuration. At the very least, you need search running and should probably configure crawl schedules for search and import schedules for user profiles. In small domains, I like having the user profiles pre-imported because it makes the user's first hit to the site that much quicker. For ridiculously huge domains (like the one I did for HP), I only imported the profiles of the site admins and didn't automatically import any AD profiles until the user physically visited the site.

At this point, you should be able to go to your home site (which might be something like http://intranet.mycorp.com) and hit the home page and start working. The beauty of this situation is that unlike the standalone installation, you're using multiple IIS application pools and sites, which creates more stability, scalability, and usually pretty good performance. In addition, you have a separate content database for My Sites (I often use the naming convention of Farm_MySites), a separate content database for the new root site collection (portal), and all of that stuff is stored on a remote database that is actually increasing the performance of MOSS rather than hindering it.

Disclaimer: Your mileage may vary. Obviously if you are a seasoned SharePoint/MOSS pro, then you know that there are thousands of variations on the list I gave above. What I wanted to provide was a quick-and-dirty guide to getting MOSS installed and running in a realistic environment that can support multiple users and decent usage.

tags: sharepoint  administration  configuration  farm  topology  moss  wss  

links: digg this    del.icio.us    technorati    reddit