Often after updates of SCOM 2012 / 2012 R2 or after a clean install people go to the SCOM Web Console and they get the following notification:
Web Console Configuration Required.
A user can click the configure button and run the executable and refresh the browser window and you should see a web console login page next.
Strange thing is that I would have sworn that I wrote a blog post about this last year, but I really can not find it online.
There are two reasons why I am writing a post about this.
- Some users do not have rights to run this executable on their desktop
- The occasional Windows XP user
In my case I ran into both cases last year and currently am in the situation where there is a VDI solution and users do not have rights to run this executable on their desktop and if they did it would be the same error every time they login.
So the easiest way is to figure out what this executable is doing in the first place and next apply it to those machines through another method.
The reason why you can have this more often after upgrades is that there are portions of the code behind this web console which are signed with a code signing certificate from Microsoft. This certificate is valid for a year or a bit longer. After a few Update Rollups suddenly the code signing certificate they used got changed and now when you go to the web console it gives you that Configuration task to do. In my case this happened while applying SCOM 2012 R2 UR3.
What the executable is doing is adjusting some rights for the Silverlight stuff (it sets this entry to true for both 32 and 64 bit for Silverlight: AllowElevatedTrustAppsInBrowser) and importing a code signing certificate in the Trusted Publisher store. All these actions can actually be replicated through the registry, so we are in luck. The rights things are still the same and only the part of the certificate changes. Well, because it’s a new certificate again :p
I will provide a registry code below. There is one portion where the certificate is defined and that is the thing that needs to get changed according to your situation. Basically this is the same for everybody using the same version and rollup level of their SCOM installation.
Alright, here we go:
On a desktop where you do have full rights, go to the SCOM web console and run the configuration tool. Refresh your browser window and go to the same website and you should end up at a login page now.
Open up an MMC, add the Certificates Snapin and select Local Computer.
Go to the Trusted Publishers – Certificates folder. Find the Code signing certificate. The above pictures shows you two of them. One with validity until April 2014 and one with validity until July 2015. In my case I was first using the other one and after upgrading SCOM to a new Update Rollup level. And now the other one got added. So open up the properties of that certificate:
Now in the details tab find the Thumbprint entry. We need that string. You can also keep this open and compare it to what you are seeing in the registry next.
Open up the registry with regedit:
Go to:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftSystemCertificatesTrustedPublisherCertificates
Next find the folder with the same string as the Thumbprint of the certificate you were looking at. In my case there are only 8 folders or something like that, so it was easy to find the correct one. I have it selected here in my case.
Now right-click that specific folder (Key) and export it to a .reg file on your machine. Open up that reg file with Notepad.
What we are looking for is the part where it lists where the Key (folder) is located and that long blob entry. In my case it looks like this:
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftSystemCertificatesTrustedPublisherCertificates67B1757863E3EFF760EA9EBB02849AF07D3A8080]
“Blob”=hex:18,00,00,00,01,00,00,00,10,00,00,00,fe,24,f2,ea,00,13,0a,30,ca,fa,
and so on and so on.
Take that line and the whole blob entry and paste it into the reg file below in the place of where my entry is for the same. Save it. If you happen to have the same version of SCOM (SCOM 2012 R2 UR3) you might not need to do it, but it is a good check to see if this is in fact the correct certificate loaded (check the Thumbprint of your certificate with the name of the key in my reg file below).
Try to import it into a second workstation where you have not run that configuration tool from the SCOM Web Console. Import the reg file. Next open up Internet Explorer and go to the SCOM Web Console site and see if you get the prompt to run the configurator or if you immediately get transferred to the login prompt. If you see the login prompt it has worked.
Now here is the attached txt file. Rename it to a .reg file.
om2012r2ur3webconsolefix.txt
Update 30 March 2015:
- The same reg keys still work for SCOM 2012 R2 UR4 and UR5. I expect UR6 to bring a new code signing certificate in which case the certificate blob would change.
- As indicated there are two locations where you can set the Silverlight permissions:
HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftSilverlight
HKEY_LOCAL_MACHINESOFTWAREMicrosoftSilverlight
However we recently found there might be an override key in place in the same two locations which might still prevent this from working if this is set to zero. It is the entry: AllowLaunchOfElevatedTrustApps
So if you see that one in the same locations as where you want to add AllowElevatedTrustAppsInBrowser than make sure they have the value 1.
Update 31 August 2015:
- SCOM 2012 R2 with UR7 finally came with an updates code signing certificate. A bit too late as the previous certificate had expired 3 weeks before release of UR7. The good thing is this new certificate will carry us to September 2016 again. Will link a tekst file for UR7 version below
Good luck and enjoy!
Bob Cornelissen