Filtered Registry Discovery Provider

AKA: Microsoft.Windows.FilteredRegistryDiscoveryProvider

This is the third post in the new VSAE Fragment category. The provider is used to discover a class type and its properties by reading keys and values from the Windows registry.

What does it do?

This particular fragment can be used to discover the class type discuss here. It demonstrates how to discover different types of properties: Integer, String, and Double (or decimal).

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Monitoring>
<Discoveries>
<Discovery ID="SCOMskills.Demo.FilteredRegistry.Discovery" Target="Windows!Microsoft.Windows.Computer" Remotable="true" Enabled="true">
<Category>Discovery</Category>
<DiscoveryTypes>
<DiscoveryClass TypeID="SCOMskills.Demo.FilteredRegistry.Class">
<Property PropertyID="IntegerProperty"/>
<Property PropertyID="StringProperty"/>
<Property PropertyID="DoubleProperty"/>
<Property TypeID="System!System.Entity" PropertyID="DisplayName"/>
</DiscoveryClass>
</DiscoveryTypes>
<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.FilteredRegistryDiscoveryProvider">
<ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
<RegistryAttributeDefinitions>
<!--===============================================================================-->
<!--Define registry keys, values, and types. -->
<!--Path and attribute types: http://msdn.microsoft.com/en-us/library/jj130492.aspx-->
<!--===============================================================================-->
<RegistryAttributeDefinition>
<AttributeName>SCOMskillsKeyExists</AttributeName>
<Path>SOFTWARE\SCOMskills</Path>
<PathType>0</PathType>
<AttributeType>0</AttributeType>
</RegistryAttributeDefinition>
<RegistryAttributeDefinition>
<AttributeName>IntegerValue</AttributeName>
<Path>SOFTWARE\SCOMskills\Integer</Path>
<PathType>1</PathType>
<!--reg_dword, any integer value-->
<AttributeType>2</AttributeType>
</RegistryAttributeDefinition>
<RegistryAttributeDefinition>
<AttributeName>StringValue</AttributeName>
<Path>SOFTWARE\SCOMskills\String</Path>
<PathType>1</PathType>
<!--reg string-->
<AttributeType>1</AttributeType>
</RegistryAttributeDefinition>
<RegistryAttributeDefinition>
<AttributeName>DoubleValue</AttributeName>
<Path>SOFTWARE\SCOMskills\Double</Path>
<PathType>1</PathType>
<!--reg string, value can be a double or integer-->
<AttributeType>3</AttributeType>
</RegistryAttributeDefinition>
</RegistryAttributeDefinitions>
<Frequency>60</Frequency>
<ClassId>$MPElement[Name="SCOMskills.Demo.FilteredRegistry.Class"]$</ClassId>
<!--========================================-->
<!--Map registry filters to class properties-->
<!--========================================-->
<InstanceSettings>
<Settings>
<Setting>
<Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Name>
<Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>
</Setting>
<Setting>
<Name>$MPElement[Name="SCOMskills.Demo.FilteredRegistry.Class"]/IntegerProperty$</Name>
<Value>$Data/Values/IntegerValue$</Value>
</Setting>
<Setting>
<Name>$MPElement[Name="SCOMskills.Demo.FilteredRegistry.Class"]/StringProperty$</Name>
<Value>$Data/Values/StringValue$</Value>
</Setting>
<Setting>
<Name>$MPElement[Name="SCOMskills.Demo.FilteredRegistry.Class"]/DoubleProperty$</Name>
<Value>$Data/Values/DoubleValue$</Value>
</Setting>
<Setting>
<Name>$MPElement[Name="System!System.Entity"]/DisplayName$</Name>
<Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetbiosComputerName$</Value>
</Setting>
</Settings>
</InstanceSettings>
<!--=========================================================-->
<!--Discover class instance if SCOMskills registry key exists-->
<!--=========================================================-->
<Expression>
<SimpleExpression>
<ValueExpression>
<XPathQuery Type="Boolean">Values/SCOMskillsKeyExists</XPathQuery>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value Type="Boolean">true</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
</DataSource>
</Discovery>
</Discoveries>
</Monitoring>
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<!--============================================================-->
<!--Provide friendly display names for elements in this fragment-->
<!--============================================================-->
<DisplayStrings>
<DisplayString ElementID="SCOMskills.Demo.FilteredRegistry.Discovery">
<Name>Filtered registry class discovery.</Name>
</DisplayString>
<DisplayString ElementID="SCOMskills.Demo.FilteredRegistry.Discovery" SubElementID="DS">
<Name>Filtered registry discovery data source</Name>
</DisplayString>
</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</ManagementPackFragment>

Microsoft Windows Local Application class type

AKA: Microsoft.Windows.LocalApplication

This is the second post in the new VSAE Fragment category. The purpose of these types of posts is to provide a practical demonstration of how to create your own fragment library. I find this useful in management pack authoring, because it’s much easier to add and modify an existing fragment than to create elements and modules from scratch each time.

What does it do?

This may be the most common base classes used for a seed class. It’s easy to implement, because it doesn’t require you to create a hosting relationships. This base class *will* rollup to the windows computer class, as a local application. So, do not choose this as a base if you do not want your application to rollup to windows computer! This is considered a concrete class, and rolls up to windows computer.

Go here for a fragment that will discover this class type using the filtered registry discovery module.

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<TypeDefinitions>
<EntityTypes>
<ClassTypes>
<!--=======================================-->
<!--Define application class and properties-->
<!--=======================================-->
<ClassType ID="SCOMskills.Demo.FilteredRegistry.Class" Abstract="false" Accessibility="Public" Base="Windows!Microsoft.Windows.LocalApplication" Hosted="true" Singleton="false">
<Property ID="IntegerProperty" Key="false" Type="int" />
<Property ID="StringProperty" Key="false" Type="string" />
<Property ID="DoubleProperty" Key="false" Type="double" />
</ClassType>
</ClassTypes>
</EntityTypes>
</TypeDefinitions>
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<!--============================================================-->
<!--Provide friendly display names for elements in this fragment-->
<!--============================================================-->
<DisplayStrings>
<DisplayString ElementID="SCOMskills.Demo.FilteredRegistry.Class">
<Name>SCOMskills Demo Filtered Registry Class</Name>
<Description>Demonstration of Microsoft.Windows.FilteredRegistryDiscoveryProvider</Description>
</DisplayString>
<DisplayString ElementID="SCOMskills.Demo.FilteredRegistry.Class" SubElementID="IntegerProperty">
<Name>Integer Property</Name>
</DisplayString>
<DisplayString ElementID="SCOMskills.Demo.FilteredRegistry.Class" SubElementID="StringProperty">
<Name>String Property</Name>
</DisplayString>
<DisplayString ElementID="SCOMskills.Demo.FilteredRegistry.Class" SubElementID="DoubleProperty">
<Name>Double Property</Name>
</DisplayString>
</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</ManagementPackFragment>

Visual Studio Authoring Extensions – Fragments, fragments, fragments!

All management pack authoring I do is by using fragments. In my opinion, fragments are the most flexible authoring element in the VSAE, as they offer full visibility into the XML code and the ability to create a library of useful fragments that can later be reused in other management packs.

I’m kicking off a new blog category named VSAE Fragment. The purpose of these types of posts is to give practical examples of using modules that are defined in OpsMgr management pack libraries, as well as how to piece together custom modules for composite workflows. MSDN already has a library of module examples here, but sometimes I find myself searching to fill in some blanks. Hopefully this will help others as much as they help me.

I’m starting the VSAE Fragment category by providing the most basic, and essential fragment I use in every new management pack: the mp.DisplayName fragment.

What does it do?

Provides a friendly management pack display name and description in the Operations console.

 

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="SCOMskills.Demo">
          <Name>SCOMskills Demo</Name>
          <Description>A demo management pack.</Description>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

Create a Group of Health Service Watcher Objects Using VSAE

Plenty of bloggers have written about creating groups of health service watcher objects. The purpose of these types of groups is primarily for notification subscriptions. The reason why we need to include Health Service Watcher objects in our subscription criteria is so recipients also receive notifications about Health Service Heartbeat Failures and Computer Not Reachable alerts.

In this post, I will demonstrate how to create these type of groups using the Visual Studio Authoring Extensions.

In this example, I will create a group of health service watcher objects based on membership of another group (the "source" group). How the source group was created does not matter, as our group of Health Service Watcher objects will always be dynamic in nature and match the source group membership.

Before you start, you’ll need to locate the sealed version of the MP that contains the source group. In this case, I’ll reference a built-in group in the Windows Operating System MP: Windows Server 2012 Computer Group. To figure out which MP the group is stored in, you can run the following command in the Operations Manager Command Shell (replace with your group name).

 Get-SCOMGroup -DisplayName 'Windows Server 2012 Computer Group' | Get-SCOMClass | Select ManagementPackName

 

In this example, the group is stored in the Microsoft.Windows.Server.Library.

1. Create a new Operations Manager 2012 Add-On project in Visual Studio, name it Demo.HealthServiceWatcherGroups, and add a reference to the Microsoft.Windows.Server.Library MP (or the MP containing your source group). Also add a reference to the Microsoft.SystemCenter.InstanceGroup.Library MP – you need to reference this for the discovery relationship.

NOTE: I use fragments heavily in MP authoring, and don’t rely on the templates at all. I think it offers much more flexibility and allows me to retain a library of my own fragments that I can reuse later. This MP will consist of three fragments; one for the MP display name, one for the singleton class (group), and one for the group discovery.

 

2. Add a new empty management pack fragment named mp.DisplayName.mpx, paste the following code into it, and save the fragment. This fragment will provide the MP friendly name.

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <
LanguagePacks>

    <
LanguagePack ID="ENU" IsDefault="true">

      <
DisplayStrings>

        <
DisplayString ElementID="Demo.HealthServiceWatcherGroups">

          <
Name>Demo – Health Service Watcher Groups</Name>

          <
Description>This management pack contains groups of Health Service Watcher objects.</Description>

        </
DisplayString>

      </
DisplayStrings>

    </
LanguagePack>

  </
LanguagePacks>

</
ManagementPackFragment>

3. Add a new empty management pack fragment named class.WindowsServer2012HswGroup.mpx, paste the follow code into it, and save the fragment. This fragment provides the group name and establishes the relationship type. Notice this is a singleton class, which is a group in this case. Also note that I am using default aliases that are generated by VSAE. I choose to use default aliases all the time, so I don’t get confused with custom aliases later. My preference is to store display strings in each  fragment, rather than bunching them all into a single fragment, but you might find other methods that work better for you.

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="Demo.HealthServiceWatcherGroups.WindowsServer2012HswGroup" Abstract="false" Accessibility="Public" Base="MSIL!Microsoft.SystemCenter.InstanceGroup" Hosted="false" Singleton="true" />
      </ClassTypes>
      <RelationshipTypes>
        <RelationshipType ID="Demo.HealthServiceWatcherGroups.WindowsServer2012HswGroupContainmentRelationship" Abstract="false" Accessibility="Public" Base="System!System.Containment">
          <Source ID="Demo.HealthServiceWatcherGroups.Source" Type="System!System.Group" />
          <Target ID="Demo.HealthServiceWatcherGroups.Entity" Type="System!System.Entity" />
        </RelationshipType>
      </RelationshipTypes>
    </EntityTypes>
  </TypeDefinitions>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Demo.HealthServiceWatcherGroups.WindowsServer2012HswGroup">
          <Name>Demo - Windows Server 2012 Health Service Watcher Group</Name>
          <Description>Contains Health Service Watcher for all instances in the Windows Server 2012 group.</Description>
        </DisplayString>
        <DisplayString ElementID="Demo.HealthServiceWatcherGroups.WindowsServer2012HswGroupContainmentRelationship">
          <Name>Windows Server 2012 Health Service Watcher Containment Relationships</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

 

4. Add a new empty management pack fragment named dis.WindowsServer2012HswGroup.mpx, paste the following code into it, and save the fragment. This fragment contains the actual discovery. The module performing the group population is specified in the data source. The main elements you need to be concerned with are highlighted; GroupInstanceId is the group (class) to be populated, MonitoringClass indicates what type of objects to populate the group with, and the expression indicates which source class (or group) to match. Also note MonitoringClass is AgentWatcher. This will populate the group with agents only, not other types of health service’s (like management servers or gateways).

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Monitoring>
    <Discoveries>
      <Discovery ID="Demo.HealthServiceWatcherGroups.WindowsServer2012HswGroup.Discovery" ConfirmDelivery="false" Enabled="true" Priority="Normal" Remotable="true" Target="Demo.HealthServiceWatcherGroups.WindowsServer2012HswGroup">
        <Category>Discovery</Category>
        <DiscoveryTypes>
          <DiscoveryRelationship TypeID="MSIL!Microsoft.SystemCenter.InstanceGroupContainsEntities" />
        </DiscoveryTypes>
        <DataSource ID="GroupPop" TypeID="SC!Microsoft.SystemCenter.GroupPopulator">
          <RuleId>$MPElement$</RuleId>
          <GroupInstanceId>$MPElement[Name="Demo.HealthServiceWatcherGroups.WindowsServer2012HswGroup"]$</GroupInstanceId>
          <MembershipRules>
            <MembershipRule>
              <MonitoringClass>$MPElement[Name="SC!Microsoft.SystemCenter.AgentWatcher"]$</MonitoringClass>
              <RelationshipClass>$MPElement[Name="Demo.HealthServiceWatcherGroups.WindowsServer2012HswGroupContainmentRelationship"]$</RelationshipClass>
              <Expression>
                <Contains>
                  <MonitoringClass>$MPElement[Name="SC!Microsoft.SystemCenter.HealthService"]$</MonitoringClass>
                  <Expression>
                    <Contained>
                      <MonitoringClass>$MPElement[Name="MWSL!Microsoft.Windows.Server.6.2.ComputerGroup"]$</MonitoringClass>
                    </Contained>
                  </Expression>
                </Contains>
              </Expression>
            </MembershipRule>
          </MembershipRules>
        </DataSource>
      </Discovery>
    </Discoveries>
  </Monitoring>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Demo.HealthServiceWatcherGroups.WindowsServer2012HswGroup.Discovery">
          <Name>Demo - Windows Server 2012 HSW Group Discovery</Name>
          <Description>Populates Demo - Windows Server 2012 HSW Group</Description>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

 

Sign, seal, and import the MP to see the end result.

 

Source group contains a mix of computer objects – both agents and management servers.

image

 

The new group contains health service watcher instances for agents running on Windows Server 2012.

image

 

I plan to post more on creating groups using the Visual Studio Authoring Extensions in the future, so check back or subscribe to the RSS feed.

If you are still using the R2 Authoring Console, I have those examples posted here.

How to create a computer group in the R2 Authoring Console
How to create an instance group in the R2 Authoring Console
How to create a group of Windows Computers based on a discovered property of virtually any class

Install SCOM Agent on Red Hat Enterprise Linux 6 (linux agent installation)

This is a step-by-step article on installing the SCOM agent on a RHEL6 system, both from an SCOM and Linux administrator perspective. Everything in this demonstration assumes a new installation of RHEL6 with no additional configuration. It is also assumed there are no firewalls between the SCOM management servers and the RHEL system. Windows Firewall is not turned on, and the RHEL system is running with default IPTABLES configuration.

Disclaimer: I do not claim to be an experienced Linux admin. This is intended to familiarize SCOM administrators with the entire process. There may be better practices or methods for configuring Linux – comments are  welcome.

If you do not have an SCOM environment or a RHEL system in your lab, you can download evaluation versions from the links below (these links may be outdated at the time you are reading this).

SCOM 2012 SP1 Evaluation

RHEL 6 Evaluation (download the rhel-server-6.3-x86_64-dvd ISO)

Installing RHEL6 on Hyper-V step-by-step

Here are the tasks that will be addressed in this walk-through:

   1: Create a Linux user account for the OpsMgr service

   2: Sudoers file configuration

   3: Configure iptables (Linux firewall)

   4: Verify DNS – forward and reverse lookup

   5: Create a cross-platform monitoring resource pool

   6: Install certificates on resource pool members

   7: Install required management packs

   8: Runas accounts and profiles

   9: Discovery wizard

 

Configuring Linux

Before attempting to discover and install the SCOM agent, an account needs to be created on the Linux system and the sudoers file must be configured to allow the account to execute certain commands. Most out-of-box monitoring activities are performed using low privileges on the Linux system, but some activities do require elevation using sudo.

In this example, SCOM will leverage a single Linux account to perform all activities: opsmgrsvc.

 

Create the opsmgrsvc account

There are several free tools you can use to establish a SSH session to a Linux system. The most common is Putty, which can be downloaded at http://www.putty.org/.

Launch Putty and connect to the Linux host by entering the host name or IP address of  the RHEL system and clicking Open.

image

 

Login with an account that has privileges to add user accounts and modify the sudoers file, or login with root. Create the opsmgrsvc account using the following command:

useradd opsmgrsvc

Next, set the password for the account using the following command:

passwd opsmgrsvc

You will be prompted to enter the password after issuing the command.

Configure sudoers file

Next you will configure the sudoers file, giving the opsmgrsvc account the ability to elevate and execute privileged commands without requiring a password (this is a SCOM requirement).

While still logged into the Linux SSH session as root, open the sudoers file editor by typing visudo and then:

1. Move down the file until you find the line Defaults requiretty, and enter Defaults:opsmgrsvc !requiretty just after it. This setting allows the service account to login without requiring a TTY session.

image

 

2. Move down the file until you find the line root ALL=(ALL) ALL, and enter opsmgrsvc ALL=(root) NOPASSWD: ALL just after it. This setting allows the service account to elevate without requiring a password.

image

 

3. Hit the ESC key to finish editing. To save and close the sudoers file, enter :wq. If you made a mistake in editing the file, you can close without saving your work by entering :q!.

 

NOTE!!! Your Linux administrator will likely want more granular control over which commands the SCOM service account can execute. Below are example sudoers file entries which would enable the opsmgrsvc account to only execute the command necessary for agent installation, maintenance tasks, and baseline monitoring.

More information about sudoers file requirements and examples for other cross-platform systems can be found at http://social.technet.microsoft.com/wiki/contents/articles/7375.configuring-sudo-elevation-for-unix-and-linux-monitoring-with-system-center-2012-operations-manager.aspx.

NOTE: Copy/Paste the following – there is no word wrap, so some of it may float off the screen!

#----------------------------------------------------------------------------------- 
#User configuration for Operations Manager agent: opsmgrsvc

#General requirements for OpsMgr service account
Defaults:opsmgrsvc !requiretty

#Agent discovery, installation, certificate signing, and maintenance tasks
opsmgrsvc ALL=(root) NOPASSWD: /bin/sh -c cp /tmp/scx-opsmgrsvc/scx.pem /etc/opt/microsoft/scx/ssl/scx.pem; rm -rf /tmp/scx-opsmgrsvc; /opt/microsoft/scx/bin/tools/scxadmin -restart
opsmgrsvc ALL=(root) NOPASSWD: /bin/sh -c sh /tmp/scx-opsmgrsvc/GetOSVersion.sh; EC=$?; rm -rf /tmp/scx-opsmgrsvc; exit $EC
opsmgrsvc ALL=(root) NOPASSWD: /bin/sh -c cat /etc/opt/microsoft/scx/ssl/scx.pem
opsmgrsvc ALL=(root) NOPASSWD: /bin/sh -c rpm -e scx
opsmgrsvc ALL=(root) NOPASSWD: /bin/sh -c /bin/rpm -F --force /tmp/scx-opsmgrsvc/scx-1.[0-9].[0-9]-[0-9][0-9][0-9].rhel.[0-9].x[6-8][4-6].rpm; EC=$?; cd /tmp; rpm -rf /tmp/scx-opsmgrsvc; exit $EC
opsmgrsvc ALL=(root) NOPASSWD: /bin/sh -c /bin/rpm -U --force /tmp/scx-opsmgrsvc/scx-1.[0-9].[0-9]-[0-9][0-9][0-9].rhel.[0-9].x[6-8][4-6].rpm; EC=$?; cd /tmp; rpm -rf /tmp/scx-opsmgrsvc; exit $EC

#Log file monitoring
opsmgrsvc ALL=(root) NOPASSWD: /opt/microsoft/scx/bin/scxlogfilereader -p

#Custom shell command monitoring example. Replace <shell command> with the correct command string
#opsmgrsvc ALL=(root) NOPASSWD: /bin/bash -c <shell command>

#Daemon diagnostic and restart recovery tasks (example using cron)
#opsmgrsvc ALL=(root) NOPASSWD: /bin/sh -c ps -ef | grep cron | grep -v grep
#opsmgrsvc ALL=(root) NOPASSWD: /usr/sbin/cron &

#Add sudo logging
Defaults logfile=/var/log/sudolog

#End user configuration for Operations Manager agent
#-----------------------------------------------------------------------------------
 
Configure Linux Firewall (iptables)

The firewall is enabled in a default installation of RHEL6. It comes preconfigured to allow SSH connections, ICMP on local subnet, and very basic network service functionality (these protocol ports may need to be manually configured on other distributions). To see the firewall configuration, run the following command in your SSH session:

iptables --list

image

SCOM discovery and installation uses SSH to copy installation files to the target computer and execute shell scripts, such as GetOSVersion.sh, but before this can happen SCOM needs to connect to the SCX CIM provider on the remote host using WinRM. This occurs over port 1270, which is not open in the default iptables file.

To allow WinRM to do it’s job, add the iptables rule with the following command (this is one line):

iptables -I INPUT 1 -p tcp -s 192.168.2.0/24 --dport 1270 -m state --state NEW,ESTABLISHED -j ACCEPT

Save iptables configuration with the following command:

/sbin/service iptables save

Take a look at the ruleset to make sure it saved correctly.

iptables --list

image

Important: You will need to save your iptables configuration and configure the network interface to restore iptables rules at startup. Otherwise, those rules will disappear the next time the computer restarts. Check your distribution for saving/restoring iptables.

 

iptables command explained

-I INPUT 1 : insert new rule at the beginning of the ruleset.

-p tcp : protocol to match.

-s 192.168.2.0/24 : accept requests from specified host (or hosts). Note: this must be changed for your environment or can be removed from the command to accept from anywhere.

--dport : destination port to match on the host.

-m : match specific connection states.

--state NEW, ESTABLISHED : connection states to match.

-j ACCEPT : accept connection and stop processing the ruleset.

 

DNS Configuration

If you host is not resolvable in DNS – forward and reverse – then read this section. Otherwise, you may skip to the next section about creating a resource pool.

Forward lookup zones are required for SCOM in general, and reverse DNS lookup zones are minimally required for a management server to establish communication with UNIX/Linux agents. connections with the management group. Some DNS systems do not automatically create DNS records, so in this example we will walk thru creating these records and zones in Windows DNS Manager.

 

Create forward lookup record

To register the Linux host in DNS, open DNS Manager and create a new A record in the forward lookup zone of your domain. If you have a reverse DNS lookup zone configured in your domain, select Create associated point (PTR) record. This should automatically create the reverse DNS record, but you may want to verify this on your first attempt.

image

 

Verify your configuration with nslookup.

image

 

In this example, forward lookup is working with nslookup rhel6-01, but reverse lookup isn’t working with nslookup 192.168.2.70. This is because either there was no reverse lookup zone configured in the domain, or the Create associated pointer (PTR) record option was not selected. In this case, a reverse DNS lookup zone did not exist.

 

Create reverse lookup record

If you don’t have a reverse lookup zone in your DNS, you’ll need to create one in DNS Manager. Select the defaults in the wizard, entering your network Id – in this case, 192.168.2.x.

image

 

Now a PTR record can be created for the Linux host. One way to do this is to open the A record created in the previous step (in the forward lookup zone) and select Update associated pointer (PTR) record.

image

 

Testing reverse DNS lookup now returns the Linux host name, and now you’re ready to move onto the next step.

image

 

Create a Resource Pool

In a typical production environment, there will be a resource pool dedicated to monitoring cross-platform systems. This resource pool should contain at least two management servers for high-availability. This example adds management servers OM12-MS02 and OM12-MS03 to the new Cross-Platform Monitoring Resource Pool.

Navigate to Administration > Resource Pools in the Operations console to create a new resource pool.

image

 

Add the management servers.

image

 

Install Certificates on Resource Pool Members

Each management server in the cross-platform monitoring resource pool needs to have it’s certificate installed on each other management server. This is task is performed by running the scxcertconfig tool on each management server; first exporting the certificate from each management server, then importing each other management server’s certificate.

Login to each management server in your cross-platform resource pool, open a command prompt as administrator, navigate to %Program Files%\System Center\Operations Manager 2012\Server folder, and execute the following command:

scxcertconfig.exe -export <hostname.cert>

In this example, <hostname.cert>is replaced with OM12-MS02 on the first management server.

After exporting the certificate on each management server, import the certificate(s) from each other management server in the same manner. in this example, if I’m logged into OM12-MS02, I would execute the following command:

scxcertconfig.exe -import OM12-MS03.cert

More information about this procedure can be read on Technet at http://technet.microsoft.com/en-us/library/hh287152.aspx.

 

Install Management Packs

By default, there are several Unix/Linux management packs installed in SCOM.

image

 

However, this is not enough to perform agent installation using the Discovery Wizard. You will need to import the version specific management packs before even attempting to install a cross-platform agent, because they contain definitions specifically designed to detect which version of the the installation package to install on the target host.

In this example, we minimally need to install the Linux and Red Hat Libraries, and the RHEL6 bundle. These management packs can be found on your installation media, in the Management Packs folder. You can also download most recent versions from the online management pack catalog.

Navigate to Administration > Management Packs in the Operations console to install the required management packs: Microsoft.Linux.RHEL.6.mpb, Microsoft.Linux.Library.mp, and Microsoft.Linux.RedHat.Library.mp.

image

 

At this point, all the prerequisites are satisfied for installing the agent on a Red Hat Enterprise Linux 6 operating system by using the Discovery Wizard. Unless you don’t want to actually monitor the Linux system, you can skip to the Discovery Wizard section.

 

Configuring Runas Accounts and Profiles

One last thing we need to do in order for object discovery and monitoring workflows can run on our Linux system. This isn’t necessarily required to install cross-platform agents, but obviously there wouldn’t be much value in it if this task isn’t completed.

Navigate to Administration > Run As Configuration > UNIX/Linux Accounts in the Operations console and create a new account.

image

 

Create monitoring account

1. On the Account Type screen, select Monitoring account.

2. On the General Properties screen, enter a display name.

image

 

3. Enter your Linux monitoring account credentials on the Account Credentials screen – do not use elevation with this account. If you use elevation with this account, monitoring workflows implementing Linux commands that do not support sudo elevation will fail.

image

 

4. Select More secure on the Distribution Security screen. Then click Create and Close.

 

Create elevated monitoring account

Create another account that will be used for elevated monitoring tasks that require sudo.

1. On the Account Type screen, select Monitoring account.

2. On the General Properties screen, enter a display name.

image

 

3. Enter your Linux monitoring account credentials on the Account Credentials screen – use elevation with this account.

image

 

4. Select More secure on the Distribution Security screen. Then click Create and Close.

 

Associate accounts with profiles

Now the accounts need to be associated with the appropriate Runas profiles.

1. Navigate to Administration > Run As Configuration > Profiles and open the properties of the UNIX/Linux Action Account.

2. Click Add on the Run As Accounts screen, and select the regular monitoring account (not the privileged account). Keep the default – All targeted objects – and click Ok.

3. After clicking Save, the wizard gives an opportunity to securely distribute the account. Click on your account to step into the distribution wizard.

image

 

4. Clicking Add on the Distribution tab launches the Computer Search screen. Select Search by resource pool name option, then click Search. Select your cross-platform resource pool in the Available items box. Click Add, then Ok.

image

 

5. Click Ok, then Close the Run As Profile Wizard.

 

Perform the same steps for the UNIX/Linux Privileged Account profile, using the privileged account you setup earlier.

 

Discovery Wizard

Navigate to Administration > Device Management in the Operations console to start the discovery wizard, and UNIX/Linux computers.

image

 

On the Discovery Criteria screen, Add the Linux host information and click Set credentials. Keep Discovery type set to All computers.

image

 

On the Credentials Settings screen, select User name and password and enter the account information that was created previously. Select This account does not have privileged access on the drop down list. Then click Ok.

image

 

The Credentials section on the Discovery Criteria screen should look like this.

image

 

Click Save, select the Cross-Platform Monitoring Resource Pool, and click Discover.

image

 

The host should be discovered and you can continue by ticking the checkbox and clicking Manage. If you scroll to the right in this window, you can also see that operating system, version, and architecture information was discovered.

image

 

After clicking manage, the wizard goes through an installation, validation, and certificate signing process. Given that all goes well, a typical installation should take 30-60 seconds for a single host. Within minutes you should see the new Linux agent appear in the monitor space, with objects being discovered and monitored.

image

 

 

Here are some useful resources to check in run into problems.

Unable to add the domain to the subject

Troubleshooting UNIX/Linux Agent Discovery in System Center 2012 – Operations Manager

Scenario #1 – “There were no computers that met the specified discovery criteria”

Scenario #2 – “SSH discovery failed.” with “unspecified problem”

Scenario #3 – “Did not find a matching supported agent”

Scenario #4 – “New computer shows as Platform: Unknown and Version: Unknown”

Sudoers Manual