Installing WSS/MOSS on Windows 2008 x64 Step-by-Step guide

By Pako Simeonov

As developers we often have to use SharePoint environments that were already prepared for us by the infrastructure guys of the company we work for. Unfortunately sometimes they just take the shortcut and install the environment (especially the DEV one) the easiest and fastest way they know about - installing it in a single server mode, which uses local accounts. This unfortunately works good only for simple scenarios and in most of the cases the solutions we are implementing doesn't go in that category, since we have integrations with different systems which are on different servers. Here are couple of scenarios:

1. There is a dedicated SQL server where we store our configuration and content databases.

2. We have timer jobs that are accessing external systems to synchronize data between them and SharePoint. As we know in this case the code is executed under the SharePoint Timer Service account.

3. We need to use Kerberos authentication instead of NTLM in order to pass the credentials of the user to service that is running on another server.

4. Crawling content sources

Here is a step-by-step guide for installing WSS 3.0 by using domain accounts instead of local ones. I used Windows 2008 x64 virtual machine, so I can revert back to a particular snapshot:

1. Install IIS - WSS 3.0 requires IIS where the central administration site will be initially installed and after that all the SharePoint web applications. You can find some more details of how to do that here Installing IIS 7.0 on Windows Server 2008.
2. Download WSS - Download Windows SharePoint Services 3.0 x64 with Service Pack 2 from the microsoft web site.
3. Choose the installation - When you run the installation you need to select the Advanced option.
4. Choose the Server Type - The Web Front End option should be selected
5. Specify configuration database settings - Since all the servers in the farm will share one configuration database in the farm mode we have the chance to select a database for it on a different server, which is what we want in our deployment scenario. At this point we need to create an account that will be used to connect to the configuration database. Since our database is on a different server we must create it as domain account. A good practice is to call this account SPConfigAcct, so you know what it is being used for. Here is how the wizard page looks like after the needed information was provided:
6. Configure SharePoint Central Administration Web Application - at this step the port number of the central administration application should be selected and the type of the security provider - either NTLM or Kerberos. The Kerberos provider is recommended but it requires some additional configuration by the domain administrator - the right Service Principal Names (SPNs) should be added.
7. Complete the configuration - if the configuration was completed successfully you should see the following wizard page with overview of the WSS configuration:
8. Configure Windows SharePoint Services Search service - two new domain accounts needs to be created at this point. One account for the search service itself (SPSearchAcct) and another one which will be used by the search service to access all the content (SPCrawlAcct). In order to configure the search service you will need to go to Central Administration -> Operations -> Services on Server: As you can see initially the search service is stopped since it is still not configured. When you select the search service you will be able to provided the needed information. At this point you need to provide the two accounts - SPSearchAcct and SPCrawlAcct that was previously created. NOTE: when you provide the accounts make sure that you also add the domain name. Otherwise you will not be able to start the search service and an error will be shown.
9. Setup the outgoing e-mail settings

Now that we have our WSS installed we can create our web application that will contain our site collection with the site which we want to use for our development.

1. Create the new web application - to create the new web application you need to go to Central Administration -> Application Management and select the Create or extend Web Application:After you click on the Create a new Web Application you will be presented the screen where you have to provide the settings for the new web application:
   You can change the port on which the web application will be created at, which in our case is 9000. We need to create a domain account for the application pool of our new web application. Following our naming convention we can name the account SPContentPoolAcct and provide the name (together with the domain name) and the password in the Application Pool section. For the database server where the content database will be created we select the same sql server as we did for the configuration database. By default the database name created for the new web application has the name WSS_Content_{GUID}, but I found out that it is much more easier to give it a more meaningful name, which will help us find it faster in the SQL server. A good name is WSS_Content_{Port Number}.
2. Create Site Collection - once the web application is created we need to create the site collection together with the root site.

At this point you need to provide the site template that will be used for the root site and the account of the site administrator, who will be responsible for managing the site.

At this point we have our site created and ready to accept all the stuff we create as devel0pers for it - willing or not.

As a good practice I would recommend you to create sub site where you will be provisioning your components. It has some benefits that can save you some troubles later. Here are some of them:

• if you are creating custom SharePoint application in most of the cases you will use the API, being it from the custom pages you create or from external applications that are connecting to the particular SharePoint site. I've seen couple of cases when the developers are using the root site for their application and when it comes the moment to move it to production where it should be in a subsite it happens that it is not working correctly.
• sometimes it happens that there is something bad in your site as a result of improper provisioning, missing files, etc and it is much faster to recreate everything than trying to figure out what exactly is wrong. Having your application provisioned to a subsite will give you the opportunity to only delete this particular subsite. If you delete the root site you will delete all its child sites, which is not what we want to do.