More often than not, the issue has to do with targeting within the report. It makes sense when it’s explained, but there’s still an element of logic in building the report that needs to be discussed.

When I deliver one of the OpsMgr workshops, I demo a specific example to illustrate what is going on and drive a few learning objectives along the way.

A Practical Example

Let’s say you want to report on the free disk space for a group of servers.

• In the Administrator Console, under Reporting, Microsoft Generic Report Library, select Performance Detail and click on Open:

• In the Report View, select standard parameters for Data Aggregation and time range (From / To), then click on Change.. to create a new series:

• Create a New Series, and select the Rule. In this case, select Logical Disk Free Megabytes 2008.

The problem comes when you choose between the Add Group… and Add Object… buttons:

Add Object…

In the case of free disk space, you probably want a report based on servers (or agents). For example, you would like to list the free disk space for a subset of servers (or even just a particular server), so you believe selecting Add Object… would be the way to go:

Unfortunately, this will result in an empty report:

Add Group…

If instead, you select Add Group…:

Then the report will contain data:

Targeting

So what’s going on and what’s the different between Add Group… and Add Object…?

This is where targeting comes into play.

In this case, the performance collection rule Logical Disk Free Megabyte 2008 is targeted at the instances of Windows Server 2008 Logical Disk. That makes sense, but when you select Add Object…, you don’t select Windows Server 2008 Logical Disk instances, you select an instance of Windows Computer. Because the rule is not targeted at that class, no data is associated with it.

If you select individual instances of Windows Server 2008 Logical Disk as objects, then data would show up in the report:

Logically, if you build reports for free disk space, you want to order/sort/group be servers and then their drives. Having a report of all C: drives in your environment isn't easy to read, but because the performance collection rule is targeted at a different class than Windows Computer, you need to select Add Group… for any data to display.

I’ve also seen confusion (which I experienced myself before sorting this thing out for myself) with the fact that the “group” in Add Group… doesn’t have the same meaning as “groups” in the Administration Console, under Authoring. In the report case, it refers to contained objects: the Windows Server 2008 Logical Disk instances are contained within the Windows Computer object. In the Authoring section of the Administrator Console, it refers to a collection of objects such as “all c: drives”.

Final Thoughts

Hope this helps clarify why some reports return no data. The support knowledge base has a troubleshooting KB article on empty reports for other cases, especially cases involving issues with OpsMgr.

Comments welcome!

In this blog post, I will demonstrate how to use the OpsMgr PowerShell cmd-let to deploy an agent through a script and still retain the advantages of a push-installation.

Push Versus Manual Installation

A “push” agent installation is done through the administrator console; in contrast, a manual installation is often done by either installing from the OpsMgr installation media or running the momagent.msi package from one of the management servers (or copying the directory somewhere else).

One of the biggest drawbacks of the manual installation method is that it prevents you from managing the agents from the console. You cannot change the Primary Management Server that the agent reports to, repair, or uninstall the agent from the console. Of course, if your organization mandates that you deploy software from a centralized location, the mandate probably extends to uninstalling as well; therefore, you may not have an incentive to remotely manage agents for those two cases.

The figure below shows the options that are not available (i.e., greyed out) when an agent is installed manually (right figure) versus the push method (left figure):

In the case of changing the agent assignment, however, or repairing the agent as part of troubleshooting, being able to do so from the console is still valuable.

Install-SCOMAgent cmd-let

You can use a PowerShell cmd-let called “Install-SCOMAgent” to install an agent from a script that results in a “push” installation.

Param(

[string]$agent

)

Import-Module operationsmanager

New-SCOMManagementGroupConnection

$PrimaryMS = Get-SCOMManagementServer –Name <fqdn_of_Management_Server>

install-scomagent –dnshostname $agent –PrimaryManagementServer $PrimaryMS

• The script starts by defining the parameter $agent, which will be the FQDN of the agent we want to deploy to.
• Then the OpsMgr PowerShell module is loaded (Import-Module operationsmanager).
• Next, the script will connect to the Management Group (New-SCOMManagementGroupConnection).
• Then we define the Primary Management Server for the agent to report to. Note that you could change this to a parameter to be passed to the PowerShell command, much like that agent name. I chose not to for two reasons:
• To avoid mixing the agent and management server name in a command line that runs the script; and
• To easily change which Management Server the agent reports to from the console once the agent has been deployed.

The picture below shows the PowerShell script and the command line with the agent parameter.

Notes on Running the Script

A few notes on running this script:

1. The script needs to run on a server where the operationsmanager PowerShell module is present, such as a Management Server.
2. I did not specify any accounts to run the installation. The parameter, –ActionAccount, can be used to specify an installation account. If the parameter is not specified (as is the case in this example), the default Management Server Action Account will be used; it needs to have the necessary rights to install software on the agent.

Since the PowerShell script runs from the Management Server, it is essentially a command line version of the console push. However, since it is scripted, it can be deployed through a centralized method such as SCCM, which would provide all the reporting and control sometimes mandated by IT organizations.

Comments welcome!

1. testing the script,
2. mapping the script parameters, and
3. generating the report using data collected by the probe.

I’ve also recreated the probe in an Operations Manager (OpsMgr) 2012 SP1 environment to verify functionality. The previous post was done in a 2007 R2 environment.

1. Testing the Script

If issues exist with your script, you will not know until the collection probe runs on an agent. If an issue exists, however, the agent will have errors or warnings logged in the local OpsMgr event log. I recommend testing your script outside of OpsMgr first.

Testing Outside OpsMgr

Here’s the same script tested outside of the OpsMgr probe with some modifications:

Note a couple of changes:

• I’ve commented the line “drive = oArgs(0)”. Within the probe, this is the parameter for the drive name that OpsMgr will send to the script. To find the right one, I’ve literally used trial and error to find out which one works.
• The line has been replaced (for testing) by drive = “c:”. This is where you might want to try the various drives on a particular server to see what kind of results it creates.
• The command msgbox(diskusedGB) will output the result of the calculation in a message box.
• The last three lines have been commented; they are specific to OpsMgr, so they are not needed until we create the probe.

Once I run the script against a particular server/drive, I get the following output (from the msgbox function):

A value like this is what I would expect to be returned to OpsMgr and written to the data warehouse.

On Error Resume Next

The script doesn’t contain any logic to determine if an instance of logical disk should be skipped (e.g., a reserve partition). Therefore, if a server contains one or more instance of logical disk for which the script would fail, we need to account for it in the script, hence using On Error Resume Next.

As an example, I’ve run the script, without On Error Resume Next, against an empty  CD-ROM drive and received Error 800A005E (below).

If I run the script with On Error Resume Next, there’s no output error. Of course, CD-ROM is not an instance of a logical disk, but it illustrates the point of adding On Error Resume Next.

2. Mapping the Script Parameters

Since some time has passed since the original posting, I recreated the rule in an OpsMgr 2012 SP1 lab to see if there where any differences, especially with some of the properties for the logical disk class. I did notice that the parameter for the drive name is now called “Device Identifier”. When I first created the rule, it was listed as “Device ID”, which is what I have in the original post.

This parameter is the value that OpsMgr will send to the script (“oArgs”).

3. Generating the Report

Here’s one tip to find the rule you created. When you create a performance report and select the rules, you can display all the rules stored in a particular management pack. In my case, I’ve stored the rule in “MG1 – Custom Rules and Monitors”, so I’ve selected the Management Pack (MP) and searched for blank (which represents all).

• In the Operations Manager Console, under Reporting, select Microsoft Generic Report Library, Select Performance Detail.
• Under Objects, click on Change.
• In the Settings windows, select New Series, and then in the Series Details, click on Add Group and select the desired agent(s).
• Under the Rule option, click on Browse…
• Change the Management Pack Name to the one where you saved the collection rule. Click on Search (this will return all rules saved in the MP):

Final Thoughts

I hoped that the clarifications in this posting provide more help. Comments welcome.

Two unfortunate situations arise from this:

1) Monitoring gaps: an issue occurs with a monitored technology (e.g., Active Directory or AD) and someone asks, “why didn’t OpsMgr send an alert about this?”

2) False positives: a large number of alerts are generated for a specific technology, but in reality, everything is fine.

Here are some pointers from the OpsMgr perspective that I’ve used with customers that have yielded positive results and reduced the two issues above.

Start with the Guide

As an OpsMgr admin, review the Management Pack (MP) guides not only before first importing the MPs, but also look at the changes when importing an updated MP.

To initiate meaningful discussions with the SMEs for the technology being monitored, begin by focusing on the relevant sections from the guide. Focus on the optional configuration and key monitoring sections.

Below is a screenshot of the table of content of the AD management pack, version 6.0.8070.0. We’ll use this one for our discussion, but the same applies to all technologies.

The sections within the red boxes are good for discussions, because they contain a lot of AD language. This will give the AD team some insight into the monitoring scenarios that OpsMgr can support—once they’ve been configured. This last point is key: some of these monitoring scenarios need to be enabled and configured.

Go Deeper with MP Viewer

Next, leverage the MP Viewer utility to review what rules and monitors are defined and enabled and what their configuration or thresholds are set to. With MP Viewer, you can look at the various components in an MP (rules, monitors, views, etc.) offline and in a format easy to consume:

I like to center early discussions around monitors and rules as they provide alerts and reporting, the most visible OpsMgr items to the SMEs.

To take this further, create an export of the rules and monitors from the MP Viewer utility to an Excel or HTML file.

From within MP Viewer:

1. Click on File.
2. Click on Save to Excel, or alternatively.
3. Click on Save to HTML.

Below is a screenshot of the Active Directory Server 2008 Monitoring MP exported to an Excel file:

The exported file can be manipulated further to hide information that isn’t relevant to the discussion at this point. Make sure that what is exposed is useful for the technology SMEs who will get a copy of these.

From here, you can have meaningful and effective discussions with the SMEs on rules and monitors that are relevant, missing, or that need adjustments.

Final Thoughts

Finally, if you are a Microsoft Premier customer, talk to your TAM about services that are offered where an OpsMgr PFE (like myself) and a technology PFE (AD, SQL, SharePoint, Exchange, etc.) can go onsite and help you and the other technology team better leverage and tune the MP for you environment.

Comments welcome.

Three Parts of a Notification

In the Administrator Console, under Administration and Notifications, three folders are available: channels, subscribers, and subscriptions. Together, these are components are used to create notifications.

Think about these components as…

Channels – how the notification will be sent and what it will look like

Subscribers – who will get the notification and when they will receive it

Subscriptions – which alerts will be sent

Simple enough, or so it seems…

Don’t create an “All Alerts, All the time to Everyone” subscription… unless you mean it!

One of the least useful ways to leverage notifications is to create a single subscription for all alerts. That is, all alerts raised by all agents, regardless of severity, sent to one or more persons. That’s usually not very effective for a few reasons:

• You don’t need a very large environment before the number of alerts generated daily will dwarf the capacity for anyone to process.
• You end up treating every alert as equal in priority, regardless of the source (e.g., a tier-1 DB versus any random services on any server).

Some exceptions do exist when this is useful, however. For example, some customers would send the alerts to a folder or mailbox automatically monitored by a helpdesk/service desk software. The service desk software would pick up the new emails and generate service desk tickets and/or incidents based on those alerts.

If you are still working this way today, look at Systems Center Orchestrator for automating and maintaining the OpsMgr alerts lifecycle within your helpdesk/service desk.

Using Subscriptions

Instead of creating an “all alerts, all the time to everyone” subscription, use the flexibility of the components that make up a notification (channels, subscribers, and subscriptions) to create notifications that will route the right alerts to the right people, at the right time. Below are a few pointers with using those components:

Channels

Many OpsMgr administrators who only use SMTP channels (i.e., emails) may miss out on the fact that through the same delivery method (for example, Exchange), you can create two versions of the same notification, but with a different consumption device in mind. For example, for alerts on a smartphone, you may want less information than the same alerts being read through a full email client such as Outlook.

On the Format window of the channel, you can modify the subject and message.  Below shows the default content:

As shown below, you may add the text <Short> in the subject line (presumably to indicate a message format for smartphones) and remove a number of parameters from the message body to only send the essential information, which will be easier to read on a small screen.

Another use for multiple channels is to generate various email subjects for easier filtering. An example would be to prepend <ACTION REQUIRED> to specifically critical alerts (for example, alerts related to certain LOB components).

Subscribers

Subscribers allow you to specify when to send notifications in addition to whom to send them to. In conjunction with the multiple channels options discussed earlier, you could have alternative formats sent to the same person depending on the time of day.

As an example, you could receive verbose critical alerts between 8 am and 6 pm, when you’re expecting to consume the alerts through your Outlook client, but receive shorten messages on your Windows Phone after business hours.

Try to leverage distribution lists for subscribers, even with few recipients. They offload the management of subscribers outside of OpsMgr and allow you to easily add or remove individuals as needed such as when an administrator goes on vacation or if you have an after-hours support rotation.

Subscriptions

So far it’s been pretty easy: channels and subscribers are straight forward to understand. Subscriptions however, are more complicated. That’s because they provide the flexibility of sending alerts from a combination of criteria such as which class or group raised the alert, the severity and priority rating, and also custom fields.

Don’t go overboard with subscriptions, especially with subscriptions that are filtered out to a single rule or monitor. Things can get out of hand quickly here.

Remember that much like actionable alerts in the console, you want the notifications that are being sent to also be actionable. Some planning should go into building notifications in order to get the most out of them.

Subscriptions have an option for “Alert aging” (see below), which tells OpsMgr to hold off sending the notification until a set number of minutes have passed and if the conditions remain unchanged. This is very useful to create an escalation notification. In the screenshot below, a delay of 25 minutes has been set. This would be used for example, to ensure that if after 25 minutes if an alert hasn’t been addressed (acknowledged/closed/etc.), then an alert would be sent to a second subscriber, such as a team lead or escalation team.

A few nifty tricks and other resources

• Kevin Holman has a few interesting posts on advanced notifications:
• Using OpsMgr notifications, and
• Creating granular alert notifications, which describes how to make changes to the criteria logic directly from the xml file (i.e., the MP that contains the notifications).
• Steve Rachui has one that’s a bit outside the box: using PowerShell to modify alerts through a subscription.
• Stefan Stranger has a blog post on pushing notifications to your Windows Phone.

Final Thoughts

So there you have it. There’s no need to limit notifications to one for all. Through the careful planning of channels, subscribers, and subscriptions, you’ll avoid subscriptions becoming a spam engine and instead be useful for the recipients.

Comments welcome.

Why are MPs updated?

If you’ve authored your own MPs, you’ll understand the amount of complexity involved with building monitoring scenarios and the increasingly better ways to implement those monitoring scenarios or discoveries. Monitoring scenarios themselves may change over time based on business goals and requirements. Also, the possibility of mistakes or errors may be introduced in MPs. For Microsoft and other third parties that build MPs professionally, user feedback is another source of change (e.g., customers may find that certain monitors are too noisy or do not provide the value originally intended and get deprecated).

What about my organization’s customizations?

You may be wondering what would happen if an update to an MP was conflicting with overrides you created for your organization. For example, what if you created an override for a monitor that was too aggressive in the original MP, but the updated MP was even less aggressive than yours?

At a high level, overrides stored in an unsealed MP will “win” over overrides stored in a sealed MP. If your organizations’ overrides are stored in a sealed MP (for change management purposes), whichever one is the more specific will be applied. For example, an override applied to a group of servers will “win” over an override applied to a class.

Where do I find MPs?

A number of resources outside of the OpsMgr Console are available for keeping up to date with the latest MPs.

• Systems Center Marketplace on PinPoint is a website that keeps track of the latest MP offerings from Microsoft and 3^rd parties. Good for downloading the MP guide at the same time.
• The OpsMgr Engineering team blog will often post information regarding new MPs.
• A new TechNet Wiki from Daniel Savage is intended to be a one stop shop for Microsoft MPs.
• Fellow PFE, Stefan Stranger, has posted a blog on using PowerShell to extract the list of MPs from the catalog.
• A number of Microsoft bloggers will either post on their site (such as Kevin Holman) or tweet when new MPs are released (such as myself!).

Finally, in the Operations Manager Administrator Console, an option exists to download MPs.

Downloading MPs

In the Administrator Console, under Administration, click on Management Packs. There are two actions on the right side pane, “Download Management Packs…” and “Import Management Packs…” (see below):

After clicking on Download Management Packs…, click on the Add button (see below):

Click on the Search button to look for all MPs available in the catalog (below). Feel free to type in keywords in the Find field for something specific (like SharePoint) and also experiment with the options in the View field:

A word of caution on using the administrator console directly to update management packs. Be careful if you import MPs directly from the MP catalog to only do one or two at a time. A few reasons for this:

1. The MP catalog allows you to easily import multiple MPs at a time, a practice that could introduce a lot of noise in an environment and make it difficult to tune MPs.
2. The MP catalog also allows you to skip over reviewing the MP guide, a practice that should be observed. After all, administrators will usually review the content of Service Packs before applying them to operating systems or applications.
3. It’s also easy to inadvertently import MPs in other languages.

Importing MPs

Before importing MPs into your environment, download them along with their guide. Ideally you want to maintain an offline store of the MPs imported in the environment. Download them on a network location so that you have a record of which MPs were imported and when.

A little trick exists in the console that often goes unnoticed: under the Information column in the catalog wizard is a hidden link to the MP guide. Click on it to download the MP guide.

After reviewing the MP guide–a quick process for updates, since you’ve already reviewed the MP guide when first imported ()—you should only need to review the changes. Pay special attention to rules and monitors that may have been disabled or deprecated or thresholds that may have changed. This could resolve in alerts that you expect, but are no longer raised. Import the MPs one by one.

Once the updated MPs have been imported, review any new alerts that may be raised.

Final Thoughts

Keeping the management packs in your environment up to date is important. MPs are updated to be more efficient, reduce noise, enable new monitoring scenarios, and address errors or issues that an MP could have encountered. Updating your MPs should be done regularly, ideally once a month.

Comments welcomed.

The TechNet library has a good entry on the impact of closing alerts generated by monitors or rules, but here’s the crux of it:

1. Closing alerts generated by rules is generally ok. If the alert condition still exists, the alert will be raised again.
2. Closing alerts generated by monitors will not be raised again if the condition still exists.

Manually closing alerts raised by monitors is generally bad practice. Monitors will not raise an alert again unless their state goes back to healthy then to unhealthy.

Why is this bad? Well, for one thing, the health model of a particular component goes out of sync with reality – this means that what you see in OpsMgr doesn’t reflect reality. This reduces the effectiveness of OpsMgr and the value of centralized monitoring.

The reality of many IT Monitoring teams, however, is that not every alert can be attended to, especially during periods of transition such as an influx of new servers/applications or the introduction of a new management pack (i.e., the tuning or stabilization period).

To help you during those times, wouldn’t it be nice to have an alert view that tells you which alerts have been raised by monitors and which alerts have been raised by rules? In OpsMgr 2012, you can do that thanks to widgets.

Note: in OpsMgr 2007 and later you can find this information in the alert details. In this post, however, you’ll create a view so that you can see at a glance the split between the two types of alerts.

Steps

• In the OpsMgr administrator console, click on the Monitoring button and right-click on Monitoring, New, Dashboard View

• In the Select a dashboard layout or widget template window, select Column Layout. Click Next.

• In the Enter a friendly name and description window, type a name for your view (e.g., Contoso Alerts by Type). Optionally, put in information to describe the view in the Description section. Click Next.
• In the Specify the number of columns window, leave the Number of columns to 1. Click Next.

• On the Summary page, click Create.
• On the Completion page, click Close.

• Click on the newly created dashboard view, which will be blank, and click on the Click to add widget… link.

• In the Select a dashboard layout or widget template window, select the Alert Widget template. Click Next.

• In the Enter a friendly name and description window, type in a descriptive name (e.g., Contoso Monitors vs. Rules Alerts). Optionally, enter a description for the widget in the Description field. Click Next.
• In the Specify the Scope window, leave it to (All). Click Next.
• In the Specify the Criteria window, select the desired criteria. For example, to display all open alerts, select the Critical, Warning, and Information severities along with the New (0) resolution states. Click Next.

• In the Display window, select the display preferences such as severity, name, age, repeat count, etc.
• Still in the same page, select the column Is Monitor Alert and add it to the Group by field. This is the key to our view. Click Next.

• On the Summary page, click Create.
• On the Completion page, click Close.

The dashboard view will now display alerts grouped by monitors (Is Monitor = True) or rules (Is Monitor = False).

This view will now help operators and support personnel triage the alerts a bit further.

Hope this helps! Comments are welcome!

I’ll also be making a quick modification to the MP using the Operations Manager Authoring Console to demonstrate how the MP Authoring lifecycle works out when using multiple authoring tools.

Note: For more details on using VMPD including an excellent example, I highly recommend this TechNet Wiki.

The overall steps for monitoring system uptime with VMPD and OpsMgr Authoring Console are…

1. Create the base MP using VMPD
2. Modify the MP using the OpsMgr Authoring Console
3. Deploy the MP

Let’s get going!

Step 1 – Create the Base MP Using VMPD

Note: If you’re not familiar with how to setup the VMPD tool and the required prerequisites, first refer to this TechNet Wiki.

Fill in the Management Pack information using the screen shot below as a guide. Change the value of “Connector Mode” to “FALSE”.

Next, drag over a Server Component shape and fill in your discovery using the information below as a guide.

I want to point out here that the Registry Key used is Software\Microsoft\Windows – meaning all Windows installations. I did this mainly for the purpose of this blog posting; however, in an enterprise setting, you want to make sure that you target your discovery as specific to your needs as possible. If you don’t need to implement this monitoring scenario on every single Windows agent deployed, pick something more specific. Many customers will add registry keys to their server installations for this purpose (e.g., Software\Contoso\LOB1, Software\Contoso\infrastructure, etc.)

Next, drag over the Windows Performance Counter Monitor shape and fill it in using the information below as a guide.

The hard part here is to make sure that you have the right performance counter Object and Counter.

Note that this simple screen provides you with…

• A monitor with thresholds set and alert configured
• A performance collection rule
• A report

Long time Authors will surely realize how much effort has been saved in a few clicks. Also note that behind the scene, the VMPD will create monitoring views for you as well.

Lastly, generate the MP. For more information on this step, see this TechNet Wiki article.

You now have a fully functional MP that will work in either an OpsMgr 2007R2 or OpsMgr 2012 environment.

However, some configurations should be modified, but just can’t be done in the VMPD. For example, you were unable to specify how often your discovery is running. You may wish to check that out and perhaps modify the value.

Step 2 – Modify the MP Using the OpsMgr Authoring Console

Next, open up the MP in the Authoring Console. Feel free to poke around to see what’s been created for you already. Veteran MP Authors should be impressed .

Since you are monitoring against all Windows Servers, you probably want to change the discovery schedule. Find the SEED discovery; right click; click on Property and modify it (see below). The default value is 14400 (4 hrs).

If you are new to MP Authoring, I may have lost you at “SEED discovery”. No sweat; here’s a good explanation and how/when to use it.

Now here’s the key. When you generated the MP using the VMPD, you began a one-way trip with your MP. Since Visio cannot read the MP format (sealed or not), you cannot open a generated MP using Visio.

What does this means? Well, for one thing, once you make changes to the MP (which you did using the Authoring Console), if you want to change your base MP (for example, you also want to add Windows Event Monitors/Rules), you have two choices:

1. Add the extra components (e.g., Windows Event Monitor/Rules) to the MP using the Authoring Console, OR

 

2. Add the extra components to the original Visio drawing, re-generate the MP, and remake the modifications to the new MP using the Authoring Console.

Depending on the extra modifications to make, you’ll need to judge where effort is best spent. If all you did was change the discovery schedule or change whether a discovery/monitor/rule is disabled by default, it may be ok to make those changes again.

In order to avoid confusion and mix up (you thought you added this monitor ages ago), be very diligent in your versioning and documenting of your custom MPs. For example, once you modify your MP  in the Authoring Console, increment the MP version number and add a comment to the description field. See below.

Step 3 – Deploy the MP

Once imported, you now have custom classes, a monitor, a performance collection rule, some views, and a report, and it took you minutes to get it done using the VMPD as a base.

Final Thoughts

I’m hoping that this exercise has driven home the point on how powerful the VMPD tool is. Sure you could have created a monitor and a performance rule based on this single performance counter (system uptime) easily through the administrator console, but the addition of views and a report is where the extra work and multiple components become more tedious.

More importantly, you now have a good base MP on which to extend your monitoring. And you’ve also done all that work offline, while the administrator console is working against the live environment.

Comments welcome.

Not a big deal as I’m bilingual, but for consistency, I wanted the collective results to be in one language--English. 

I collected data from the various OpsMgr servers that were part of a particular Management Group (RMS, MS, DBs, etc.) and then saved the binaries (.blg) and then copied them to a central location. I used Perfmon to export the data as CSV files, which I was then planning on consolidating for my analysis and report.

After collecting the data, I found myself needing to translate a number of column headers from French to English (for example “Disque Physique” to “Physical Disk”).

How did I resolve this? Using a script of course! Let’s go through the steps.

Once the data collector set has been created and the data has been collecting for a certain length of time in a binary (.blg) file then…

1. Copy the .blg file somewhere where you’ll make your modifications (e.g., c:\temp\myperfcollections)
2. Open the .blg file with Perfmon; right click on the data diagram and select Save Data As…
3. Save the data as “Text File (Comma delimited) (*.csv)” (see below)

Next, create a VB Script that will create an instance of Excel and do a programmatic “find and replace”.

   1:  On Error Resume Next

   2:   

   3:  Set objExcel = CreateObject("Excel.Application")

   4:   

   5:  objExcel.Visible = True

   6:   

   7:  Set objWorkbook = objExcel.Workbooks.Open("C:\temp\mgr.csv")

   8:   

   9:  Set objWorksheet = objWorkbook.Worksheets(1)

  10:   

  11:  Set objRange = objWorksheet.UsedRange

  12:   

  13:  objRange.Replace "Disque physique", "PhysicalDisk"

  14:   

  15:  objRange.Replace "Taille de file d'attente du disque actuelle", "Current Disk Queue Length"

  16:   

  17:  objRange.Replace "Processus", "Process"

  18:   

  19:  objRange.Replace "% Temps processeur", "% Processor Time"

  20:   

  21:  objRange.Replace "Plage de travail", "Working Set"

  22:   

  23:  objRange.Replace "Fichier d'échange", "Paging File"

  24:   

  25:  objRange.Replace "Pourcentage d'utilisation", "% Usage"

  26:   

  27:  objRange.Replace "Disque logique", "LogicalDisk"

  28:   

  29:  objRange.Replace "Usage maximal", "% Usage Peak"

  30:   

  31:  objRange.Replace "Moy. disque s/écriture", "Avg. Disk sec/Write"

  32:   

  33:  objRange.Replace "Moy. disque s/lecture", "Avg. Disk sec/Read"

  34:   

  35:  objRange.Replace "% Durée d'inactivité", "% Idle Time"

  36:   

  37:  objRange.Replace "Mégaoctets libres", "Free Megabytes"

  38:   

  39:  objRange.Replace "Transferts disque/s", "Disk Transfers/sec"

  40:   

  41:  objRange.Replace "Mémoire", "Memory"

  42:   

  43:  objRange.Replace "Entrées libres en table des pages système", "Free System Page Table Entries"

  44:   

  45:  objRange.Replace "Mégaoctets disponibles", "Available MBytes"

  46:   

  47:  objRange.Replace "Système", "System"

  48:   

  49:  objRange.Replace "Octets de réserve paginée", "Pool Paged Bytes"

  50:   

  51:  objRange.Replace "Octets de réserve non paginée", "Pool Nonpaged Bytes"

  52:   

  53:  objRange.Replace "Changements de contexte/s", "Context Switches/sec"

  54:   

  55:  objRange.Replace "Longueur de la file du processeur", "Processor Queue Length"

  56:   

  57:  objRange.Replace "Temps d'activité système", "System Up Time"

  58:   

  59:  objRange.Replace "Interface réseau", "Network Interface"

  60:   

  61:  objRange.Replace "Bande passante actuelle", "Current Bandwidth"

  62:   

  63:  objRange.Replace "Total des octets/s", "Bytes Total/sec"

  64:   

  65:  objRange.Replace "Longueur de la file d'attente de sortie", "Output Queue Length"

  66:   

  67:  objRange.Replace "% Temps privilégié", "% Privileged Time"

  68:   

  69:  objRange.Replace "% Temps d'interruption", "% Interrupt Time"

  70:   

  71:  objRange.Replace "Nombre de handles", "Handle Count"

  72:   

  73:  objRange.Replace "Temps d'activité System", "System Up Time"

  74:   

  75:  objRange.Replace "Processeur", "Processor"

The script is straight forward--just match the objects/counters in one language for another. Feel free to create a translation between any two languages by replacing the text in the script.

Remember to replace the location of the CSV file in the script with your own (this one is “c:\temp\mgr.csv” – line 7) and run from an elevated command prompt.

I could have done this work manually, but where’s the fun in that?! Now I have another “tool” ready to go for the next occurrence and I can easily create the reverse-–flip the terms around and the script will translate from English to French.

QED! (Quite Easily Done!)

Ideally, we’d like our OpsMgr environment to be fine-tuned so that the environment…

1. only generates alerts for something that will be actionable; and
2. only collects data that has value to our organizations.

That sounds nice and is relatively easy to get to when you are starting an implementation of OpsMgr, but what if you’ve inherited an environment where fine tuning didn’t really go as planned?

Well, one option to regain control of your environment, without having to rebuild everything or take out every management pack, is to use Distributed Applications to surface what’s critical to your organization.

What is DA?

Distributed Applications, DA, (not to be confused with Direct Access–-an awesome piece of technology in its own right) is a feature in OpsMgr that allows us to combine and group any discovered objects into a logical arrangement and roll up the health of the group into one availability monitor thus generating a single alert. This last part is key and often overlooked when building a DA.

A Scenario – Database Tiers

Let’s say we’re looking after SQL database health and availability in our organization using OpsMgr. In a large organization, OpsMgr may discover and monitor hundreds or even thousands of SQL DBs, each one that can go offline, run out of space, fail to backup, experience disk IO contention, etc. How can we prioritize these alerts?

In the case of databases, some good tricks exist out there to reduce non-actionable alerts (like disabling the discovery of certain DBs altogether), but maybe we still have a large number of DBs where things can go wrong.

The SQL DB view is a good place to start.

We can then reduce this administrative task further and embed some simple logic into our monitoring.

Creating our Simple DA – All Tier 1 DBs

• Start the OpsMgr Administrator Console.
• Under Authoring, right-click on Distributed Applications and Create a new distributed application…

• When the Distributed Application Designer wizard comes up, fill in the information. Remember to be accurate and descriptive to facilitate reuse and troubleshooting.

• Chose the Blank(Advanced) template so that we can build the DA as we want. Click OK.
• On the next screen, we look for all the DBs that have been discovered.
• Click on Advanced Search

,

• In the Advanced Search window, under Search for: select Database and click Search (leaving the search field blank will return any value). All the discovered objects of type Database are returned.
• Select the databases that you want to include in your DA and click Add.

• On the Advanced Search Result pane, right click on one of the databases and select add to New Component Group (since we haven’t created one yet).

• Name your component and click OK:

• Select the rest of the databases from the search result and right click; then add to the component group we just created.
• Save the distributed application and then Configure the Health Rollup – Availability at the bottom:

• After clicking on Configure Health Rollup – Availability, you can change the various parameters such as alert severity, priority, etc.
• The parameter we are interested in here is Generates Alert, which is disabled by default. Change the Override Value to True and click Ok.

Now let’s test to see what happens. When we put one of our databases “test_cloned” offline, an alert is generated:

So how are we better off than before?

The idea is to help us prioritize our remediation work while we develop a longer term strategy and tune our environment. So here’s what this DA alert gives us:

1. One single alert for any of the tier 1 DBs instead of an alert for each single one. From a notification subscription perspective, we get one alert and get on it. All DBs in that DA are critical.
2. Similarly, for our tier 2 DBs, we could then create a tier 2 database DA (i.e., Contoso Tier 2 DBs). If both alerts are raised within the same timeframe, we know which one to devote resources to first – and that’s the whole point!

I’d like to stress once more that this tactic shouldn’t be used as a free pass to ignore the other alerts. It’s just a way to have the critical alerts filter out to the top. If you can only work on a limited number of alerts in one day, this technique allows you to address the key items first.

What do you think? Would a DA allow us to better prioritize our alerts?

For more information on Distributed Applications, see: https://technet.microsoft.com/en-us/library/hh457612.aspx