locked
Incorrect/Corrupt Farm Configuration database server name RRS feed

  • Question

  • I have a SharePoint 2007 farm (version 12.0.0.6219) with a corrupt configuration database (SQL Server 2008 R2) consisting of a Central Administration server and a database server for Windows SharePoint Services Database. In a failed attempt to move the configuration database to a new SQL server, the farm is referring to a SQL server that no longer exists. All databases on the new SQL server have been successfully moved from the old SQL server, but SharePoint does not recognize the configuration database. The network name of the old SQL server has been aliased to the never SQL server, so the farm is operational. But the Servers in Farm page states the old server as the configuration database server.

    After doing my own research, it appears to me the issue is in the Objects table in the SharePoint_Config database below.

    # Id ClassId ParentId Name Status Version
    1 AF14B6A3-2152-41BB-9407-3BB3D8E30C10 3112E92F-B97D-481E-8CEB-03FDE15ED1A7 BD5B4337-4294-4FC4-8EE2-0D51968D05DB 0 0x00000000000007DD
    2 990CCD53-6D0F-4998-A060-45408E818ED5 3112E92F-B97D-481E-8CEB-03FDE15ED1A7 5DAA8D3C-B6EF-443C-B6AC-E1F704E35A94 0 0x00000000000BDF1D
    3 DA951888-B47A-473E-97C2-B0EF78226512 E6591A38-008A-4F23-A88F-36A181C7D4EB AF14B6A3-2152-41BB-9407-3BB3D8E30C10 SharePoint_Config 0 0x00000000000007E3
    4 109CA292-69CB-417D-AFDF-C2A9DCE44A1B 674DA553-EA77-44A3-B9F8-3F70D786DE6A 109CA292-69CB-417D-AFDF-C2A9DCE44A1B SharePoint_Config 0 0x00000000000008E7
    5 BD5B4337-4294-4FC4-8EE2-0D51968D05DB E77AAF47-3CAC-4001-BC6B-5BCCB6486318 109CA292-69CB-417D-AFDF-C2A9DCE44A1B Old SQL Server 0 0x00000000000007D4
    6 5A9AAEA8-A7E8-490F-8107-3D61F0D2A4E5 E77AAF47-3CAC-4001-BC6B-5BCCB6486318 109CA292-69CB-417D-AFDF-C2A9DCE44A1B Exchange server 0 0x0000000000039216
    7 3886B6E4-0E9E-499B-96A0-7CC677F8A5D0 E77AAF47-3CAC-4001-BC6B-5BCCB6486318 109CA292-69CB-417D-AFDF-C2A9DCE44A1B Web Server 0 0x00000000000BFE51
    8 5DAA8D3C-B6EF-443C-B6AC-E1F704E35A94 E77AAF47-3CAC-4001-BC6B-5BCCB6486318 109CA292-69CB-417D-AFDF-C2A9DCE44A1B New SQL server 0 0x00000000000BDF17

    It looks like all I’d have to do delete row id’s ...E1F704E35A94 and ...45408E818ED5 (<red>red</red> row #’s 8 and 2) after shutting down all SharePoint Web Applications and services. Then update Old SQL Server with New SQL Server. Possibly even deleting row ...B0EF78226512 (orange row # 3) could be done as it appears to be an orphaned part of the configuration. These ids are not referenced in any other table in this database.

    Any help on this would be appreciated. Thanks in advance.

    P.S. Sorry it looks like my table rendering didn't work as intended.


    -----&amp;gt;Executive Vector


    Tuesday, February 25, 2014 7:31 PM

All replies

  • are you using the SQL alias to pointing to the Config Database server?

    did you stop all the timers services, admin services other services before moving the Config DB and configuring the alias to new server.if you did not then it will corrupted.

    If you are not using the SQL Alias and using the sql server name then you cannot move it.

    you need to rebuild new farm with creation of new Config DB, then create SSP /Web apps and attached your content Database.

    Directly playing with the Config Database is not a good idea at all and i am sure deletion is not supported in any means.


    Please remember to mark your question as answered &Vote helpful,if this solves/helps your problem. ****************************************************************************************** Thanks -WS MCITP(SharePoint 2010, 2013) Blog: http://wscheema.com/blog

    Tuesday, February 25, 2014 8:22 PM
  • I did not shutdown those services you mentioned, my mistake. Yes, before we added the network alias, the timer service was failing. I wanted to avoid having to rebuild our SharePoint farm, but it's looking that's what I'm facing. Thanks anyway.

    -----&amp;gt;Executive Vector

    Tuesday, February 25, 2014 8:40 PM
  • i would try to clear the config cache and then check the behavior.

    Please remember to mark your question as answered &Vote helpful,if this solves/helps your problem. ****************************************************************************************** Thanks -WS MCITP(SharePoint 2010, 2013) Blog: http://wscheema.com/blog

    Tuesday, February 25, 2014 8:45 PM