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.
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!
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.
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.