A: If you look at the error in the event log and at the actual workflow within the Service Manager console, you'll find a more detailed error. Most likely, it will be

<span style="font-size: 10pt;">Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryException: The ConfigMgr Provider reported an error. ---> System.Management.ManagementException: Access denied </h3>
at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
at System.Management.ManagementScope.InitializeGuts(Object o)
at System.Management.ManagementScope.Initialize()
at System.Management.ManagementObjectSearcher.Initialize()
at System.Management.ManagementObjectSearcher.Get()
at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.Connect(String configMgrServerPath)

This shows an access denied error, which is typically caused by either the SCSM workflow or service account not having the correct permissions in SCCM, or the DCOM permissions on the SCCM server being incorrect. The easiest way to test is to run the wbemtest utility from the SCSM server to the SCCM box running as the SCSM workflow and service accounts. If this fails and you get "access denied," then you know it's something in the SCCM or DCOM permissions you need to fix.

  1. Launch wbemtest.exe on the Service Manager box.
  2. Click Connect.
  3. Enter the namespace as \\<SCCM server>\root\sms and enter the credentials for the SCSM workflow account. Then repeat with the service account. Click Connect.

  4. If the connection works, the DCOM permissions are OK. If you get access denied, the DCOM permissions need to be reset.
  5. If the connection did work, follow the instructions on this TechNet page to test the SCCM permissions.

To ensure you have the right DCOM permissions, see this TechNet page. I found I had to remove and re-add the permissions for SMS Admins to fix the problem. Remember both your workflow and service account for SCSM should be members of the SMS Admins group on the SCCM server.

If your DCOM permissions are fine, verify the actual SCCM permissions, as described on this TechNet page.