KB: The System Center Data Access Service fails to start after applying KB2677070

KB: The System Center Data Access Service fails to start after applying KB2677070

  • Comments 1
  • Likes

imageHere’s a new Knowledge Base article we published. This one talks about an issue where the System Center Data Access Service may fail to start with a Timeout error after applying the hotfix in 2677070.

=====

Summary

After applying KB2677070, the System Center Data Access Service may fail to start with a Timeout error.

More Information

This issue occurs because the update changes the URLs used to contact Windows Update to download the trusted and untrusted CTLs. If the old URLs were hardcoded as exceptions in the firewall or proxy, the server running the Data Access Service will fail to download the new CTLs because it can't reach the updated web address.
The workaround for this is to ublock the updated URLs in the firewall or proxy or disable CRL checking for the Data Access Service.
The updated URLs are:
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
To disable CRL checking for the Data Access Service, open Microsoft.Mom.Sdk.ServiceHost.exe.config in a text editor and add the following line in the <runtime> section:
<generatePublisherEvidence enabled="false"/>
Below is an example of this tag being added for System Center 2012 Operations Manager:
<runtime>
<generatePublisherEvidence enabled="false"/>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.EnterpriseManagement.HealthService" publicKeyToken="31bf3856ad364e35" />
<publisherPolicy apply="no" />
<bindingRedirect oldVersion="6.0.4900.0" newVersion="7.0.5000.0" />
</dependentAssembly>
<publisherPolicy apply="no" />
<probing privatePath="" />
</assemblyBinding>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Mom.Common" publicKeyToken="31bf3856ad364e35" />
<publisherPolicy apply="no" />
<bindingRedirect oldVersion="6.0.4900.0" newVersion="7.0.5000.0" />
</dependentAssembly>
<publisherPolicy apply="no" />
<probing privatePath="" />
</assemblyBinding>
<gcServer enabled="true"/>
</runtime>
The next example shows the same parameter added in the configuration file for System Center Operations Manager 2007 R2:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
<gcServer enabled="true"/>
</runtime>
Microsoft.Mom.Sdk.ServiceHost.exe.config is found in the following directories (where x is the drive on which Operations Manager is installed):

· System Center Operations Manager 2007 R2: x:\Program Files\System Center Operations Manager 2007
· System Center 2012 - Operations Manager: x:\Program Files\System Center 2012\Operations Manager\Server

=====

For the most current version of this article please see the following:

2730040 - The System Center Data Access Service fails to start after applying KB2677070

J.C. Hornbeck | System Center & Security Knowledge Engineer

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • This can also happen if there is a proxy server and winhttp is not configured to use it.  To check, open Internet Explorer and check if the proxy info is entered correctly and if as a user you can get out the Internet.  If so, check if winhttp proxy is set.  Open a command line and run as administrator, then

    > Netsh

    > winhttp

    > show proxy

    The output should match the settings in IE.  If not, then type at the same command prompt:

    > import proxy source=ie

    The output should now match what is entered in IE.  Now start System Center Data Access service.