Category: OpsMgr 2012

Set-SCOMMaintenanceMode Deluxe ed. [#opsmgr #powershell]

Untimely, perhaps While most of us are waiting for SCOM 2016 RTM to be generally available i’ve completely forgot to blog about my little Set-SCOMMaintenanceModeDeluxe.ps1 script I wrote a while ago. It is pretty much a small extension to the regular Set-SCOMMaintenanceMode cmdlet that allows you to set Computers, Groups or specific Windows Services into maintenance mode. I have yet to make it a proper module (although I have promised myself to do so) so you’d still have to manually download the script and execute it the old-fashioned way. I’ve uploaded it as a public gist on github, so feel free to add adapt it to your needs. Here’s the gist

PoSH Grid Dashboard for RDSH [#opsmgr]

TLDR Customer wanted to see all RDS Host servers in a view with their current total session count. Decided to use a powershell grid dashboard, and share the script. Here’s the gist of it: SCOM_RDSH_TotalSession_PoSHWidget.ps1 How To Keeping it fairly short this time. Pre-requisites are: System Center 2012 R2 with UR2 or later Microsoft RDS Management Pack Microsoft Windows Core OS Management Pack Create a dashboard Rightclick and create a new view somewhere, make it a Dashboard View Enter Name and Description Select Grid type, and layout

Event Id 4001 – “Cannot Add Type” in [#SQL] MP 6.6.4.0 for [#OpsMgr2012]

Was troubleshooting this little error message for a customer after deploying the SQL Server Management Pack version 6.6.4.0. The event is the generic “Health Service Script” with id 4001. Management Group: REDACTED. Script: Main Module: CPUUsagePercentDataSource.ps1 :Computer Name = "REDACTED.redacted.com" WMI = "ComputerManagement11" Service Name = "MSSQLSERVER" SQL Instance Name = "MSSQLSERVER"Error occured during CPU Usage for SQL Instances data source executing.Computer: REDACTEDReason: Cannot add type. Compilation errors occurred.Position:256Offset:21Detailed error output: Cannot add type. Compilation errors occurred.--------(0) : No source files specified(1) : using System;--------(0) : Source file "C:\Windows\TEMP\njdqtgfb.0.cs" could not be found(1) : using System; There are some known errors to the 6.6.4.0 version of the SQL management packs, and one of them does mention “Cannot add type. Compilation errors occured.” In a thread on the Technet Forums it was suggested that it has to do with rights, but focusing mainly on the SQL instance. What caught our eyes, however, was the fact that the script is using the C:\Windows\TEMP folder instead of its private one. And this seems to be because it is using a few .Net components that do some sort of JIT compilation. We took a quick look using procmon, filtered on C:\Windows\TEMP\ and yes indeed. The monitoring account used is trying to create and delete its temporary files in that very folder. A wild work-around appears! The work-around is simple, but cumbersome. Just make sure that the assigned RunAs account have read/write/delete rights on C:\Windows\TEMP. Now you just have to manage this on all your SQL-servers! (yaaaay)

OpsMgr 2012 R2 UR4 - Field Notes [#opsmgr]

Quick and unrefined notes on Update Roll-up 4 for System Center 2012 R2 - Operations Manager Preparation The usual routine applies. Check the KB for instructions and take not of known issues. Check if Kevin Holman has written something about it. As this is an update roll up, I pre-emptively expect that gotchas in UR3 may apply. Remember to open the update catalog in IE as the downloader is not working in other browsers. Download, unpack, toss what languages that does not apply to your organization. It is advised to disable any mail-generating alert subscriptions during the upgrade process to avoid unnecessary spammage. Issues - So Far [updated: 2014-11-03] Got a few problems with cross-platform monitoring templates not working after the update. This was due to missing files in the update package. Make sure you download the updated version! Have not updated a customer using gateways yet, so unless they have fixed the issues in UR3, expect an update to this section soon. Planning

SquaredUp Installation - Manual? Pfffft! [#opsmgr #squaredup]

Story-time I saw SquaredUp some year or two ago while googling about on behalf of a customer looking for a dashboard kind of thingy. It looked good and fairly simple, but for some reason it never clicked with the customer and we ended up going for some custom-made dashboards with a little scripting and some DB-queries. I kind of liked the look of their product though and have kept an eye on them now and then. Fast-forward to may 21st this year and the release of version 1.8 and a whole slew of nifty little features. What specifically piqued my interest was the linked dashboards, SharePoint integration and the included SLA and Map plugins. This basically ticked a lot of boxes many of my customers have looked for and something we’ve normally been looking into… err… other products for. That, coupled with some new videos on their Youtube-channel, a few well-placed tweets and a little mail-correspondence had me setting it up in my portable little lab. One of the interesting points is how, supposedly easy, it is to set the portal up. So I reset my lab – PDT is just wonderful – and decided to go for the hail-dummy approach. No manual, no preparations, no check-lists… Next-next-next then hopefully a working portal.

OpsMgr 2012 R2 UR3 - Field Notes [#opsmgr]

Quick and unrefined notes on Update Roll-up 3 for System Center 2012 R2 - Operations Manager. Preparation Usual routine, check the KB for instructions and known issues. Double-check with Holman’s blog and take note of any irregularities. Download, curse your favourite deity and re-try in IE. Unpack the CAB-files (why do you keep putting them in CAB-files?) and throw away all the unnecessary language-specific console patches. Notify affected parts of the organisation, I’ve had the benefit to work with good release managers at all clients so far, so no biggie. Then try to close as many consoles as possible to avoid any blocks in database. Make sure you have the credentials for the Data Access service account at hand. Issues - So Far (updated 2014-09-02) The SQL Script for the OpsDW was deadlocked at all sites and customers without exception. It’s easily fixed by stopping the management server services. A few dashboards (the 2012 versions) went blank. Self-healed after some aggregation job over night. From what I’ve noticed, only the SLA Dashboards are affected but never all of them. Agents behind daisy-chained Gateways is not identified as in need of an update. “Repairing” them from the Console is one work-around that seems to work consistently. A few agents that was updated using Windows Update did not report as updated. Repair fixed that nuisance. Had to flush the cache on a few Gateways to avoid heartbeat failures from their agents. Only daisy-chained ones if I recall correctly.

OpsMgr 2012 Agent Failover – A Faster Script with Wildcards [#opsmgr, #powershell]

Now we’re gonna make things even faster! In the previous post on the subject of Agent Fail-over in Operations Manager 2012 we created a script that will go through a selection of agents and make sure that they all have up-to-date fail-over settings. We are doing the same thing in this one, but making it go faster. In my lab, it’s about five times faster in fact and I only have about 20 agents to play with. Not really a big deal, but scale it up a bit and add a few thousand agents and the pay-off will be very significant. As usual, the script will work as is, but it really is more to show the concept. You would have to add filtering to make sure you don’t mix agents behind gateway servers and agents behind management servers. Giving an agent behind a gateway a management servers as it’s fail-over server will likely not help you in any way. We will pretty quickly go “advanced” this time, so buckle up. 😉

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.

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.

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!