The other caveat is all about retyping the usernames AND passwords for the SCOM accounts defined in the SCOM Console as described in the same TechNet article:
I did this a THOUSAND times but was bugged by the annoying EventID 29120, Source OpsMgr Management Configuration, with this information (a part of it): ‘…OpsMgr Management Configuration Service failed to process configuration request (Xml configuration file or management pack request) due to the following exception: Microsoft.EnterpriseManagement.ManagementConfiguration.Interop.HealthServicePublicKeyNotRegisteredException: Padding is invalid and cannot be removed…’
It has taken me HOURS to crack it since I couldn’t find the culprit. Had the help of Kevin Holman who pointed out to me that the problem was in the accounts as found in the Console. But those accounts I already checked and the ones using certificates (binary authentication) were removed by me.
And still, this MG didn’t move at all since EventID 29120 was stopping it!
After a long search I found it: there was also a UNIX/Linux account. And when I removed that one (it wasn’t used anymore) things started to get moving again .
So whenever you are recovering from a disaster with your SCOM 2012 x MG, and rebuilt yourself a new MS connecting to the old SQL databases, don’t forget those accounts, also the UNIX/Linux accounts.
Either retype ALL the credentials (USERNAME & password) or remove them like the accounts using certificates. Of course, later on you have to restore them but soon you’ll find yourself in good order!
1 comment:
Thanks this was very helpful.
Post a Comment