I am restoring a SharePoint 3.0 installation (part of TFS 2010) from database backups after a server failure. The old server, running on Server 2003 (32-bit), used a local SQL Server 2008 instance, but I am changing the topology for the new install to this: Server A: Server 2008 R2 64-bit with SharePoint 3.0 (and TFS 2010) front-ends. It has the same name as the old server.Server B: Server 2008 R2 64-bit with SQL Server 2008 R2. The SharePoint databases are restored to Server B at this point, and all software is installed on Server A, so I just want to hook everything up again. I start the Configuration Wizard, select the configuration database on the new SQL instance, and set the same domain user for database access as the previous installation. I also choose to install the central administration at Server A. The configuration process then fails with the following information logged: 06/26/2012 15:43:28 8 INF Creating connection string for config db STS_Config_TFS server [Server B] 06/26/2012 15:43:28 8 INF Creating connection string for admin content db SharePoint_AdminContent_3bd304f8-292b-4913-87d8-0997953adcbc server [Server B] 06/26/2012 15:43:28 8 INF Using NTLM for sql connection string 06/26/2012 15:43:28 8 INF Openning configdb so that I can join it at server [Server B] database STS_Config_TFS in farm mode 06/26/2012 15:43:28 8 INF Now joining to farm at server [Server B] database STS_Config_TFS 06/26/2012 15:43:36 1 INF Not running in high contrast, so we will paint the background with our trademarked image 06/26/2012 15:43:37 8 ERR Task configdb has failed with an unknown exception 06/26/2012 15:43:37 8 ERR Exception: 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 I have tried a few things: Adding all kinds of permissions on SQL Server to the domain user used to access the database (although it looks like the Wizards accesses the service as my user, who is admin at both Server A and Server B).Applying SP3 to the SharePoint installation. I am unsure of the original install version (the server is bust), but it was either SP2 or SP3.Making a SQL alias for Server A on Server A that points to Server B. When tracing the wizard with Process Monitor, I noticed that it was attempting to talk to the (old) SQL server at Server A right before it failed. What else can go wrong at step 2 of the Configuration Wizard? I have traced it with Process Monitor and see nothing suspicious. The SQL Server doesn't log anything, and tracing it reveals nothing. What resource is the wizard trying to access in SPPersistedObject.Update() which it doesn't have access to? I would be very grateful for any help here. Regards,/ David

Hi! I think the The Service Account must be Domain Admin. BTW, try Google It using "at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.CreateOrConnectConfigDb()"MVP Office Development, MCP, MCTS SharePoint 2010 Development

Check if this helps http://blogs.catapultsystems.com/mpoole/archive/2011/05/10/sharepoint-2007-config-wizard-access-denied-%E2%80%93-does-your-database-server-have-an-alias.aspx http://social.msdn.microsoft.com/Forums/en/sharepointdevelopment/thread/185e7674-8847-49d4-8eb6-b7aef7eced80Sushant Rao http://blogs.technet.com/sushrao1

I do have a SQL alias on the front-end server A that points to the new server B, but using that in the config wizard will unfortunately not help. By now I think I have tried every suggested solution on the web, short of making my account and the farm account Domain Admins (as has been suggested). It is still unclear to me what generates the Access Denied condition. Looking at the Update() method in Reflector (hard, because it seems to be obfuscated) gives a hint that it does a lot of validation on the account (which one - mine or the farm account?) before connecting. I suspect this is where things go wrong, even if my account and the farm account are added to every security group that I can think of. How do I enable ULS logging during the setup phase? That would probably give me a more detailed clue of where in the account checks things go wrong. Unfortunately, the stsadm tool assumes that the product is already configured, so I need to know how to enable the ULS log completely manually./ David

Hi Joao, Are you sure that the farm/service account must be Domain Admin? It looks like it doesn't even have to be a Local Admin (but member of the WSS_WPG groups). However, both the user running the wizard (me) and the service account are local admins (and have full permissions on the SQL server as well). I am running out of options here, so any more ideas are welcome./ David