We return to our OpsMgr by Example series with a discussion of deploying the OpsMgr Agent.

Scenario: If you're looking for an automated way to provision new systems into management and monitoring solutions without human intervention, you will want to consider using Configuration Manager 2007 for deploying the agent, combined with AD Integration to identify the management server.

We begin the process with required changes for Active Directory.

Active Directory

By default, all new computers added to Active Directory are placed in the Computers container. We will be changing this as we need to define a group policy to deactivate the firewall on systems so the ConfigMgr client can be pushed out to those systems. Since Active Directory does not allow applying a group policy to the Computers container, we will change the default location for new systems added to Active Directory.

We created a new Build OU structure, applied a GPO to remove the firewall policy, and then changed the default location where new computers were added to the domain.

Defining the Build OU: We started by creating a top-level OU structure called Build.

GPO to remove the firewall policy: We next defined a group policy that disabled the firewall and linked it to the new OU structure (Build) as shown below:

Setting the default computers location: To change the default location for computer objects, use the redircmp command (sample syntax for this command is redircmp ou=build,dc=contoso,dc=com).

Once the computers complete their ConfigMgr and OpsMgr agent deployment, they can be moved to their final OU location. Our next step is configuring ConfigMgr agent deployment.

Configuration Manager 2007

On the Configuration Manager side, automated agent deployment is pretty straight-forward. We need to configure discovery, agent deployment, and site mode settings within Configuration Manager 2007.

ConfigMgr Discovery: Discovery is used to discover new systems. Active Directory System Discovery is configured to run daily at midnight for all domains in our ConfigMgr environment.

ConfigMgr Agent Deployment: Agents will be deployed using the Client Push Installation method for servers, workstations, domain controllers and site systems.

ConfigMgr Site Mode Configuration: We need ConfigMgr to automatically approve all computers in trusted domains. If computers will be managed outside of the trusted domains, the only method to automate the process is to check the Automatically approve all computers option (not recommended) option - which we do not recommend. Configure the setting on the Properties of the site on the Site Mode tab:

After deploying Configuration Manager agents to the systems previously discovered, we can use collections to gather up the targets to which to distribute the OpsMgr Agent. We will also create the required packages and advertisements.

OpsMgr Package Creation: To effectively target the correct version of the Operations Manager 2007 agent we created three different packages (AMD64, I386, IA64) as displayed here.

The per-system unattended program for each package is configured on the Requirements tab for each program to only allow the program to be run on specific client platforms (as an example, the I386 package is restricted to only run on I386 systems).

OpsMgr Exclusion Collection #1: The Operations Manager agent is not designed to be pushed to Operations Manager servers. To avoid this issue, we created a collection including all the OpsMgr servers, based upon the naming convention in place. For this particular environment, all OpsMgr servers were labeled with OMRM (Operations Manager RMS), OMMS (Operations Manager Management Server), and OMGW (Operations Manager Gateway Server). We defined the collection to update on an hourly basis. The syntax for this collection follows:

select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from SMS_R_System where SMS_R_System.Name like "%OMRM%" or SMS_R_System.Name like "%OMMS%" or SMS_R_System.Name like "%OMGW%" order by SMS_R_System.Name

OpsMgr Exclusion Collection #2: The Operations Manager agent is not designed to be deployed to domain controllers from ConfigMgr, as AD Integration does not work on domain controllers. To work around this, we created a collection that included all the Domain Controllers based on the role of the server. The collection was defined to update on an hourly basis. The syntax for this collection follows:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_COMPUTER_SYSTEM.Roles like "%Domain_Controller%" order by SMS_R_System.Name

OpsMgr Top-Level Collection: To determine which systems need the OpsMgr agent deployed, we created a top level collection (OpsMgr Client Deployment) designed to include all servers in a specific set of domains that are not domain controllers or OpsMgr servers. This collection was defined to update on an hourly basis. The query is designed to only choose those systems that are Configuration Manager clients, in the appropriate domain, and use a server-level operating system. The last two sections of the next query remove the members of both OpsMgr Exclusion collections that were previously defined.

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.Client = 1 and SMS_R_System.ResourceDomainORWorkgroup in ("domain1","domain2","domain3") and SMS_R_System.OperatingSystemNameandVersion like "%Server%" and SMS_R_System.ResourceId not in (Select ResourceID from SMS_FullCollectionMembership where CollectionID="XYZ0003E") and SMS_R_System.ResourceId not in (Select ResourceID from SMS_FullCollectionMembership where CollectionID="XYZ0003D")

OpsMgr Sub-Collections: Under the top level collection, we created one sub-collection for each of the different types of OpsMgr agent packages that we designed, displayed here: 

Each sub-collections is defined based upon the type of the computer system. As an example, the AMD64 collection used the following:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_COMPUTER_SYSTEM.SystemType = "x64-based PC"

Advertisements: Now that we have all the other required pieces, we create an advertisement for each package we created to push to their appropriate sub-collection, as displayed:

We defined the advertisements and then assigned them to their appropriate sub-collection. As an example, the Per-system unattended to AMD64 was assigned to the AMD64 sub-collection under the OpsMgr Client Deployment collection.

Operations Manager 2007

Next, to push the Operations Manager 2007 agent out to the appropriate systems, we need to configure AD Integration and set auto-approval for agent installations. 

AD Integration: Using AD Integration, information is stored in Active Directory specifying the management group in which to add an agent. There are some excellent articles available on configuring configure AD Integration. We recommend either System Center Operations Manager 2007 Unleashed, or the guide available at System Center Forum (http://www.systemcenterforum.org/downloads/active-directory-integration-in-ops-mgrs-2007).

Auto-approve within OpsMgr: Once AD Integration is in place, we need to tell OpsMgr that it needs to automatically approve manually installed agents, since a ConfigMgr-installed OpsMgr agent is treated as a manually installed agent. The configuration is shown below as part of settings in the Administration node of the OpsMgr console:

In configuring OpsMgr to use AD Integration and manually installing agents auto-approved for agent deployment, we have completed the OpsMgr piece of this configuration. Now let's see how it all comes together!

Auto-Deployment Example:

Let's say a system was added to one of the new domains at the end of day Monday and discovery started the next morning. The deployment process would look similar to the following:

12:29 am: Active Directory System Discovery occurs within the new domain, and the new computer system is found.

12:31 am: ConfigMgr agent installation started.

12:39 am: ConfigMgr agent reporting in.

12:47 am: New server appears in the top-level OpsMgr Client Deployment collection.

12:53 am: New server appears in the I386 sub-collection.

1:48 am: OpsMgr software installed on the new server.

2:00 am: New server reporting into OpsMgr correctly.

Summary

By combining multiple technologies such as Active Directory, Group Policies, ConfigMgr, AD Integration, and OpsMgr, we can provide a fully automated method for deploying both the ConfigMgr and OpsMgr agents, greatly simplifying the process of managing and monitoring servers.

Andy Dominey, of System Center Operations Manager 2007 Unleashed fame and a contributor to this blog, has completed a white paper on best practices and considerations for designing a highly available OpsMgr 2007 infrastructure. Andy has quite a bit of experience in this area, and working with Microsoft, has come up with some unique approaches.

The paper is available at http://www.it-jedi.net/downloads/Deploy_OpsMgr%20in%20HA_EntEnv-ADEd_v1.0.pdf and discussed at http://www.systemcenterforum.org/news/deploying-opsmgr-in-highly-available-and-distributed-enterprise-environments-download/. Happy reading!

It was only at the end of August 2008 that this blog crossed the 200,000 hit mark (see http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!772.entry). Today we are very excited to report we have over 250,000 page views to date.

Thank you once again to everyone who has contributed to the blog via articles, comments, or questions, and sent words of encouragement and thanks.

- Kerrie, Cameron, John, and Andy   12/09/08

Version 6.0.6441.0 of SQL Server Management pack, which includes support for monitoring SQL Server 2008 databases, was released to Microsoft's Management Pack catalog October 29th of this year. It has since been discovered that the discovery scripts fail to discover SQL Servers with databases larger than 32 GB in size. Not only that, once the discovery fails no new discovery will occur. (Discovery worked fine in earlier versions of the management pack.)

A fix has been written for this and tested, but due to delays in getting it posted to the Management Pack catalog, the MOM Team is making the download available from their blog (http://blogs.technet.com/momteam). Once the updated management pack is available on the catalog (http://technet.microsoft.com/en-us/opsmgr/cc539535.aspx), it will be removed from the MOM Team blog.

If you need the fixed management pack immediately, you can download it now from http://blogs.technet.com/momteam/archive/2008/11/13/the-database-discovery-scripts-discoversql200-db-vbs-fail-on-sql-servers-with-dbs-larger-than-32gb-in-the-6-0-6441-0-version-of-the-sql-mp.aspx.

We've been asked by several (see http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!858.entry) about how to use watcher nodes to run synthetic transactions created withVBScript. Here's an approach:

1. Create a group, add the watcher node(s) to the group and target the monitor to the group. Note that if you need to add this to a distributed application, it is best to create a custom class in the Authoring console.
2. Next, configure your script to run on the watcher node and as for the script/monitor, you most likely will need to use a probe rule to run the script.

If you are using a monitor, the script would also have to do something like log to the event log - with a monitor configured to look for these events for its state change.

This can entail a bit of work up front, but a lot of the stuff such as the class object could be reused.

As far as using the Perspective class (asked by some) - that's probably not a good approach. It isn’t really possible to make a web request appear as a member of the Perspective class; when you create a web transaction using the wizard, it goes off and creates a ton of rules/monitors and classes in the background which would be difficult if not impossible to reproduce outside of the wizard.

Hope this helps!

Please note that these are perspectives of the coauthors and contributors of System Center Operations Manager 2007 Unleashed.