teknoglot:

Load-balanced SCOM2012 SDK Services for Network Illiterates [#opsmgr, #nlb]

Posted on May 18, 2012 by Sam T

Prelude

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:

A Dedicated Cluster IP-Address:
A Dedicated Cluster DNS Name:
A list of SCOM2012 Management Servers:

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.

Enter the name of a management server
Click Connect
Select the network interface to use
Click Next

Select the settings on your first host in the cluster.

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

Set the Cluster IP-address.

Click Add
Enter your Dedicated Cluster IP-Address and Subnet mask
Click OK
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.

Select your Dedicated Cluster IP-address
Enter your chosen Dedicated Cluster DNS Name
Select Multicast mode
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.

Verify that Affinity is set to “Single”. If not, Click “Edit…” and adjust.
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

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

Verify your Host Parameters

Doublecheck the IP-address
Click Next

Verify the Port Rules

Make sure that Load is Equal and Affinity is Single
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!]

Categories: OpsMgr 2012 | Tags: Highly-Available, How-To, NLB, OpsMgr, Tutorial

Quick-Hack: Send SMS through Powershell [#powershell]

Posted on May 15, 2012 by Sam T

No Comments

Decided to do a quick-hack/fast-publish on this one as I have had a bit less time to create a nice clean production-ready version as of yet… and people has been asking about how far off the article is.

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!

Categories: PowerShell | Tags: GSM, PowerShell, Quick-hack, SMS

Rant – The Concept of Booth-Babes

Posted on May 8, 2012 by Sam T

No Comments

Having visited a few conferences in the last years I have spotted a trend I didn’t think I would see in the IT-Pro sphere. You could probably call me naive for that but logically we should not encourage this trend. This is my appeal to all exhibitors of future conferences to re-evaluate the concept of booth-babes.

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.

Categories: Technobabble | Tags: Conference, Rant

Parameter Replacement in AlertName

Posted on April 9, 2012 by Sam T

No Comments

…and why you should not use it.

Virtual OpenVPN Server at Home

Posted on September 28, 2011 by Sam T

1 Comment

I was going to write a post on how to install and configure your own virtual SSL-VPN server as I had in mind to make one myself as a means to surf safely while on hotspots and to access my System Center lab at home.

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.

Categories: Linux | Tags: Linux, OpenVPN, Virtual Appliance

OpsMgr 2007 R2 Documentation

Posted on August 8, 2011 by Sam T

No Comments

Here a link to the System Center Operations Manager 2007 R2 Documentation for those of you out there who keeps asking of its whereabouts and then tell me to not tell you to google for it.

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?

Categories: OpsMgr 2007 | Tags: Rant, Sillyness, Teach a Man to Fish

Bulk disable ACS Forwarders (with wildcards)

Posted on July 7, 2011 by Sam T

2 Comments

Here’s a little something-something for the wicked.

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!

Load-balanced SCOM2012 SDK Services for Network Illiterates [#opsmgr, #nlb]

Prelude

Prerequisites

Create a New Cluster

Post-Configuration

Adding Hosts to the Cluster

Final Verification

Postlude

Quick-Hack: Send SMS through Powershell [#powershell]

Disclaimer!

The Script

The Copy/Paste part…

Rant – The Concept of Booth-Babes

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

Reason #2 – BBs are alienating the visitors

Reason #3 – BBs are intimidating the female visitors

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

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

Parameter Replacement in AlertName

…and why you should not use it.

Virtual OpenVPN Server at Home

OpsMgr 2007 R2 Documentation

Bulk disable ACS Forwarders (with wildcards)

kaTWEET!

Categories

Recent Posts

Recent Comments