locked
Configuration Issue with fresh MOSS 2007 SP2/Feb2011CU on fresh Windows Server 2008 R2 server? RRS feed

  • Question

  • I've seen numerous posts about MOSS 2007 SP1 on WinServ2008 upgrading to WinServ2008R2, but the problem I am encountering is on a brand new WinServ2008R2 box with no additional software installed using the MOSS 2007 SP2 installation files.  The installation and updates go perfectly fine and I've installed MOSS 2007 successfully numerous times on Windows 2003 systems.  However, during configuration the Configuration Wizard fails at step 2 of 9 with the following error:

    "Failed to create the configuration database.  An exception of type System.IO.FileLoadException was thrown.  Additional exception information: Unable to connect to database.  Check database connection infromation and make sure the database server is running"

    Environment:

    • MOSS 2007 SP2 x64 with CU's on Windows Server 2008 R2 Datacenter with latest MS Updates
    • SQL Server 2008 R2 x64 on Windows Server 2008 R2 Datacenter with latest MS Updates for SQL and Windows

    Here's the odd behavior.  When running the SharePoint Configuration Wizard...

    1. SharePoint sees and connects to SQL Server 2008 R2 (Default Instance)
    2. It creates the SharePoint Admin database with GUID
    3. It creates the SharePoint_Config database

    Then the Wizard produces the error.  Every time.  After all troubleshooting attempts, reinstalls, slipstream updates, etc.  Every time, the same failure notice.

     Troubleshooting steps attempted so far (that haven't resolved the issue):

    • The firewall on the CA server has been disabled for testing.
    • The SharePoint Setup Admin account used to install and configure MOSS 2007 SP2 has been given local admin rights on the CA server and on the SQL 2008 R2 server.  Although I've followed the MS guidelines for permissions as outlined by Mindsharp (and that matches our production MOSS 2007 system in place for years), I gave the setup account full SQL permissions to troubleshoot this issue.
    • The SQL Service account used during the instllation of SQL Server 2008 and related updates is also part of the Local Administrators group on the CA and SQL Server for troubleshoot.  This account also has full SQL Server permissions.
    • Through the SQL Configuration Tool, Named Pipes has been enabled.
    • From the CA server I used the ODBC Connection Tool to test a normal system SQL Connection to the SQL Server.  This worked for the Setup Account as well as the SQL Service account.
    • I even ran the SharePoint Configuration tool against several different SQL 2005 and SQL 2008 Development Servers we use for other SharePoint farms, and the same behavior was produced.  So i don't believe the issue is with the SQL machines.
    • Updated DCOM permissions (something that needed to be done on MOSS 2007 on Windows 2003)
    • Updated MSDTC permissions

    On the SQL Server, the error logs produced by this configuration wizard are consistent.  For each failed attempt, I see the following log info:

    2011-05-02 11:18:55.33 spid55      Starting up database 'SharePoint_Config'.
    2011-05-02 11:18:55.35 spid55       index restored for SharePoint_Config.syspriorities.
    2011-05-02 11:18:55.36 spid55       index restored for SharePoint_Config.sysowners.
    2011-05-02 11:18:55.37 spid55       index restored for SharePoint_Config.sysschobjs.
    2011-05-02 11:18:55.37 spid55       index restored for SharePoint_Config.syscolpars.
    2011-05-02 11:18:55.38 spid55       index restored for SharePoint_Config.sysnsobjs.
    2011-05-02 11:18:55.38 spid55       index restored for SharePoint_Config.syscerts.
    2011-05-02 11:18:55.38 spid55       index restored for SharePoint_Config.sysxprops.
    2011-05-02 11:18:55.39 spid55       index restored for SharePoint_Config.sysscalartypes.
    2011-05-02 11:18:55.39 spid55       index restored for SharePoint_Config.sysidxstats.
    2011-05-02 11:18:55.39 spid55       index restored for SharePoint_Config.sysclsobjs.
    2011-05-02 11:18:55.40 spid55       index restored for SharePoint_Config.sysremsvcbinds.
    2011-05-02 11:18:55.40 spid55       index restored for SharePoint_Config.sysrts.
    2011-05-02 11:18:55.40 spid55       index restored for SharePoint_Config.sysasymkeys.
    2011-05-02 11:18:55.40 spid55       index restored for SharePoint_Config.syssqlguides.
    2011-05-02 11:18:55.41 spid55       index restored for SharePoint_Config.syssoftobjrefs.
    2011-05-02 11:18:55.55 spid55      Setting database option AUTO_CLOSE to OFF for database SharePoint_Config.
    2011-05-02 11:19:04.27 spid58      Starting up database 'SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266'.
    2011-05-02 11:19:04.29 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.syspriorities.
    2011-05-02 11:19:04.29 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.sysowners.
    2011-05-02 11:19:04.29 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.sysschobjs.
    2011-05-02 11:19:04.30 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.syscolpars.
    2011-05-02 11:19:04.30 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.sysnsobjs.
    2011-05-02 11:19:04.31 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.syscerts.
    2011-05-02 11:19:04.31 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.sysxprops.
    2011-05-02 11:19:04.31 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.sysscalartypes.
    2011-05-02 11:19:04.32 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.sysidxstats.
    2011-05-02 11:19:04.32 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.sysclsobjs.
    2011-05-02 11:19:04.32 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.sysremsvcbinds.
    2011-05-02 11:19:04.33 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.sysrts.
    2011-05-02 11:19:04.33 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.sysasymkeys.
    2011-05-02 11:19:04.33 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.syssqlguides.
    2011-05-02 11:19:04.33 spid58       index restored for SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.syssoftobjrefs.
    2011-05-02 11:19:04.47 spid58      Setting database option AUTO_CLOSE to OFF for database SharePoint_AdminContent_a67a4ae4-4ebb-4a10-a9b4-d62c5a6ed266.

    It is very odd behavior and almost looks like the CA server can see the SQL box and then can't see the SQL box.  Doh!  Could it be a .Net issue on the CA Server?  Or a SQL command that blocks further accesss to one of the databases?  An issue with needing additional WSS 3.0 files?

    Tuesday, May 3, 2011 2:41 PM

Answers

  • Okay, so we went forward with Microsoft Support to assist with this issue.  We did resolve it and the steps are listed below.  This worked for us in our particular situation and I can't mark my own post as an answer! (Moderator Note: You can - in this case [as OP] should - actually)

    The issue reported indicated a potential problem with corrupted files on the server.

    1. Created New Document.Txt on the C drive
    2. Change the Extension to UDL.
    3. Double-clicked on the UDL file.  This produced the following error:

      "Run DLL Failed: There was a problem starting c:\program files\systems\ole db\oledb32.dll"
    4. Opened a command prompt and ran "SFC /SCANNOW".  After approximately 15 minutes, the scan completed.  The Windows Resource Protection did find corrupted files and repaired them.  The fixes were saved in a log file.
    5. I double-clicked on the UDL file again.  The Data Link Properties window loaded this time!
    6. In the Provider tab we ensured that Microsoft OLE DB Provider for SQL Server was selected
    7. In the Connection tab, I entered the SQL SERVER Name, checked Windows NT Integrated security, and successfully selected the SharePoint_Config database from the dropdown menu.
    8. I clicked on Test Connection and successfully connected!
    9. I re-ran the SharePoint Configuration Wizard without any problems and was able to load the Central Administration site.

    I'm happy that it's working now and relieved that it wasn't related to SharePoint!!!  Happy Five de Mayo =)


    • Edited by Mike Walsh FIN Thursday, May 5, 2011 4:21 PM Moderator Note added
    • Marked as answer by Mike Walsh FIN Thursday, May 5, 2011 4:21 PM
    Thursday, May 5, 2011 3:23 PM

All replies

  • Try installing the April 2011 CU instead.

    There is at least one thread here about a problem after installing the Dec 2010 or Feb 2011 CU that was cleared up by installing the April 2011 CU.

     P.S. Here's a link to the description of the MOSS 2007 April 2011 CU.

    http://support.microsoft.com/kb/2512782

     so-called hotfix (it is not a hot fix it's the full CU file) from here

    http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2512782&kbln=en-us#step1


     

    SP 2010 "FAQ" (mainly useful links): http://wssv4faq.mindsharp.com/default.aspx
    WSS3/MOSS FAQ (FAQ and Links) http://wssv3faq.mindsharp.com/default.aspx
    Both also have links to extensive book lists and to (free) on-line chapters


    • Edited by Mike Walsh FIN Tuesday, May 3, 2011 4:34 PM P.S. with link added
    Tuesday, May 3, 2011 4:06 PM
  • Thanks Mike. I was hoping this would work, but I get the same result with the April 2011 CU, even after rebooting.  So the same behavior is exhibited with:

    • Fresh installation of MOSS 2007 SP2 without any CU's
    • MOSS 2007 SP2 with Feb 2011 CU
    • MOSS 2007 SP2 with April 2011 CU

    I get the feeling that the configuration is sending a SQL command that essentially blocks itself from connecting to the database after that. 

    Just for the heck of it, I tried running the Config Wizard again, but this time attempted to join the farm I'm trying to set up.  As expected, that didn't work.  Here's the failure message just in case:

    "Failed to connect to the configuration database.
    An exception of type System.InvalidOperationException was thrown, Additional exception information:
    Windows SharePoint Services configuration infrastructure is not initialized, You must wait until completion before joining another server to the farm."

    Tuesday, May 3, 2011 5:10 PM
  • Okay, so we went forward with Microsoft Support to assist with this issue.  We did resolve it and the steps are listed below.  This worked for us in our particular situation and I can't mark my own post as an answer! (Moderator Note: You can - in this case [as OP] should - actually)

    The issue reported indicated a potential problem with corrupted files on the server.

    1. Created New Document.Txt on the C drive
    2. Change the Extension to UDL.
    3. Double-clicked on the UDL file.  This produced the following error:

      "Run DLL Failed: There was a problem starting c:\program files\systems\ole db\oledb32.dll"
    4. Opened a command prompt and ran "SFC /SCANNOW".  After approximately 15 minutes, the scan completed.  The Windows Resource Protection did find corrupted files and repaired them.  The fixes were saved in a log file.
    5. I double-clicked on the UDL file again.  The Data Link Properties window loaded this time!
    6. In the Provider tab we ensured that Microsoft OLE DB Provider for SQL Server was selected
    7. In the Connection tab, I entered the SQL SERVER Name, checked Windows NT Integrated security, and successfully selected the SharePoint_Config database from the dropdown menu.
    8. I clicked on Test Connection and successfully connected!
    9. I re-ran the SharePoint Configuration Wizard without any problems and was able to load the Central Administration site.

    I'm happy that it's working now and relieved that it wasn't related to SharePoint!!!  Happy Five de Mayo =)


    • Edited by Mike Walsh FIN Thursday, May 5, 2011 4:21 PM Moderator Note added
    • Marked as answer by Mike Walsh FIN Thursday, May 5, 2011 4:21 PM
    Thursday, May 5, 2011 3:23 PM