SharePoint 2007 Config Wizard Access Denied – Does your database server have an alias?

This post is a follow-up to my post from February 12th of this year – http://blogs.catapultsystems.com/mpoole/archive/2011/02/12/sharepoint-2007-config-wizard-access-denied.aspx.

Well, not really a follow-up but more like "another reason" that Access Denied doesn’t always mean there is a permissions issue.

So let’s get to the issue and the resolution. I was adding a server to a SharePoint 2007 farm. On task 2 of the Configuration Wizard, it failed with the following error message:

Server event error 104 –
Failed to connect to the configuration database.
An exception of type System.Security.SecurityException was thrown.  Additional exception information: Access denied.
System.Security.SecurityException: Access denied.
   at
Microsoft.SharePoint.Administration.SPPersistedObject.Update()
   at Microsoft.SharePoint.Administration.SPServer.Update()
   at Microsoft.SharePoint.Administration.SPFarm.Join()
   at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.CreateOrConnectConfigDb()
   at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.Run()
   at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()
The Zone of the assembly that failed was:
MyComputer

Yeah, yeah, yeah…I’ve seen this before. The setup user account I’m using must not have the right permissions. Here are the permissions the account should have:

 

  • It must have domain user account permissions.
  • It must be a member of the local administrators group on each server in the Office SharePoint Server 2007 farm, excluding SQL Server and the Simple Mail Transfer Protocol (SMTP) server.
  • This account must be able to log in to the computer running SQL Server.
  • This account must be assigned to the securityadmin and dbcreator SQL Server security roles.
  • If you use any Stsadm operations that affect a database, the administrator account must be a member of the db_owner role.

 

Nope. The permissions were right.

 

Okay, so maybe the SharePoint version on the server isn’t at the same level as the other servers in the farm? Nope, this wasn’t the problem either. All servers had the same SharePoint version.

 

Solution

 

The SharePoint farm I’m working on uses a SQL server alias (check in Central Administration -> Operations -> Default Database Server). When running the configuration wizard, you must enter the Alias instead of the actual database server name. Before doing this, however, you need to add the alias to the server. Here’s how:

  • On the server, go to Start -> Run, type cliconfg then press enter. The SQL Server Client Network Utility will open.
  • Select the Alias tab then click on "Add".
  • Change the Network libraries type to TCP/IP. Enter the Server alias (from Central Administration -> Operations -> Default database server) and then under connection parameters, enter the real server name.
  • Select OK.
  • Run the Configuration Wizard and use the Alias name when prompted to enter the Database server name.

 

 

Here’s hoping this saves someone a few hours/days of stress!

3 Comments

  1. Rich Warner May 11, 2011
  2. Melonie May 11, 2011
  3. Joerg August 14, 2012

Leave a Reply