Freigeben über

Service Manager 2016 Setup Doesn't Detect Data Warehouse Management Server

  • Artikel

My client ran into an issue in January running a test upgrade of their lab Service Manager 2012 R2 environment (UR9) to Service Manager 2016. Setup properly detected their management server as a "Service Manager Management Server". Unfortunately, when run on the data warehouse server, it detected that as a "Service Manager Management Server" as well, rather than a "Service Manager Data Warehouse Management Server". They found some other notes about this on the web (see the comments section to Harsh Vardhan Verma's post announcing Service Manager 2016 at https://blogs.technet.microsoft.com/servicemanager/2016/10/25/service-manager-now-available-in-system-center-2016/). After running a number of tests to confirm that the data warehouse server was functioning properly, and trying some thoughts shared by Harsh, the problem persisted.

As a test, we ran the setup program against the production data warehouse server - as expected, setup detected that it was running against a "Service Manager Data Warehouse Management Server". Now we had a way to compare good to bad to locate the cause of the issue.

Using the SysInternals Process Monitor utility, we collected a log of file and registry accesses by setup.exe on the production data warehouse server. In the SCSMSetupWizard log, we could see that the time logged for the detection of the "Service Manager Data Warehouse Management Server" server. Filtering the ProcMon log on the PID for setup.exe, we zeroed in on the detection time logged in the SCSMSetupWizard log. We could see that setup completed the following steps before recording the Data Warehouse detection to the SCSMSetupWizard log:

  • It first checked HKCR/Installer/Features/763325B7B0636BE4E94D2D368761DDF0 for the string value SMDW.
  • It then checked HKLM/Software/Microsoft/Windows/CurrentVersion/Installer/UserData/S-1-5-18/Products/763325B7B0636BE4E94D2D368761DDF0/Features for the string value SMDW.
  • Finally, it checked HKLM/Software/Microsoft/Windows/CurrentVersion/Installer/UserData/S-1-5-18/Components/ to evaluate a long list of keys.

Running Process Monitor on the lab data warehouse server, and using the time recorded for "Service Manager Management Server" detection in the SCSMSetupWizard log, we found the same series of steps:

  • It first checked HKCR/Installer/Features/763325B7B0636BE4E94D2D368761DDF0 for the string value SMDW.
  • It then checked HKLM/Software/Microsoft/Windows/CurrentVersion/Installer/UserData/S-1-5-18/Products/763325B7B0636BE4E94D2D368761DDF0/Features for the string value SMDW.
  • Finally, it checked HKLM/Software/Microsoft/Windows/CurrentVersion/Installer/UserData/S-1-5-18/Components/ to evaluate a list of keys.

HOWEVER, on the lab data warehouse server improperly detected as a "Service Manager Management Server", the list of components checked was much shorter - maybe half as many component values were checked on the lab server than on the production server.

On the lab data warehouse server, in the procmon log we found that component checking stopped after setup looked for the key HKLM/Software/Microsoft/Windows/CurrentVersion/Installer/UserData/S-1-5-18/Components/C136289094C3BF843A93EE1FF3BA42B5 and returned a result "NAME NOT FOUND". At that point setup seems to determine that this must be a "Service Manager Management Server" rather than a "Service Manager Data Warehouse Management Server" server.

On the production data warehouse server, setup found this key and continued checking the rest of the components, eventually determining that it was going to upgrade a data warehouse server. On the production server, HKLM/Software/Microsoft/Windows/CurrentVersion/Installer/UserData/S-1-5-18/Components/C136289094C3BF843A93EE1FF3BA42B5 contained the following value:

763325B7B0636BE4E94D2D368761DDF0 REG_SZ 22:\SOFTWARE\Microsoft\System Center\2010\Common\Reporting\Server

On both these servers, we checked HKLM\SOFTWARE\Microsoft\System Center\2010\Common\Reporting\Server and verified that each server pointed to the correct reporting server configured for that environment (as expected, since reporting services works properly in each environment). In each case, the reporting server was hosted on a system separate from the Service Manager systems. So the only delta between a data warehouse server properly detected by Service Manager 2016 setup and a data warehouse not detected by setup appeared to be the presence of this key.

On the lab data warehouse server, we created the key HKLM/Software/Microsoft/Windows/CurrentVersion/Installer/UserData/S-1-5-18/Components/C136289094C3BF843A93EE1FF3BA42B5. We then created the string value 763325B7B0636BE4E94D2D368761DDF0 under that key, setting it to "22:\SOFTWARE\Microsoft\System Center\2010\Common\Reporting\Server" (without the quotes).

We re-ran Service Manager 2016 setup, and now the server was properly detected as the data warehouse server.