In the low privelige scenario for the ADMP you are asked to create an account that has the “standard” low rights and then another one for the replication monitoring.  The problem is that the default action account on the DC’s cannot run the scripts which test the FSMO role binding in a low priv environment. 

The scripts which fail use a COM object which performs a ping method.  This method simply fails unless the user is local admin priv’s.

Latest I had from Microsoft is that this would be a hotfix but would be released after SP1 as it won’t make the SP1 timeframe.

Although going into DR is rare, DR test days are very common and this leaves the possibility that you could be running an environment in a clustered setup, go into a DR test day and then find it difficult to get back.

The piece that is “missing” is there there is no way to promote back to a clustered RMS – the code simply isnt there.

After pressing Microsoft about this they have released a document which tells you how to fail back but in all honesty its pretty much a rebuild – you restore the DB, restore the RMS keys and run a few SQL commands.  They will be producing a more structured failback in the SP1 timeframe but this is still a while away.

Until then however, this is all you can do…  http://blogs.technet.com/momteam/archive/2007/07/24/disaster-recovery-opsmgr-2007-root-management-server-on-a-cluster.aspx

First up the powershell, this is pretty well known but you can dump all your rules using this line:

Get-ManagementPack -Name “Microsoft.SystemCenter.2007″ | Export-ManagementPack -Path “C:\”

 this leaves you with an XML file but to make sense of this I find it easier to open it in excel and use the “use xml source task pane” option when you open it.  This gives you all the schema down the right hand side (see the picture “The Excel Spreadsheet”). 

You can now just drag and drop the fields onto excel and then right click and choose to “refresh xml data” and it populates the column”.  You have to know what you are looking for but some experiementation gets you there.

In my case I was after all rules that result in a critical alert being raised.  To find this I used the Rules part of the XML schema and was interested in any rules that had a “Write Action” with Severity 1 which meant they raised critical alerts.  By dragging the ID column of write action and the “Severity” column of write action I was able to get the alert name that would be raised and could sort by severity.  If I had added the Rule “ID” column that would have given me the rule name as well though these two fields are commonly the same.

The only other thing I wondered Jakub helped me with.  If you are forwarding your alerting to an upstream environment then what about state changes ?  It’s alright having alerts as they are documentable but how do you “document” state changes to an upstream monitoring system.  This is where Jakub helped me out, here’s the thread, but read it from the bottom up because its a dump of replies in the newsgroups:

The short answer is nothing.

–
Jakub Oleksy
Developer
Blog: http://blogs.msdn.com/jakuboleksy/
Log a bug or Feature Request directly to the SCOM Product Team by going to
http://connect.microsoft.com/site/sitehome.aspx?SiteID=209. This posting is
provided “AS IS” with
no warranties, and confers no rights.

“Mike Betts” <mike@nospam.com> wrote in message
news:79CDF7C8-4F0A-4E04-9D61-3639A9440EAA@microsoft.com…
> Thanks Jakub,
>
> That leads me neatly onto the crux of where the question leads…  I have
> successfully looked at the xml output and using Excel no less produced
> something that lists rules if the write action generates a critical error
> which is great but (and this is a very general question).. MOM only
> generates alerts for some things now, whereas many are done by health
> state via monitors which often do not generate an alert (I think, correct
> me if im wrong).  When it comes to both documenting the “severity” of
> monitors and also exposing this to a parent monitoring system for the
> building of a connector what do health state changes “appear” as to a
> parent monitor if you see what I mean.  By example, take the SDK connector
> example on MSDN – it picks up alert objects and forwards them but how does
> it detect state changes and what does it send upstream if a state change
> occurs but no alert is raised on the back of the monitor.
>
> Where Im coming from is that the parent monitoring team are asking for a
> list of alerts and their severity both from a documentation perspective
> and also with a view to the upcoming connector we will build, but how do I
> present from an object sense the idea of a health state change because it
> is “critical” but it isnt an “alert” so what should they look for or
> expect to receive upon this occurring in MOM at the parent monitor level.
>
> Apologies if my question is a bit foggy, I am using general terms because
> state is something that is easy to explain within windows but I dont see
> how you can “convert” it into the id-alert-severity approach the
> traditional monitoring systems are used to.
>
> Thanks
>
> Mike
>
> “Jakub Oleksy [MSFT]” <jakub.oleksy@online.microsoft.com> wrote in message
> news:O4StlQjwHHA.2004@TK2MSFTNGP06.phx.gbl…
>> Are you concerned only with rules that produce alerts, or is there some
>> heuristic you use for all rules?
>>
>> For alert-based rules, the first thing you need to do is figure out if
>> the rule is an alert based rule. You do this by looking at the write
>> action module of the rule (either from exported xml, UI or SDK). In the
>> configuration of the module, the severity of the generated alert should
>> be present.
>>
>> Monitors can also generate alerts, but their alert generation is built
>> into the schema of the monitor itself, rather than generic module
>> configuration.
>>
>> Let me know if you have further questions or need some specifics.
>>
>> –
>> Jakub Oleksy
>> Developer
>> Blog: http://blogs.msdn.com/jakuboleksy/
>> Log a bug or Feature Request directly to the SCOM Product Team by going
>> to
>> http://connect.microsoft.com/site/sitehome.aspx?SiteID=209. This posting
>> is
>> provided “AS IS” with
>> no warranties, and confers no rights.
>>
>> “Mike Betts” <mike@nospam.com> wrote in message
>> news:9458AC34-186D-4498-94AA-9ACF033A6421@microsoft.com…
>>> Hi this is just a new spin on an old question:  I need to document all
>>> rules in each MP with their severity.  So for example I need to list all
>>> rules that will raise severity critical in the windows 2003 OS MP.  I am
>>> aware I can dump sealed MP’s to xml using PS but this does not (as far
>>> as I can tell) give me this information.  Is there any way to report or
>>> retreieve this information ?
>>>
>>> Thanks
>>>
>>> Mike
>>>
>>
>

A number of things need doing from the command line or can be programmed.  On the SDK documentation there is an article on how to approve manual agents using C# but this can be done from the PowerShell command line as well.

When MOM is installed go to the PowerShell command line.  You need to make sure it has connected to the Monitoring namespace, which can be seen by the format

PS Monitoring\

Then make sure you have a connection to your Management Group.  To do this type:

New-ManagementGroupConnection [RMS Name]

This then changes the prompt to:

PS Monitoring:\[RMSName]

and also prints out some summary info.  You can dig around your MG infrastructure using get-childitem from here if you want.

Now you can start playing around.  There are a million and one things you can do so I’m just going to list them in seperate posts.  Here we are going to list pending agents and then approve them.

To list pending agents type:

get-agentpendingaction

and it will list any pending agents.

Then to approve them type

get-agentpendingaction | where {._agentname -like ‘MyAgentName’} | approve-agentpendingaction

make sure its all on one line.  MyAgentName should be replaced with your agent.  Wildcards are allowed.

Now you can check by typing

get-agent | where {_.name -like ‘sms0001*’}

cool!

Each physical node has to have “Agent Proxy” enabled (in the administration tab -> Agent managed)In case this was not set, restart the agent on each cluster node. The discovery reruns. Check now that each virtual node comes in under “agentless” managed. (in the discovered inventory it will show as “not monitored” which is ok)Now check under Windows Server (state view). Each virtual server has to be discovered. Check the properties, it has to say “Is Virtual Node” true. Now the SQL 2005 should work as well. Check the SQL state views (this may take a moment if the Virtual node was not discovered previously – again you can restart the agent on the cluster node where the SQL is currently active)

Here is a Step-by-step guide on exactly what to do.

1. Open System Center Operations Manager Operator Console.
2. Open the Administration view, and select Agent Managed under Device Management.
3. Right-Click on the Cluster Nodes and select Properties.
4. In the security tab tick the box that says Allow this agent to act as a proxy and discover managed objects on other computers.
5. Click OK.
6. On the Cluster Nodes restart the OpsMgr Health Service. (The Discovery will re-run)
7. Open the Administration view, and select Agentless Managed under Device Management.
8. You should see all the Cluster Virtual Servers.
9. Open the Monitoring view, and select Discovered Inventory. It will show “not monitored” this is expected.
10. Select Windows Server State under Microsoft Windows Server. (You should see the Cluster Object listed with their IP address).
11. Right-Click the Cluster Virtual Servers select Properties.
12. Check that the line saying “Is Virtual Node” is True (The SQL 2005 MP should work now)
13. Select Database State under Microsoft SQL Server\Databases. (This may take a moment if the Virtual Servers were not previously discovered. You can re-start the OpsMgr Health Service where SQL is currently active to rescan).

HKLM\System\CCS\Services\HealthService\Parameters\ConnectorManager\EnableADIntegration

0 is off

1 is on.

You can look at this if you get the 2017 error in the OpsMan event log

So far from self experimentation it seems that two things will be required, firstly you need to remove the AD components from the Directory. This can be done with

MOMADAdmin.exe -d <mgname> <domainname>

But this still leaves your agents with AD enabled on them.  This is controlled by a reg key,

HKLM\System\CCS\Services\HealthService\Parameters\ConnectorManager\EnableADIntegrationso if you move this to 0 it switches it off.  You would need to do this to all your agents still outstanding.

Could not start the OpsMgr Health Service on Local Computer. Error 0x80ff0043

I found that in the HKLM\CCS\Services\HealthService\Parameters\Management Groups

registry location the information for the MG the agent was meant to be a member of had disappeared.  By running agent.msi and repairing the agent this also failed.  But then I re-ran the agent.msi but chose “modify” from the options, put the missing details in and then the information was repopulated and the agent could be restarted successfully.

The HSLockDown.exe utility is in the MOM 2007 folder on all agents (System Center Operations Manager 2007 folder) and the syntax is

HSLockdown.exe /switch MGName Group

where switch is to add, remove, list the accounts etc and MGName is the Management Group Name, and Group is the NT group you are adding or removing. 

You will see that the NT Authority\System is disallowed by default on these systems.  You need to enable is by using HSLockDown.exe with the /A (for Add) switch to enable it.  then your monitoirng should resume correctly.

This isnt a bug as how could a manual install know the DC MP is installed when it hasnt yet authenticated with the Management Server but it is worth knowing as you will have to get this down to the agent somehow and run it for the ADMP to work successfully