Now that System Center Operations Manager no longer has that pesky Root Management Server role; a server role that in larger environments quickly became the choking point and made creating a fully Highly-Available SCOM-environment both complex and frustrating to maintain and with little gain at that. With that gone and the SDK Service, or Data Access Service, thriving on all of the Management Servers HA suddenly became pretty simple. All you have to do in SCOM2012 to make sure your management groups keep on kicking is to have at-least two Management Servers and your databases clustered.

This new distributed architecture does not only give easy HA, it also makes it possible to connect to the SDK-service—be it using the Operations Console or powershell to name two options—on any Management Server. This, in turn, provides for a completely new level of scalability. Choked on sessions? Deploy a new Management Server!

Anyway… given all this scalability and HA, would it not be nice if you could load-balance all these SDK-sessions you are going to be running from System Center Virtual Machine Manager, System Center Service Manager, System Center Orchestrator, regular scheduled powershell scripts and what-not?

Of course it would! And you can! The simple solution is to use the built-in Network Load Balancer (NLB for short) feature in Windows Server and that’s what we’re going to discuss in this post.
Before we go, I’d like to point to a great article written by Justin Cook that is covering most bases but in a less for-dummies manner. So, yeah… I suppose this is the for-dummies version then.

Enjoy!

Prerequisites

We need to have the Network Load Balancing feature installed on all our targeted Management servers. The quick way to do this is using command-line (Windows Server 2008 R2 or later?).

dism /online /enable-feature /featurename:NetworkLoadBalancingFullServer 

You also need a plan and some information about your new cluster. Make sure you have identified the following parameters before starting the configuration:

You can use this pre-flight table to take note of your IP-address, DNS Name and Server List.

Create a New Cluster

Open the Network Load Balancing Manager and create a new cluster.

In the “New Cluster” dialogue, connect to one of your Management Servers.

1. Enter the name of a management server
2. Click Connect
3. Select the network interface to use
4. Click Next

Select the settings on your first host in the cluster.

1. Make sure it’s the correct IP-address.
2. Click Next

Set the Cluster IP-address.

1. Click Add
2. Enter your Dedicated Cluster IP-Address and Subnet mask
3. Click OK
4. Click Next

If another IP-address is needed, like an IPv6 address, you simply repeat step 1-3 before proceeding to step 4.

Edit DNS Names and Cluster Operation Mode.

1. Select your Dedicated Cluster IP-address
2. Enter your chosen Dedicated Cluster DNS Name
3. Select Multicast mode
4. Click Next

Note: We are not going to delve into the Cluster Operation Mode in this guide, but this is what I use for Operations Manager 2012.
If you are interested, here’s the KB on the various settings: http://support.microsoft.com/kb/323437

Set your Port Rules and Affinity Settings.

1. Verify that Affinity is set to “Single”. If not, Click “Edit…” and adjust.
2. Click Finish

Note: “Single” affinity tells the cluster to always direct the same client to the same host if possible. This is required to be able to maintain sessions.
In the world of NLB, a “client” is an IP-address.

Post-Configuration

Now that you have a cluster configured you have to make sure your SDK-clients are able to resolve the dedicated cluster DNS-name. The one you picked in the pre-flight table.

To enable name resolution you have to add your cluster DNS-name to your DNS-zone and point it to your dedicated cluster IP-address. Make it an A-record and it should work.

If you intend to use the cluster name from outside the local network or subnet—Operation Consoles or Powershell sessions for example—you would also need to verify that the router is able to handle the multicast packages. I am by no means a network guy, but asking the person behind that “Don’t blame the network” sign to help you access a NLB cluster on network X from network Y usually works. One way to troubleshoot this is to ping the cluster DNS-name from one of the hosts. If that works but you are still unable to ping from another network or subnet, then it might be a router setting.

Adding Hosts to the Cluster

With the cluster configured and up-and-running you need to add the rest of the Management Servers. Repeat this section for each Management Server you wish to add to the load-balancing cluster.

In the Network Load Balancing Manager, right-click your cluster and select “Add Host To Cluster”.

Connect to your next Management Server to be added

1. Enter the servername of the Management Server (“host” in cluster terminology)
2. Click Connect
3. Select the IP-address of the host
4. Click Next

Verify your Host Parameters

1. Doublecheck the IP-address
2. Click Next

Verify the Port Rules

1. Make sure that Load is Equal and Affinity is Single
2. Click Finish

Final Verification

After each added host it would be proper to check if it was added correctly. The easiest way is to check their statuses in the Network Load Balancing Manager. Green is generally considered good and you want your hosts to be “Converged”.

Another way to verify functionality is to point your Operations Manager console to the Cluster DNS-name instead and connect. If you are in a lab or in an environment where it happens to be OK to shut down Management Servers you could try that as well.

Considering my note on routers in the Cluster Post-Configuration I guess it would be prudent to point out that you should test to launch SDK-sessions from all networks you intend to connect from to make sure that your routers are configured to handle these kinds of sessions.

Postlude

Now; as easy this may be I would personally argue that you should involve your network team before starting to deploy your load-balanced clusters. A little heads-up is always a good thing—I have noticed that network people rarely like surprises—and they might actually be able to help you all the way is you ask nicely. And maybe they’ll tell you right away that the routers need to be configured before-hand instead of giggling frantically in a corner at your feeble attempts to troubleshoot your fresh little cluster.

Soooo… have fun!

And remember; with great powers come great responsibility.

[Sheesh! This post got out of hand!]

What this script does is to send a text message using a GSM/GPRS modem connected to a local (or LAN-connected with local drivers) serial port using Powershell.

Disclaimer!

This script “works” but is not fit for production. See it as an example of the general concept to evolve and adapt into something worthy of production use.

What’s missing in the latest iteration is:

• A working Event-Handler to deal with asynchronous call-backs.
• Support for AT+MSGW (write to modem memory)
• Reusing messages in modem memory for multiple recipients.
• Various error- and exeption-handlers.
• Actually verifying that the modem is AT-capable.
• Querying the system for available modems and their ports.

The Script

So, a short note before digging into the script. Prerequisites for this script is that you have identified which COM-port to use and it’s supported baud-rates and whether it supports DTR or not. If you do not know what the hell I am talking about, you could probably have it work with my preconfigured settings anyway. If you are unsure about if your modem supports AT commands you could open a serial connection to the modem using Hyperterminal or PuTTY and run AT+CMGF=1. If supported, the return should be OK. If it is not supported (you get ERROR instead) you would have to use PDU-mode which require a bit of hex-encoding of your messages. This is nothing I have had to do yet and will not be including in this script. Maybe in the future. Maybe.

So, looking a some powershelling then. First thing would be to connect to the modem.

# Create your instance of the SerialPort Class
$serialPort = new-Object System.IO.Ports.SerialPort
# Set various COM-port settings
$serialPort.PortName = "COM1"
$serialPort.BaudRate = 19200
$serialPort.WriteTimeout = 500
$serialPort.ReadTimeout = 3000
$serialPort.DtrEnable = "true"
# Open the connection
$serialPort.Open()

With the connection established, you the set to modem in AT-mode and start sending the message to the modem.

# Tell the modem you want to use AT-mode
$serialPort.Write("AT+CMGF=1`r`n")

# Start feeding message data to the modem
# Begin with the phone number, international
# style and a <CL>... that's the `r`n part
$serialPort.Write("AT+CMGS=`"+46888888888`"`r`n")

# Now, write the message to the modem
$serialPort.Write("This is a test!`r`n")

# Send a Ctrl+Z to end the message.
$serialPort.Write($([char] 26))

As you may notice, the message is only stored in the modems memory until you send a Ctrl+z which will end the message and send it. It is possible to add more text to the message before sending it if you would like. Personally, I prefer to store the message into a regular powershell variable and pass that one to the script. The SerialPort library is sort of clever and a local phone number will probably work. For safety, I always use international number with country code as it will work every time.

Only thing left now is to close the serial port connection and end the script. Like this.

$serialPort.Close()

The Copy/Paste part…

Here’s the entire script with some added control-features and check to avoid trying to send text messages with no serial connection.

### DISCLAIMER ###
## This script is a quick-hack to demonstrate
## the basics of sending an SMS using an AT-
## compatible GSM modem connected a local
## serial port through PowerShell.
## No error-handling is implemented and this
## is NOT a script fit for production.
##################

# Create your instance of the SerialPort Class
$serialPort = new-Object System.IO.Ports.SerialPort
# Set various COM-port settings
$serialPort.PortName = "COM1"
$serialPort.BaudRate = 19200
$serialPort.WriteTimeout = 500
$serialPort.ReadTimeout = 3000
$serialPort.DtrEnable = "true"
# Open the connection
$serialPort.Open()
# Add variables for phone number and the message.
$phoneNumber = "+46888888888"
$textMessage = "This is a test message!"

try {
 $serialPort.Open()
}
catch {
 # Wait for 5s and try again
 # Told you this is a quick-hack, right?
 Start-Sleep -Seconds 5
 $serialPort.Open()
}
If ($serialPort.IsOpen -eq $true) {
 # Tell the modem you want to use AT-mode
 $serialPort.Write("AT+CMGF=1`r`n")
 # Start feeding message data to the modem
 # Begin with the phone number, international
 # style and a <CL>... that's the `r`n part
 $serialPort.Write("AT+CMGS=`"$phoneNumber`"`r`n")
 # Give the modem some time to react...
 Start-Sleep -Seconds 1
 # Now, write the message to the modem
 $serialPort.Write("$textMessage`r`n")
 # Send a Ctrl+Z to end the message.
 $serialPort.Write($([char] 26))
 # Wait for modem to send it
 Start-Sleep -Seconds 1
}
# Close the Serial Port connection
$serialPort.Close()
if ($serialPort.IsOpen -eq $false) {
 echo "Port Closed!"
}

# That's all folks
# Now, add call-backs, event-handlers, and return-
# message handling.

Enjoy!

I will not go into the genus-political part of this discussion as of now–others are more eloquent and fit to handle that–but rather some of the more pragmatic sides to ditch the BB (short for Booth-Babe) and how that would gain us visitors as well as the exhibitors. I will also keep a pretty frank, and perhaps impolite, tone in this rant of mine.

So, here’s my top reasons, in no particular order, to give up the BBs.

Reason #1 – BBs is disrupting the purpose of the exhibition

When I go to a conference, I am there for the tech, to network and shake paws with the people I collaborate with on-line. It is also a good place to meet the actual corporations that I do business with and discuss their products between four eyes.
I do not want to plow through a crowd of great white whales [Oops! I meant "males"] ogling the BBs to get to someone with actual knowledge about the products and solutions at hand.

Reason #2 – BBs are alienating the visitors

If you are a heterosexual male or a homosexual female, the BBs can actually make you embarrassed, shy and unwilling to approach the exhibitor for that sole reason.
If you are not, you might find an exhibitor with BBs appalling and take another route for that sole reason.

Reason #3 – BBs are intimidating the female visitors

There is, of course, exceptions to this, but I actually discussed this matter with a couple of gentlewomen in the alumni lounge and they did say that they are both appalled and intimidated to the slightly clad BBs at one particular booth at this years MMS. They even used terms like “ridiculous” and “waste of space” to describe the phenomena.
Now, I believe I can hear some of you readers thinking “what? Nice addition to the boring screens and …”. But imaging the opposite for a while. Imagine a whole bunch of Booth-Hunks instead. You know, Brad Pitt in Fight Club and the likes. I know I would be intimidated by that kind of display.

Reason #4 – BBs makes it hard to know who to talk to

Because of the BBs, it can at time be hard to know if the lady at the booth just happen to be a nice-looking knowledgeable tech-specialist or simply someone there to be eye-candy. Too many times have I had a conversation like this:
- “Hi! So, tell me about [SystemX]. It looks kinda interesting on paper.”
- “Hi! Uh, oh! Yeah! You should probably be talking to that guy over there. I don’t really know anything about their stuff.”
I hate it. I want to be able to pick anyone in the booth and get a cohesive answer. You cannot be expert on everything and some people are more marketing focused, but at least they can give you the big picture before calling some techy fellow. Last year I had a really nice discussion with a nice lady from EMC that later on led to access to some beta code. Unfortunately, I had by then grown tired of the BBs and merely approached her since there were lines to the male exhibitors. Which brings me to…

Reason #5 – Having BBs is disrespecting your female colleagues.

There you are. You most certainly have some very talented women in your development teams–my experience is that’s where you’ll find most of them, as architects and lead developers–but for some reason your decide to hire a bunch of BBs to “spice it up a little”, “draw a little crowd”, “get the attention” and so forth. Do you really think your female colleagues appreciate that? Isn’t that diminishing their talent a bit? I am fairly sure that those who attend conferences for technical reasons and to do a bit of networking would take a nice technical discussion with anyone, however geeky she/he might be, rather than side-stepping a crowd or some figure head on my way there.

I don’t know. Maybe I am alone in this matter, but I’d really like to see this change. I would really like to see vendors and exhibitors trying to dazzle the visitors with great displays, clever uses of software and mind-blowing products rather than scantily clad women.

Ah, well. Thanks for your time.

A Disclimer

A Disclaimer

I have had serious doubts about actually writing this article for almost a year now for reasons that I will explain further on. But as others have discovered this “feature” as well–maybe “hack” would be a better name for it–I feel the need to explain how it works and also why you should not use it. Knowledge is power, and even if I advice against using this technique it is also a good way to understand how SCOM uses display-strings in management packs.

The Good News

The Good News

Yes, you can use parameter replacement in you AlertName.

With “parameter replacement” i mean using some kind of substitute text, or mnemonic if you like, that at run-time get translated into something useful. If you have written any kind of alert generating rules or monitors, you most like included something like $Data/Context/Property[@Name='SomeDataFromAPropertyBag']$ into your alert description.

In this dialog, you also have the possibility to set the Alert Name. And if you are lazy, like I am, you probably also noticed that it is impossible to insert any kind of dynamic data into that field as well. This is especially annoying when you are writing a management pack that needs to look different in the Alert Views in the console, and you want to monitor 50 different Events or Performance counters or Log entries that are pretty much the same apart from a Name or ID.
Of course I could not refrain from copy-pasting a $Data/Context…$ into the alert name only to realize that it simply is not being parsed and translated into the value of the specified parameter. Over time I have settled for a stand-point that it’s probably a performance issue and I have also used that as an argument for this apparent lack of simplicity that some of my customers have been questioning.

Two, maybe three, years later. Microsoft releases an update to the core agent monitoring packs. Much to my surprise, one performance monitor suddenly generated alerts with a dynamic performance value in the Alert Name. You know, that field that is not gettingt parsed I was mentioning in the earlier paragraph. It actually looked pretty bad and made it very much impossible to practice any kind of alert supression, but still. It actually had a parsed value in the Alert Name.
As the lack of this feature had me irked before, I exported the core MP and started reading through the XML to find out how they did it. To my surprise, it was actually pretty simple if you ditched the Authoring Console and used your trusty text-editor instead.

How To Do It

How To Do It

In simple terms, if you know your SCOM XML out-side-in, you add the parameters to your “Alert” and modify your DisplayString, the one under LanguagePacks, to call that parameter by it’s relative ID.

Just in case you happen to be a regular mortal, here’s the step-by-step guide.

In this example I have created a silly-simple Alert Generating EventLog rule in wich I have added some parameters to the description. It pretty much looks like this:

Saving the MP at this point I will have a new WriteAlert action with a bunch of parameters and a displaystring with a unique ID.
The resulting XML-code for the WriteAlert action looks like this:

<WriteAction ID="Alert" TypeID="Health!System.Health.GenerateAlert">
  <Priority>1</Priority>
  <Severity>2</Severity>
  <AlertName />
  <AlertDescription />
  <AlertOwner />
  <AlertMessageId>$MPElement[Name="TestMP.MyEventlogAlertRule.AlertMessage"]$</AlertMessageId>
  <AlertParameters>
    <AlertParameter1>$Data/EventDescription$</AlertParameter1>
    <AlertParameter2>$Data/LoggingComputer$</AlertParameter2>
    <AlertParameter3>$Data/UserName$</AlertParameter3>
    <AlertParameter4>$Data/EventNumber$</AlertParameter4>
  </AlertParameters>
  <Suppression />
  <Custom1 />
  <Custom2 />
  <Custom3 />
  <Custom4 />
  <Custom5 />
  <Custom6 />
  <Custom7 />
  <Custom8 />
  <Custom9 />
  <Custom10 />
</WriteAction>

In this slab of code, you’ve got the Parameters, their “relative ID” (the number in the Tag), and also the which is what you would need to search for among the displaystrings. Take note of the you want to use in your AlertName since you are going to need it later. A quick search for “TestMP.MyEventlogAlertRule.AlertMessage” will lead you to the actual message, which should looke similar to this:

<DisplayString ElementID="TestMP.MyEventlogAlertRule.AlertMessage">
  <Name>I want Parameter Replacement here:</Name>
  <Description>Event Description: {0}
{1}
{2}
{3}
  </Description>
</DisplayString>

You should have one of these for every language you have configured in your management pack.
As you may notice, the Description does not contain any XPaths of any kind but rather references to the parameters defined in the WriteAction. That would be the {X} thingies within the description tags. You may also notice that the AlertParameters starts from “1″ while the parameter references begin with “0″. In practice, that means that {0} in the displaystring definition equals to AlertParameter1 and so forth.

Now, with this in mind, adding a Parameter to AlertName if very simple and straight-forward. Simply decide which parameter your want to use and add it’s reference to the Name definition.
So, let’s say I have the above alert message and I want to include UserName in the Alert Name, I would change the <Name> tag to:

<Name>I want Parameter Replacement here:{2}</Name>

That’s it folks!
Save the XML, make sure you verify it and import it into your Operations Manager LAB and watch the magic. Just make sure you continue reading this post as the next part about the downsides is pretty important.

What's the Downside?

What’s the Downside?

The negative effects of using Parameter Replacement in AlertName really boils down to two main perspectives. These are, if I may say to, pretty major and is the reason I have been reluctant on posting this, sort of, how-to.

You are breaking your subscriptions and connectors!

Apparently, parameter replacement is not working in subscriptions and connectors, be it 3:rd-party, Universal, Orchestrator IPs et.c. Basically anything other than the Operations Console will not be able to handle your parameters in AlertName. This will give you a “{1} in {2} has received an error” instead of “veryimportant.log in C:\Logs\ImportantSystem\ has received an error” in anything except the Operations Console. Now, this might not be a bad thing if the Operations Console is your only interface to Operations Manager, but if you would like to forward these alerts to a mobile phone, IM user or a mail recipient it will be utterly useless. I have not verified this, but I am not sure if Alert Suppression is actually parsing the parameters as well. Also. If you, by means of connectors or System Center Orchestrator, are generating incidents from alerts the AlertName forwarded will be equally useless for anyone receiving it.

It’s killing your health perspective.

Might sound drastic, but I’m quite serious about this. Using Parameter Replacement in AlertName might be useful for alert generating rules, but should never be used in a monitor. The reason is pretty simple actually. If you are using a monitor, you are without a doubt interested in it’s state. Otherwise, you would not use a monitor, am I right? I cannot see how it would make sense to create a monitor that does not reflect the health of a specific checkpoint. Much less having a monitor generating alerts that might confuse any service desk operator about what monitor that caused the alert. Also–I have not tested this–I assume that a monitor would not update it’s AlertName once the alert are generated making it more difficult to troubleshoot. Alert generating rules are, to me, something I tend to use only when all other options fail for some reason and I do not like to monitor things to cannot have health. And since parameters in AlertName is nothing for monitors I also question whether it actually is usable at all.

Conclusion

The Conclusion

While this is an interesting techique and a good way to enjoy MP Authoring and learn about the behaviour of display strings and languages in you Management Packs, I would definitely consider it a mostly academical exercise. Only in extreme use-cases and situations would I consider it a viably option and while it might look good in the console, do be aware of the limitations. I have also not seen anything about it on MSDN, and I have serious doubts about it being a supported feature. I have personally been using it in transition to a “better” management pack to get alerting running quickly, yet a prefered solution would actually be using a custom datasouce and a decent macro-enabled text-editor–not to mention snippets–to bulk-generate your monitors and/or rules.

MP Authoring
is fun and powerful
– be resposible

I’m not gonna do that. Instead I just want to point to this free, already pre-configured, OpenVPN Virtual Appliance. Just follow its instructions and it will work quite nicely.

Have fun.

So now I can direct you to my site, tell you to click on “OpsMgr 2007″ to the left and browse through my posts instead of wasting precious time on googling and pretend being more helpful.
To the rest of the world, sorry for wasting your time!

Happy now, eh?

Me and my apprentice is currently decommissioning an entire Management Group with a thousand (-ish) agents. Long story short, we got a new Management Group, migrated all the agents, added a couple of hundreds more, deployed a bunch of gateways and now we are shutting down the old one.

Now, uninstalling the old Management Group from all the agents is a breeze using SCCM and handling the few 20-ish servers that are left is not a biggie either. Shutting down ACS, however, is a different matter.

Although you do configure your forwarders using Operations Manager, removing the management group you were running ACS in does not mean the agents will shut down and disable the AdtAgent service or stop trying to forward audit events to your collector. Now, selecting 10 agents at the time and running the “Disable Audit Collection” task–in case you did not know, there’s a limitation on how many agents you can run a task on in the Operations Console–is not my idea of a jolly good day and since Powershell is a bucket of joy in comparison; here’s a script for you all!

DisableACSForwarders

It is zipped to avoid security alerts, but as with any script found on the internet I implore to to read the code before actually running it.

Anyway, you can use it in a couple of ways.

To run it interactively, just go to the directory where you unpacked it and run it. You will be requested to enter the FQDN of you Root Management Server and a wildcard search for ACS Forwarders.
For example:

PS C:\..\Scripts> .\DisableACSForwarders.ps1
Root Management Server: rms.teknoglot.local
ACS Forwarder name (wildcard): *.teknoglot.local

You can also run it with parameters (for scheduling?) like this:

PS C:\..\Scripts> .\DisableACSForwarders.ps1 rms.teknoglot.local *.teknoglot.local

If you need to run the task with different credentials there’s a switch for that. Just add -UseCredentials to the command and you will be prompted for it.
Like this:

PS C:\..\Scripts> .\DisableACSForwarders.ps1 -UseCredentials

As you might already have realized, the wildcard search does not require actual wildcards. If you only want to disable the ACS forwarder on a single machine, just enter it’s FQDN. As for what wildcards it will accept; anything supported by the powershell -like operator is valid.

[UPDATE!] You might get false failures when running the script on clustered machines because of a bug in the AC Management Pack

For the source code, read on!

## Using parameters for RMS and wildcard search
param(
 [string]$rootManagementServer = $(Read-Host -Prompt "Root Management Server"),
 [string]$filterAgents = $(Read-Host -Prompt "ACS Forwarder name (wildcard)"),
 [switch]$UseCredentials
)

## Make sure the $rootManagementServer variable is defined
while (-not $rootManagementServer) {
 Write-Host "`nRoot Management Server MUST be defined!" -ForegroundColor Red
 [string]$rootManagementServer = $(Read-Host -Prompt "Root Management Server")
}

if ($UseCredentials -eq $true) {
 $taskCredentials = Get-Credential
}

$startLocation = Get-Location
$checkPSSnapin = Get-PSSnapin | where {$_.Name -eq "Microsoft.EnterpriseManagement.OperationsManager.Client"}
if ($checkPSSnapin -eq $null) {
 Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client"
}
$result = Set-Location "OperationsManagerMonitoring::"
$result = New-ManagementGroupConnection -ConnectionString:$rootManagementServer
$result = Set-Location $rootManagementServer

$acsForwarderClass = Get-MonitoringClass -Name "Microsoft.SystemCenter.ACS.Forwarder"
$agentNames = Get-MonitoringObject -monitoringclass:$acsForwarderClass | where {$_.Path -like $filterAgents} | Select Path
$successfulTasks = @()
$skippedTasks = @()
$failedTasks = @()

$monitoringClass = Get-MonitoringClass -Name "Microsoft.SystemCenter.Agent"
if ($agentNames -ne $null) {
 Write-Host "`nFound"$agentNames.Count"ACS forwarders with wildcard $filterAgents"
 Write-Host "`n`nWaiting for 5 seconds to give you a chance to abort!`n"
 Start-Sleep -Seconds 5
 Write-Host "Time's UP!`n`n"
 $agentNames | ForEach-Object {
 $agentName = $_.Path
 Write-Host "Disabling Audit Collection on" $agentName
 $monitoringObject = Get-MonitoringObject -monitoringclass:$monitoringClass | where {$_.DisplayName -like $agentName}
 $agentTask = $monitoringObject | Get-Task | where {$_.Name -eq "Microsoft.SystemCenter.DisableAuditCollectionService"}
 if ($monitoringObject.IsAvailable -eq $true) {
 if ($credentials -eq $null) {
 $result = Start-Task -Task $agentTask -TargetMonitoringObject $monitoringObject
 } else {
 $result = Start-Task -Task $agentTask -TargetMonitoringObject $monitoringObject -Credential $taskCredentials
 }
 if ($result.Status -eq "Succeeded") {
 Write-Host "Operation Successful!" -ForegroundColor Green
 Write-Host `n
 $successfulTasks += $agentName
 } else {
 Write-Host "Operation failed." -ForegroundColor Red
 Write-Host $result.ErrorMessage
 Write-Host `n
 $failedTasks += $agentName
 }
 } else {
 Write-Host "The agent is unavailable, Skipping!"
 Write-Host `n
 $skippedTasks += $agentName
 }
 }
 Write-Host "Summary"
 Write-Host "`tSuccessful:`t"$successfulTasks.count
 Write-Host "`tFailed:`t`t"$failedTasks.count
 Write-Host "`tSkipped:`t"$skippedTasks.count
} else {
 Write-Host "`nNo ACS Forwarders found using wildcard $filterAgents"
}

Set-Location $startLocation

Enjoy!

I’ve had this little visio drawing lying around on my desktop for a while now and I thought that it might be a nice thing to share.

It is nothing ground breaking at all and all the information is available at the Operations Manager 2007 R2 Supported Configurations page on Technet, but I find the visual map easier to read and I use it personally to quickly look up all port openings for the most common components in Operations Manager.

It is missing a few components like ACS, AEM and XPlat, but I usually just look them up when needed.

Have fun!

For quite some time now I’ve had this idea spinning around in my head to write a couple of blog-posts about some of the more useful techniques available when building management packs. Many of these techniques are already described on MSDN and Technet- or other blogs as well as on various forums, but often no more than small bits and pieces of them and I have yet to see some humanly readable information about how to tie them together into a useful management pack. I say “humanly readable” because the information you do find online so far may be clear and somewhat easy to understand for someone with a system development background and a pretty good idea of how object oriented development models tend to work. But the real life System Center Operations Manager engineer–you know the one who get those “do you think we could monitor our …-system too?” questions a couple of times a week, you know… you (most likely, being here)–tend to have a completely different background. Yet as their OpsMgr environment grows, so does the demand for custom monitoring and all of a sudden the former server engineer are now also a developer. A developer who has never before had the need to grasp such abstract concepts as classes, instances, inheritance and who probably never before have had any reason whatsoever to write any XML code.

Purpose

My idea for this series of posts is to shed some light into the world of the authoring console and modules and cookdown and so forth. I am by no means an accredited author, but I will do my best to stay human in this venture and in plain english try to explain why and how you do certain things when going from Management Pack templates, rules, monitors and the safe haven that is authoring in the Operations Console into making your scripts resuable, easy to extend and prime for cookdown using the Authoring Console and XML.

The TG WinAutoSvc Management Pack

To give the series some kind of context and at the same time not only be a matter of examples I will base them on a fully functional management pack that discovers and monitors all Windows services that are set to automatic startup. I know there is other similar management packs out there but I haven’t fancied any one of them yet, and since I had the idea of writing this series I decided that building a new one would be a good way to go. Some of the interesting features with this management pack is:

• You will get an instance of the service classes for each and every service.
• It uses different classes for Own Process services and Shared Process services (svchost for example).
• Every service have a health state (you can use them in distributed applications).
• The service state monitors are inherited from their base classes, no coding neccesary.
• There is only one discovery script for all kinds of windows services.
• Extending the discovery to include different kinds of windows services, like kernel processes, is a matter of filtering.
• It is Open Source and licensed under the Eclipse Public License v1.

Most of these features will be described thoroughly in later posts in the series and as development of it progresses I will document what I do, how I do it and why I do it in certain ways. Hopefully you will learn something new through this and get closer to becoming that MP Dev the organization asks for.
In the mean time, feel free to download, look at the source code (which it by no means perfect) and try it out.

The TG WinAutoSvc monitoring management pack is available for download here:
http://code.google.com/p/tg-winautosvc/downloads/detail?name=TG.WinAutoSvc.xml

The latest revision of the source code is located here:
http://code.google.com/p/tg-winautosvc/source/browse/trunk/TG.WinAutoSvc.xml

A small word of advice though. If you implement this in your environment, remember that you probably have alot more automatic services than you would expect. Because of this, discovery is disabled by default.

Best of luck, and enjoy!

I’ve been fiddling about quite alot and unfortunately don’t know which one action that fixed the problem. If I do figure it out, I will post it here.

Site performance should be a bit better now.

Sorry for any inconvenience in the meantime.

But now it’d done. The server is now self-hosted and self-maintained. Now, that obviously gives me a bit more to do, but on the other hand. I can fix any problems myself and not have to create tickets and hope someone responding to them knows what they’re talking about.

The design is mostly borrowed, for now, but it works and I hope I did all the HTACCESS rules on the old server correct so that they forward all the old links to the same post on the new one.

So, welcome!

Anyway, I have tried to make sure that all the links, images and urls are still intact and that people are automatically redirected to the correct address on the new site too. I think I got it right, but who knows?

Still fiddling with the themes thought.

Sorry for the inconvenience!

ps. Post from the old site is a jump ahead.

Hi all,

I’m finally getting my male donkey out of the wagon and has started moving this blog to a new self-hosted server.

The current host is cheap and delivers quite the good service, but since I already have servers running 24/7 at home, with attached electric bills, and more than enough bandwidth for a couple of websites I find it silly paying for yet-another hosting solution.

Also, it is a good time to do some spring-cleaning and actually start using that teknoglot.se domain i bought some time ago.

Hopefully, the transition will go mostly unnoticed apart from the automatic redirect (301 – Permanently moved) to the new domain.

To make it clear right away, this is not going to be a “Building an SNMP Management Pack Tutorial” since there’s plentiful good ones out there already, and to be extra helpful I’m gonna include a few links right away:

• SNMP Setup and Simple Custom SNMP Discovery – Pretty much the basics
• SNMP Management Pack Example: NetApp Management Pack – Part 4 actually, but has the links to the other parts
• Creating SNMP Probe Based Monitors – No custom discovery, but a good and simple guide to SNMP Probes

It’s the second, the NetApp one, I’ve used as a guide to building the UPS management pack since it goes through the process of building your own filtered discovery using SystemOID to identify your hardware-classes and then building the monitors on top of those.

Let’s get to it

When building the discovery of my hardware classes I ran into problems. The discovery simply did not work. At first I got some strange errors about “invalid queries”, something that turned out to be related to me reading two guides–seriously though, pick one guide that is closest to what you want to achieve and stick to it–and mixing up the XPathQuery variables. Silly me.
I got those errors to go away and I was able to get a few objects to my base-class, but none of the hardware classes who was populated through the return value of an SNMP OID got discovered.
The only error I got this time was the following:

Log Name:      Operations Manager
Source:        Health Service Modules
Date:          2010-09-02 11:19:12
Event ID:      11001
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      CENSORED
Description:
Error sending an SNMP GET message to IP Address XX.XX.XX.XX, Community String:=CENSORED, Status 0x6c.

One or more workflows were affected by this.

Workflow name: CENSORED.MP.CLASS.DISCOVERY
Instance name: CENSORED_DEVICENAME
Instance ID: {5C7EFB30-D885-8843-0DD7-EA86B4FD2311}
Management group: CENSORED

<IsWriteAction>false</IsWriteAction>
<IP>$Config/IP$</IP>
<CommunityString>$Config/CommunityString$</CommunityString>
<Version>1</Version>
<SnmpVarBinds>
	<SnmpVarBind>
		<OID>1.3.6.1.4.1.534.1.1.1.0</OID>
		<Syntax>0</Syntax>
		<Value VariantType="8"></Value>
	</SnmpVarBind>
	<SnmpVarBind>
		<OID>1.3.6.1.4.1.534.1.1.2.0</OID>
		<Syntax>0</Syntax>
		<Value VariantType="8"></Value>
	</SnmpVarBind>
	<SnmpVarBind>
		<OID>1.3.6.1.4.1.534.1.1.3.0</OID>
		<Syntax>0</Syntax>
		<Value VariantType="8"></Value>
	</SnmpVarBind>
</SnmpVarBinds>

Preparations

Read the documentation provided in the Linux Integration Services download. Much of the information in this article is in there, but some parts are not. Otherwise I would not have bothered writing about it.

I’m not going to go through the OS installation process here, but make sure to select the “Software Development” packages since you will be needing it. In case you missed it, you can install them later by running these commands.

# yum groupinstall "Development Tools"
# yum install kernel-headers

I’m not actually sure that you need to run the kernel-headers install manually or if it’s included in the “Development Tools” package.

The first gotcha i ran into was the fact that the link to the Linux Integration Services–previously known as Linux Integration Components or LinuxIC–on RedHat’s information pages gave me a 404 and a redirect to a bing-search that returned the exact same 404. The page have simply been removed by Microsoft without any form of redirection to the new page. Anyway, a search on http://download.microsoft.com for “Linux Integration Components” do return the new page, and that’s where I learned about the new name.
Thank you for making it easy for us Microsoft!
Here’s a direct link to the search on the current name: http://www.microsoft.com/downloads/en/results.aspx?freetext=linux+integration+services&displaylang=en&stype=s_basic
And here’s a direct link to the actual download page: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=eee39325-898b-4522-9b4c-f4b5b9b64551

This download contains an ISO file that you can mount using the Hyper-V- or VMM-console, or you can do as I did and download the ISO to the virtual machine, mount it locally, copy the files and unmount it. Like this.

# mkdir /mnt/ISO
# mount -o loop /root/LinuxIC v21.iso /mnt/ISO
# mkdir /opt/linux_ic_v21_rtm
# cp /mnt/ISO/* -R /opt/linux_ic_v21_rtm/
# umount /mnt/ISO

You probably have to be root to do this by the way.
With that done, let’s get to the installation.

Installation

As root, do the following:

# export PATH=$PATH:/sbin
# cd /opt/linux_ic_v21_rtm/
# make
# make install
# reboot

Why the export PATH command? Apparently, on RHES5, /sbin is not in the PATH by default and this is something that the make scripts are completely unaware of. The “make install” will try to run “depmod” which will fail since it’s not in the default path. You could also add “PATH=$PATH/sbin” to the root users ~/.bashrc which will put it back in the PATH but only for the root user, but I don’t know if that’s recommended.
And, yes. You DO have to reboot after the install.

If you are running RHES5 64bit you also have to install the “adjtimex” package. It is in the RHN repository but also on the RHES5 Installation CD in case you have no internet connection. Install it with yum like this:

# yum install adjtimex

And from the CD (mount it first) like this:

# rpm –ivh /mnt/cdrom/Server/adjtimex-1.20-2.1.x86_64.rpm

And that’s basically it for the installation.

Verification

How do you know that the driver are installed?

After the reboot, try running “modinfo vmbus” which should return something like this:

# modinfo vmbus
filename:       /lib/modules/2.6.18-194.11.1.el5/kernel/drivers/vmbus/vmbus.ko
version:        2.1.25
license:        GPL
srcversion:     3C1899C419665CB2514F2D0
depends:
vermagic:       2.6.18-194.11.1.el5 SMP mod_unload gcc-4.1
parm:           vmbus_irq:int
parm:           vmbus_loglevel:int

Try that with netvsc, storvsc and blkvsc too (replace the vmbus part) and you should get something similar. If you don’t, the installation did not succeed.
The documentation also tells us to check that the components are running with “/sbin/lsmod | grep vsc” which should return:

# /sbin/lsmod | grep vsc
blkvsc                 70184  3
storvsc                64264  0
netvsc                 73504  0
vmbus                  88304  3 blkvsc,storvsc,netvsc
scsi_mod              196953  6 scsi_dh,sg,blkvsc,storvsc,libata,sd_mod

The numbers will probably differ from installation to installation depending on blocksizes and allocation.

Configuration

Configuration is pretty straight-forward so I’ll keep this short.

When you install the drivers you will get a new network card called seth0, which I presume stands for Synthetic ETHernet. There’s nothing magic about it regarding configuration and “system-configuration-network” will work just fine.

The drivers will also give you a couple of SCSI-devices (if you have one attached) with the regular /dev/sd* naming. Simply configure these using fdisk or whatever GUI you might prefer.

There is also a note in the documentation about changing the grub configuration in the “Additional Information…” section. Do read that section.

Additional Comments

One thing I tend to do now that disk space is dirt cheap is to copy all ISO-files I use locally instead of mounting them when needed through Hyper-V. Simply because you can bet your insert-shorter-word-for-buttocks that the day you need it again, someone has been kind enough to have done som spring-cleaning or it’s locked by another machine in the cluster. If you have it locally and followed my instructions in the “Preparation” section, you will allready have a /mnt/ISO directory. Only thing you’ll have to do is

# mount -o loop /path/to/your.iso /mnt/ISO

And there you have it. Just remember to unmount it when you’re done.

I also almost never use the Hyper-V remote connection interface thingy since it will give you a GUI and the mouse just won’t work. If you haven’t configured a network card yet though, you could connect through Hyper-V and hit Ctrl+Alt+F1 to get a command prompt. Unfortunatly cut/paste don’t work here, but you could run system-configuration-network, assign an IP-address and then connect with an SSH client. I prefer PuTTY to a degree that I usually install the ported version on my Linux desktops aswell.

And I never logon using root. People should know this, but it should be stressed anyway. Always logon as regular user and su or sudo when needed. I can’t understand why RHES has root-login enabled by default in the SSH-server config.

Good luck!