We recently released a set of PowerShell scripts for cross platform computers in Operations Manager, which you could use for migrating a computer to a new management group, script-based discovery, or to upgrade the agent (see “Cross Platform PowerShell Scripts Released”). These scripts are great because they allow you to do things with your Unix/Linux computers that might not be as easy to do as with Windows computers. The problem is that when you use the OpsMgr PowerShell environment and use the command “Get-Agent”, all it returns is the Windows managed computers. None of the Unix/Linux computers show up. This makes dealing with individual Unix/Linux computers more challenging, and it’s why these PowerShell scripts are so handy – because we did all the work for you.

In my own testing I had a need for being able to quickly reset my system and remove all the Linux computers from the management group. For my own purposes, I could just hit delete a few times and be done with it – not much effort. Then, a few days ago, a customer wrote in and said they have 100+ Linux machines in their console and they’d like to delete them, and wondered if we had any PowerShell script to do that. Well, we didn’t, but using the existing PowerShell scripts we already released, I was able to quickly write up a script that used existing functions in the released scripts and then added the functionality of finding all the computers under Microsoft.Unix.Computer (the master class for all Unix and Linux computers) and then removing all of them from the management group.

Ok, so here’s the setup. The code below is PowerShell. Copy & paste it to a file called RemoveAllUnixComputers.ps1 (you can name it anything you want but I think this name clarifies its purpose).

Note that this script calls the scx.ps1 script. This is to provide some basic functions, load the appropriate OpsMgr assemblies, and other things. This script should be modified to point to the correct location of the scx.ps1 scipt..

This is what was in my OpsMgr console before I ran the script:

To run the script, you’ll need to start a PowerShell shell, so go to Start > All Programs > System Center Operations Manager 2007 R2 > Operations Manager Shell. When the window opens, just type in the path and filename of the script and hit Enter. Don’t CD to the directory because then you’ll lose the connection to the provider for the management interface. Here’s what you see when you run it.

And when I refresh my OpsMgr console, the Linux computers are gone!

Happy scripting!

Recently I was doing some tests and was trying to deploy a new Linux computer to be managed by Operations Manager. The discovery wizard kept failing with “unspecified error”. That’s really helpful, right? Well, I did what I normally do when i have any kind of discovery problem – I started DebugView to watch what was going on behind the scenes during the discovery. It didn’t end up being very helpful either, though it did show where the process was failing. Here’s what DebugView was showing me:

So my discovery was failing after deploying the discovery script to the computer. I still didn’t have enough info to figure out the problem, so I looked at the debug logging for the SCX modules.

Utilizing the DeployFile.vbs.log and the SSHCommandProbe.log files, I could see a little more detail into what was happening. Here’s what the logs showed:

So this told me the file was getting transferred (so not indicating problems with SSH) but when it was being run, there was no output. Hmmm. I’m still no further to finding the answer. I logged on to the Linux computer locally and ran the GetOSVersion.sh script using the same command line as above, and got a 0 return code and the appropriate XML. That’s weird. The script works fine, OpsMgr can connect to the Linux computer via SSH, it can drop the file there and run it, but nothing comes back.

Next I get out WinSCP to manually transfer the agent over there, and in opening up an SSH connection, WinSCP actually times out. This is interesting since both of these are VMs running on the same host, sharing the same networks. Now I realized that both the OpsMgr VM and the Linux VM have two network connections. One to my corporate network (so I have Internet connectivity) and one to a private 10.x network. Perhaps there are issues with the network connections not figuring out where the communication should go? I disabled my corporate network connections on both VMs, leaving only my private 10.x network on each. Magically, WinSCP connects instantly. It couldn’t be this simple could it? Well if you read the title of this article, you already know the answer to that. :)

Disabling the multiple network connections and keeping the single subnet active enabled the discovery to occur without a problem. And, only now did I realize that when both networks were active, discovery was taking a really long time. I did notice it at the time and wondered why it was taking so long, but I didn’t really link the issue until I saw how fast discovery was with the single network. Now I know that you can’t just go disabling NICs in a production system – they’re there for a reason. But what you can do is see if there are any conflicts with DNS, gateways, or other issues that might slow down the communication process to the point the discovery process times out on getting things done. The tell-tale signs are a really slow discovery (it shouldn’t take more than 30-45 seconds to get back the initial discovery data).

Hopefully my pain is your gain and this will be helpful to those having issues!

This question comes up often enough, and I saw another person send an email out on it today – “How is Operations Manager licensed when it comes to monitoring UNIX and Linux computers?” For some reason, people think that because a monitored computer is running UNIX or Linux that the process must be different. Our licensing process is complicated enough without adding in different rules for UNIX and Linux computers! :)

So here’s the simple answer: Operations Manager is licensed according to the workload, and there are two license types – Standard Server ML and Enterprise Server ML. The workload you’re managing with a management pack determines the license type needed.

For Standard Server ML:

• Management of basic workloads:
• Base OS or system hardware
• Storage/File/Print (FTP, NFS, SMB and CIFS)
• Networking (DHCP, DNS, WINS and RADIUS)

For the Enterprise Server ML:

• Any functionality not covered by the Standard Server ML (including application management)

I recently saw a bug submitted to our team about CPU usage statistics being reported by the cross platform agents and MP. The explanation from the customer was that our performance numbers weren’t the same as what they were seeing in tools like vmstat and mpstat and it was a bit confusing. It seemed like our CPU calculations were just wrong. In this article, I’ll discuss how the calculations are made and why the performance numbers might not match up to some other tools.

First of all, it’s important to understand how the agent gathers the data and how it gets to the OpsMgr server. The agent doesn’t gather the data every second – to do so would put an undue burden on the system just to monitor things burdening the system (recursive monitoring?). The agent collects the performance data once every 60 seconds. It’s a snapshot of what is occurring in that split second when it captured the data, just like if you looked at the current temperature outside. You know what it is now, but not what it has been during the day. This snapshot of data is then combined with the previous four snapshots and averaged into a rolling five-minute window of performance. This window shows the average CPU utilization over the previous five minutes and goes up and down with each 60-second data collection interval. Based on how often your OpsMgr server polls the agent for data (for CPU utilization the interval is 5 minutes), you will see some point along that trend line. The confusion occurs when people think the data they see in the monitor is real-time or actual data, when what they are actually seeing is this rolling average.

To demonstrate how this works, let me show you a graph of hypothetical CPU data:

This first chart shows some CPU utilization over a period of 11 minutes.

Next, we’ll overlay the values taken at the sampling interval (at the top of every minute), shown in green. Note that the performance data from the sampling is not the same as the overall CPU utilization – it only matches at the one-minute intervals. If a spike happens between the collection intervals but then returns to normal when the interval hits, you won’t see the spike. This filters out some of the noise of the ups and downs.

Next, we’ll overlay the rolling 5-minute average, which is essentially a trend line. Note that it is drastically different than the other values. This further smoothes out the data, and I’ll explain later how all this makes sense for the admin.

This next chart shows what the actual values will be when the data is collected from the agent at its 5-minute interval. The data points occur at minutes 0, 5 and 10. I put a dashed line between them just so you can see the trending. When viewing the performance data in the Operations Manager “Processor Performance” view, OpsMgr will “connect the dots” and show you the trend line.

Just looking at the chart above, you might begin to think that CPU utilization is always underestimated by this rolling average, but it’s not. You’ll note at the end of the chart that the red average line is going upward and will meet the other two lines (possibly at the next interval).

The thing about this rolling average is that it smoothes out the spikes in load values to show what is true utilization. We all know that when apps start or perform some operation that it’s going to use more CPU than when it’s just sitting there. What every admin wants to know is how much their server is being utilized on average so that when average utilization gets too high they can plan on making resource modifications. Spikes aren’t that worrisome because the system generally absorbs those spikes and it doesn’t affect the users to any great degree. It’s when average utilization gets high that every spike becomes a problem for users. By using this rolling average for calculating utilization, you also avoid getting lots of “noise” type alerts from OpsMgr. Let’s face it, you really don’t want to have alerts hitting you every time the CPU hits full utilization – you want to know when it’s been at full utilization for some time. This rolling average gives you that.

I know what you’re saying… if having an average utilization is good, why not just have total average utilization? The reason is that this rolling 5-minute window gives the performance data “more responsiveness”. By that I mean that it can show fluctuation more rapidly than an ongoing average of all data. Here’s one last chart to demonstrate this point. I’ve plotted the 5-minute average of the 1-minute samples in red and an ongoing average of all samples in blue:

For this example, I estimated that the CPU utilization was a constant 10% for the previous 10 minutes and that the continuous averaging method only went back to the previous 10 minutes. This means the chart shows a total of 20 minutes of averaged activity. The biggest thing you notice about these two lines is that the constant average line is very steady. It doesn’t move up or down very fast. The red line, showing the 5-minute average, moves up a lot in a couple of places. The benefit here is that while smoothing out the data, the 5-minute average can still give you evidence of high utilization without having to be sustained for a long time. It takes a lot more for the blue line to move up or down, which means that the reaction time to major issues could be a lot longer. If your CPU was at 10% utilization for a long period of time and suddenly went to 100%, You’d see it right away with the 5-minute average, but the continuous average would take a lot longer.

I hope this article clears up a little mystery surrounding CPU performance data. I’ll be writing a lot more of these types of articles in the future.

I hear this same question over and over in the forums, email discussions and face to face with lots of different groups: “How do I convince the Linux admins in the company to work with us on implementing Operations Manager to monitor the Linux machines too? From a cost savings and compliance perspective, having a single management infrastructure is definitely a benefit to everyone involved. You only have “one pane of glass” to look through to see how your entire IT infrastructure is operating, whether it’s Windows, Linux or UNIX. This is the benefit of Operations Manager R2’s cross platform support for UNIX and Linux platforms. The problem is that there’s an inherent protectionism among Linux admins that puts up an invisible force field around the Linux servers so that “the Windows guys” don’t touch them. It’s not that the Linux guys are just being angry, spiteful admins – they just want to protect the machines they’re responsible for, and face it Windows guys, you just don’t know a lot about running a Linux server. Now it’s true that the Linux guys probably don’t eat lunch with the Windows guys, and they don’t pal around together after work, but they don’t hate you. Honest, they don’t.

When I started working on server deployment tools for HP about 10 years ago, we started talking about automating network switch configuration along with server deployment. Back then, it was the same thing…”How do I get the network guys to trust this tool? They have their own tools and don’t want some outside deployment process to go messing up the network.” The push-back was the same then as it is now, but I believe that the differences between Linux and Windows server management are much smaller than between server and network management differences. We all want to monitor the same things – overall system health, performance, disk space, utilization. The difference is the commands used and the location of information. Fundamentally, server management is server management, regardless of the OS. The only difference is in the fine details.

Ok, so how do I answer the question? How do I get the Linux guys to accept using Operations Manager as the default management tool? It has to be a top-down and a bottom-up approach. From the top down, management in the company has to issue an edict that there will be a single management infrastructure. They know this will save money, save admin resources, and make the overall health of the company’s infrastructure better, because everything will be transparent, through “one pane of glass”, and resources will be used to build and extend additions to that management infrastructure just once, not once for each management infrastructure in place. From the bottom up, you have to involve the Linux guys in planning and architecture. Have them provide an analysis of their current Linux tools versus the System Center capabilities, and feel free to say if there are things that their current tools do better. The goal here is getting everything out in the open. Once that happens, you can discuss how to extend or modify the System Center tools to suit the needs of Linux management. Many times, they’ll end up with something much better than what they had before.

One thing that always appeals to the Linux guys is when products are open source. Linux admins want to know that things aren’t hidden under the covers, and that if they want to change the way something works, they can (but most likely won’t) go modify code and make it act the way they want. The cross platform solutions for Operations Manager 2007 R2 leverage open source and open standards. We utilize OpenPegasus as the CIM server, which is completely open source. We’ve even submitted enhancements back to the Open Group to include in OpenPegasus 2.10 coming out next month. We also provide the source code for our CIM providers on our site on CodePlex and we’re also starting to build a community extensions project as well.

Aside from the purely social or political aspect of the issue, we can also address the technical side. Many times Linux admins object to the requirement that root privileges are required to run the agent and the CIM server, and also object to yet another agent on their machines. I’ve discussed root privilege requirements before, but suffice it to say that root requirements are nothing new. OpenPegasus itself requires root, the PAM requires root to authenticate other users, some kernel APIs require root in order to collect the performance / monitoring data needed, and the agent needs to impersonate other users (like when a low privilege user runs a command, a process is spawned as that user). All of these things that are relatively normal in monitoring require that we have root level access. That said, we are working to enable sudo access in more situations in the next release.

If the remaining objection is that they can’t use a Linux/UNIX-based tool to monitor these machines, we can also point them to our connector solutions for HP OVO, Tivoli, or even the universal connector that will let them share data with virtually anything.

More often than not, objections from teams in implementing anything new are caused by (1) fear of the unknown – they know their system and don’t want change, and (2) anger at not being involved in the decision-making – being told by “the Windows guys” that they will implement something and they don’t have a say. It’s too easy to get put into camps of IT administration with Windows on one side and Linux on the other. Let’s build some bridges and get people communicating! Above all, let’s be more efficient by working on a management system that crosses the boundaries between the different platforms.

In part 1 of this article, I talked about the basics of building a CentOS Management Pack, beginning with trying out the Red Hat agent. Now I’ll continue the article where I left off, talking about building the MP itself.

Creating the Management Pack

In order to replicate everything I did, it helps to understand a bit of the process surrounding the cross platform management capabilities in Operations Manager 2007 R2. First of all, there’s the schema, or organization, of the libraries and management classes related to UNIX and Linux. Here is a section of the schema chart for the classes for Red Hat related to the System.LogicalHardware class:

You’ll notice that there are several levels that drill down into further and further detail: UNIX - > Linux -> Red Hat -> RHEL 5. Each lower level derives from and adds greater detail to the more common properties of the one above. This is a basic concept of Operations Manager (hey, I said I was new to this, so bear with me).

After I wrote the last article “Using OpsMgr Class Inheritance to Extend Monitoring to New (Unsupported) Operating Systems” I thought about going a different direction in creating this MP than I was going to do originally. I thought about using overrides and inheritance to extend the RHEL.5 MP for CentOS, but in the end I decided to stick with the “copy, search and replace” method. The reason was the same one we have for creating virtually identical RHEL4 and RHEL5 MPs – because if anything changes in the base, it could break the derivative if the derivative didn’t need to change.

So what I’m going to demonstrate here is taking the existing Red Hat Library and the Red Hat 5 Management Pack and then creating new MPs to support CentOS 5. The graphic below sort of demonstrates how these new MPs will fit into the hierarchy.

Creating the CentOS MP XML Files

The first thing I need to do is to get copies of the Red Hat Library and Red Hat 5 MPs. Since these MPs are sealed, I need to export them into XML format so that I can see what needs to be changed. To do this, I got the MpToXml.ps1 PowerShell script for converting sealed MPs to XML from the OpsMgr++ Blog here: Converting a sealed management pack to readable XML. This PowerShell script really only does two things (using the public OpsMgr SDK): creates a management pack object from the MP specified, and then writes it out to XML.

I ran the script to export the MPs (RHEL.5 shown below):

I copied these files to a new location and renamed them Microsoft.Linux.CentOS.Library.xml and Microsoft.Linux.CentOS.5.xml. I opened these files and did a search and replace on the following strings (you should do them in this order):

Root XML Element Changes

Because the XML comes from a sealed MP, the “ManagementPack” element in the XML includes a “RevisionId” attribute, and the “ContentReadable” attribute is set to “false”. And, since our new CentOS MP is not sealed, this needs to be changed. Just remove the “RevisionId” attribute and its setting, and set “ContentReadable” to “true”, as the example shows below:

<ManagementPack xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" ContentReadable="true">

Identity Element Changes

Just like the above, a sealed MP has a PublicKeyToken value inside the Identity element. Because this MP is not sealed (yet), this element needs to be removed. Just remove the whole element and its contents as shown below:

Next, there are specific changes for the individual files.

Changes to the Library XML File

Computer Discovery Changes

While it’s true that CentOS is a derivative of Red Hat, and as you saw in the first part of this article, the Red Hat agent works on CentOS, unless we change something in the discovery to distinguish a CentOS computer from a Red Hat computer, OpsMgr won’t know which is which.

If we look back at the output from the command to scxcimcli enumerating the SCX_OperatingSystem class, then compare that to the same output from a Red Hat computer, the “Name” property of both is “Red Hat Distribution”. However, looking at the “Caption” property, the CentOS computer has a value of “CentOS release 5.4 (Final). This is what we’ll have to use to distinguish the two computer types.

To make this change, look for the Monitoring -> Discoveries -> Discovery element with an ID of “Microsoft.Linux.CentOS.Computer.Discovery”. Now just change the values of the FilterProperty and FilterValue elements in the XML to the values shown below:

There’s one more change needed in this discovery to make it work. We could have put the exact OS version string in the FilterValue property (“CentOS release 5.4 (Final)”), but that would make it fixed to that specific build, and since this is a general CentOS library, we want it to work with any version. The version-specific MP should have that information in it, not this one. So what I did was I just put the beginning of the string there (enough to distinguish that it’s CentOS). However, if you look at the DataSource element below, it’s using an “Equal” comparison, so a partial match is not a match. This needs to be changed to “ContainSubstring” so we can do the partial comparison:

We’re done editing the library XML, so save the file and close it.

MP Sealing Requirements

Since I mentioned the previous MPs were sealed, now is a good time to talk about sealing requirements. Any time an MP references or extends another MP, the base MP must be sealed. This means that if I want to replicate the OS Library -> OS Version structure of Red Hat’s MP, I have to seal the new CentOS Library MP in order for the CentOS 5 MP to extend it.

In order to seal an MP you will need a key file, which is a strong name key ending with an extension of “.snk”. You can create a key using the Strong Name Tool, and use it for signing any of your custom MPs.

Once you have the key file, the easiest way to seal an MP (and check it for issues in the process) is to use the Operations Manager Authoring Console. Open the XML file for the Library (you may need to locate the UNIX and Linux Library MPs as well). Verify the MP is structured correctly by selecting Tools > Verify, and you should get a success notification like the one below:

Next, select File > Save As > Sealed and Signed Management pack from the menu. The file should automatically be named Microsoft.Linux.CentOS.Library.mp. Click Save. Enter appropriate values for Company name and Copyright, and click the button on the right to browse to your key file created above.

Click OK. A new .mp file is created in the target directory.

Changes to the CentOS.5 XML file

Reference Changes

This XML references the CentOS.Library MP because it extends that MP. However, the PublicKeyToken value for this reference needs to be changed to point to the specific value from the sealed MP you just created. Since this was a cut and paste, the current value points to the Red Hat MP value. You can get the value for this by using the sn.exe utility again with the following command line:

The utility will display something similar to the following (your PublicKeyToken value will be different):

Now take this value and replace the current value in the XML, similar to the following:

Computer Discovery Changes

Just like the Library MP, the CentOS.5 MP needs to change what it’s looking for to classify the discovered system as a CentOS 5 computer. To make this change, look for the Monitoring -> Discoveries -> Discovery element with an ID of “Microsoft.Linux.CentOS.5.Computer.Discovery”. Now just change the value of the FilterValue element (since it already uses the “Caption” property”) in the XML as shown below:

The same change needs to be made to the Microsoft.Linux.CentOS.5.OperatingSystem.Discovery element contents.

So now we have a library MP file (signed and sealed) and a CentOS.5 MP file (still in XML format) that references the library. The next step is to import the MPs into OpsMgr and use them. I’ll cover that in the next installment of the article.

A couple of weeks ago, I posted “Privileged and Non-Privileged “Run As” accounts in cross platform monitoring”, which was a brief article giving an overview of Run As accounts for OpsMgr Cross Platform. I ended up writing a long post in the forum about this, since it’s a common question and not documented very well. I thought I’d also write another article about this and not only provide what I said in the forum post, but a couple of other tidbits as well…

Run As Profiles

First of all there's the topic of the two Run As Profiles - the "Unix Action Account" and the "Unix Privileged Account". Each of these profiles needs to be configured and must contain at least one user account to function. They can both use the same account, or they can use different accounts. The Unix Privileged Account must be root if you want all of the rules, diagnostics and recoveries to function. The agent does not currently support sudo accounts. For diagnostics and recoveries, it's possible to override the command used (something like "<p:command>sudo sh -c 'ps -ef | grep syslog | grep -v grep'</p:command>", but sudo passwords cannot be used. The Unix Privileged Account profile is used for certain actions that require root-level privileges to perform. These include some rules, some diagnostics, and most recoveries.   

You can find out which monitors, diagnostics or recoveries require which account profile by looking at the management packs (you could use either the Authoring Console to look at the sealed MP or you can access the XML from the Health Service State\Management Packs directory and view it in an XML editor). Just look for things like "Invoke.Privileged.ProbeAction" (compared to the normal "Invoke.ProbeAction"). There's also "Invoke.Privileged.WriteAction" and "SCXLog.Priviledged.DataSource".

• TechNet Documentation:  Configuring a Cross Platform Run As Account

Root Account Requirements for the Agent

Next is the topic of why a root account is needed to install the agent, and why the agent runs in root context. Basically, the Linux/UNIX kernel requires root-level privileges in order to access the data counters that the agent uses and reports on. Many of the classes used are read only and we allow them to be queries with a non-privileged account. For classes that also allow write operations (like ExecuteCommand()), the agent runs the command using the credentials of the Run As account. Since only root can spawn processes as other users, the agent requires root context to run. Other processes like the logfile scanning provider use the Run As account to instantiate the provider process to make sure privileged files can only be read by privileged users.

Agent Background Activities

Finally, the answer to "just what is the agent doing in the background when not asked to provide monitor data to OpsMgr?"... The agent is performing collection of performance data in a separate thread. For the delta counters (CPU load, Disk IO, etc.), data is kept in a rolling window, and when OpsMgr asks for it, an average value is returned. There is very little cost in querying the agent for the data, since the data had already been collected. The data sampling interval has been optimized for the OpsMgr-> agent communication interval to reduce load.

Hope this helps.

I got an email the other day from a customer who asked if we were planning on supporting Red Hat desktop anytime soon. It seems that they’ve installed the desktop versions on their servers instead of the server versions, and since the Management Packs included with Operations Manager R2 support only Red Hat Enterprise Linux (RHEL), and are geared to discovering that specific OS, their desktop systems won’t get discovered properly. It seems the agents get pushed out and installed properly, but none of the discoveries are working, so the machine sites there not being monitored.

Well, since I was already working on my other article on porting a Red Hat MP to work for CentOS, I thought it was an opportune time to see if I could generate a quick MP extension to make this work. I thought that the real problem was that the initial computer and OS discoveries were not working (because it was RHED instead of RHEL), but all the other monitors, rules, diagnostics and recoveries should be exactly the same. So, I worked on a hunch that if I could get OpsMgr to discover these systems and then act like they were actually RHEL machines (discover them using the RHEL classes), everything would work. My hunch worked, and the systems began getting discovered properly, so I thought I’d share the MP I created.

Differences between RHED and RHEL

The main differences between the discoveries that the RHEL MP performs and what the RHED OS provides are small. When you look at the computer discovery in the RHEL MP (OS discovery is the same), you can see that it’s looking for a specific value in the “Caption” property:

<FilterProperty>//*[local-name()="Caption"]</FilterProperty>
<FilterValue>Red Hat Enterprise Linux Server release 5</FilterValue>

In order for this to work with the desktop OS, it needs to be changed to this:

<FilterProperty>//*[local-name()="Caption"]</FilterProperty>
<FilterValue>Red Hat Enterprise Linux Client release 5</FilterValue>

Making this into an MP

Ok, so now that we know these differences, how can we make this into an MP that enables monitoring these machines? The key is in taking these new discoveries and making them apply to the existing targets and discovery classes. For the Operating System discovery, the existing RHEL MP has the Targets and DiscoveryClasses shown below:

This means that when the computer matches the “Caption” property filter, a RHEL.5.Computer object is created, and that this class belongs to the Linux.RedHat.Computer object.

This means that when the computer matches the “Caption” property filter, a RHEL.5.OperatingSystem object is created, belonging to the RHEL.5.Computer object created above.

So, if we want to take our RHED discoveries and make them discover as RHEL machines, all we have to do is give our new discoveries a Target and DiscoveryClass the same as the RHEL MP. The resulting XML looks like this:

The only other things that need to be done for this MP are to define the ClassTypes (which are really just definitions for the abbreviations used for targets), and to specify the other MPs that this MP will reference. Here’s how that looks:

The result is that one you import this Management Pack, any Red Hat Desktop systems you have in your environment will look exactly like RHEL systems! This technique is useful when you have other Linux versions or distros that don’t match the supported platforms list but where the agent installs just fine and all you care about is that the systems are monitored. Of course, if you actually want to have RHED systems show up as RHED instead of RHEL, you’ll have to do a lot more than this. You'll probably want to replicate a lot more of the MP and make other changes, but instead of referencing the RHEL classes, you’ll be making new RHED classes so those new object types will appear in OpsMgr.

The sample XML file from this article is attached below. Good luck!

We are happy to announce the release of the Cross Platform Audit Collection Services for Operations Manager 2007 R2. This feature extends the existing Audit Collection Services and Cross Platform features in R2 to include UNIX and Linux Event auditing.

Cross Platform Audit Collection Services allows you to collect events from UNIX/Linux servers and have Operations Manager 2007 R2 ACS collect them in the same way the Windows events are collected. Reports can then be viewed to show the collected events (the reports are included with the Cross Platform Audit Collection Services installer) .

Three downloadable components are required for Cross Platform Audit Collection Services:

• System Center Operations Manager 2007 R2 Cross Platform Updated Management Packs
• Cross Platform Audit Collection Services Management Packs
• Cross Platform Audit Collection Services Installer

For Cross Platform ACS to function, the existing R2 Cross Platform Management Packs were updated. They are not required for normal Cross Platform operation, only for Cross Platform ACS. These Management Packs can be downloaded from within the Operations Manager 2007 R2 Console or directly from the link above.

Note: With these updated MPs, Language Packs have been introduced (versus full MPs containing all languages as was the case with the Release of R2). If you are using a localized version of Operations Manager, you will need to download and install the English Updated Management Pack and any Language Pack that you require.

The logic as to which events are to be collected for each of the UNIX/Linux Servers is included in the Cross Platform Audit Collection Services Management Packs. There is a UNIX ACS Management Pack that is required by all the platforms, as well as individual Management Packs for each supported Platform (for example, SUSE Linux Enterprise Server 11). These Management Packs can be downloaded from within the Operations Manager 2007 R2 Console or from the link above.

Note: The Cross Platform Audit Collection Services Management Packs are currently only available in English.

Finally, the Cross Platform Audit Collection Services Installer needs to be downloaded and installed. Cross Platform ACS should be installed only on Operations Manager Management Servers that actively monitor the UNIX/Linux Servers. Also, an ACS Collector needs to be configured and the ACS Forwarder on the Management Server needs to be enabled. The RMS should not act as an ACS Collector/Forwarder. For more information on best practices and how to install Cross Platform ACS, check out the Deployment Guide. The Cross Platform Audit Collections Services Installer can be downloaded from the link above.

Note: As with the Cross Platform ACS Management Packs, the Installer is currently only available in English.

For more information on installing and configuring the Cross Platform Audit Collections Services feature and installing the included report, refer to the Deployment Guide (available on the download page with the Installer).

 The documentation can be access directly via the following links:

• ACS Release Notes and Deployment Guide: http://technet.microsoft.com/en-us/library/ee873221.aspx
• ACS Managment Pack Guide  http://technet.microsoft.com/en-us/library/ee873234.aspx

One of the initial configuration requirements (and one of the top things new users forget to do) for cross platform monitoring is setting up the user accounts to use for privileged and non-privileged actions. But what exactly are privileged and non-privileged actions? Why would you need one or the other?

When performing remote operations on clients such as monitoring, diagnostics or remediation, the agent performs these actions running as a specific user account (the “Run As” account specified by the administrator). The recommended security practices call for specifying a low-privilege account for most actions and using a higher-privilege account only where necessary. This segregates security privileges according to the types of actions performed and can help prevent inadvertently assigning tasks outside of the user’s security scope.

You assign Run As accounts to multiple computers through Run As Profiles, and assign the profile to the group of computers. When you install Operations Manager R2 Cross Platform extensions, it creates for you two profiles under Administration > Run As Configuration > Profiles. These profiles are named Unix Action Account and Unix Privileged Account. These profiles are pre-assigned to the various monitors and tasks within the UNIX and Linux management packs, so that once the actual accounts are specified, they need to be set up only once and all of the UNIX/Linux MPs will now work.

They key is that the user accounts need to be defined in the Run As Profile for the profile to work. There’s no obvious indication in the console that these accounts aren’t defined in the profile, but your MP’s will not work until the accounts are added.  (See: How to Create  a Run As Account in Operations Manager 2007)

Ok, so you understand the basics of Run As accounts and profiles – but which tasks require which profile? Generally, monitoring actions do not require privilege, but many remediation actions do. This is because they are stopping / restarting processes or daemons and we don’t want that happening accidentally. Also, deploying agents does not require privilege, but installing and uninstalling requires a privileged account.

Here are some links to specifics about the actions requiring privilege across the supported operating systems (latest OS version shown, but other versions similar and in the same documentation):

• AIX Recoveries
• HP-UX Recoveries
• Red Hat Recoveries
• Solaris Recoveries
• SLES Recoveries

We are pleased to announce the release of the System Center Operations Manager 2007 R2 Connectors!  The Connectors are available for download at the following location:

               http://www.microsoft.com/downloads/details.aspx?FamilyID=592e4143-c5c8-4270-9a7a-cd0a31ab3189

The Operations Manager 2007 R2 Connectors provide Operations Manager 2007 R2 alert forwarding to remote systems, such as an Enterprise Management System (EMS) or a help desk system. After Operations Manager 2007 R2 forwards an alert to a remote system, the alert data is synchronized throughout the lifetime of the alert.  The result of that data synchronization is a robust and seamless systems management environment. Such an environment enables cross-organization support processes to take advantage of the resources and strengths of formerly independent support groups. The ultimate effect is improved enterprise systems health through improved organizational communication.

Sharing data between Operations Manager 2007 R2 and remote systems enables enterprise correlation of events from Windows-based systems, hardware, network, and UNIX systems. Correlating these events allows IT staff to determine the causes of issues and reduce the time to resolution of IT outages.  Synchronization of data between Operations Manager 2007 R2 and remote systems also enables operational groups to use familiar management interfaces. Users update an alert by using their management tool, and the data is updated in tools that are used by other operational groups.

The following connectors are available in this initial RTM:

-          Operations Manager 2007 R2 Connector for IBM Tivoli Enterprise Management Console

-          Operations Manager 2007 R2 Connector for HP Operations Manager (formerly HP OpenView Operations)

-          Operations Manager 2007 R2 Connector for BMC Remedy Action Request System (ARS)

-          Operations Manager 2007 R2 Universal Connector

For more information regarding the Connectors, you can review the following resources:

Download Details:

-          http://www.microsoft.com/downloads/details.aspx?FamilyID=592e4143-c5c8-4270-9a7a-cd0a31ab3189

TechNet Documentation:

-          http://technet.microsoft.com/en-us/library/dd795265.aspx

TechNet Forums:

-          General:  http://social.technet.microsoft.com/Forums/en-US/interopgeneral/threads

-          Connector for IBM Tivoli Enterprise Console:  http://social.technet.microsoft.com/Forums/en-US/interoptivoli/threads

-          Connector for HP Operations Manager:  http://social.technet.microsoft.com/Forums/en-US/interophpoperationsmanager/threads

-          Connector for BMC Remedy ARS:  http://social.technet.microsoft.com/Forums/en-US/interopremedy/threads/

-          Universal Connector:  http://social.technet.microsoft.com/Forums/en-US/interopuniversalconnector/threads

We are happy to announce that the Cross Platform Extensions Beta 1 refresh is now available on the Microsoft connect site - http://connect.microsoft.com.  We appreciate the feedback on the product received to date and hope you will continue this.  Please let us know if you have any questions.

 This Beta refresh adds three new features to the product that customers have been asking for:

·         Support for OpsMgr Server running on 64-bit systems

·         Gateway role support

·         AIX 5.3 support