OpsManager Agent Installation Methods & AD Integration

 

Hi, in this post I will try and clarify some of the issues surrounding agent deployment with OpsManager, plus how your agent deployment method is related to AD integration.

Firstly, lets look at how we can deploy the agent.  This is one of the decisions that must be made at the design stage, you don’t want to be deciding this during the implementation phase!

So here they are:

1. ‘Push’ using the discovery wizard in the Operations Console
2. Manually, by running MOMAgent.msi
3. Using a software delivery mechanism such as Configuration Manager

(there are others, but you get the idea)

Next, lets talk about AD integration…

AD integration is a method of storing agent configuration in the Active Directory.  This means that agents will know which management groups to talk to, and also know their primary and failover management servers.  The configuration is updated regularly, so using AD integration means that you have a central place to manage (nearly) all your agent configuraiton.

A few points though:

• AD integration does not install the agent.  You must do this another way.
• AD integration does not work on Domain Controllers, agents in a DMZ or those behind a gateway server.  We must resort to PowerShell again here.
• You should implement AD integration in every domain in the forest and every domain in a trusted forest.

So now that we’ve established the basics, lets look at the agent deployment methods:

 

Push – Discovery Wizard

This option is the often perceived as the simplest way of getting the client out there.  There are, however, some things that must be considered:

Firstly, firewall ports must be open on the agent managed machines to allow RPC and WMI access.  This makes push a less attractive option when dealing with DMZ machines or those behind network firewalls.

Secondly, you must have an account with which to install the agent.  This must be a local admin on the computers that you wish to manage,

Thirdly – and this is the biggest problem for me…

Deploying the agent using the discovery wizard will disable AD integration for that agent (for that particular management group)

This means that agent failover for agents deployed using the discovery wizard must be managed using PowerShell.  To prevent the configuration drifting, I recommend scheduling a suitable PowerShell script to run on a regular basis.

Why MS chose to do things this was is baffling to me.  It’s also not talked about that much in the docs, therefore it can be confusing.

Manual Installation

This has obvious scale limitations but may be your only option.  AD integration is possible.

 

Deployment using Configuration Manager

I prefer this method.  Of course you do have to have ConfigMgr installed :)   It’s a great way of getting the agent out there and then having a reliable method of patching and maintaining the agents.  It’s easy to set up a query based collection to automatically deploy the agent to the correct computers.  There is no further configuration required because this would typically be combined with AD integration.

 

Conclusion

As you may have gathered, I like AD integration.  It’s such a shame that Microsoft make it incompatible with the discovery wizard.

Here is a list of MSI parameters to use when you want to silently install the agent:

http://blogs.technet.com/momteam/archive/2009/07/08/windows-agent-install-msi-use-cases-and-commands.aspx

Interested in desktop virtualisation?

 

Microsoft are running a “moderated televised discussion” - whatever that is – on desktop virtualisation.

This is a hot topic at the moment.  It’s also a complex one, with many permutations.

The date and time of the event is: March 18th @ 9AM PST

http://blogs.technet.com/systemcenter/archive/2010/03/03/upcoming-event-microsoft-desktop-virtualization-hour-march-18-9-00-am-pst.aspx

Using SCCM to start (and stop) maintenance mode for software updates

Hello,
If you have been reading any of my previous posts, you may know that I have been writing a web service for Operations Manager.  I thought that I’d share one of the uses for this web service that provides an easy way of integrating Configuration Manager and Operations Manager.

[Download the web service here ]

Background

Say you are patching your servers with SCCM, you are also monitoring them with SCOM.  Being a fan of the System Center suite, you like automation and process :)
You also have installed the web service that I have been working on.  Available here.

SCCM Configuration

Once the web service is set up, all the configuration is performed within the SCCM console.
First, a new package is created for the web service client.  This contains the command line client and the config file (this tells the .exe the URL of the web service).
Now, two programs are created:

1. Start maintenance mode - 4 hours
2. Stop maintenance mode

Each program references the same .exe, but has different parameters.  So that the commands will work on any computer, I use the %COMPUTERNAME% variable in the command line.


Next, I create the task sequence that will tie all this together:

You can see that the task sequence will start MM, then install the updates, reboot the computer and then finally remove the computer from MM.
This task sequence is then advertised to all servers with a reoccurring mandatory schedule that repeats once a month.
To control the rollout, I use maintenance windows:

The servers are placed into these collections to allow the updates to be installed on a regular basis.  For example, the “S3 3nd Friday 2200” collections, has a 6 hour maintenance windows that begins on the 2nd Friday of the month at 2200hrs.

Limitations and Constraints

There are a few limitations to this process at the moment, I am working to resolve them but it will take time.  There are also a few constraints that should be known about:

1. Clusters – the process for placing clusters into MM is different.  I need to integrate this into the web service and web service clients.
2. Waiting for the workflows to unload – once an object is placed into MM, a config change is sent to the agent to make it unload all the workflows.  This can take time.  Therefore, the patching process may begin before this happens.  One way round this would be to add another step in the task sequence – something which checks the Operations Manager event log for event ID 1215 and then quits.  Then the process would be awesome :)
3. Maximum run time – Each software update has a maximum run time, each task sequence also has a maximum run time.  This run time MUST be less that the maintenance window, or it won’t run.  So, the max run time of each update must be changed (can be done in bulk).  Also the task sequence maximum run time must be set accordingly.  This is the reason that I use 6 hour maintenance windows, the patching process will not actually take 6 hours.
4. Deployment Management Job – One of these must be created WITH NO DEADLINE.  This is how the task sequence knows which updates to install.  This method does not preclude you from configuring software updates.

Conclusion

Using this method, patching becomes a much easier, with far fewer alerts in the SCOM console combined with a highly automated and efficient process requiring little administrator effort.