Scenario – imagine a quick hit on Delete button while standing on BUILTIN\Administrators entry in Operations Manager Administrators user role window. What happens few hours later? If this was a default setting and no-one was later added to OM Admins group – oh well – no-one is an administrator. That happens. There should be a fix.
NOTE – You can delete BUILTIN\Administrators only, if you added second entry as a member. You can’t be left without any group there (through console of course).
NOTE 2 – To this group you can add only domain groups, not local, so BUILTIN\Administrators are unable to be added.
Step 1 – Go to your favourite search engine and look for the topic above. You will be redirected to TechNet page – http://technet.microsoft.com/en-us/library/hh456441.aspx
Step 2 – You go step-by-step through the guide. You go to paragraph 2, point 2. You go into <drive letter>:\Program Files\System Center Operations Manager 2012\SDK Service State… wait a minute. There no such folder! Default path is <drive letter>:\Program Files\System Center 2012\Operations Manager\Server and even there there is no momauth.xml file. You hit search – it has to be somewhere – and you are punished by your naivety…
Just to be clear – as per Mihai Sarbulescu blog and post on missing Built-In User Roles, the MomAuth.xml is not there anymore.
NOTE: In OM 2007 the user roles and their permissions, roles, etc. were managed through Authorization Manager which is an OS component and the data was stored in an XML file called MomAuth.xml which could be found on the RMS. Now, in OM 2012, this has been changed and AzMan is no longer used – the user roles and security checks, permissionsm information, etc. about the OM Management Group is stored and checked directly in the OM operational database.
Now what? Now let’s go into SQL Server Management Studio and let’s play a bit. There are few new tables there which gives you an idea how the authorization works in OM12 and where to find specific data.
If you are familiar with AzMan and you created a totally custom user role, you now need to familiarize with those most important tables.
AzMan_AzOperation – list of all operations, which can be scoped (i.e. Agent__Deploy, Agent__Get, Agent__Set etc.)
AzMan_AzRoleAssignment – connects User Roles to AzMan profiles
AzMan_AzTask – list of User Roles with their descriptions
AzMan_Role_SIDMember – list of SIDs (stored in DB as varbinary(85) connected to Roles
And the last one is what we want. When you have a deleted an account from OM Admins you will have a table like this (fresh install, in your environment there can be lots of them)
Well, there is something here, so why I don’t see it in console? Because the first one is a default entry for LocalSystem, which is always an OM Admin member, but hidden from list. So how can we add a member here? Well, that’s a bit nasty, but just creating a simple INSERT. But what to insert? A varbinary value for BUILTIN\Administrators is:
So just copy the SQL query from below to your Query Window:
INSERT INTO [OperationsManager].[dbo].[AzMan_Role_SIDMember]
Now re-run the SELECT query.
And let’s check the console too.
OH NO! Aaaah, wait, let’s use /clearcache
Hope this will help anyone when falling into trouble of need to recreate Operations Manager Administration User Role.
DISCLAIMER: THIS SOLUTION IS PROVIDED "AS IS". YOU ARE RUNNING IN ON YOUR OWN RISK AS THIS IS NOT MICROSOFT’S SUPPORTED SOLUTION AT THE DATE OF POSTING.