Monday, 15 December 2014

Create SLA Calendars in Service Manager 2012 R2 using PowerShell and XML

Every task I do these days, I look to automate. Even if this means doing something manually and then later going back to see if it can be.

This is probably because I work with multiple customer, with different environments, rather than just setting things up once within my own environment so this “Automate everything” approach will not apply to everyone. It’s about finding the value and ROI of spending the time designing/writing the automation versus the effort of manually doing the task.

That said, the latest one I went to tackle, was creating SLA working hours calendars within System Center 2012 R2 Service Manager (SCSM).

I had been on and off trying it for a while but picked it back up again the other week, but finally gave up banging my head on the desk (especially when I forgot to move my cup of coffee) and reached out for some help.

I sent a tearful email to my fellow SCSM Cookbook authors and Dieter Gasser, like the SCSM coding guru that he is, replied back in triple quick time with how to do this in PowerShell.
The basic outline principal for this is:
  • Gather the classes for Calendar and Working Days
  • Gather the Relationship between the two
  • Gather the Enumerations for the Days
  • Set an array for the Calendar and each Day with the Name, TimeZones, Start/End times and if they’re enabled or not
  • Create new Objects for the Class based on those arrays
  • Create the Relationships between the Days and the Calendar
  • Commit them to the database

This was so easy in the end I (as usual) had been trying to boil the ocean with a bonfire instead of taking a cup full and using a kettle.

So thanks to Didi, I was able to take his simple code which went line by line setting each day and wrapped it into a script that queries an XML file allow modelling of multiple calendars and the streamlined creation of them.

I’ve uploaded the script and example XML file to the TechNet gallery as a zip file here:

The XML is fairly self-explanatory. For each calendar you would like to create, add a <SLACalendar> </SLACalendar> section and fill in the details for the days.

If you don’t want a day as a working day, just set it as Enabled=”False”

The only part I’ve not made easier yet is the TimeZone setting.
Currently you will need to find the string value used within SCSM and copy this to the XML.

This is fairly easy to find, just create a temporary calendar with the timezone you want and then run this PowerShell one-liner to display all the timezones in use:
(Get-SCSMObject -Class (Get-SCSMClass System.Calendar$)).TimeZone

Copy and paste the output to the XML.

Once you have the XML ready, create the calendars by running the script as so:

New-SCSMCalendar.ps1 –XMLFile <Path to XML>

e.g. New-SCSMCalendar.ps1 –XMLFile C:\Temp\Calendars.xml

Again, huge thanks to Didi with his help on this, be sure to check out his blog ( or follow him on Twitter @DiGaBlog

Tuesday, 9 December 2014

What needs an Agent update in VMM?

When you apply an Update Rollup to System Center 2012 R2 Virtual Machine Manager (VMM), if you're not using plain WSUS, ConfigMgr SUS, or even the built in Update Management features of VMM, you may notice that you will see "Needs Attention" under your host status column view in the Fabric Node.

Nothing to worry about, it just means there is an agent update to push.

However, you will need to work through the fabric in the GUI, checking the Library Servers, PXE Servers, Update Servers etc etc.

You'll probably want to add the extra columns to each view of the console as you go to make it easier to check. Add these columns:
  • Agent Version
  • Agent Version Status
  • Updated Date

Or alternatively, you could always drop to a PowerShell Prompt and run this to check your entire estate very quickly:

Get-SCVMMManagedComputer | FT ComputerName,Role,VersionStateString,AgentVersion,UpdatedDate -AutoSize

This will show you the current state of your VMM Agent deployment status.

If you wanted to just see those servers requiring an update, add a filter:

Get-SCVMMManagedComputer | Where VersionState -eq UpgradeAvailable | FT ComputerName,Role,VersionStateString,AgentVersion,UpdatedDate -AutoSize

And just to finish, you "could" (I wouldn't to this on mass!!) update all of those pending agents with a couple of lines:

$Credential = Get-SCRunAsAccount | Out-GridView -PassThru

Get-SCVMMManagedComputer | Where VersionState -eq UpgradeAvailable | Update-SCVMMManagedComputer -Credential $credential -RunAsynchronously

Once run, you should see all the jobs running and then hopefully complete inside the VMM console:

See the failed one? That's the Cluster Object Name of my library file server cluster and VMM (although it shows as having an Agent Status etc) won't allow direct update of that, only the nodes that are part of the cluster.

Tuesday, 2 December 2014

Updates Galore!! But not all are equal...

Now that Microsoft are delivering updates and features at a much faster cadence, we're seeing regular updates to System Center 2012 in the form of "Update Rollups" on roughly a quarterly basis.

Update Rollups (there's a hint in the name) are an incremental set of updates, rolling up (told you) previous updates along with new updates for that release.

Currently for the 2012 R2 version we're on Update Rollup 4 (as of 02/12/14).

So after a new deployment of a System Center component, patch it to UR4 and you're ready to go, right?


You see, not all of the components always get updated with every UR, meaning that for some, UR3 might be the latest patch level even though UR4 is available.

I've pulled together the following table that shows the individual System Center 2012 R2 (I haven't pulled together the information for SP1 and if you're still on SP1, look to move to R2!)

Component UR1 UR2 UR3 UR4 Current Latest Level
SMA No Yes Yes No UR3
Orchestrator No Yes No No UR2
Service Manager No Yes Yes Yes UR4
Data Protection Manager Yes Yes Yes Yes UR4
Operations Manager Yes Yes Yes Yes UR4
Configuration Manager CU1 CU2 CU3 N/A CU3
Virtual Machine Manager Yes Yes Yes Yes UR4
App Controller No No No No RTM
Service Provider Foundation Yes Yes No Yes UR4
Windows Azure Pack WAP UR1 WAP UR2 WAP UR3 WAP UR4 WAP UR4
Service Reporting No No No Yes UR4

N.B. ConfigMgr is slightly different in that they use "Cumulative Updates" and tend to be 1 version number behind the UR's (at least for a few months).

From this table we can clearly see that the majority of the components after a new install just need UR4 applying, but in the same vein we can see that SMA & Orchestrator still need you to dig out and apply UR3 or UR2 to them.

It also shows the it wasn't until UR2 that SCSM + SMA + Orchestrator got some loving, App Controller we now know is going the way of the Dodo and Service Reporting didn't need touching until UR4.

I think what I'm trying to explain here is don't just assume you need to grab the latest patch and you're done.  Take some time to read the KB articles, see which components are updated, query your WSUS/ConfigMgr SUPs and plan appropriately.

Just for completeness, here are the latest release dates for versions of the Xplat Operating System Components:
SCOM Unix & Linux Monitoring - 28/10/2014
CM Unix & Linux Management   - 30/10/2014

And to make it easier for you, here's all the KB articles for reference:

Update KB Link
System Center 2012 R2 UR1
System Center 2012 R2 UR2
System Center 2012 R2 UR3
System Center 2012 R2 UR4
ConfigMgr Clients for Additional OS'es
SCOM  MP for UNIX & Linux OS'es

** Updated - Orchestrator is only up to UR2, Orchestrator(SMA) is UR3) **