locked
Old Site Code Being Used in "ExecQuery Operation" on Site Server RRS feed

  • Question

  • In our test environment, we are getting the typical error message "Configuration Manager cannot connect to the site database..." when trying to run the adminstraton console on the site server with a remote database. This is a little different than the other posts I've seen with this message in that the query is failing because it is using the old site code instead of the new one.

    The old site code is a holdover from ConfigMgr 2007 R2 which failed during our upgrade attempt. Since we have only a few systems in our inventory and the upgrade was not working we decided to uninstall ConfigMgr 2007 R2 and install SCCM 2012 from scratch. Instead of rebuilding the server (2008 R2) we just uninstalled ConfigMgr 2007 and installed SCCM 2012 on the same server. We got SCCM 2012 installed and working fine and it ran without issue for over 6 months.

    A few weeks ago we brought up a new test SQL 2012 (SP1) database server and moved the SCCM database over from SQL 2008 R2. All went well using the steps outlined on TechNet for modifying the database here and the console connected to the database on the new server.

    After a few days we noticed NGEN errors in the event log on the SQL server related to a bug in the SQL 2012 SP1.  One of the workarounds was to uninstall the Management Tools and then reinstall them from the non-SP1 source which we did.  After performing the workaround we started getting the ‘cannot connect to site database’ error whenever we start the console.

    We have tried resetting the site from Configuration Manager Setup and repairing the site from a restored database.  Each one ran successfully and showed the NEW site code in the greyed out fields but launching the console fails.  The event log shows 2 critical errors for each attempted connection with the following details (sanitized).

    Transport error; failed to connect, message: 'The SMS Provider reported an error.'
    Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryException
    The SMS Provider reported an error.
    at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryResultsObject.<GetEnumerator>d__0.MoveNext()
    at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.Connect(String configMgrServerPath)
    at Microsoft.ConfigurationManagement.AdminConsole.SmsSiteConnectionNode.GetConnectionManagerInstance(String connectionManagerInstance)

    ConfigMgr Error Object:
    instance of __ExtendedStatus
    {
     Operation = "ExecQuery";
     ParameterInfo = "SELECT * FROM SMS_Site WHERE SiteCode = 'OLD'";
     ProviderName = "WinMgmt";
    };

    Error Code:
    ProviderLoadFailure
    System.Management.ManagementException
    Provider load failure 
    at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
    at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()
    at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryResultsObject.<GetEnumerator>d__0.MoveNext()
    ManagementException details:
    instance of __ExtendedStatus
    {
     Operation = "ExecQuery";
     ParameterInfo = "SELECT * FROM SMS_Site WHERE SiteCode = 'OLD'";
     ProviderName = "WinMgmt";
    };

    The WMI data on the site server contains 3 subfolders under root/SMS.
      inv_schema
      site_OLD
      site_NEW

    Is there a way to cleanly remove the WMI references to the OLD site code and if so, will that solve the issue?  Is the console connection information stored somewhere other than WMI on the site server?  I've searched the registry to no avail and SMSProv.log is repeating the same errors using the wrong namespace.

    "Namespace : root\sms\site_OLD"

    All servers are Server 2008 R2.  The environment consists of 3 servers: primary site server, distribution point server and database server.  From what I can tell from the logs everything is still working behind the scenes.  It is only the administration console not working.

    Friday, January 4, 2013 12:56 AM

Answers

  • SQL 2012 support is for 2012 *SP1*, not RTM.

    I don't *think* that lead to your issues but it could have. I think the restores have probably exacerbated the issue. In 2007, directly restoring a site database was *not* supported because of the many things that existed outside of the database -- mainly in WMI but in some files also. Most (if not all) of this has been rolled into the database in 2012 (to my knowledge) and that's why they support a direct restore of DB now. However, I still would not trust method just because it is something new and the old backup restore method has proved itself reliable many times over.

    From the above log, it appears that the provider is trying to connect to the old site. Not sure why it would do this though. You've done a few out of bounds things and some have possibly been done by a colleague so its really hard to know exactly what could be the root cause.

    I'm assuming the SMS Provider is on the site server. If so, have you examined the SMS_ProviderLocation object in the root\sms namespace? The SiteCode attribute should contain the proper site code to connect to. Not sure how this would get changed but you should be able to manually modify it from OLD to NEW (if it is OLD that is).


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Paul Krueger Friday, January 4, 2013 3:31 PM
    Friday, January 4, 2013 3:33 AM

All replies

  • There are at least two very odd things in your description above. First, there is no such thing as an upgrade from 2007 to 2012. You can only do a side by side migration so totally not sure what you were trying to do although if you were truly trying to do an in-place upgrade, that's why it failed: it's simply not possible. Also, SQL Server 2012 is completely unsupported for use with 2012 RTM. You've potentially set yourself up for other issues and this is possible the cause of the current issue.

    As for console connection, have you tried simply reconnecting to the correct site using the Connect to a New Site option from the main ribbon bar menu?

    Where is the SMS Provider installed?

    Also, how did you restore the database? A simple DB restore is technically supported in 2012 but I would never actually recommend using one because ConfigMgr is so much more than just the DB.

    For the SMS_OLD namespace, delete it. It was for the old site and is completely unused now.

    Finally, for any one else reading this thread, I would never, ever recommend installing a ConfigMgr site server on the same installation of Windows as a previously installed instance site server (of the same or different ConfigMgr version). There are a lot of things, like the namespace, that do not get cleaned up by a simple install. A completely new installation of Windows should have been performed.


    Jason | http://blog.configmgrftw.com


    Friday, January 4, 2013 1:39 AM
  • Thanks for the quick response Jason!

    The 'upgrade' was in fact an attempted migration but we ran into all kinds of problems which led to the uninstall of 2007 R2 and new install of 2012.  I freely admit that we should not have tried cutting corners this way and we certainly don't do this in production but often times test environments are rushed. (Although they shouldn't)   We don't have a problem tearing these systems down and rebuilding but I thought it might be a good excersice in recovery and repair.

    As far as SQL 2012 being supported, I could swear the Technet SQL matrix for SCCM 2012 includes SQL 2012 at CU2.  Did I miss something here?

    The restore of the database was from DPM to a SQL 2008 instance and then detached and attached to the SQL 2012 server.  What is strange is that it worked initially but then stopped.  I'm not the only person using this test environment so there is always the possibility something else got changed.

    I did try installing the administraton console on a brand new server and pointed it to the FQDN of the site server and it returned the same error as when I ran it locally on the site server.  I tried every permutation I could think of using the Connect to New Site option but everything I entered returned the same error in the event logs.

    As stated above, this is more of a curiosity on how one might go about fixing a busted site reference.

    I appreciate the feedback and will see where we go after deleting the old site namespace.

    Friday, January 4, 2013 2:40 AM
  • SQL 2012 support is for 2012 *SP1*, not RTM.

    I don't *think* that lead to your issues but it could have. I think the restores have probably exacerbated the issue. In 2007, directly restoring a site database was *not* supported because of the many things that existed outside of the database -- mainly in WMI but in some files also. Most (if not all) of this has been rolled into the database in 2012 (to my knowledge) and that's why they support a direct restore of DB now. However, I still would not trust method just because it is something new and the old backup restore method has proved itself reliable many times over.

    From the above log, it appears that the provider is trying to connect to the old site. Not sure why it would do this though. You've done a few out of bounds things and some have possibly been done by a colleague so its really hard to know exactly what could be the root cause.

    I'm assuming the SMS Provider is on the site server. If so, have you examined the SMS_ProviderLocation object in the root\sms namespace? The SiteCode attribute should contain the proper site code to connect to. Not sure how this would get changed but you should be able to manually modify it from OLD to NEW (if it is OLD that is).


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Paul Krueger Friday, January 4, 2013 3:31 PM
    Friday, January 4, 2013 3:33 AM
  • I wrote a long reply and then clicked on "Mark as Answer" before submitting my reply.  :(

    I'm not going to write it all out again but the WMI updates DID change the query to look for the NEW site but still failed to connect.  I tried using the setup program to change the SMS Provider to the database server but got an error that it could not compile smsstub.mof.  When I ran the setup program and tried to 'repair' the SMS provider on the site server it complained with a similar error that it could not compile the smsprov.mof file.

    If you have any other suggestions please feel free to update this post.  I've marked it as answered because this resolved my initial issue.

    Thanks again for your help!

    Friday, January 4, 2013 3:37 PM
  • I'm all out of ideas at this point if you're still having issues. Given that its a test lab, its probably not worth the call to support to help you truly sift through the wreckage -- it's usually very difficult to do detailed troubleshooting here in the forums.

    Did it give a specific error code when trying to compile those MOFs?


    Jason | http://blog.configmgrftw.com

    Friday, January 4, 2013 3:56 PM
  • Both compiles failed with -1 as the error code.  I agree that this issue not worth spending a lot of time on. We will simply rebuild the servers like we should have done from the start!
    Friday, January 4, 2013 4:03 PM