SCSM 2012 - Data Access Service (DW) Won't Start


  • We recently rebuilt the SQL server that houses our SCSM Data Warehouse DBs.  It was running Windows Server 2008 R2 with SQL Server 2008 Enterprise.

    Now the server OS is Server 2012 and SQL is 2012 Enterprise.

    Since that move the Data Access Service has failed to stay running.  It is configured to logon with the same service account as it was before.  The Data Access service on the SM Management server starts and stays running fine.  It's just a problem on the DW management server.

    Event IDs that appear in the event log after starting the service are:

    26337:  The encryption keys in the registry were either not valid or not present.
     The System Center Data Access service will not start.

    26339:  An exception was thrown while initializing the service container.
     Exception message: Initialize
     Full exception: Feature of type 'Microsoft.EnterpriseManagement.ServiceDataLayer.IManagementGroupPropertiesFeature, Microsoft.EnterpriseManagement.DataAccessService.Core, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' cannot be added to the container.

    26380:  The System Center Data Access service failed due to an unhandled exception.  
    The service will attempt to restart.

    Microsoft.EnterpriseManagement.ConfigurationReaderException: Feature of type 'Microsoft.EnterpriseManagement.ServiceDataLayer.IManagementGroupPropertiesFeature, Microsoft.EnterpriseManagement.DataAccessService.Core, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' cannot be added to the container. ---> Microsoft.EnterpriseManagement.Common.SdkServiceNotInitializedException: The Data Access service has not yet initialized. Please try again.
       at Microsoft.EnterpriseManagement.ServiceDataLayer.ManagementGroupPropertiesFeatureImplementation.InitializeManagementGroupProperties()
       at Microsoft.EnterpriseManagement.SingletonLifetimeManager`1.GetComponent[K]()
       at Microsoft.EnterpriseManagement.LifetimeManagerWrapper`2.GetComponent[K]()
       at Microsoft.EnterpriseManagement.FeatureContainer.GetFeatureInternal[T](Type type, String featureName)
       at Microsoft.EnterpriseManagement.FeatureContainer.AddFeatureInternal[T,V](ActivationContext`1 context, String featureName)
       --- End of inner exception stack trace ---
       at Microsoft.EnterpriseManagement.ConfigurationReaderHelper.ReadFeatures(XPathNavigator navi, IContainer container)
       at Microsoft.EnterpriseManagement.ConfigurationReaderHelper.Process()
       at Microsoft.EnterpriseManagement.ServiceDataLayer.DispatcherService.Initialize(InProcEnterpriseManagementConnectionSettings configuration)
       at Microsoft.EnterpriseManagement.ServiceDataLayer.DispatcherService.InitializeRunner(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart(Object obj)

    Wednesday, November 27, 2013 7:56 PM

All replies

  • Bumping up a little to see if anyone has any suggestions yet before I open another case with Microsoft.
    Thursday, January 23, 2014 6:22 PM
  • Have you found a solution to this problem?

    We are having the same issue with our migration of the data warehouse server, databases, and SRS from Windows Server 2008 r2 to Windows Server 2012 r2.

    Wednesday, February 05, 2014 10:20 PM
  • sadly, I hve not.
    Friday, February 07, 2014 8:35 PM
  • Hi Chris,

    I am assuming you reinstalled the entire OS to Windows Server 2012 and not upgrade.

    If this is the case, you have to restore the Encryption Key. The encryption key is the key you were prompted to backup upon a successful installation by a wizard of SecureStorageBackup and the output ussualy will be in *.BIN format.

    Without this key, the the DB is as good as none. Just want to know if you have the key backup earlier ?

    Thank you and hope this help.


    Choo Hoong

    Monday, February 10, 2014 6:26 PM
  • This was not an upgrade.  It was a fresh build and then we restored the DB.  I did restore the Encryption Key but that didn't seem to help.
    Wednesday, February 19, 2014 6:34 PM
  • Hi Chris,

    So, you removed the old DW SQL server. Then you installed a new server, using the exact same name as the previous one. After that you restored all the involved databases. Correct?

    You didn't change anything else at all? How did you re-create all the permissions needed on all the databases for the SCSM service account?

    Have you seen this section of the SCSM documentation?


    Anders Asp | Lumagate | | Sweden | My blog:

    Wednesday, February 19, 2014 10:44 PM
  • I forwarded your questions on to our DBA who assisted with this.  Here is his response:

    (And yes, I'm familiar with that section of the SCSM documentation)


    I used the sp_help_revlogin output to recreate the logins:

    Verified that the same logins were created on the rebuilt server, but I think that’s about all the verification I did. The database-specific permissions are kept in the databases, which we restored so they should be identical. Almost all the logins are AD accounts, so passwords and SID’s shouldn’t be a problem. There are only two sql logins, and their passwords and SID’s were transferred over (pw was hashed). These two sql logins are non-essential anyway.


    Hope that helps!


    Wednesday, February 19, 2014 11:48 PM
  • Strange. If you only touched the SQL server the encryption key shouldn't be an issue at all (since it's stored on the DW mgmt. server).

    The console is working fine?
    Do you still have all data accessible in the console or has some of it been groomed out?


    Anders Asp | Lumagate | | Sweden | My blog:

    Friday, February 21, 2014 7:46 PM
  • Console still loads fine, but I get errors that the Reporting Data Warehouse MS is currently unavailable (obviously) so the DW and Reporting objects in the Wonderbar are missing.

    I still have data in the Incident Management Work Items section as well.  That's currently all we're using SCSM for at the moment.  No Activity or Change, etc.

    PS:  Thanks for the attention on this.

    Friday, February 21, 2014 7:50 PM
  • If you still have all data available in the console, the best and easiest fix would be to re-install the DW.

    What is the retention time for incident set to?
    (Administration --> Settings --> Data Retention)

    When did you take SCSM in production?


    Anders Asp | Lumagate | | Sweden | My blog:

    Friday, February 21, 2014 9:55 PM
  • 90 days for Incident retention time.

    We took SCSM into production in, October 2012 I believe.

    If I go the route of reinstalling the DW, how do I deal with the fact of unregistering it first, if the management server can't talk to the DW management server?

    What steps would you suggest I take to reinstall the DW in this state?

    Friday, February 21, 2014 9:58 PM
  • Oh, that's 16 months ago... That would mean that you would lose around 13 months of history. Well, doesn't sound like an option then. You haven't reached out to Microsoft support yet?


    Anders Asp | Lumagate | | Sweden | My blog:

    Friday, February 21, 2014 10:07 PM
  • Since this is our Test environment, I'm not too concerned about losing historical data.  Production hasn't suffered this problem - which is strange.  I was trying to resolve this on my own before opening a case with MS to save some support hours.

    Friday, February 21, 2014 10:09 PM
  • So, I attempted to unregister the DW server from the primary management server and it failed to communicate with it because it requires the Data Access service to be running on the DW server.

    What steps do you suggest I take for completely removing the SCSM DW from our test environment and reconfiguring it again?

    Monday, March 10, 2014 10:50 PM
  • Forgot to mention this other Event ID in the Operations Manager log that appears after trying to start the stopped Data Access service:

    Event ID:  26371

    The System Center Data Access service failed to register an SPN. A domain admin needs to add MSOMSdkSvc/WNSCSMTST2 and MSOMSdkSvc/WNSCSMTST2.xx.xxxxxx to the servicePrincipalName of CN=WNSCSMTST2,OU=xxxxxxxxxx,OU=xxxxxxx,DC=xx,DC=xxxxxx

    I have never seen an SPN where it uses the CN name like that before.  And of course trying to do a

    setspn -A MSOMSdkSvc/WNSCSMTST2 CN=WNSCSMTST2,OU=xxxxxxxxxx,OU=xxxxxxx,DC=xx,DC=xxxxxx fails.

    ckeander>setspn -A MSOMSdkSvc/WNSCSMTST2 CN=WNSCSMTST2,OU=xxxxxxxxxx,OU=xxxxxxx,DC=xx,DC=xxxxxx
    nForAccount: Call to DsGetDcNameWithAccountW failed with return value 0x00000525
     locate account CN=WNSCSMTST2,OU=xxxxxxxxxx,OU=xxxxxxx,DC=xx,DC=xxxxxx

    Friday, March 21, 2014 10:40 PM