Category: Microsoft

2012

MicrosoftOpsMgr 2012

OpsMgr 2012 Agent Failover - Simple Script with Wildcards [#opsmgr, #powershell]

In the last post, OpsMgr 2012 Agent & Gateway Failover – The Basics, we looked at the basics of the Agent and Gateway fail-over configuration cmdlets and how to use them in a direct and interactive setting. This is absolutely useful when you got this specific agent that you need to configure with a specific fail-over management server. To spice it up a little, we are going to add a little intelligence to it and enable wild-card selections while at it. The scenario we are building this script for is that now and then you want to make sure that certain agents have fail-over management servers configured. You also want to make sure that all management servers that are not the primary management server of any selected agent will be in that list of fail-over servers. This would include any new management servers as well as exclude any removed ones. In short, make sure your agent fail-over settings are up-to-date with the current environment. Inputs To use this script you need to know which management server you should connect your powershell session to and which agent, or agents, you want to check and configure. # Input SCOM Management Server to connect to in this session[string]$inputScomMS = "scomms01.domain.local"# Input an existing agent you want to modify[string]$inputTargetAgent = "*.domain.local" Note: If you are using load-balanced SDK-services, or “Data Access Services”, pointing $inputScomMS to that virtual host-name will work perfectly fine. This example uses a wild-card for the agent selection and I guess it’s the most likely scenario for this script, but a single host-name obviously works fine as well. Supported wildcard selections are documented at TechNet. An array of computer-names or a comma-separated list, however, will not work. You could easily add that functionality but it’s out of scope for this example. Connect to Your Management Group To run any script against an Operations Manager 2012 Management Group we need a connection to one. To connect to a management group we have to load the OperationsManager module. Lets check for a loaded module, load it if necessary and connect to the Management Server from the $inputScomMS setting. If loading the module fails–maybe it is not installed–we will exit the script. # Check if OperationsManager module is loadedIf (Get-Module -Name "OperationsManager") { try { # Try to load the module Import-Module -Name "OperationsManager" } catch { # Did not work, exit the script Write-Output "Could not load Operations Manager module" exit }}# Module is loaded, connect to Management Group/ServerNew-SCOMManagementGroupConnection -ComputerName $inputScomMS

MicrosoftOpsMgr 2012

OpsMgr 2012 Agent & Gateway Failover - The Basics [#opsmgr, #powershell]

I have previously posted a few scripts on managing and configuring fail-over management servers on gateways and agents in System Center Operations Manager 2007 R2. Now that System Center 2012 Operations Manager is RTM and users are starting to explore the differences between the versions I see more and more questions on how you do, in OpsMgr 2012, what you did in OpsMgr 2007. In a few posts henceforth I will go through Agent and Gateway server fail-over configuration and management. In this first post I’ll look at the very basics of fail-over configuration, the cmdlets to use and some one-liners. The cmdlet First of all, the cmdlets of OpsMgr powershell have all got new names looking like Verb-SCOM_noun_ and to list them all in the console you can execute the following command: get-command *SCOM* The cmdlet we are looking for to set and manage primary and fail-over management servers is Get-SCOMParentManagementServer As usual, you can pass the cmdlet as a parameter to get-help for information about its parameters and a few use-cases. SYNOPSIS Changes the primary and failover management servers for an agent or gateway management server. SYNTAX Set-SCOMParentManagementServer -Agent -PrimaryServer [-PassThru ] [-Confirm ] [-WhatIf ] [] Set-SCOMParentManagementServer -Agent -FailoverServer [-PassThru ] [-Confirm ] [-WhatIf ] [] Set-SCOMParentManagementServer -GatewayServer -FailoverServer [-PassThru ] [-Confirm ] [-WhatIf ] [] Set-SCOMParentManagementServer -GatewayServer -PrimaryServer [-PassThru] [-Confirm] [-WhatIf] [] But that’s so boring to read the manual is a bit sketchy on how it behaves and the limitations.

MicrosoftOpsMgr 2012

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

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 support and with little gain at that. With that gone and the SDK Service, or Data Access Service, thriving on all 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 will 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 way. 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

MicrosoftOpsMgr 2007

Parameter Replacement in AlertName

…and why you should not use it 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 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′]Data/Context/Property[@Name='SomeDataFromAPropertyBag']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...Data/Context...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 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.

2011

MicrosoftOpsMgr 2007

OpsMgr 2007 R2 Documentation

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?

MicrosoftOpsMgr 2007

Bulk disable ACS Forwarders (with wildcards)

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: C:\..\Scripts> .\DisableACSForwarders.ps1Root Management Server: rms.teknoglot.localACS Forwarder name (wildcard): *.teknoglot.local

MicrosoftOpsMgr 2007

OpsMgr 2007 Connectivity Map

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!

MicrosoftOpsMgr 2012

Introduction to TG WinAutoSvc v1

Background 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

2010

MicrosoftOpsMgr 2007

SNMP GET Errors in OpsMgr EventLog

I’ve been building a little SNMP Management Pack in the past few days to discover and monitor a bunch of PowerWare UPS’s, which turned out to take quite a lot more energy and time than expected. Mostly due to the facts that I am really bad with SNMP and how it works, I’ve never really looked into the inner working of building an SNMP management pack and also because we ran into a couple of errors preventing the discovery process to work alright. 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 ManagerSource: Health Service ModulesDate: 2010-09-02 11:19:12Event ID: 11001Task Category: NoneLevel: ErrorKeywords: ClassicUser: N/AComputer: CENSOREDDescription: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.DISCOVERYInstance name: CENSORED_DEVICENAMEInstance ID: {5C7EFB30-D885-8843-0DD7-EA86B4FD2311}Management group: CENSORED I went through all the other logical steps of troubleshooting an error like that which include double-checking firewall settings, OIDs, IP-addresses, allowed hosts and so forth. It wasn’t until I loaded the PowerMIB into a MIB Browser installed on the proxy machine (in this case a Management Server) I realized that there was no problem sending an SNMP GET to the UPS from that server. I launched Wireshark and had it listen to SNMP traffic between the UPS and the Management Server. The thing that struck me right-away was the fact that I could see the a bunch of “SNMP Get-Request” but no “SNMP Get-Response” which means that Operations Manager did send an SNMP GET but there was no response. After a bit of intense staring i noticed what you see in the screenshot.

MicrosoftOpsMgr 2007

MSMQ 4 and MSMQ 5 MP for OpsMgr Released! (finally)

After a long wait (definitely more than 90 days) the management packs for MSMQ 4 (Windows 2008) and MSMQ 5 (Windows 2008 R2) are finally released. Both seem to be fully Cluster aware and pretty much holds the same monitoring as the the latest MSMQ 3 MP. Message Queuing 4.0 Management Pack for Operations Manager 2007 > **Quick Details** Version: 6.0.6700.83 Date Published: 4/5/2010 Language: English Download here: http://www.microsoft.com/downloads/details.aspx?FamilyID=cfc103b8-7185-4721-8098-110885fe9e9e&displaylang=en Message Queuing 5.0 Management Pack for Operations Manager 2007 Quick Details Version: 6.0.6700.88 Date Published: 4/5/2010 Language: English Download here: http://www.microsoft.com/downloads/details.aspx?FamilyID=28349b78-8329-44aa-8a1f-81f4e3f84d0c&displaylang=en