locked
After Move All Databases Procedure, Cannot Connect to Configuration Database RRS feed

  • Question

  • I have a single-server server farm (WSS 3.0 and SQL Server 2005 on Windows Server 2008 R2). All 64-bit. We purchased a second server with much more storage with the intention of moving the SQL installation to the new server. I followed the instructions in the Move All Databases article (cc512723). After creating the SQL alias on the old server, restarting the WSS services and performing iisreset /start (and stopping the SQL services on the old server), I get a "Cannot Connect to Configuration Database" error in the browser.

    The site is accessible again if I restarting the SQL services on the old server and removing the SQL alias (but of course, WSS is still pointed to the old SQL Server).

    Researching this problem suggests that this is either security related or related to the SQL alias. With respect to the latter, there appears to be lots of confusion as to whether the alias should be set up using SQL Server Configuration Manager, cliconfg.exe, the 32-bit or 64-bit section of either utility, and where the setting is stored in the Registry. But if I use SQL Server Configuration Manager on the old server, configure the alias in the 64-bit section, and then test whether the redirection to the new server works by setting up an ODBC connection using the old server's name, the ODBC connection correctly points to the new SQL Server (the alias works). So I assume that the problem isn't with the alias.

    That leaves security. I followed the instructions in the Move All Databases article and have verified that all the SQL logins exist on the new server and that the database permissions and fixed server roles are the same on both the old and new server. So I don't think the problem is with SQL security. That leaves WSS and IIS security. During the initial installation, I took mostly default settings during WSS setup--that resulted in using a domain account for the Central Administration Application Pool identity, but the NETWORK SERVICE for the SharePoint - 80 identity. That seems like it would work fine if the SQL Server is on the same machine as WSS, but not if they are on two different machines, which they would be after the move. But I don't have enough knowledge/experience to know whether that's even relevant with respect to the current problem.

    The site is heavily used, so I can't afford to blindly change settings and hope the problem gets fixed. Any ideas?

    Tuesday, January 25, 2011 6:40 PM

Answers

  • With the help of a Microsoft support technician, I was finally able today (2/8) to track this down as being due to using the NETWORK SERVICE as the application pool identity for the SharePoint - 80 application. As suggested in the original post,  this worked fine when IIS and SQL Server were on the same machine, but once the databases were moved to a new SQL Server, a domain account needed to be used. The clue was that after the move, the Central Admin site was reachable but not the main site collection (the Central Admin site used the domain farm account as the application pool identity, not NETWORK SERVICE). There were audit failures in the Windows and SQL logs on the new database server that suggested a security issue, but nothing specific to the NETWORK SERVICE. After changing the application pool identity to a domain account using Central Administration (not IIS Manager), everything worked fine.

    Re the SQL alias issue, we used the 32-bit version of the CLICONFG utility (not SQL Configuration Manager) to set up the SQL alias. This is the version of the utility in the Windows\System32 folder, not the WOW64 folder. We left the default as "Use dynamic port".

    Hope the above is useful, and thanks again for the help.

    • Marked as answer by PGallez Tuesday, February 8, 2011 9:56 PM
    Tuesday, February 8, 2011 9:54 PM

All replies

  • I am not so sure about the NETWORK SERVICE account issue, but according to http://msdn.microsoft.com/en-us/library/ff647402.aspx#paght000015_sqlserver , ASP.Net application can use this account to access Remote SQL Server (you need to create SQL server login with the DomainName\ServerName$ account and grant permission for that login). And WSS is build with ASP.net.

     

    Anyway, I don’t think it is recommended to use that account as SharePoint web application pool identity. What if you have more than one web front end in a load balanced environment?

    You can change that account into a domain account as described in http://weblogs.asp.net/erobillard/archive/2007/07/06/how-to-change-service-accounts-and-their-passwords-in-moss-and-wss-3-0.aspx

     

     

     

     

    Gu Yuming

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com

    Wednesday, January 26, 2011 3:53 AM
  • Hi, thanks for the response and the references, I'll take a look.

    Re the NETWORK SERVICE, I agree this should be changed and could be relevant to the problem. I'll schedule some down time for the server, make the account change, and re-try going through the process to point the old server to the new one. I'll leave this thread open in the meantime.

    One follow-up question I didn't get into the original post: I've read some postings that suggest moving the configuration database isn't supported (though the "Move all databases" article suggests that it is. Do you know, have people successfully moved anything but the content database using the supported procedure? Also, lots of postings suggest using Central Administration or STSADM to delete and then re-connect a database, but I've been assuming that doing that isn't relevant if you're using a SQL alias. Is that correct?

    Wednesday, January 26, 2011 6:36 PM
  • First, thanks for sharing your detailed study.

     

    I guess you had read this kind of document saying that the configuration database moving is not supported using the built in backup and restore functionality: http://support.microsoft.com/kb/948725 . but it also gives the link to the manual process.

     

    As far as I know, it is not in conflict with the “Move all database” (I think this is the one you have read: http://technet.microsoft.com/en-us/library/cc512725(office.12).aspx ).

     

    BTW, A Senior colleague suggest that Kerberos double hop (http://blogs.msdn.com/b/knowledgecast/archive/2007/01/31/the-double-hop-problem.aspx) can also be one of the cause for your initial “Cannot Connect to Configuration Database” error, Do you have any web part on your web application to impersonating the user account to access configuration database?  

    Thursday, January 27, 2011 5:21 AM
  • Regarding the Kerberos issue, we are working in an AD environment, so I assume Kerberos is involved (this isn't my area of expertise, so I can't say much more than that). But when I installed SharePoint, I chose NTLM rather than Kerberos (to avoid the additional configuration Kerberos would have required), so as far as I understand it, nothing related to the SharePoint configuration is Kerberos-specific.
    Thursday, January 27, 2011 6:08 PM
  • It sounds like you just need to run the SharePoint Products and Technologies Configuration Wizard to reconnect to the config database.

    \Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Bin

    psconfig -cmd upgrade -inplace b2b

    Or just run it from the shortcut in Administrtive Tools on the start menu.  I expect you just need to reconnect the config database back into the farm.  You could also try removing the DB server from the farm and adding it back in.  Usually fixes issues like this.  Running the application pool with NETWORK SERVICE as the identity will have no effect on being able to connect to the config database and run SharePoint since it uses whatever security principal you configured in setup to connect toe the SQL database, usually a SQL login or domain account configured as a SQL login.

    Thursday, January 27, 2011 7:25 PM
  • Hi Joshua, thanks for the suggestion. I'll take a look at the powershell command and also review the SharePoint documentation re adding/removing servers, connecting/reconnecting databases. I want to make sure before I start with this that anything I do is reversible and I can get back to the known working configuration.

    Regarding the NETWORK SERVICE issue, like I said in the original post, after the initial (mostly default) farm installation and configuration, the identity for the SharePoint - 80 application pool ended up being NETWORK SERVICE, but the identity for the Central Administration application pool was the farm's domain account (let's call it sp_farm). The error message I'm getting is that SP can't connect to the config database (presumable the default sharepoint_config in our installation?). So (forgive my stupidity) is SP trying to connect to sharepoint_config as NETWORK SERVICE or as sp_farm?

    From your response it sounds like you don't think the problem is related to security, but is instead a configuration issue with the farm not pointing to the config database on the new server. But isn't that what the SQL alias is there for--so that when SP asks to connect to a database on the old server, the request gets redirected to the new server?

    Thursday, January 27, 2011 10:13 PM
  • Sorry for the delay.

     

    is SP trying to connect to sharepoint_config as NETWORK SERVICE or as sp_farm You can find this out in SQL Server log, please refer to http://www.mssqltips.com/tip.asp?tip=1735 ;

     

    And from which web application did you get the “Cannot connect to configuration database”, the 80 web application or the central administration? If it was the central administration, SharePoint use the sp_farm account to connect.

    Monday, February 7, 2011 3:37 AM
  • With the help of a Microsoft support technician, I was finally able today (2/8) to track this down as being due to using the NETWORK SERVICE as the application pool identity for the SharePoint - 80 application. As suggested in the original post,  this worked fine when IIS and SQL Server were on the same machine, but once the databases were moved to a new SQL Server, a domain account needed to be used. The clue was that after the move, the Central Admin site was reachable but not the main site collection (the Central Admin site used the domain farm account as the application pool identity, not NETWORK SERVICE). There were audit failures in the Windows and SQL logs on the new database server that suggested a security issue, but nothing specific to the NETWORK SERVICE. After changing the application pool identity to a domain account using Central Administration (not IIS Manager), everything worked fine.

    Re the SQL alias issue, we used the 32-bit version of the CLICONFG utility (not SQL Configuration Manager) to set up the SQL alias. This is the version of the utility in the Windows\System32 folder, not the WOW64 folder. We left the default as "Use dynamic port".

    Hope the above is useful, and thanks again for the help.

    • Marked as answer by PGallez Tuesday, February 8, 2011 9:56 PM
    Tuesday, February 8, 2011 9:54 PM