WSS and MOSS Install – Additional Configuration Tips and Tricks

When installing WSS or MOSS the setup program and the SharePoint Products and Technologies Configuration Wizard will complete most install operations for you, but there are several things that should also be completed that the wizard will not do and is also not included in the Microsoft documentation.  This post will outline some additional configuration tasks that should always be completed when configuring your SharePoint farm.

1 – Turn Off User Account Control

There are a few issues that I have run into with UAC turned on for a SharePoint server.  An example is that the Office Search Service might say that it has expired after a short time of being in use.  This happens because the SharePoint Products and Technologies Configuration Wizard was unable to elevate its permissions properly to complete all of the tasks when it ran.

2 – Give the Central Administration Content Database a More Friendly Name

Use psconfig.exe with the –cmd configdb command instead of the SharePoint Products and Technologies Configuration Wizard to create the farm.  Using the command line, you can specify a name for the Central Administration content database instead of using the auto-generated filename that contains a GUID.  Just remember to *ALWAYS* run the SharePoint Products and Technologies Configuration Wizard after you have created the configuration and CA content databases using the command line.

3 – Complete DCOM Configuration

In your System Event Log, there are usually constant errors with a source of DCOM and and Event ID of 10016.  This happens since your application pool service accounts have not been granted the local activation privilege on the IIS WAMREG admin Service.  To fix this error take a look at Microsoft knowledge base KB920783.  In the KB document, it says to give the username displayed local activation rights, but this is not what I would recommend.  I would give the WSS_WPG and WSS_ADMIN_WPG local computer groups this privilege instead of each account individually.

On Windows Server 2008 you must follow the steps at http://www.wictorwilen.se/Post/Fix-the-SharePoint-DCOM-10016-error-on-Windows-Server-2008-R2.aspx to fix this.

4 – Change Permissions on the Windows Tasks Folder

On a few occasions, I have run into issues with the Office Search Service when the service accounts have not been local administrators.  To fix this the Windows\Tasks folder permissions should be changed appropriately.  Do this by running the following commands as an administrator.  You should enter the account in which the search service runs in the last line.

cacls %windir%\tasks /e /g %COMPUTERNAME%\WSS_WPG:C
cacls %windir%\tasks /e /g %COMPUTERNAME%\WSS_ADMIN_WPG:F
cacls %windir%\tasks /e /g <DOMAIN\SEARCH_SERVICE_ACCOUNT>:C

5 – Change Permissions on the HOSTS File

If you have configured a dedicated crawl target, the HOSTS file on the index server will be modified so that it will only access the target machine.  This modification happens through a SharePoint timer job that will run frequently.  To prevent any issues with this process, modify permissions on the HOSTS file as follows.

cacls %windir%\system32\drivers\etc\hosts /e /g %COMPUTERNAME%\WSS_ADMIN_WPG:C

6 – Move the SharePoint and IIS Log Files Location to a Non-System Volume

You should change the default SharePoint and IIS logging directory to a volume that is not your system volume.  You must make sure this path is consistent between ALL servers in your farm.

7 – Set SQL Login Default Database for Service Accounts

This is one that exists in almost every environment that I see and nobody notices it.  Look at your SQL log files and you will probably find an error with a Source of Login and a message that states: Logon failed for user ‘<service account>’, Reason: Failed to open the explicitly specified database.  This happens because the default database for the service account is the master database, which the account does not have access to.  When the service account logs into the SQL server it attempts to open the master database.  Immediately, the database content is switched the the desired database, but not before the error is generated in the log.  To prevent log pollution, just change the SQL login’s default database to on that it does have permissions to.

8 – Assign Farm Administrators Full Control to the Shared Service Provider Administration Site

By default only the account that was used to create the SSP admin site will have the ability to access the site.  What you really want is for your farm administrators to have access to this site.  As soon as you create the SSP, open the SSP administration site and grant your farms administrators group or users Full Control to the site.

9 – Give Farm Administrators Personalization Services Administration Rights

In SSP Administration, click Personalization services permissions and make sure to give your farm administrators the ability to: Manage user profiles, Manage audiences, Manage permissions, Manage usage analytics.