For Opalis / Orchestrator content, see the Orchestrator blog at https://blogs.technet.com/b/orchestrator.

For Operations Manager cross-platform content, see the Operations Manager blog at https://blogs.technet.com/b/momteam.

The public beta version of Operations Manager 2012 is now available here (https://www.microsoft.com/systemcenter/en/us/om-vnext-beta.aspx).  

This is first publicly available version of the new release, and it has lots of great new capabilities as described on the web page.   There’s a great datasheet and FAQ list that are linked to from that page.

New cross-platform capabilities are in two categories: 

1. UNIX/Linux and
2. Java.  

For UNIX/Linux, the major improvements are:

• You no longer need the “root” password for UNIX/Linux computers!   The ability to elevate privileges using “sudo” is now implemented, so your UNIX/Linux admin can provide an unprivileged account to OpsMgr, and manage the elevation using UNIX/Linux tools.
• Resource Pools are supported for UNIX/Linux computers, providing a configuration that’s highly available in the face of a Management Server failure
• The console UI for discovering UNIX/Linux computers has been improved, and there’s now console UI for upgrading and uninstalling
• Support for Red Hat 6 and AIX 7.1 is included

For Java, this beta includes new management packs for managing Java application servers, specifically IBM WebSphere, Oracle WebLogic, Red Hat JBoss, and Tomcat.    Note that these management packs are in a .zip file that must be separately downloaded.   Documentation is included in the .zip file.   With these management packs, we’re extending OpsMgr to include monitoring the full range of applications that are found in enterprise – not only .NET, but Java as well.

Please take this beta out for a test drive!   We really want your feedback on the functionality as well as on any bugs or problems you find. 

Here are some useful links:

• The new Operations Manager 2012 beta page
• Documentation: https://go.microsoft.com/fwlink/?LinkID=213297
• Forums: https://social.technet.microsoft.com/Forums/en-US/category/systemcenteroperationsmanager
• Feedback: https://connect.microsoft.com/OpsMgr/Feedback
• Team Blog: https://blogs.technet.com/b/momteam/

I’m very happy to announce that R2 CU4 has now shipped.  The Download and KB Article are available here:

KB Article:  https://support.microsoft.com/kb/2449679

Download: https://www.microsoft.com/downloads/en/details.aspx?FamilyID=39a871e0-d996-4568-be5d-2edb6f539330&displaylang=en

CU4 is the highest quality CU shipped thus far, and resolves numerous long standing OM issues.  It also significantly improves the deployment/install experience, while at the same time delivering some critical customer features such as SQL 2008 R2 Support. It’s the first CU to have been released to TAP first (Beta Release), and the second CU to integrate OM + XPlat, which has now become the expected experience for our customers.

PS:  The following screenshot from Kevin Holman’s blog appears to be representative of the community reaction thus far:

Now these activities are great and form the basic building blocks of a lot of capabilities, but they require installing an agent on the remote machine, and the agent is supported on RedHat 4 and 5, Solaris 8, 9 and 10, HPUX 11.11, and AIX 5.3.

Meanwhile, the current cross platform integrations for Operations Manager support the following operating systems:

• AIX 5.3 (Power), 6.1 (Power)
• HP-UX 11iv2 (PA-RISC and IA64), and 11iv3 (PA-RISC and IA64)
• Red Hat Enterprise Server 4 (x64 and x86) and 5 (x64 and x86)
• Solaris 8 (SPARC), 9 (SPARC), and 10 (SPARC and x86 versions later than 120012-14)
• SUSE Linux Enterprise Server 9 (x86), 10.1 (x86 and x64) and 11

If you already have the Operations Manager cross platform agent installed, you probably don't want another agent on there as well, so utilizing the existing agent would be a good thing. In this article, I'll show you how to quickly create your own Opalis activity using the QIK CLI wizard and simple WinRM commands. This activity will be able to query the OpenPegasus (CIM) database on the UNIX/Linux computer to get information provided by the SCX Agent. In another article, I'll show you how to use the "invoke" command to run command lines on a remote computer so you can replicate all of the functionality currently provided in the UNIX IP.

Creating your custom activity

The first thing to realize is that you can create a new custom object out of virtually any command line, and that using a WinRM command, you can talk to the SCX agent on a UNIX or Linux computer. For example, here's a command you can use to enumerate the SCX Agent info:

winrm enumerate https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_Agent?__cimnamespace=root/scx -username:root –password:<PASSWORD> -r:https://<computer name>:1270/wsman -auth:basic -encoding:utf-8 -skipCAcheck -skipCNCheck -skipRevocationCheck -format:#pretty

Knowing this, you can start creating your own custom activity! Here's how:

1. Make sure you have the Quick Integration Kit installed
2. Click Start > All Programs > Opalis Software > Quick Integration Kit 3 > QIK CLI
3. Click Next
4. Enter some information about the assembly you'll be creating. Just a name and file location will do here.
   
5. Click Assembly Information
6. Enter some more information to give a description, title, version number,etc. to the assembly.
   
7. Click Next
8. On the Commands page, click Add to add a new command for the assembly. The Add/Edit Command dialog appears.
9. On the General tab, enter a Name for the command (this will appear as the object name in the Client).
10. Select Run Command as the mode – this allows you to run a command line.
11. Enter a Description for the command just to provide some useful information
    
12. Click on the Arguments tab. Now we have to add Parameters so that you can define some of the values at runtime.
13. Click Add next to the Parameters box. The Add/Edit Parameter dialog appears.
14. Since we need to make the namespace being queried a variable, it will become a parameter here. Enter the following information:
    
15. Click the Ellipsis (…) button next to Options and enter the following text to provide options for the namespace selection:

    SCX_Agent
    SCX_DiskDrive
    SCX_DiskDriveStatisticalInformation
    SCX_EthernetPortStatistics
    SCX_FileSystem
    SCX_FileSystemStatisticalInformation
    SCX_IPProtocolEndpoint
    SCX_LogFile
    SCX_MemoryStatisticalInformation
    SCX_OperatingSystem
    SCX_ProcessorStatisticalInformation
    SCX_StatisticalInformation
    SCX_UnixProcess
    SCX_UnixProcessStatisticalInformation

16. Click OK, then click Add again.
17. Enter the following information for providing a username at runtime:
    
18. Click OK, then Add again.
19. Enter the following information for providing the password at runtime:
    
20. Click OK, then Add again.
21. Enter the following information for providing the target computer name at runtime:
    
22. Now go back up to the Command Line box and enter the following:
    
    winrm enumerate https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/$(namespace)?__cimnamespace=root/scx -username:$(username) -password:$(password) -r:https://$(computer name):1270/wsman -auth:basic -encoding:utf-8 -skipCAcheck -skipCNCheck -skipRevocationCheck -format:#pretty
    
23. Since the output to StdOut and StdError automatically show up in published data, you don't need to  add any specific published data items. Click OK to go back to the Commands page.
24. Click Next. The wizard now builds your assembly file. By itself, your assembly could be used with the "Run .NET Object" activity that comes with QIK, but it's easier to use if you go ahead and make a custom Integration Pack.
25. Click Build Integration Pack. This starts the Opalis Quick Integration Kit Wizard.
26. Several of the fields will be filled in for you already. Just fill in the Category Name – this is what group the activity will appear under in the Designer Client. Use a unique name here.For the purposes of this exercise, I'll just use "SCX"
    
27. Click Next
28. On the Objects tab, you should see the Query SCX Agent object automatically added
    
29. Click Next
30. There are no files to be added with the IP, so click Next again at the Dependencies page.
31. Now you just need to name your IP file
    
32. Click Next to built the IP, then Finish to exit the wizard.
33. Now just use the Opalis Deployment manager to register and deploy the IP to your client / action server.

Using the New Activity

Now that you have the custom IP built and imported, you can use it in a workflow. The simplest example is shown above. You can get information back using this example (you just don't have any means of acting on the information yet). But first you have to configure the activity with runtime information, like this:

Now just open it in the testing console by clicking the Test button in the toolbar. Click Run to start the policy, and when it finishes, you'll see details like this:

Of course, you can't read all of the content under Standard output, but when you mouse over it, you 'll see this:

Looks like XML, doesn't it? Well, it is! That means I can use a Query XML activity in the workflow to actually do something with the data. This part is REALLY simple… Just drag a Query XML activity (under Utilities) into the policy and link it after the Query SCX Agent activity. Open the properties and set them like this:

You now have a means to find out the architecture of the computer. Just look for the published data property of "Number of Matches" to be > 0 and you've matched a value, and the value appears in "Query Result" as shown here:

OK, that was simple, but how about if you want to get different information? I can just go back to the Query SCX Agent activity and change the namespace to any of the other values and re-run the policy. The result will show me what properties are available for me to use in the Query XML activity.

For example, changing the namespace value to "SCX_FileSystem", I get back two different instances of the class, and in each one I see the "<p:AvailableSpace>" element. Now if I change my Query XML activity to look for that element, it looks like this:

And when I run the policy in the test console, I get this:

The "<…>" means I got multi-value data back (which I can confirm because "Number of matches = 2). Opening the Published Data Browser I see my values:

Just to show you the power of this tiny little workflow, let's say I wanted to find the overall percentage of free disk space on the system. I can use a slightly more complicated XPath query to divide the available disk space into the total disk space and get that number! I just put the following text into the XPath Query box:

((//p:AvailableSpace) div (//p:FileSystemSize))

And here is the result:

I can now see that my system has 88.5% free disk space.!

Now it's your turn… go forth with this new knowledge and see what kind of information you can gather and use within your workflows using the SCX Cross Platform Agent for Operations Manager and Opalis!

Release notes for this update

• This update is only for cross platforms including the Linux operating system and the UNIX operating system.
• This update is released as built-in components that are included in Cumulative Update 3 for System Center Operations Manager 2007 R2 instead of as a separate update.
• Cross platform updates are language neutral. Therefore, this update is released in English only.

2251525 (https://support.microsoft.com/kb/2251525/ ) System Center Operations Manager 2007 R2 Cumulative Update 3

Issues that this update resolves

The following issues are resolved in Cross Platform Cumulative Update 3 for Systems Center Operations Manager 2007 R2.

Additionally, the following feature addition is added in this update to control the rules that generate log file alerts in Linux management packs or in UNIX management packs:

• The default behavior combines duplicate log file entries into a single alert. After you install this update, you can generate a separate alert for each log file entry.

So why am I mentioning this? It's not because we're having to justify whether or not to support cross platform operating systems in Operations Manager or other System Center products. The evidence is clear that it's a customer requirement and that we need to do it. We're not scaling back our plans for supporting cross platform. Far from it – we're working on supporting cross platform in much larger ways (which will be detailed as we get further in product development cycles). I'm mentioning ODR because we want to get a good estimate of the percentage of the Operations Manager customers who are using cross platform MPs, and also which ones they're using.

Your cross platform ODR data could result in even more effort being put into cross platform support, or could help us decide resourcing for the individual supported operating systems.

People ask us all the time if we can "officially" support some new Linux or Unix platform, and without the data to back up these requests, it's not something we can justify. I know, I know… how can we get data from ODR on Management Packs that don't exist? Well it's an issue that has two sides. First, by tracking ODR data, we can spot trends or shifts in "official" MP usage. For example, if Red Hat 4 started declining and Red Hat 5 increased, we know people are moving to new versions. Or, if Sun Solaris usage was dropping and another Linux or Unix platform was gaining, we might say that was a trend toward that OS. Second, we can track "unofficial" MP usage too. For example, if you read this blog and created a CentOS management pack, we would be able to see that and it would show up as a statistic we could track. If we spot more MPs that are related to Linux and UNIX but not in the official supported list, there can be a point where we might add that MP as a supported OS. The thing is, that without the data, the only thing we can go by is random customer surveys and the existing ODR-enabled customers. This limits our decision-making abilities.

So here's your call to action:       Enable Operational Data Reporting in Operations Manager!

It's easy and painless! Here's how:

1. Start the OpsMgr admin console (use elevated privileges if possible)
2. Go to Administration > Settings > Privacy
3. Click on the Operational Data Reports tab
4. Select Yes, send operational data reports to Microsoft (recommended) and click OK

Thanks for helping us make a better product and give you what you need for cross platform support!

Microsoft is a big company, and there are lots of moving parts. A lot of times, things happen and you don't know about it, like new KB articles being released. I thought of this yesterday when JC Hornbeck posted a new article on the Opalis blog and referenced the KB at the end. Now, I get a monthly email with a spreadsheet of new or updated KB articles, but from that I have to search and see if any are relevant to me. Not only is that an extra step, I only get it once a month, so sometimes I could wait a whole month to find out something was published. Sure, I could ask the support guys to send me an email when they published relevant KB articles, but that's really not a scalable model – the CSS guys would have to create tons of different distribution lists and would be emailing lots of various people each time they published something.

Instead, I found a really simple way to keep myself notified using Bing search, domain restrictions, and output as RSS. Now I have new KB articles pop up in Outlook when they're published. And, since my RSS feed updates once an hour, I'm at most an hour behind instead of a month. Since this was valuable to me, I thought I'd share it with you too.Note that these instructions are for Outlook 2010. Previous versions may be slightly (or radically) different.

1. In Outlook 2010, Click on File > Account Settings > Account Settings. The Account Settings dialog opens.
2. Click on the RSS Feeds tab
3. Click New. The New RSS Feed dialog opens.
4. Copy and paste the following into the text box: https://www.bing.com/search?q=%22cross+platform%22+AND+%22system+center%22+site%3asupport.microsoft.com%2fkb&format=rss
   • (this searches for "Cross Platform" and "System Center" from the KB site)
5. Click Add. The RSS Feed Options dialog opens.
6. Modify the feed name to something friendly, like "SCX KB Articles"
7. Click Change Folder. The New RSS Feed Delivery Location dialog opens.
8. Expand RSS Feeds and click New Folder.
9. Enter a new folder name like "SCX KB Articles" and click OK.
10. Click OK to return to RSS Feed Options.
11. Check the boxes under the Downloads section if you want to automatically download the whole article
12. Click OK to return to Account Settings.
13. Click Close.

Your new RSS feed is now added to Outlook RSS feeds, and next time you do a Send/Receive, the RSS feed will pull in the items!

You can do this with just about anything that's searchable via Bing, so you could do this with stuff like:

• TechNet Library pages that mention "Cross Platform" and "System Center":

•  https://www.bing.com/search?q=%22cross+platform%22+AND+%22system+center%22+site%3atechnet.microsoft.com%2fen-us%2flibrary&format=rss

• Webcasts and Virtual Labs that mention "Cross Platform" and "System Center"

• https://www.bing.com/search?q=%22cross+platform%22+AND+%22system+center%22+site%3amsevents.microsoft.com&format=rss

One caveat about this is that Bing limits you to 10 items in the RSS feed at a time, so you'll only get the most recent 10 items. But, over time you'll see new things pop up, and that's the goal.

Enjoy!

We are pleased to announce the release of the Systems Center Operations Manager 2007 R2 Connectors Cumulative Update 2! 

Feature Summary:
This updated release includes all features that were in the previous update release (KB975774) and additional fixes in this release:

• Added Support for Remedy 7.5
  • This update enables support for Remedy 7.5 with the Operations Manager 2007 R2 Connector for Remedy.
• Added Support for HP Operations Manager for UNIX v9
  • This update enables support for HP Operations Manager for UNIX v9 with the Operations Manager 2007 R2 Connector for HP Operations Manager. The Connector supports HP Operations Manager for UNIX v9 on the following platforms:
    • HPUX 11i v3 Itanium
    • Solaris 10 SPARC
    • RedHat Enterprise Linux 5.2 x64
• Fixed an issue where incorrect dates are passed to the remote system by the connector
  • The Connector performs an incorrect date conversion and forwards the incorrect date to the remote system.
• Fixed an issue where Product Knowledge is not forwarded when the locale is Canadian English
  • If the locale on the Operations Manager server is set to Canadian English, the Product Knowledge will not be forwarded from Operations Manager to remote system, even if it is configured to do so.

This update is available from the Microsoft  Download Center: 

https://www.microsoft.com/downloads/details.aspx?FamilyID=87c27d91-4549-4169-a87a-ca88e4136e4f&displaylang=en

(part 1)       Scenario #1 - "There were no computers that met the specified discovery criteria"

(part 2)       Scenario #2 - "SSH discovery failed." with "unspecified problem"

(this article) Scenario #3 - "Did not find a matching supported agent"

(part 4)       Scenario #4 – "New computer shows as Platform: Unknown and Version: Unknown"

Scenario #3 - "Did not find a matching supported agent"

I barely got past my last issue, and now in DebugView I see this (note the last line):

[6556] 9| DiscoveryScript.Discovery.Task returned as succeeded 
[6556] 9| Return from DiscoveryTaskHelper.ExecuteOSInformationScript() 
[6556] bd9a8d8f-2686-48f9-9831-a04bb45459c9 | 9 | Return from DiscoveryTaskHelper.ExecuteSSHDiscovery() 
[6556] Microsoft.MOM.UI.Console.exe Information: 0 : 
[6556] bd9a8d8f-2686-48f9-9831-a04bb45459c9 | 9 | 10.10.10.17: ExecuteSSHDiscovery successful. 
[6556] bd9a8d8f-2686-48f9-9831-a04bb45459c9 | 9 | Set MonitoringTaskResult 
[6556] bd9a8d8f-2686-48f9-9831-a04bb45459c9 | 9 | Call to DiscoveryTaskHelper.GetSupportedAgentInfo() 
[6556] bd9a8d8f-2686-48f9-9831-a04bb45459c9 | 9 | Return from DiscoveryTaskHelper.GetSupportedAgentInfo() 
[6556] Microsoft.MOM.UI.Console.exe Error: 0 : 
[6556] bd9a8d8f-2686-48f9-9831-a04bb45459c9 | 9 | 10.10.10.17: Did not find a matching supported agent. 

Ok, so apparently, even though I imported the CentOS management pack and made copies of the Red Hat agents to work for CentOS, OpsMgr still thinks this is an unsupported system. So now what? Well, I have to think of the components that OpsMgr uses to make this determination…

1. The results of the GetOSVersion.sh script
   
   is compared to…
   
2. The CentOS Management Pack class:Microsoft.Linux.CentOS.5.i386.Discovery (since this is an x86 computer)
   
   which then deploys…
   
3. The agent RPM file itself

Let's examine each to see what's going wrong…First the GetOSVersion.sh script. The DebugView output doesn't show anything about the results of running the script, so I go back to the debug logs in the C:\Windows\temp folder and find SSHCommandProbe.log. Looking in this log file, I see this XML was returned:

<DiscoveredOS>
    <Hostname>centos55-x86</Hostname>
    <OSName>CentOS</OSName>
    <OSAlias>CentOS</OSAlias>
    <Version>5.5</Version>
    <Arch>i686</Arch>
    <IsLinux>true</IsLinux>
</DiscoveredOS>

Now I compare that to my MP's discovery class (of which, the "InstanceSettings" part is shown below):

<ClassId>$MPElement[Name="Microsoft.Linux.CentOS.5.SupportedAgent"]$</ClassId>
  <InstanceSettings>
    <Settings>
      <Setting>
        <Name>$MPElement[Name="Unix!Microsoft.Unix.SupportedAgent"]/UnixOS$</Name>
        <Value>CentOS 5 (i386)</Value>
      </Setting>
      <Setting>
       <Name>$MPElement[Name="Unix!Microsoft.Unix.SupportedAgent"]/Version$</Name>
       <Value>1.0.3</Value>
     </Setting>
     <Setting>
       <Name>$MPElement[Name="Unix!Microsoft.Unix.SupportedAgent"]/Build$</Name>
       <Value>106</Value>
     </Setting>
     <Setting>
       <Name>$MPElement[Name="Unix!Microsoft.Unix.SupportedAgent"]/OS$</Name>
       <Value>CentOS</Value>
     </Setting>
     <Setting>
       <Name>$MPElement[Name="Unix!Microsoft.Unix.SupportedAgent"]/Arch$</Name>
       <Value>i386</Value>
     </Setting>
     <Setting>
       <Name>$MPElement[Name="Unix!Microsoft.Unix.SupportedAgent"]/ArchFriendly$</Name>
       <Value>i386</Value>
     </Setting>
     <Setting>
       <Name>$MPElement[Name="Unix!Microsoft.Unix.SupportedAgent"]/ArchKitName$</Name>
       <Value>i386</Value>
     </Setting>
     <Setting>
       <Name>$MPElement[Name="Unix!Microsoft.Unix.SupportedAgent"]/Ext$</Name>
       <Value>rpm</Value>
     </Setting>
      <Setting>
        <Name>$MPElement[Name="Unix!Microsoft.Unix.SupportedAgent"]/MinVersion$</Name>
        <Value>5</Value>
      </Setting>
      <Setting>
        <Name>$MPElement[Name="Unix!Microsoft.Unix.SupportedAgent"]/ComputerType$</Name>
        <Value>Microsoft.Linux.CentOS.5.Computer</Value>
      </Setting>
      <Setting>
        <Name>$MPElement[Name="Unix!Microsoft.Unix.SupportedAgent"]/KitOSVersion$</Name>
        <Value>5</Value>
      </Setting>
      <Setting>
        <Name>$MPElement[Name="Unix!Microsoft.Unix.SupportedAgent"]/TaskVersion$</Name>
        <Value>5</Value>
       </Setting>
    </Settings>
</InstanceSettings>

Comparing the <Arch> element of the script results and the "Arch$" setting in the MP, I see my problem… My MP says "i386" and my GetOSVersion script says "i686". So, My MP is wrong and needs to be changed. And, before I go creating yet another scenario step, I know my agent RPM file name needs to be changed too in order to be consistent. So I will change the "Arch$", "ArchFriendly$" and "ArchKitName$" settings in the MP to "i686" (and increment the version number of the MP) and change my file name to scx-1.0.4-258.centos.5.i686.rpm.

Now I will re-run the discovery and see what happens. Ah-ha! This time it says "Found a matching supported agent". Great! My discovery wizard shows the correct OS and architecture:

Now I can select the computer and deploy the agent. It's successful! Just to show you what that looks like in DebugView, here's the output:

[6556] Entered Install/Upgrade Process 
[6556] Call to executeDeploymentTask() 
[6556] Return from executeDeploymentTask() 
[6556] Microsoft.MOM.UI.Console.exe Information: 0 : 
[6556] centos55-x86: Deployment was successful 
[6556] Entered Install Process 
[6556] Call to executeInstallationTask() 
[6556] Return from executeInstallationTask() 
[6556] Microsoft.MOM.UI.Console.exe Information: 0 : 
[6556] centos55-x86: Installation was successful 
[6556] Call to DiscoveryTaskHelper.ExecuteWSManDiscovery() 
[6556] Return from DiscoveryTaskHelper.ExecuteWSManDiscovery() 
[6556] Microsoft.MOM.UI.Console.exe Information: 0 : 
[6556] centos55-x86WS-Man result validation was successful 
[6556] Call to DiscoveryTaskHelper.SignHostCertificate() 
[6556] Return from DiscoveryTaskHelper.SignHostCertificate() 
[6556] Microsoft.MOM.UI.Console.exe Information: 0 : 
[6556] centos55-x86: Certififcate was signed successfully 
[6556] Begin Post-Process WS-Man Validation Process 
[6556] Call to DiscoveryTaskHelper.ExecuteWSManDiscovery() 
[6556] Return from DiscoveryTaskHelper.ExecuteWSManDiscovery() 
[6556] WS-Man result has no exceptions 
[6556] Call to DiscoveryTaskHelper.GetSupportedAgentInfo() 
[6556] Return from DiscoveryTaskHelper.GetSupportedAgentInfo() 
[6556] Microsoft.MOM.UI.Console.exe Information: 0 : 
[6556] centos55-x86: Post-Process WS-Man Validation succeded 
[6556] End Post-Process WS-Man Validation Process 
[6556] Microsoft.MOM.UI.Console.exe Information: 0 : 
[6556] centos55-x86: Discovery into OpsMgr succeeded 

I click Done to exit the discovery wizard and now I can go see how my new computer shows up in the console. It's not quite what I expect though.

More on that in part 4.

I was originally going to write this as one article and just divide it into sections, but when the word count got over 2500, I thought it would be best to break it up into smaller pieces. I'll go ahead and link all the parts here so you can be sure to get them:

(this article) Scenario #1 - "There were no computers that met the specified discovery criteria"

(part 2)       Scenario #2 - "SSH discovery failed." with "unspecified problem"

(part 3)       Scenario #3 - "Did not find a matching supported agent"

(part 4)       Scenario #4 – "New computer shows as Platform: Unknown and Version: Unknown"

Tools and Logs Mentioned

I'll be talking about a number of tools and log files for this set of articles, and for your convenience, I'll summarize them here:

• DebugView is one of my favorite tools for troubleshooting issues with installation of UNIX and Linux agents. The reason is that it shows me information that doesn't appear in the module logging, and it's quicker than activating and viewing the overall OpsMgr trace logging. Using DebugView, I can start it, begin a discovery, and see debugging information output to the DebugView window in real time. In this article, I will discuss a few scenarios and how DebugView can help you resolve them.
• Module Debug Logging is a set of log files that are generated when you enable them using the process described here.
• OpsMgr Trace Logging is another set of log files generated when you enable trace logging using the process described here.
• SCX Agent logs and CIM logs are the log files on the Unix or Linux computer, and are controlled using the process described here.
• WinSCP and PuTTY are tools for remote file sharing and remote login to Unix and Linux computers from Windows.

Discovery Process Flow

First of all, it's helpful to understand the actual agent discovery and installation process. Here's a diagram of that:

Scenario #1 - "There were no computers that met the specified discovery criteria"

When you do a discovery and you see the following message in the discovery results, it can sometimes be a little difficult to figure out.

In this example, I entered an IP address (not a DNS name) in the discovery criteria, and I knew I had the root account correct, so I wondered what it could be. Maybe DNS reverse lookup? I go and check DNS settings (my HOSTS file) and it has my Linux computer in there so that shouldn't be the problem. Going to DebugView output, I see this:

[11160] initializeWorkers 
[11160] Initializing _workerSupportedUnixAgents 
[11160] Initializing _workerAvailableUnixAgents 
[11160] Begin Supported Agent Info Query 
[11160] Begin Available Unix Agents Query 
[11160] Microsoft.MOM.UI.Console.exe Information: 0 : 
[11160] Supported agents result: {### lots of XML here ###}
[11160] Microsoft.MOM.UI.Console.exe Information: 0 : 
[11160] Available agents result:  
[11160] Queries completed 
[11160] Microsoft.MOM.UI.Console.exe Error: 0 : 
[11160] One of the queries returned a null value 

So if I look at this output and compare it to the flowchart of discovery steps above, it looks like the process to find the list of supported agents worked, but the process to actually find the available agent files returned nothing. I actually know this is supposed to return an XML-formatted list of the files in that directory, so the fact that it's not means something's going wrong in running the script that gets that list.

I know that the agent files are located in the following directory:

C:\Program Files\System Center Operations Manager 2007\AgentManagement\UnixAgents

Going to that directory, I see a bunch of agent files. So if I can browse that directory and see files, but OpsMgr can't get a list of files, what's going on? I know that OpsMgr runs under a configured set of user credentials (not just the logged in user), so maybe it's there? Oh yeah, I remember that I had to change the admin password the other day, but I guess I forgot to change it in OpsMgr.

I go to the Run As Configuration settings and update the password in the administrator account, and re-run the discovery. It's still not completely succeeding but I'm past the point I was. The DebugView output now shows this:

[6556] initializeWorkers
[6556] Initializing _workerSupportedUnixAgents
[6556] Initializing _workerAvailableUnixAgents
[6556] Begin Supported Agent Info Query
[6556] Begin Available Unix Agents Query
[6556] Microsoft.MOM.UI.Console.exe Information: 0 :
[6556] Supported agents result: <SupportedAgents>
[6556] aris.10.Computer" KitOSVersion="10" TaskVersion="10" DisplayName="Solaris 10 (x86)" />
[6556] Microsoft.MOM.UI.Console.exe Information: 0 :
[6556] Available agents result: <SupportedAgents>
[6556] Queries completed
[6556] Call Submit Discovery Task
... (more after that)

After fixing the above, the discovery details in the UI shows this:

More on this in part 2!