I spent a while knocking my head against a problem with a SharePoint server farm that’s worth posting about. It’s also worth a big hats-off to our Technical Support Coordinator at Microsoft Partner Support who dredged up the article that finally pointed us in the right direction.
The problem
I’ll post later about our approach to SharePoint installations, but I’ll summarise thus: We create multiple user accounts to the SharePoint services - a db access account, an installation account etc etc. In this instance we were building a three server setup - db server, web server, index server. The accounts were created first, logged in as a domain admin. I also installed SharePoint as the domain admin, but didn’t run the config wizard.
I then logged in as our installation user, which has local admin rights to the two servers and dbcreator and securityadmin roles in the SQL server. I ran the config wizard on the web server and created the farm, specifying the db access account for (shock!) db access! The web server got to host the central admin site, which was tested and worked.
Before doing anything else I ran the config wizard on the second server and connected to the farm. At this point I had three servers listed in the Central Admin site, and it was time to configure services.
At this point we hit the snag - when I tried to configure the Office Server Search Service to run on the second server I got a SharePoint page telling me access was denied (‘The request failed with HTTP status 401: Unathorised’. There was a similar error in the event log with an event ID of 1314, and we also found an event log error with ID 5000.
I bashed my head against this for a while, checking user rights, group memberships and stuff. I checked the DCOM IIS WAMREG activation rights for the users that the app pools were running as and just in case did an aspnet_regiis -ga <username> for those accounts to ensure that all the .Net registrations and rights were correct. No success.
I removed SharePoint and reinstalled the farm with the roles reversed. The fault moved to the other server. I confirmed that I could configure the service on the same server as the central admin site but never on the other server. I looked at the system registry, compared service configurations with a working system and tried manually hacking the config to no effect.
In the end I uninstalled everything, installed the farm clean and unconfigured and called in air support.
The fix
I can’t praise our support guy at Microsoft enough. He’s incredible - I emailed him and got a phone call within five minutes! We ran through the problem and he consulted his support resources. What he came back with took a few goes to make stick, but it worked, and in fixing SharePoint pointed to the root of the problem.
The solution is to edit the web.config for the Office Server Web Services site. On our system that file is in C:\Program Files\Microsoft Office Servers\12.0\WebServices\Root. The original file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<sectionGroup name="microsoft.office.server" type="Microsoft.Office.Server.Administration.OfficeServerConfigurationSectionGroup, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" >
<section name="sharedServices" type="Microsoft.Office.Server.Administration.SharedServiceConfigurationSection, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
</sectionGroup>
</configSections>
<system.web>
<authorization>
<allow roles=".\WSS_ADMIN_WPG" />
<deny users="*" />
</authorization>
<webServices>
<protocols>
<clear />
<add name="AnyHttpSoap" />
<add name="Documentation" />
</protocols>
</webServices>
</system.web>
</configuration>
The solution is to edit the <authorization> section, adding entries to grant access to the user accounts for installation and db access:
<authorization>
<allow roles=".\WSS_ADMIN_WPG" />
<allow users="ondemand\MOSSdba" />
<allow users="ondemand\MOSSsetup" />
<deny users="*" />
</authorization>
However, the gotcha is that SharePoint puts the settings back - don’t do an IISreset; don’t recycle the app pool. Simply edit the file then go the page to configure the search service and it works. Once you’ve done that the service will start.
I then found that I couldn’t get back into the page because the web.config got reset (grr), but that’s not important right now.
The cause
The key in all this is that the two users I added explicit rights for were members of the WSS_ADMIN_WPG group specified in the original file. This pointed at an issue with the domain - the server was failing to get a list of members for that group.
The servers themselves were built and managed by our customer’s hosting provider, so I passed the fault to them. They checked the systems and found a domain fault affecting synchronisation. Result!