In Hyper-V versions prior to Windows Server 2012, a .bin file was created for each virtual machine, that was the exact same size as the memory allocated to the VM.  This was to automatically reserve the disk space needed if you ever saved the state of the VM.  It ensured that if you needed to save the state of all your VM’s, you would have enough disk space to do so. 

In 2012, the behavior changed.  We only create the .BIN file (with the size pre-allocated to RAM size) IF the VM settings for Automatic Stop Action are set to “Save the Virtual Machine State”  (which happens to be the default).

However, in the case of highly available clusters, we’d prefer to live migrate VM’s, and would not inadvertently shut down a host node, so this storage requirement really isn't as necessary.

Additionally, if you are using Hyper-V for labs, or test/dev scenarios where disk space might be very constrained, you might consider setting this default stop action to “Shut Down the Guest Operating System”, and save yourself a potential amount of disk space.

If your server has 64GB of RAM allocated to VM’s, this means you are consuming 64GB of additional disk space for these save-state files.  That might not be significant to you, but in my environment, where all my VM’s run on SSD drives, every single GB is precious!

Here is an example of the .bin file:

You can change the setting manually for each VM, or here is a one-liner PowerShell command that will make the changes for you.  This setting requires the VM’s be shut down to make the change:

get-vm | set-vm -AutomaticStopAction ShutDown

Here is my disk consumption prior to the changes.  Not the free space available on my SSD drives:

And after:

That frees up a nice chunk of real estate for additional density on these super-fast solid state volumes!

For additional reading on this – the PFE platforms team has a great blog with Hyper-V best practices:

http://blogs.technet.com/b/askpfeplat/archive/2013/03/10/windows-server-2012-hyper-v-best-practices-in-easy-checklist-form.aspx

And any Hyper-V enthusiast or administrator should always follow Aidan’s blog as well, he also commented on this post above:

http://www.aidanfinn.com/?p=14288

Well, after 3 years in the Microsoft Sales organization, I have decided to return to Microsoft Premier Field Engineering.  As of today, I am back in PFE as a SCOM engineer. 

I had a great time in Technical Sales, and it was a fantastic learning experience for me.  After almost three years, I decided that I really missed working directly with customers on solutions, and working deeper with the products in System Center.  So the opportunity to return opened up recently and I jumped on it.

I will be returning to Premier DSE as a dedicated engineer primarily supporting System Center Operations Manager, along with connected System Center solutions.  I look forward to new challenging issues and solutions which should start driving more technical content here.

On a personal note, my wife is pregnant with twins, our first kiddos.  So while I am returning, I don’t know how much sleep I will be getting this year.  Wish me luck!

We use the scheduler datasource in SCOM for workflows for all kinds of purposes.  Most workflows have some concept of a schedule in the datasource to tell how often to inspect for something, like a service running, or to look at perfmon data, or to run a script.

The most common property would be the Interval, which is how often we want the workflow to run.

SyncTime is another common property.  This is used to tell the workflow to run “synchronized” on a very specific point in time.  From:  http://msdn.microsoft.com/en-us/library/jj130319.aspx

“Specifying a synchronization time forces the module to output a data item at the specified time, and it executes on that frequency based on that synchronization point. “

If we do not provide a sync time, and only provide an interval (say, 5 minutes for example), the behavior of the workflow will be to run the workflow IMMEDIATELY upon agent startup (or as soon as the agent is capable of running workflows) and then on a 5 minute interval schedule from that point forward.  This is generally a good thing, as it will randomize when agents are running workflows on common intervals, assuming all your agents don’t start up at the same time.  This has two good effects:  It controls us from flooding the network sending data from the agents to MS in bursts, all at the same time, and it keeps us from overloading a Hypervisor host, having lots of monitored servers running on it.  If all agents ran a script that consumed 50% CPU at the exact same time, it could exhaust the resources of the host during script executions.

If we DO provide a sync time for the workflow, then the behavior is to NOT run the workflow immediately on agent startup.  Instead, we will run the workflow based on the set interval, and start running it as soon as possible where it will run “synchronized” to the given sync time.  When the workflow or agent is initialized, the full schedule is calculated, and the module is output at the next closest time. This might be confusing, so let me provide some examples:

Scenario 1: Daily execution  I have a script based rule, where the Interval is set to 86400 seconds (once per day) and the sync time is set to 05:15.  Sync time is based on a 24 hour clock, so 05:15 is 5:15am, local agent time.  Lets say the monitored agent gets rebooted at 11:03 PM.  The workflow will wait, to run on its defined interval, and execute at exactly 5:15 am.

Scenario 2: Infrequent execution  I have a script based rule, where the Interval is set to every 4 hours and the sync time is set to 05:15.  Sync time is based on a 24 hour clock, so 05:15 is 5:15am, local agent time.  Lets say the monitored agent gets rebooted at 11:03 PM.  The workflow will wait, to run on its defined interval, and execute based on its interval, that also must fall on 5:15 AM.  Therefore, since the agent started up at 11:03 PM, the next possible interval on the 05:15 sync time would be 1:15 AM.  This will be the first execution of the script, and then it will continue repeating every 4 hours, staying in sync with always having one of the executions running at 05:15.

Scenario 3: Moderate frequency  I have a script based rule, where the Interval is set to every 15 minutes and the sync time is set to 05:15.  Sync time is based on a 24 hour clock, so 05:15 is 5:15am, local agent time.  Lets say the monitored agent gets rebooted at 11:03 PM.  The workflow will wait, to run on its defined interval, and execute based on its interval, that also must fall on 5:15 AM.  Therefore, since the agent started up at 11:03 PM, the next possible interval on the 05:15 sync time would be 11:15 PM.  This will be the first execution of the script, and then it will continue repeating every 15 minutes, staying in sync with always having one of the executions running at 05:15.

Scenario 4: Very frequent  I have a script based rule, where the Interval is set to every 1 minute and the sync time is set to 05:15.  Sync time is based on a 24 hour clock, so 05:15 is 5:15am, local agent time.  Lets say the monitored agent gets rebooted at 11:03 PM.  The workflow will wait, to run on its defined interval, and execute based on its interval, that also must fall on 5:15 AM.  Therefore, since the agent started up at 11:03 PM, the next possible interval on the 05:15 sync time would be 11:04 PM.  This will be the first execution of the script (assuming the agent has fully started and is ready to run workflows), and then it will continue repeating every 1 minute, staying in sync with always having one of the executions running at 05:15.  As you can see, there is VERY LITTLE value to ever using a sync time with a very frequent execution.

What we can see, is that synch time bring the most value, when we want to control when workflows execute at a specific point in time.  This works really well, if I have a MP with very expensive discovery scripts, and I need to ensure they don’t all run at the same time, or we wish to control which discoveries runs first as subsequent discoveries might depend on previous discovered data.  It can also be useful if we DON’T want the agent to run the workflow upon agent startup.  Beyond that, you should take care in leveraging any sync time value, as you can accidentally create unnecessary load on the network, or virtualization hosts.

Raphael Burri mentioned a potentially better solution for controlling workflow initialization and intervals, using the “SpreadInitializationOverInterval” element in the Scheduler datasource.  This property is shown in the schema here:  http://msdn.microsoft.com/en-us/library/ee692976.aspx and an example in XML here:  http://msdn.microsoft.com/en-us/library/hh442320.aspx   It is not well documented however.  The best explanation of how it works and how to use it is written by Kris Bash, here:  http://operatingquadrant.com/2009/10/12/scom-distributing-workflows-with-the-spreadinitializationoverinterval-scheduler-parameter/

Essentially, using “SpreadInitializationOverInterval” will keep your workflow from executing immediately after agent startup, and will initialize randomly over a set interval of time that you provide.  This will help randomize execution across multiple agents, and will keep all agents from running your workflow immediately upon startup.

I have written several posts over the years dealing with authoring groups.  See many examples here:  http://blogs.technet.com/b/kevinholman/archive/2010/07/27/authoring-groups-from-simple-to-complex.aspx

This post will deal with the concept that we might want to create groups in SCOM, of Windows Computer objects, based on the time zone setting for those computers.  This might be useful for maintenance mode, where we want to put all computers in a given Time Zone into maintenance mode at a very specific time on a schedule, for a set maintenance window.

There are lots of ways to do this, we could do a script based discovery, WMI, or registry.

This first example will be somewhat of a “Hack”.  What I found is that in SCOM 2012, there is a new property on the Windows Computer class called OffsetInMinuteFromGreenwichTime.  This property has no discovery associated with it.  I ASSUME this new property had more to do with keeping synchronization with the class properties in Service Manager, as it DOES populate this property there.  What we can do, is write a VERY simple Registry Discovery, and populate this existing Class Property on the Windows Computer class with data.

For this example – we will use the SCOM 2007 Authoring Console…. as it does a simple job for writing a basic discovery.  You can download it here:  http://www.microsoft.com/en-us/download/details.aspx?id=18222

Lets get started:

Open the Authoring Console and create a new empty management pack, give it an ID and a display name:

Open the Health Model pane, and highlight Discoveries.  Right click, choose New, Unfiltered Discovery:

Fill in the required information, which is a Discovery ID, Displayname, and target Windows Server Operating System (provided we only want this data for Servers.)

Set a schedule.  For something like this, every 24 hours is typically just fine.

Accept the default for the Computer name property value:

In the registry properties, we will be getting this data from a Registry Value, which is an Integer located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\ActiveTimeBias.  Give the discovery value a name, such as “ActiveTimeBias” and set it to Integer:

Here is the “hack”.  On the class to be discovered – choose Windows Computer.  In the key properties map it via the “flyout” to the Host – Windows Computer Principal Name value.

In SCOM 2007 R2 – the OffsetInMinuteFromGreenwichTime class property does not exist.  So it does not show up in our list.  No bother – we will just set it to any existing non-key property in the console, and fix it up in XML later.  I am going to choose “LogicalProcessors” just for an example – as a temporary target for our discovered data.  For a registry discovery – the value is in the format $Data/Values/RegistryAttributeName$.  Since we named ours “ActiveTimeBias” in the graphic above, we will match that.

Now save the MP and open the XML in your XML editor of choice.

Find the <InstanceSettings> section of our discovery – this is where we map the discovery data to a class property.  We need to change “LogicalProcessors$” to “OffsetInMinuteFromGreenwichTime$”

Save the XML and import it.  You will see your class property get populated in a Windows Computer State or Discovered Inventory view:

At this point – we can make a dynamic group based on these values – the offset from GMT.  Central time is 360, Eastern is 300, Pacific is 480.  See example below:

I view group members and see that it is working:

The above process will work great for you – IF you are running SCOM 2012. 

What if you are using SCOM 2007 R2?  Or what if you don’t want to populate a property on Windows Computer – you’d rather create a class property on your own?

No problem.  In the next example, we will take a different approach.  We will create a new class, which is generic, based on the “Local Application” class.  This class will be generic, used not to discover any specific application, but used to discover lots and lots of properties that we want for specific purposes.  Such as time zone, or custom registry stamping that we add ourselves, or anything really.  Then – we will seal this MP, and use these properties to create groups in many other MP’s.

Lets get started 2:  Management pack boogaloo.

Again – for this exercise – we will leverage the 2007 R2 Authoring console.  This will allow us to use the MP in SCOM 2007 R2 or in SCOM 2012. 

Step 1– Create an empty MP. 

This MP will contain only our one class, and a single discovery for it.  Then – we will seal this MP and only add class properties and discoveries over time.  I used “Custom.Discovered.Properties”

Step 2– Create a class. 

In the Service Model pane, Classes, create a new custom class.  Give it a proper ID

In the next screen – choose a base class.  A Base class is the class type that our custom class will be based on.  Microsoft.Windows.LocalApplication is a good generic base class and was created for uses like this, and common for simple applications.

Give the Class a good display name.  Change the value to “Public” as we wish to leverage this class and properties in other MP’s down the road.

On the Properties tab – right click and create a new property.  Call it “GMTOffset”.  Click OK.

Provide a Display name, then click OK.

Step 3– Create a discovery.

On the Health Model, Discoveries, New, Registry (Filtered).

Provide an ID and displayname for the discovery.

For the target, choose to run this on all Operating Systems, or Server Operating Systems.  Since I will be using this custom class solution on client OS’s and Server OS’s, I will choose “Microsoft.Windows.OperatingSystem”

Run once per day.  Click Next.

Accept the default on the Computer Name screen, and click Next.

On the Registry Probe Configuration – click Add.  For the first registry item, we need to choose a registry Key that will be used to create membership in our class.  Since I want ALL machines to have an instance of this class, I am going to set membership to “Has a registry key of HKLM\SOFTWARE”.  So I select Key, then for the name, I will use “SoftwareKeyExists”.  Type in “software” for the key path, and sett attribute type to “Check if exists” and click OK.

For the second registry entry – this will be to find the value to populate time zone information.  Click Add again, and choose Value, and provide the same name we used before:  “ActiveTimeBias”.   Provide the registry location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\ActiveTimeBias.  Note – HKLM is provided in the console, so start with “SYSTEM”.  Set attribute type to Integer and click OK.

Click Next when done.  Click Insert, and for the parameter, choose “SoftwareKeyExists”.  Set the Operator to “equals”.  Type “true” in for the value.  A “check if exists” (Boolean) expression will be true or false.  If it is found, it will be true, and we will create an instance of our custom class on that agent.

Click Next.  For the class that will be discovered – choose our new custom class we recently created.  For the Key property – choose Host > Principal Name

For the GMTOffset class property – map this to our custom registry discovery data, in the format of:  $Data/Values/ActiveTimeBias$

For the displayname property – I like to use the FQDN of the agent, so Host > NetworkName.

Click Finish.

That’s it!

At this point you can save and import the MP for testing in a lab, or seal it, test, and move into production.

In the SCOM console – Monitoring pane, choose discovered inventory.  Change Target Type to our Custom Discovered Properties Class.  Within a few minutes, you should start to see discovered instances of this class, along with the property value for GMTOffset.  These instances will show “not monitored” by design, as we don’t have any monitors pointing at this class, it is not designed for monitoring purposes, only discovery of custom properties.  Eventually we should see the same number of instances that you have Windows Operating System instances in the management group.

Lastly – we need to create the group. 

The SCOM console does not let us create groups of Windows Computers based on a property of a DIFFERENT class… so for this, we need to do a little XML work for the group population.  Jonathan Almquist covered this in a previous blog post:  http://blogs.technet.com/b/jonathanalmquist/archive/2010/07/22/how-to-create-a-group-of-windows-computers-based-on-a-discovered-property-of-virtually-any-class.aspx

Follow that blog post to create the group – and essentially in the XML – your group membership expression will look like this (assuming you sealed the custom discovery MP):

<MembershipRule><MonitoringClass>$MPElement[Name="Windows!Microsoft.Windows.Computer"]$</MonitoringClass><RelationshipClass>$MPElement[Name="SC!Microsoft.SystemCenter.ComputerGroupContainsComputer"]$</RelationshipClass><Expression><Contains><MonitoringClass>$MPElement[Name="ReferenceNameofCustomClassMP!Custom.Discovered.Properties.Class"]$</MonitoringClass></Contains></Expression></MembershipRule>

That’s it.

Now – with this custom class, we can continue to easily add new properties, and add groups based on those custom discovered properties.

A new MP authoring tool was announced today.  Read the release at http://blogs.technet.com/b/momteam/archive/2014/01/13/mp-blog-the-right-tool-for-the-right-job.aspx

This is a FREE tool which Silect is releasing.  This tool essentially replaces the functionality of the previous “Visio Management Pack Designer”  This is targeted at the IT Pro, who needs to create custom management packs and author new classes, discoveries, rule, monitors, etc… but is not a developer.  This new tool will make simple work of creating a new class to monitor a specific application, quickly discover it, and add several types of monitoring.

You can register and download here:  http://bridgeways.com/products/mp-author

One of the big benefits of this over the Visio tool, is that it can open existing MP’s and make changes to them, where the Visio tool was a “one way” solution.  This new tool also expands on the types of workflows that are possible to create over the Visio tool.  If you were using the Visio MP designer, I’d recommend migrating to this new solution immediately.  If you considered but didn’t like the Visio designer, – try this one out.

This is the initial release, I imagine we will see additional capabilities as time progresses.  Keep in mind – this is meant for SIMPLE management packs, not a full development suite.  The Visual Studio authoring extensions are the right place for a more full featured management pack development environment.

Here are some simple examples of using MP Author:

Open MP Author.  Click “New” to create a new MP.

Most fields come pre-populated, but are simple to change. 

Provide a location for your new MP:

The MP Author automatically creates the necessary references, and you can add more if you need to reference classes in other MP’s:

Now we can choose what we want to create from common templates.

The MOST common should be “empty management pack”.  Even a “single server application” create a class for our app, but it also creates an additional distributed application for each as well, and this is not commonly needed.  I’d prefer the “single server application” only create a single, simple class, based on Microsoft.Windows.Local.Application, but that is open for discussion.  When we choose to create an empty MP we still have full use of wizards to help create our MP.

I choose Empty MP and click Next, Finish.

Now – what I want to do is to create a class (or “Target”) in this MP to represent an application that I need to discover and monitor.  For this example, I will use the WINS server role.

Go to “Targets” and choose “New Registry Target”

Connect to an existing WINS server to browse the registry of that machine.

I will base the discovery of my class on the Registry value for the WINS service – in this case it is located at:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WINS\Start

When Start = 2 (automatic) I consider that a WINS server.  Click OK, Next.

Provide an ID and displayname for the Class, or accept defaults:

Provide an ID and displayname for the Discovery, or accept defaults:

Validate or modify the expression for class membership:

Set schedule for once every day, and Finish.

SAVE YOUR MP AT THIS POINT.  We’d hate to lose all our work. 

Now we can quickly add in some event rules, service monitor, performance monitors, etc….  When happy, right-click the top level folder for your MP in the left tree view, and choose Import Management pack:

We provide a MS name, and credentials.  mine popped up and said it could not validate my creds which was odd.  The next screen shows what referenced MP’s must also be imported.  This appears a little odd to me because these MP’s are already imported in my environment anyway.  This operation crashed on my PC so there might be some issues to work out yes on this process.  No bother, I’d rather manually import anyway.  Unfortunately I didn’t save my work FIRST.  So off I go to recreate what we just did. 

I manually import my MP, and I can view my discovered servers using Discovered Inventory for my new class:

Could not be any easier to create classes for granular targeting of applications, and creating common authored workflows to rapidly provide monitoring.

I had an interesting request from a customer.  They wanted to collect events that would still continue to be collected, even when the monitored server was in maintenance mode.

This presents an interesting challenge.  When we place the “Windows Computer” object into maintenance mode, this starts a chain of events to occur.  First, due to a special relationship, this also places the instances of “Health Service” and “Health Service Watcher” into maintenance mode.  This will generate a config update for that agent, which will be sent down to the agent.  The agent will process this config, and upon reading it – see that it is being told to unload ALL of its workflows.

Now, this happens because almost every single class instance running on an agent, is *hosted* by the Windows Computer object.  Therefore, all workflows targeting all instances that are hosted by Windows Computer also go into maintenance mode, by design.

So what we need to do, is create some kind of instance, that is run on the agent, but is NOT hosted by Windows Computer.  Was this even possible?  Yes!

We can create a new custom class, and choose a base class of Microsoft.Windows.ApplicationComponent.  This is a good base class because it basically inherits no properties or relationships.

We create this class as Abstract=False, Hosted=False, and Singleton=False.  Abstract is False because we want a class that will contain instances, and we will not be using this class only as a base class.  Hosted is false, because if this was a hosted class, we would have to provide another class to have a relationship, and the maintenance mode would unload the workflows, such as if we had chosen Microsoft.Windows.LocalApplication as a base class.  Lastly, Singleton is False because we want multiple instances of this class we are creating, not a singleton instance, such as would be used for a group (group is a class with only one instance – the group itself, which has containment over the objects in the group)

Note:  Read more about classes here:  http://technet.microsoft.com/en-us/library/ee957039.aspx

Since we are creating a class which is not Singleton, we much define a key property.  The key property is simply a unique identifier for each instance of the class.  A good thing to populate a key property of a class is the FQDN of the agent OS, because FQDN’s should always be unique in any environment.  I will create a key property named “KeyProperty” for simplicity… since I am only creating it because I have to.  The SCOM God’s said so.  Ok, here is what my class definition looks like:  (hint – copy and paste this into your Notepad++ to see the entire code)

<TypeDefinitions><EntityTypes><ClassTypes><ClassTypeID="Demo.UnhostedClass"Accessibility="Internal"Abstract="false"Base="Windows!Microsoft.Windows.ApplicationComponent"Hosted="false"Singleton="false"><PropertyID="KeyProperty"Type="string"Key="true"CaseSensitive="false"Length="256"MinLength="0"/></ClassType></ClassTypes></EntityTypes></TypeDefinitions>

Next up, I need to discover the instances of my class, and create a special relationship.  Discovering the instances is pretty easy.  HOWEVER, if I simply discover instances of an unhosted class, these instances will be managed on (or exist on) the management servers (or RMS if you are on SCOM 2007 R2).  This is simply because this is the default behavior for any class that is not hosted.  (Remember, we could not use an existing hosted class or it would go into maintenance mode).

I need to create a special relationship in a discovery script.  This is a special relationship called HealthServiceShouldManageEntity which is defined in the Microsoft.SystemCenter.Library.mp.  This is a simple relationship which states that the HealthService “should manage” the discovered entity.  This makes the instances of our unhosted class, get managed by the agent healthservice on each machine where we discover an instance!  That is exactly what we want.

I need this discovery to do a few things.  First, I need to define the discovery in XML (see below, this is very basic)

Next, I need to choose who should run the discovery.  I choose my generic target of choice “Windows Server Operating System” or Microsoft.Windows.Server.OperatingSystem.

Then, in the script, I need to define the criteria for discovering an instance of the class.  I could use the registry to look for a specific key or value, or WMI to filter based on a specific property…. or I could just create an instance of the class for EVERY Windows Server OS it runs on.  I chose the latter, because I want to target all servers for these custom workflows.

Then, I need to discover the special relationship for HealthServiceShouldManageEntity.  That part is really simple as you will see from the script below.

I also added to the script, a logging of an event each time the script runs.  This will help us troubleshoot to make sure the script is running successfully, and on the agents we’d expect.  See more examples at http://blogs.technet.com/b/kevinholman/archive/2009/07/22/101-using-custom-scripts-to-write-events-to-the-opsmgr-event-log-with-momscriptapi-logscriptevent.aspx

I chose VBScript, and not PowerShell, simply because I need to include Windows 2003 and 2008 servers that most likely don’t have PowerShell installed.

I borrowed a LOT of this code directly from the MP Authoring Sample Discovery management pack at:  http://gallery.technet.microsoft.com/Sample-Management-Pack-b9da59a7

<Discoveries><DiscoveryID="Demo.UnhostedClass.Discovery"Enabled="true"Target="Windows!Microsoft.Windows.Server.OperatingSystem"ConfirmDelivery="false"Remotable="true"Priority="Normal"><Category>Discovery</Category><DiscoveryTypes><DiscoveryClassTypeID="Demo.UnhostedClass"/></DiscoveryTypes><DataSourceID="DS"TypeID="Windows!Microsoft.Windows.TimedScript.DiscoveryProvider"><IntervalSeconds>86400</IntervalSeconds><SyncTime/><ScriptName>DiscoverUnhosted.vbs</ScriptName><Arguments>$MPElement$ $Target/Id$ $Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Arguments><ScriptBody><![CDATA['==================================================================================' Script:     DiscoverUnhosted.vbs' Date:    1/19/14    ' Author:     mpauthor@microsoft.com' Purpose:    Discovers unhosted Demo.UnhostedClass class'        Creates a HealthServiceShouldManageEntity relationship between the local agent and the '            newly created Demo.UnhostedClass object to cause the object to'            be managed on the local agent instead of the Management Servers.'=================================================================================='Setup variables sent in through script arguments
SourceId = WScript.Arguments(0)         'GUID of discovery calling the script.  Provided by the MPElement variable.
ManagedEntityId = WScript.Arguments(1)    'GUID of target object.  Provided by the Target/Id variable.
sComputerName = WScript.Arguments(2)    'Name of the computer holding the Store Server or Store Client class.'Start by setting up API object and creating a discovery data object.'Discovery data object requires the MPElement and Target/ID variables.  The first argument in the method is always 0.
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)'===== Log that the script is running for troubleshooting
    Call oAPI.LogScriptEvent("DiscoverUnhosted.vbs", 123, 0, "Running discovery script")'===== Create the instance'Create an instance of the class and add it to the discovery data.'The KeyProperty property is required because it is the key property of the class.
    Set oUnhostedInstance = oDiscoveryData.CreateClassInstance("$MPElement[Name='Demo.UnhostedClass']$")
    oUnhostedInstance.AddProperty "$MPElement[Name='Demo.UnhostedClass']/KeyProperty$", sComputerName
    oDiscoveryData.AddInstance(oUnhostedInstance)'===== Force object to be managed on agent'By default, unhosted objects are managed on the Management Servers.'To manage the object on an agent instead, create an instance of the HealthServiceShouldManageEntity relationship.'Source of the relationship is the health service of the agent. Target of the relationship is the object itself.'Create an instance of the health service class.
    Set oHealthServiceInstance = oDiscoveryData.CreateClassInstance( "$MPElement[Name='SC!Microsoft.SystemCenter.HealthService']$" )
    oHealthServiceInstance.AddProperty "$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", sComputerName 
    oDiscoveryData.AddInstance oHealthServiceInstance'Create the relationship and add to the discovery data.
    set oShouldManageInstance = oDiscoveryData.CreateRelationshipInstance("$MPElement[Name='SC!Microsoft.SystemCenter.HealthServiceShouldManageEntity']$")
    oShouldManageInstance.Source = oHealthServiceInstance
    oShouldManageInstance.Target = oUnhostedInstance
    oDiscoveryData.AddInstance oShouldManageInstance'Return the discovery data.
oAPI.Return(oDiscoveryData)'Sample GUID for testing from the command line'{286671bf-40d1-133e-e623-68fe42a3c091}
]]></ScriptBody><TimeoutSeconds>60</TimeoutSeconds></DataSource></Discovery></Discoveries>

The example is heavily commented above so it should make sense for each step, if you need to make some changes for your specific needs.

That’s IT.  When this script runs, it will do three things:

1. Log an event in the OpsMgr event logs that it is running.
2. Create an instance of our custom, unhosted class “Demo.UnhostedClass”
3. Create a relationship on each agent so that the local HealthService will manage the instances of our custom class, and NOT the management servers.

In order to properly test this, I created some ample alert generating event rules, and performance collection rules, which are included in the MP I will attach to this post.

The behavior you will see, is that when you place Windows Computer into maintenance mode, our custom class instances will not go into maintenance mode, and their targeted workflows will continue to run on the agent.  HOWEVER, we will not transfer this data to the management servers until maintenance mode has ended.  We will generate any alerts at the time of maintenance mode ending, and performance, state, and event data will be inserted into both DB’s at that time.  I am not yet 100% clear on why we cannot seem to process this data until MM is over, but I am researching.  At any rate, this will ensure that we don’t miss any critical events that we need to collect regardless of maintenance mode windows.  We should use our custom class to target these collection rules.

MP attached below.

There is sometimes confusion over upgrades, if you can just upgrade to the next version, or if there is an CU (Cumulative Update) or UR (Update Rollup) minimum level that is required BEFORE a major version upgrade.

The MAJOR VERSION upgrade path is below, which Marnix talked about HERE. 

This article covers IN PLACE upgrades only, not side by side migrations.

SCOM 2007R2> SCOM 2012 RTM> SCOM 2012 SP1> SCOM 2012 R2

No shortcuts… you have to upgrade to each major version before continuing to the next.  So if you are way behind, considering a side-by-side migration can be MUCH less work.  Depends on where you are at.

Ok, back to the Update Rollup requirements.  Technically speaking, the upgrade from SCOM 2007 R2 > SCOM 2012 RTM has a documented CU level.  Per http://technet.microsoft.com/en-us/library/hh476934.aspx which states the following:

Upgrading to System Center 2012 – Operations Manager is supported from Operations Manager 2007 R2 CU4, or from the latest available CU.

Which basically means if you are at CU4 or later on SCOM 2007R2, you can upgrade to SCOM 2012 RTM.  There are no other statements in TechNet which state that any of the SCOM 2012 SP1 or R2 upgrades have a minimum UR requirement. 

Next, the upgrade from 2012 RTM to 2012 SP1 has this page:  http://technet.microsoft.com/en-us/library/jj628203.aspx  This “recommends” updating to SCOM 2012 RTM UR2 (or the latest UR available.)  I cannot say this is a requirement, it is likely what was tested at the time.

Same for SCOM 2012 SP1 to SCOM 2012 R2.  http://technet.microsoft.com/en-us/library/dn521010.aspx  This page states “We recommend that you update all of the System Center 2012 SP1 components with the most current update rollups.”  The most current UR at the time of that publishing was SCOM 2012 SP1 UR4.

Therefore, it appears the “required” upgrade path looks like:

SCOM 2007R2 CU4+> SCOM 2012 RTM> SCOM 2012 SP1> SCOM 2012 R2

Our “Recommended” rolling upgrade path looks like the following:

SCOM 2007R2 CU4+> SCOM 2012 RTM UR2+> SCOM 2012 SP1 UR4+> SCOM 2012 R2

If I were performing a rolling upgrade, this is most likely how I’d recommend doing it.  If you are planning a VERY SLOW migration from one version to another, due to lots of additional work that is necessary, such as upgrading OS’s or SQL versions along the way, then you might consider going ahead and applying whatever the most recent Update Rollup available for SCOM 2012.  There are documented here:

http://support.microsoft.com/kb/2906925

One word of caution.  The latest word from the product group just came out, on supported interop scenarios:

http://blogs.technet.com/b/momteam/archive/2014/01/17/system-center-2012-operations-manager-supported-configurations-interop-etc.aspx

They specifically called out one little point:

*Latest CU or UR applies in all cases

This most likely means, this is what they tested, at the time of this posting.  I cant say this is a “requirement”.  If you are doing a rolling upgrade, applying the latest UR to SCOM 2012 RTM before upgrading to SCOM 2012 SP1, then applying the latest UR to SCOM 2012 SP1 before upgrading to SCOM 2012 R2, would be a lot of extra effort, and technically is not a requirement to make the upgrade.   The best decision would be to figure out how long you plan to stay at each stage, how large your management group is, and how much effort it would be in order to deploy the latest UR in each case.  Also to test this in your environment before rolling out the upgrade to production.

The upgrade from 2007R2 CU4+ to SCOM 2012 RTM is the biggest jump, because you must update ALL your agents to SCOM 2012 before finalizing the upgrade.  After that, you can technically leave your agents alone, since a SCOM 2012RTM agent can report to both SCOM 2012 SP1 and R2 management servers.  Then just update your agents at the end, to SCOM 2012 R2 (plus whatever the latest UR is at that time).

Resource links:

SCOM 2007R2 > SCOM 2012 RTM Upgrade Guide TechNet

SCOM 2012 RTM > SCOM 2012 SP1 Upgrade Guide TechNet

SCOM 2012 SP1 > SCOM 2012 R2 Upgrade Guide TechNet

There are a TON of really good blogs out there with upgrade experiences, tips and tricks, so I cant possibly list them all.  I did want to point out a really cool link from a colleague, Wei H Lim, who wrote an updated version of the “Upgrade Helper” MP but for moving from SCOM 2012 SP1 > SCOM 2012 R2.  He does some amazing work so if you don’t follow his blog definitely add him to your lists.

OpsMgr- Sample Upgrade Helper MP for 2012 SP1 to 2012 R2 (SUHMP2012R2)

One of the powerful authoring capabilities of Visual Studio Authoring Extensions, is the use of “Snippets” to create lots of monitoring workflows with minimal effort.  Snippets can be input manually, or they can use a CSV file with the input data already prepared.

I had a request from a customer who needed an MP to monitor a Windows Server Role, but the only Management Pack available was an ancient MOM 2005 conversion MP.  So, I decided to create a new management pack that is native for SCOM for the server role.  One of the challenges, is that I needed to create about 140 event log rules.  This would be very time consuming.

Snippets solve that challenge.  Lets have a look.

Open Visual Studio with VSAE installed.  New project.  Give your project a name.  Choose Operations Manager 2007R2 management pack since we wont be doing anything special that could not be used in either version.

First, we should add some references which will be needed for certain types of workflows.  Right click “References” in Solution Explorer (at the right) and add references to the appropriate version of the Microsoft.SystemCenter.DataWarehouse.Library and the System.Performance.Library.  These should be located on your SCOM 2007 R2 media/management servers, or whatever version of SCOM you are writing the MP’s for.

Next, right click your solution name, add, new Item.

Scroll down to the bottom, and choose “Snippet Template”.  Give your template a name, and click OK.

This will add the template to your project in Solution Explorer on the right, and it will throw a bunch of code up.  Our default sample is a performance collection rule. 

The snippet template will accept a data input variable such as “#text(‘Rule Id’)#” in place of any fixed data that you would find in XML.  We want to use these tags to replace the things that would change in a rule, such as the Rule ID, the Perf Counter, Object, Instance, frequency, etc.  Review the examples.  You have items like #text, #choice, and #alias.

#text we already covered, it will replace that text with whatever we feed it from another source (later).  #choice lets you present a comma delimited list of options to the user executing the snippet with snippet data.  #alias simply will resolve your references and ensure the correct reference alias is chosen.  If you already know what aliases you are using in your manifest section of the XML, you can just hard code these.

Without changing any of the XML – just to show how these work, we will use the Perf Collection rule example.  Now, right click the Project again, Add, New Item.  Choose “Snippet Data”.  Give it a name and click Add.  This will bring up a box to select snippet type:

Click that, and it will show all snippet templates in the project.

Choose your snippet template name you created earlier, and click OK.

That’s it!  At this point, you can start adding new rules quickly and easily, by supplying the required data, OR you can import a huge list from a CSV you have pre-prepared using Excel. 

To demo the “add new item” select that.  You can see you are prompted to input the Rule ID, Counter, Object, Instance, and frequency.  For each item you add, you are generating lots of new XML. 

Fill in a few lines with dummy data.

When complete, click “Save”

Once you save it – you will see a .mpx file under your snippet object in Solution Explorer.  Right click it – choose Open.  This will show you the XML you just generated that will become simple perf collection rules when you Build the MP.

The example above is a simple one – for Perf Collection.  However, I want to use an alert generating rule, so what I will do is open the XML of some sample MP I already have with a good Alert generating Event rule, and copy/replace the perf collection XML sample with my own. 

The snippet template will accept a data input variable such as “#text(‘Rule Id’)#” in place of any fixed data that you would find in XML.  We want to use these tags to replace the things that would change in an event log rule, such as the Rule ID, the event ID, the alert name, and any display name data for each in the display strings. 

So – I Add a New Item, Snippet Template, and name it DemoEventRules.templatesnippet and click Add.

Now, I replace the XML with a rule I have already written from a previous MP.  This includes the section under <Rules> and <Presentation> and <DisplayStrings>.  Here is my initial sample MP Fragment:

<ManagementPackFragment SchemaVersion="1.0"><Monitoring><Rules><Rule ID="ruletest.testrulename" Enabled="true" Target="Windows!Microsoft.Windows.Server.OperatingSystem" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100"><Category>Alert</Category><DataSources><DataSource ID="DS" TypeID="Windows!Microsoft.Windows.EventProvider"><ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName><LogName>System</LogName><Expression><And><Expression><SimpleExpression><ValueExpression><XPathQuery Type="UnsignedInteger">EventDisplayNumber</XPathQuery></ValueExpression><Operator>Equal</Operator><ValueExpression><Value Type="UnsignedInteger">4000</Value></ValueExpression></SimpleExpression></Expression><Expression><SimpleExpression><ValueExpression><XPathQuery Type="String">PublisherName</XPathQuery></ValueExpression><Operator>Equal</Operator><ValueExpression><Value Type="String">MyEventSource</Value></ValueExpression></SimpleExpression></Expression></And></Expression></DataSource></DataSources><WriteActions><WriteAction ID="Alert" TypeID="Health!System.Health.GenerateAlert"><Priority>1</Priority><Severity>1</Severity><AlertName /><AlertDescription /><AlertOwner /><AlertMessageId>$MPElement[Name="ruletest.testrulename.AlertMessage"]$</AlertMessageId><AlertParameters><AlertParameter1>$Data/EventDescription$</AlertParameter1></AlertParameters><Suppression><SuppressionValue>$Data/EventDisplayNumber$</SuppressionValue><SuppressionValue>$Data/PublisherName$</SuppressionValue><SuppressionValue>$Data/LoggingComputer$</SuppressionValue></Suppression><Custom1 /><Custom2 /><Custom3 /><Custom4 /><Custom5 /><Custom6 /><Custom7 /><Custom8 /><Custom9 /><Custom10 /></WriteAction></WriteActions></Rule></Rules></Monitoring><Presentation><StringResources><StringResource ID="ruletest.testrulename.AlertMessage"/></StringResources></Presentation><LanguagePacks><LanguagePack ID="ENU" IsDefault="true"><DisplayStrings><DisplayString ElementID="ruletest.testrulename"><Name>Test Rule Display Name</Name></DisplayString><DisplayString ElementID="ruletest.testrulename.AlertMessage"><Name>Custom Alert Name Here</Name><Description>Event Description: {0}</Description></DisplayString></DisplayStrings></LanguagePack></LanguagePacks></ManagementPackFragment>

Now I will proceed to add in the variable input tags.  You can reuse the same tag in multiple places and only provide a single input for that as your CSV.

When I am done with all my tag edits, my MP fragment looks like this:

<ManagementPackFragment SchemaVersion="1.0"><Monitoring><Rules><Rule ID="#text('RuleId')#" Enabled="#text('Enabled')#" Target="Windows!Microsoft.Windows.Server.OperatingSystem" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100"><Category>Alert</Category><DataSources><DataSource ID="DS" TypeID="Windows!Microsoft.Windows.EventProvider"><ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName><LogName>#text('LogName')#</LogName><Expression><And><Expression><SimpleExpression><ValueExpression><XPathQuery Type="UnsignedInteger">EventDisplayNumber</XPathQuery></ValueExpression><Operator>Equal</Operator><ValueExpression><Value Type="UnsignedInteger">#text('EventId')#</Value></ValueExpression></SimpleExpression></Expression><Expression><SimpleExpression><ValueExpression><XPathQuery Type="String">PublisherName</XPathQuery></ValueExpression><Operator>Equal</Operator><ValueExpression><Value Type="String">#text('EventSource')#</Value></ValueExpression></SimpleExpression></Expression></And></Expression></DataSource></DataSources><WriteActions><WriteAction ID="Alert" TypeID="Health!System.Health.GenerateAlert"><Priority>1</Priority><Severity>#text('Severity')#</Severity><AlertName /><AlertDescription /><AlertOwner /><AlertMessageId>$MPElement[Name="#text('RuleId')#.AlertMessage"]$</AlertMessageId><AlertParameters><AlertParameter1>$Data/EventDescription$</AlertParameter1></AlertParameters><Suppression><SuppressionValue>$Data/EventDisplayNumber$</SuppressionValue><SuppressionValue>$Data/PublisherName$</SuppressionValue><SuppressionValue>$Data/LoggingComputer$</SuppressionValue></Suppression><Custom1 /><Custom2 /><Custom3 /><Custom4 /><Custom5 /><Custom6 /><Custom7 /><Custom8 /><Custom9 /><Custom10 /></WriteAction></WriteActions></Rule></Rules></Monitoring><Presentation><StringResources><StringResource ID="#text('RuleId')#.AlertMessage"/></StringResources></Presentation><LanguagePacks><LanguagePack ID="ENU" IsDefault="true"><DisplayStrings><DisplayString ElementID="#text('RuleId')#"><Name>#text('RuleDisplayName')#</Name></DisplayString><DisplayString ElementID="#text('RuleId')#.AlertMessage"><Name>#text('RuleAlertName')#</Name><Description>Event Description: {0}</Description></DisplayString></DisplayStrings></LanguagePack></LanguagePacks></ManagementPackFragment>

Once I am happy, save the DemoEventRules.templatesnippet.

Now, add a new item, Snippet Data, and provide a name like DemoEventRulesData.mpsd and click Add.   Choose our new snippet template from the list:

This time, in the upper right corner, choose “Import from CSV” and browse to a prepared CSV file.  Your CSV will need to be in the order of tags in your XML, which is visible in the rows in the Snippet Data:

I will choose a CSV that I have prepped for this, which is a bunch of event rules for WINS in the System Event log.  Here in an excerpt:

I select the CSV and click Open.  I can now review all the input data:

If I am happy – click “Save” icon at the top.

Now I can review the XML generated, by opening the .mpx file under my Snippet Data MPSD file in Solution Explorer.  If it took correctly, then you will see LOTS of XML.  If it didn’t, look at the bottom “Error List” and review any issues.  One thing I notices is that Excel likes to auto case “TRUE” and “FALSE” in all caps.  This must be lower case for XML.

When done, you can click “Build” and “Build Solution” at the top, and it will generate your XML.  This will be located at C:\Users\username\Documents\Visual Studio 2013\Projects\DemoSnippets\DemoSnippets\bin\Debug\ by default.

As you can see, using snippets and XML MP fragments is a great way to generate a lot of data, quite quickly. 

I will attach my CSV file and MP XML in a zip file below, for your reference.

I had a request from a customer recently, for an updated version of the WINS Management pack.  Microsoft’s WINS MP is currently an old MOM 2005 converted MP, and only supports NT4.0, Windows 2000 Server, and Server 2003.  My customer still relies on WINS for some legacy requirements, and they use Server 2008 for their WINS server platform.

There is just no simple way to “convert” a MOM 2005 conversion MP into a native SCOM 2007 MP.  Therefore, I wrote a new one.  I wanted an opportunity to test out the VSAE Snippets function, which I recently wrote about here:  How to use Snippets in VSAE to write LOTS of workflows, quickly!

Using Management Pack Viewer’s export to Excel function, I knew it would it should be easy to come up with a simple CSV file to feed Visual Studio to create the bulk of the MP quickly.   You can get the latest MPViewer here:  http://blogs.msdn.com/b/dmuscett/archive/2012/02/19/boris-s-tools-updated.aspx

So I recreated the WINS MP “somewhat” quickly using VSAE, then I added some views, performance collection, and a service monitor for the WINS service to round this out.

This MP will discover and monitor WINS on Server 2003, 2008, 2008R2, 2012, and 2012R2.  If you need to change this scope, you can edit the version information in the discovery:

<Expression>
  <RegExExpression>
    <ValueExpression>
      <XPathQuery Type="String">Values/WinsServerOSVersion</XPathQuery>
    </ValueExpression>
    <Operator>MatchesRegularExpression</Operator>
    <Pattern>^5.2|6.0|6.1|6.2|6.3$</Pattern>
  </RegExExpression>
</Expression>

There is a single class, “WINS Server” which discovers any Windows Server Operating System that has the WINS service installed, and it is set to automatic startup.

A single monitor, monitoring the running state of the WINS service.

140 event log rules, looking for known issues written to the event logs.

I also collected a few counters, so you can monitor how busy your WINS servers are:

The MP is attached below.  This is being published as an EXAMPLE ONLY.  It is not official nor is it supported by Microsoft.

Resource Pools in SCOM 2012 are an advancement over SCOM 2007, where a resource pool can be used to host instances, that have targeted workflows, and make them highly available.  This allowed the “All Management Servers Resource Pool” to host the instances that the RMS used to run in SCOM 2007.  This allowed for all management servers, in the AMSRP, to automatically load balance the old RMS workflows, across all management servers.

This also is used for thing like the Notifications Resource pool, which hosts two instances (or Top Level Managed Entities) which are the Pool object itself, and the “Alert Notification Subscription Server” which have many monitoring workflows target it to monitor the notification process health.

Well, we can also write workflows and target resource pools.  We might do this if we want a workflow to run on the management servers, but be highly available. 

In this example, I will take a VERY simple script that does nothing but log an event, and target the All Management Servers Resource Pool.

First, here is my PowerShell script:

$api = new-object -comObject 'MOM.ScriptAPI'
$api.LogScriptEvent("momscriptevent.ps1",9999,0,"this is a test event")

This script simply loads the MOM.ScriptAPI which is necessary to perform specific SCOM actions in script, such as logging events to the SCOM event lot, creating property bags, submitting discovery data, etc.

Then, it logs an informational event for the script in the SCOM event log wherever it is running.

Next up – write my rule to run the script.

We cannot use the SCOM 2007R2 Authoring Console to write this rule, as we need to target the Resource Pool object which SCOM 2007R2 does not understand, nor can it reference.  If you are most familiar with authoring in that tool, and you really want to use that SCOM 2007R2 Authoring Console, you can do that, and just target something else, like “Windows Server Operating System” and then change the class later in an XML editor.

Here is my manifest section.  Note – I need to reference the SCOM 2012 versions of these MP’s since this MP will not work on SCOM 2007:

<Manifest><Identity><ID>Target.ResourcePool.Example</ID><Version>1.0.0.1</Version></Identity><Name>Target.ResourcePool.Example</Name><References><Reference Alias="SC"><ID>Microsoft.SystemCenter.Library</ID><Version>7.0.8427.0</Version><PublicKeyToken>31bf3856ad364e35</PublicKeyToken></Reference><Reference Alias="Windows"><ID>Microsoft.Windows.Library</ID><Version>7.5.8500.0</Version><PublicKeyToken>31bf3856ad364e35</PublicKeyToken></Reference><Reference Alias="Health"><ID>System.Health.Library</ID><Version>7.0.8427.0</Version><PublicKeyToken>31bf3856ad364e35</PublicKeyToken></Reference><Reference Alias="System"><ID>System.Library</ID><Version>7.5.8500.0</Version><PublicKeyToken>31bf3856ad364e35</PublicKeyToken></Reference></References></Manifest>

Next, my simple rule.  Notice – I target the AMSRP class, I add a simple scheduler module to run this workflows every 30 seconds, and I have a simple write action based on Microsoft.Windows.PowerShellWriteAction module.

<Monitoring><Rules><Rule ID="Target.ResourcePool.Example.RunSampleScriptRule" Enabled="true" Target="SC!Microsoft.SystemCenter.AllManagementServersPool" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100"><Category>Custom</Category><DataSources><DataSource ID="SchedDS" TypeID="System!System.SimpleScheduler"><IntervalSeconds>30</IntervalSeconds><SyncTime></SyncTime></DataSource></DataSources><WriteActions><WriteAction ID="PoshWA" TypeID="Windows!Microsoft.Windows.PowerShellWriteAction"><ScriptName>momscriptevent.ps1</ScriptName><ScriptBody><![CDATA[
$api = new-object -comObject 'MOM.ScriptAPI'
$api.LogScriptEvent("momscriptevent.ps1",9999,0,"this is a test event")]]></ScriptBody><TimeoutSeconds>30</TimeoutSeconds></WriteAction></WriteActions></Rule></Rules></Monitoring>

That’s it!  I will post my full XML as a sample attached to this article.

Now, when I import this MP, ONE of my management servers should start running this workflow.  It will be whichever MS is hosting the AMSRP class at that time.  This could change as loads are reshuffled, or as management servers are taken down for maintenance.

I have three management servers, SCOM01, SCOM02, and SCOM03.  I can see this workflow is running happily on SCOM02:

I will stop the health service on SCOM02, or shut the OS down.

The last event I got from the test script was at 9:09:56 AM.

What happens now, is the other management servers are waiting for a heartbeat failure threshold to take a vote, and evict SCOM02 from the pool.  The SCOM database is also a “default observer” and plays a role in the voting process. 

At 9:12:36 AM, I start to see the pool manager events coming in, showing that they other management servers are redistributing the workflows.  My 9999 event is now being created on SCOM03, with my first event showing up at 9:12:55 AM, or about 3 minutes after SCOM02 went down.

My sample XML is provided below.

This Cumulative Update (CU7) shipped back in January of 2013, but I never wrote up a quick guide on deploying it.  I am doing that now just for the purposes of those customers who want to apply CU7 to their SCOM 2007R2 environment before the upgrade to SCOM 2012.

The KB article describing the fixes, changes, and instructions:

http://support.microsoft.com/kb/2783850/

Get it from the download Center:

http://www.microsoft.com/en-us/download/details.aspx?id=36379

List of all OpsMgr R2 Cumulative Updates:

http://support.microsoft.com/kb/2453149

Here are the high level fixes:

Cumulative Update 7 for Operations Manager 2007 R2 resolves the following issues:

• Console performs poorly when User Roles are used to scope object access.
• Availability data is not shown for the current day when daily aggregation is used.
• Behavior is inconsistent between some views on web console and console.
• Log files do not roll over when the Unicode log file is monitored.
• Several security issues are fixed.

Cumulative Update 7 for Operations Manager 2007 R2 resolves the following cross-platform issues:

• Logical disk performance statistics are not collected for some volume types on Solaris computers.
• Some Network Adapters on HP-UX computers may not be discovered.
• Network adapter performance statistics are not collected for HP-UX network adapters.
• The Solaris 8 and 9 agent may not restart after an ungraceful shutdown.

Note You can download the management packs for new cross plat operating system versions by going to the following Microsoft website:

System Center Operations Manager 2007 R2 Cross Platform Monitoring Management Packs

Let’s Roll:

So – first – I download it. The hotfix is about 1000MB.

Now – before your heart rate starts rising…. understand… this update combines the Cross Plat CU with the OpsMgr CU. (CU3 through CU6 did this as well) Aligning these is a very good thing – but it ends up increasing the size of the initial download. No worries though – I will demonstrate how to only have to copy specific files to lessen the impact of distributing this update to all your management servers and gateways, if copying a 1GB file around is a problem for you. Read about that here: http://blogs.technet.com/b/kevinholman/archive/2010/10/12/command-line-and-software-distribution-patching-scenarios-for-applying-an-opsmgr-cumulative-update.aspx

Next step – READ the documentation… understand all the steps required, and formulate the plan.

I build my deployment plan based on the release notes in the KB article. My high level plan looks something like this:

1. Backup the Operations and Warehouse databases, and all unsealed MP’s.
2. Apply the hotfix to the RMS
3. Run the SQL script(s) update against the OpsDB AND Warehouse DB.
4. Import the updated management packs provided.
5. Apply the hotfix to all secondary Management Servers.
6. Apply the hotfix to my Gateway Servers.
7. Apply the hotfix to my agents by approving them from pending
8. Apply the hotfix my dedicated consoles (Terminal servers, desktop machines, etc…)
9. Apply the hotfix to my Web Console server
10. Update manually installed agents…. well, manually.
11. Apply the hotfix to my Audit collection servers

Ok – looks like 11 easy steps. This order is not set in stone – it is a recommendation based on logical order, from the release notes. For instance – if you wanted to update ALL your infrastructure before touching any agent updates – that probably makes more sense and would be fine.  Perhaps you have already deployed SCOM 2012 agents, then you might just be updating the infrastructure only.

****Requirement– as a required practice for a major update/hotfix, you should log on to your OpsMgr role servers using a domain user account that meets the following requirements:

• OpsMgr administrator role
• Member of the Local Administrators group on all OpsMgr role servers (RMS, MS, GW, Reporting)
• SA (SysAdmin) privileges on the SQL server instances hosting the Operations DB and the Warehouse DB.

These rights (especially the user account having SA priv on the DB instances) are often overlooked. These are the same rights required to install OpsMgr, and must be granted to apply major hotfixes and upgrades (like RTM>SP1, SP1>R2, etc…) Most of the time the issue I run into is that the OpsMgr admin logs on with his account which is an OpsMgr Administrator role on the OpsMgr servers, but his DBA’s do not allow him to have SA priv over the DB instances. This must be granted temporarily to his user account while performing the updates, then can be removed, just like for the initial installation of OpsMgr as documented HERE. At NO time do your service accounts for MSAA or SDK need SA (SysAdmin) priv to the DB instances…. unless you decide to log in as those accounts to perform an update (which I do not recommend).

Ok, Lets get started.

1. Backups. I run a fresh backup on my OpsDB and Warehouse DB’s – just in case something goes really wrong. Since I haven’t grabbed my RMS encryption key in a long while – I go ahead and make a backup of that too, just to make sure I have it somewhere.

I also will take a backup of all my unsealed MP’s. You can do the backup in PowerShell, here is an example which will backup all unsealed MP’s to a folder C:\mpbackup:

Get-ManagementPack | where {$_.Sealed -eq $false} | export-managementpack -path C:\MPBackup

We need to do this just in case we require restoring the environment for any reason.

2. Apply the hotfix to the RMS.

Tip #1: Here is a tip that I have seen increase the success rate: Reboot your RMS/RMS nodes before starting the update. This will free up any locked processes or WMI processes that are no longer working, and reduce the chances of a timeout for a service stopping, file getting updated, etc.

Tip #2: If you are running any SDK based connectors – it is a good idea to stop these first. Things like a Remedy product connector service, Alert Update Connector, Exchange Correlation Engine, etc… This will keep them from throwing errors like crazy when setup bounces the SDK service.

Tip #3: If you are low on disk space, and you have previously installed prior R2-CU’s, you can uninstall those and make sure they are removed from \Program Files (x86)\System Center 2007 R2 Hotfix Utility\ directory. This can free up a substantial amount of disk space, and once applied these files are no longer necessary.

Tip #4: If you are running the Exchange Correlation Service for the Exchange 2010 MP, it might be a good idea to disable this service during the CU update. This service uses a lot of resources and would be best to keep it out of the picture for the CU process.

****Note: If applying this update to a RMS cluster – FIRST see: How to apply a SCOM hotfix to a clustered RMS

****Note: Many people struggle with OpsMgr hotfixes – for failing to follow instructions. When applying an OpsMgr hotfix – you need to copy the downloaded MSI file (such as SystemCenterOperationsManager2007-R2CU7-KB2783850-X86-X64-IA64-ENU.MSI) to EACH and EVERY Management server and Gateway. You need to INSTALL this hotfix installer utility to EACH Management Server and Gateway. Don’t try and just copy the update MSP files. This wont work and you will fail to update some components. Common complaints are that the agents never go into pending actions, or the agent update files never get copied over to the \AgentManagement folders. In almost ALL cases, people were taking a shortcut and making assumptions - Don’t.   Docopy the 1GB file to each machine, then install the hotfix utility, then run the hotfix from the splash screen that comes up (this is a bootstrapper program), immediately after installing the downloaded MSI. The only acceptable alternative to this process – is to install/extract the 1GB MSI to a workstation, and then build a command line based package as described below. For memory limited test environments – the command line method is the way to go.

Since my RMS is running Server 2008 R2 – I need to open an elevated command prompt to install any SCOM hotfixes. That is just how it is. So I launch that – and call the MSI I downloaded (SystemCenterOperationsManager2007-R2CU7-KB2783850-X86-X64-IA64-ENU.MSI). This will install the Hotfix Utility to the default location. I always recommend installing this hotfix utility to the default location. You can always uninstall the utility later to clean up disk space.

Tip: (This part may take a LONG TIME to complete if calling the 1GB file on a system will limited memory resources. This is because it must consume 1GB of RAM to open the file, temporarily. For production systems meeting the minimum supported 4GB, this probably wont be as much of an issue. For virtualized labs and test environments where you are running very limited memory, (1-2GB RAM) you will see this process take a considerable amount of time. On my 1GB memory virtualized management servers, it would not install at all. I upped them to 2GB and they took about 10-20 minutes to open and run the setup program. See section at the end of this article **Command line install** for ideas on how to mitigate this issue if affected)

Eventually – a splash screen comes up:

I choose Run Server Update, and rock and roll. You MUST execute the update from this “Run Server Update” UI. NO OTHER METHOD will work.

It runs through with success, I click finish – then another setup kicks off. This is by design. There should be three actual setups running consecutively (once for the core update, one for the localization, and one for Xplat.)

You could see this potentially three times:

Then wait around 30 seconds for any post install processes to complete, and then click “Exit” on the splash screen.

If you have trouble at with this stage – get some error messages, or if the installation rolls back – see the troubleshooting and known issues at the KB article and below in this post.

If you are patching a clustered RMS – you can continue the process using the link posted above – and complete the second node.

Now – it is time to validate the update applied correctly. I can see the following files got updated on the RMS in the standard install path: \Program Files\System Center Operations Manager 2007\

**note – this isn't all the files included in the hotfix package, just a spot check to make sure they are getting updated.

Next I check my \AgentManagement folder. This is the folder that any agents will get updates from. I check the \x86, \AMD64, and \ia64 directories:

3. Time to run the SQL scripts. There are 2 scripts, located on the RMS, in the CC:\Program Files (x86)\System Center 2007 R2 Hotfix Utility\KB2783850\SQLUpdate folder:

• CU_Database.sql
• CU_DataWarehouse.sql

Let’s start with CU_Database.sql

I simply need to open this file with SQL management studio – or edit it with notepad – copy the contents – and paste it in a query window that is connected to my Operations (OperationsManager) Database. I paste the contents of the file in my query window, it takes about a minute to complete in my lab. It will return a list of rows updated.

Next up – we now need to connect to the Warehouse database instance, and open a new query window against the OperationsManagerDW database. We will execute CU_DataWarehouse.sql which will return “Command(s) completed successfully”.

DO NOT skip step number 3 above, and do not continue on until this is completed.

4. Next up – import the MP updates. That's easy enough. They are located at C:\Program Files (x86)\System Center 2007 R2 Hotfix Utility\KB2626076\ManagementPacks\ and are named:

• Microsoft.SystemCenter.DataWarehouse.Report.Library
• Microsoft.SystemCenter.WebApplication.Library.mp
• Microsoft.SystemCenter.WSManagement.Library.mp

These will upgrade existing MP’s in your environment. They take a few minutes each to import.

At this point – if you are using cross platform monitoring for Unix agents – you would upgrade the Xplat MP’s via a separate download. See the KB article for steps on this, and potentially upgrading your Unix agents if required.

System Center Operations Manager 2007 R2 Cross Platform Monitoring Management Packs

This download site contains the latest MP’s which were updated/included for CU7.

5.  Time to apply the hotfix to my management servers. I have 1 secondary MS server which is Windows Server 2008 R2 SP1. So I open an elevated command prompt to run the hotfix utility MSI,

Again – I MUST RUN SystemCenterOperationsManager2007-R2CU7-KB2783850-X86-X64-IA64-ENU.MSI on each Management server. This installs the hotfix utility, which will then launch the splash screen.

Tip: (This part may take a LONG TIME to complete if calling the 1GB file on a system will limited memory resources. This is because it must consume 1GB of RAM to open the file, temporarily. For production systems meeting the minimum supported 4GB, this probably wont be much of an issue. For virtualized labs and test environments where you are running very limited memory, you will see this process take a considerable amount of time. On my 1GB memory virtualized management servers, it would not install. I upped them to 2GB and they took about 10-20 minutes to open and run the setup program. See section at the end of this article **Command line install** for ideas on how to mitigate this issue if affected)

Once the splash screen comes up I “Run Server Update” These all install without issue (again – three setups run consecutively). I spot check the \AgentManagement directories and the DLL versions, and all look great. REMEMBER – you can sure patch all your management servers at the same time, however, your agents WILL fail over during this time because we stop the MS HealthService during the update. Keep this in mind. It is best to update management servers one at a time, synchronously, to keep your agents from failing over to the RMS and overloading it, or causing massive Heartbeat failures because they have nowhere to report to.

6. Next up – any Gateway machines here.

I “Run Gateway Update” from the splash screen, and setup kicks off. It runs three separate installs and I see the following – 3 times:

Remember to spot check your DLL versions and \AgentManagement directories. They both should be updated.

7. I check my Pending Management view in the Administration pane of the console – and sure enough – all the agents that are set to “Remotely Manageable = Yes” in the console show up here pending an agent update. I approve all my agents (generally we recommend to patch no more than 200 agents at any given time.)

After the agents update – I need to do a quick spot check to see that they are patched and good – so I use the “Patchlist” column in the HealthService state view to see that. For creating a “Patchlist” view – see LINK

8. I have a few dedicated consoles which need updating. One is a desktop machine and the other is my terminal server which multiple people use to connect to the management group. So – I kick off the installer – and just choose “Run Server Update” as well. I do a spot check of the DLL files – and see the following was updated on the terminal server:

I can also perform a “Help > About” in the console itself – this will now show the update version for your console:

9. Next up – Web Consoles. I run mine on a stand alone management server, which I have already patched with CU7. So – I will simply just go check their DLL files to ensure they got updated.

From: \Program Files\System Center Operations Manager 2007\Web Console\bin

Additionally – there are some manual steps needed to secure the Web Console from a client side script vulnerability, per the KB Article  (you might have already done this in a previous CU):

Update the Web.Config file on the Web Console server role computers

• To ensure that all cookies created by the web console cannot be accessed by client cscript, add the following configuration to the Web.Config file on each Web console server:

<httpCookies httpOnlyCookies="true"/>

• If the web console is configured to run under SSL, add the following configuration to ensure all cookies are encrypted:

<httpCookies httpOnlyCookies="true" requireSSL="true"/>

Now – ONE of these lines need to be added to your web.config file. Scroll down in that file until you see the <system.web> tag. You can add one of these on a new line IMMEDIATELY after the <system.web> line. Here is mine – before and after:

Use the correct line based on your SSL configuration status for your web console. Reboot your web console server to pick up these changes.

10. At this point – I update ACS components on any ACS running Management servers that have already been patched with CU7 – but this time run the update and choose to “Run ACS Server Update”

After you update your collector…. you must run a SQL script that is included in the update.  This script will be run against your ACS database.  See the KB article for instructions.

11. Manually installed agents. I have a fair bit of these… so I will do this manually, or set up a SCCM package to deploy them. Most of the time you will have manually installed agents on servers behind firewalls, or when you use AD integration for agent assignment, or when you installed manually on DC’s, or as a troubleshooting step.

Additional Activities:

12. Since this particular environment I am updating is going from CU6 to CU7 – I need to import the latest cross platform management packs. If I am not using and don’t desire to use OpsMgr to monitor cross platform OS’s like SUSE, RedHat, and Solaris… then I can skip this step. However, if I do want to be fully up to date for Xplat monitoring – I need to ensure I have the latest Xplat MP’s available. The ones that are version .304 are current: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18891

13. I need to update the ACS reports, if I am using ACS. We have included in the CU6, some new reports which fix some reported issues with the reports. These can be found at:

C:\Program Files (x86)\System Center 2007 R2 Hotfix Utility\KB2783850\ACS\Reports

You might have already updated these in a previous CU.  They started shipping in CU5.

At this point I would browse to my Sql Reporting Services website that hosts my ACS reports, and import these RDL’s over the existing reports, or place them in a new folder for testing, and then move them later.

Now – the update is complete.

The next step is to implement your test plan steps. You should build a test plan for any time you make a change to your OpsMgr environment. This might include scanning the event logs on the RMS and all MS for critical and warning events… looking for anything new, or serious. Testing reporting is working, check the database for any unreasonable growth, run queries to see if anything looks bad from a most common alerts, events, perf, state perspective. Run a perfmon – and ensure your baselines are steady – and nothing is different on the database, or RMS. If you utilize any product connectors – make sure they are functioning.

The implementation of a solid test plan is very important to change management. Please don't overlook this step.

*** Command line install option

In some situations, you might want to perform a command line installation of the update on your RMS/management server. Most of the time – I don’t recommend this, because you generally need the feedback if each part was successful or not. However, there are situations where it is required.

One example is for users who have issues with the 1GB MSI file, and getting the hotfix installer running, especially on limited memory systems. For those, you can use a command line options which removes the issue.

For additional command line options, including how to make a CU package smaller, and how to patch consoles, agents, etc…. see the KB article which contains some guidance, and the following post which contains command line package ideas from a previous CU:

http://blogs.technet.com/b/kevinholman/archive/2010/10/12/command-line-and-software-distribution-patching-scenarios-for-applying-an-opsmgr-cumulative-update.aspx

Known issues/Troubleshooting:

1. New management packs cannot be edited in the authoring console after the Cumulative Update is installed
When a new management pack is created after CU4, CU5, CU6, or CU7 is installed and then an attempt is made to edit the management pack in the Authoring console, the Authoring console cannot edit the management pack because it cannot find the latest version of the Microsoft.SystemCenter.Library Management Pack (build .61 for CU4 and build .81 for CU5 and later). This is resolved – please see: http://support.microsoft.com/kb/2590414

2. CU fails to apply.The SDK or config service may not start after this, and CU fails on subsequent retries. The installation rolls back and you get a dialog box that the setup was interrupted before completion. There are two possible issues, with workarounds to this. One is caused by a general timeout, the other is a .NET 2.0 Issue due to a CRL response delay. Start with workaround “#1” and if that fails, try workaround “#2”. #2 is a fairly rare condition.

Workaround #1:

The services are timing out while trying to start. Using http://support.microsoft.com/kb/922918 set the ServicesPipeTimeout entry for all services to have 3 minutes (180000 milliseconds) and REBOOT the server. Then try and apply CU4. It should apply. You likely will see a few warning messages about failure to start the OMCFG service – just click ok and the setup will continue.

Workaround #2:

Using Follow the steps that are outlined in Microsoft Knowledge Base article KB936707

***Note: This hotfix likely will not be required. The hotfix is ONLY required if you are still running .NET 2.0 RTM. This hotfix is included in .NET 2.0SP1 and later. The hotfix does not resolve the issue, simply put – the hotfix (or .NET 2.0SP1 or later) simply ENABLES the use of a new tag in XML which will allow for disabling of CRL checking. If your RMS is on Windows Server 2008 or 2008R2 – you already have this hotfix included.

***Note: Once you have verified you have .NET 2.0 SP1 or later installed – you MUST perform the second step – which involves editing 2 application.exe.config files. The KB article is misleading in that it tells you to add this information as an entire section – which is incorrect – you must find the <runtime> section in your existing config files – and add a SINGLE new line to that existing section.

The manifest files are located on the RMS at the \Program Files\System Center Operations Manager 2007\ root directory. The manifest files will need to be edited for the config and sdk service on affected RMS. The file names are:

• Microsoft.Mom.Sdk.ServiceHost.exe.config
• Microsoft.Mom.ConfigServiceHost.exe.config

In between the EXISTING <runtime> and </runtime> lines – you need to ADD a NEW LINE with the following:

<generatePublisherEvidence enabled="false"/>

This solution disables CRL checking for the specified execute-ables, permanently.

3. Agentpatchlist information incomplete, or CU patching failure. The agent Patchlist is showing parts of CU7, CU6, or CU5 but also CU4, CU3, CU2 or CU1 or nothing. The CU7 localization ENU update is not showing in patchlist. This appears to be related to the agents needing a reboot required by Windows Installer from a previous installation package. Once they are rebooted, and a repair initiated, the patchlist column looks correct with the CU7 and CU7 ENU (localized) information. The correct and complete patchlist information will appear as below:

System Center Operations Manager 2007 R2 Cumulative Update 7 - ENU Components; System Center Operations Manager 2007 R2 Cumulative Update 7 - KB2783850;

If you apply Cumulative Update 3 or 4 for Operations Manager 2007 R2, the pushed agent may not display the update list correctly. This issue occurs because the agent updates in Cumulative Update 3/4 for Operations Manager 2007 R2 may require a restart operation and then a repair operation. If you do not restart these servers after you apply Cumulative Update 3/4 for Operations Manager 2007 R2, the agent updates in Cumulative Update 6 for Operations Manager 2007 R2 are not applied. However, the restart required state is set on these computers. Therefore, you have to restart these computers and then repair the agent to apply the updates in Cumulative Update 6 for Operations Manager 2007 R2.

System Center 2012 R2 has shipped the first Update Rollup, UR1.

http://support.microsoft.com/kb/2904734/en-us

There are updates available for OpsMgr 2012 R2, VMM 2012 R2, and DPM 2012 R2, in this release.

See the KB article for full details of each, with links to the individual updates and downloads.

System Center 2012 SP1 has shipped Update Rollup 5.

http://support.microsoft.com/kb/2904730/en-us

There are updates available for OpsMgr 2012 SP1, VMM 2012 SP1, Orchestrator 2012 SP1 and DPM 2012 SP1, in this release.

See the KB article for full details of each, with links to the individual updates and downloads.

KB Article:   http://support.microsoft.com/kb/2904678/en-us

Download catalog site:  http://catalog.update.microsoft.com/v7/site/Search.aspx?q=2904678

Key fixes:

Issue 1 - An error occurs when you run the p_DataPurging stored procedure. This error occurs when the query processor runs out of internal resources and cannot produce a query plan.
Issue 2 - Data warehouse BULK INSERT commands use an unchangeable, default 30-second time-out value that may cause query time-outs.
Issue 3 - Many 26319 errors are generated when you use the Operator role. This issue causes performance problems.
Issue 4 - The diagram component does not publish location information in the component state.
Issue 5 - Renaming a group works correctly on the console. However, the old name of the group appears when you try to override a monitor or scope a view based on group.
Issue 6 - SCOM synchronization is not supported in the localized versions of Team Foundation Server.
Issue 7 - An SDK process deadlock causes the Exchange correlation engine to fail.
Issue 8 - The "Microsoft System Center Advisor monitoring server" reserved group is visible in a computer or group search.
Issue 9 - Multiple Advisor Connector are discovered for the same physical computer when the computer hosts a cluster.
Issue 10 - A Dashboard exception occurs if the criteria that are used for a query include an invalid character or keyword.

Xplat updates:

Issue 1 - On a Solaris-based computer, an error message that resembles the following is logged in the Operations Manager log. This issue occurs if a Solaris-based computer that has many monitored resources runs out of file descriptors and does not monitor the resources. Monitored resources may include file systems, physical disks, and network adapters.
Note The Operations Manager log is located at /var/opt/microsoft/scx/log/scx.log.     errno = 24 (Too many open files)    This issue occurs because the default user limit on Solaris is too low to allocate a sufficient number of file descriptors. After the rollup update is installed, the updated agent overrides the default user limit by using a user limit for the agent process of 1,024.

Issue 2 - If Linux Container (cgroup) entries in the /etc/mtab path on a monitored Linux-based computer begin with the "cgroup" string, a warning that resembles the following is logged in the agent log.  Note When this issue occurs, some physical disks may not be discovered as expected.  Warning [scx.core.common.pal.system.disk.diskdepend:418:29352:139684846989056] Did not find key 'cgroup' in proc_disk_stats map, device name was 'cgroup'.

Issue 3 - Physical disk configurations that cannot be monitored, or failures in physical disk monitoring, cause failures in system monitoring on UNIX and Linux computers. When this issue occurs, logical disk instances are not discovered by Operations Manager for a monitored UNIX-based or Linux-based computer.

Issue 4 - A monitored Solaris zone that is configured to use dynamic CPU allocation with dynamic resource pools may log errors in the agent logs as CPUs are removed from the zone and do not identify the CPUs currently in the system. In rare cases, the agent on a Solaris zone with dynamic CPU allocation may hang during routine monitoring.  Note This issue applies to any monitored Solaris zones that are configured to use dynamic resource pools and a "dedicated-cpu" configuration that involves a range of CPUs.

Issue 5 - An error that resembles the following is generated on Solaris 9-based computers when the /opt/microsoft/scx/bin/tools/setup.sh script does not set the library pathcorrectly. When this issue occurs, the omicli tool cannot run.  ld.so.1: omicli: fatal: libssl.so.0.9.7: open failed: No such file or directory

Issue 6 - If the agent does not retrieve process arguments from the getargs subroutine on an AIX-based computer, the monitored daemons may be reported incorrectly as offline. An error message that resembles the following is logged in the agent log:   Calling getargs() returned an error

Issue 7 - The agent on AIX-based computers considers all file cache to be available memory and does not treat minperm cache as used memory. After this update rollup is installed, available memory on AIX-based computer is calculated as: free memory + (cache – minperm).

Issue 8 - The Universal Linux agent is not installed on Linux computers that have OpenSSL versions greater than 1.0.0 if the library file libssl.so.1.0.0 does not exist. An error message that resembles the following is logged:  /opt/microsoft/scx/bin/tools/.scxsslconfig: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

I have seen *several* customers having issues with the OpsDB grooming/purging process, so that looks like a good one to get implemented, especially if this was affecting you.

Lets get started.

From reading the KB article – the order of operations is:

1. Install the update rollup package on the following server infrastructure:
   • Management servers
   • Gateway servers
   • Web console server role computers
   • Operations console role computers
2. Apply SQL scripts (see installation information).
3. Manually import the management packs.

There are no agent updates in this UR1.  Agents will be placed into pending, however there are no updates.  You must reject the agents in pending.

Now, we need to add another step – if we are using Xplat monitoring – need to update the Linux/Unix MP’s and agents.

4.  Update Unix/Linux MP’s and Agents.

1.  Management Servers

Since there is no RMS anymore, it doesn’t matter which management server I start with.  There is no need to begin with whomever holds the RMSe role.  I simply make sure I only patch one management server at a time to allow for agent failover without overloading any single management server.

I can apply this update manually via the MSP files, or I can use Windows Update.  I have 3 management servers, so I will demonstrate both.  I will do the first management server manually.  This management server holds 3 roles, and each must be patched:  Management Server, Web Console, and Console.

The first thing I do when I download the updates from the catalog, is copy the cab files for my language to a single location:

Then extract the contents:

Once I have the MSP files, I am ready to start applying the update to each server by role.

***Note:  You MUST log on to each server role as a Local Administrator, SCOM Admin, AND your account must also have System Administrator (SA) role to the database instances that host your OpsMgr databases.

My first server is a management server, and the web console, and has the OpsMgr console installed, so I copy those update files locally, and execute them per the KB, from an elevated command prompt:

This launches a quick UI which applies the update.  It will bounce the SCOM services as well.  The update does not provide any feedback that it had success or failure.  You can check the application log for the MsiInstaller events for that.

You can also spot check a couple DLL files for the file version attribute. 

Next up – run the Web Console update:

This runs much faster.   A quick file spot check:

Lastly – install the console update (make sure your console is closed):

A quick file spot check:

Secondary Management Servers:

I now move on to my secondary management servers, applying the server update, then the console update. 

On this next management server, I will use Windows Update.  I check online, and make sure that I have configured Windows Update to give me updates for additional products:

This shows me two applicable updates for this server:

I apply these updates (along with some additional Windows Server Updates I was missing, and reboot each management server, until all management servers are updated.

Updating Gateways:

I can use Windows Update or manual installation.

The update launches a UI and quickly finishes.

Then I will spot check the DLL’s:

2. Apply the SQL Script

In the path on your management servers, where you installed/extracted the update, there is a SQL script file: 

%SystemDrive%\Program Files\System Center 2012\Operations Manager\Server\SQL Script for Update Rollups

Open a SQL management studio query window, connect it to your Operations Manager database, and then open the script file.  Make sure it is pointing to your OperationsManager database, then execute the script.

****Note – at the time of this writing – the KB article says to run this against the DataWarehouse – the KB article is in error

Click the “Execute” button in SQL mgmt. studio.  The execution could take a considerable amount of time and you might see a spike in processor utilization on your SQL database server during this operation.

You will see the following (or similar) output:

3. Manually import the management packs?

We have four updated MP’s to import  (MAYBE!).

The TFS MP bundles are only used for specific scenarios, such as DevOps scenarios where you have integrated APM with TFS, etc.  If you are not currently using these MP’s, there is no need to import or update them.  I’d skip this MP import unless you already have these MP’s present in your environment.

The Advisor MP’s are only needed if you are using System Center Advisor services.

However, the Image and Visualization libraries deal with Dashboard updates, and these need to be updated.

I import all of these without issue.

Reject the agent update

Agents are placed into pending actions by this update.  HOWEVER – there are no updates for the agents in the Update Rollup.  You must approve the agents in pending, using the console or PowerShell.

4.  Update Unix/Linux MPs and Agents

Next up – I download and extract the updated Linux MP’s for SCOM 2012 SP1 UR2

http://www.microsoft.com/en-us/download/details.aspx?id=29696

7.5.101 is current at this time for SCOM 2012 R2. 

****Note – take GREAT care when downloading – that you select the correct download for R2.  You must scroll down in the list and select the MSI for 2012 R2:

Download the MSI and run it.  It will extract the MP’s to C:\Program Files (x86)\System Center Management Packs\System Center 2012 R2 Management Packs for Unix and Linux\

Update any MP’s you are already using.

You will likely observe VERY high CPU utilization of your management servers and database server during and immediately following these MP imports.  Give it plenty of time to complete the process of the import and MPB deployments.

Next up – you would upgrade your agents on the Unix/Linux monitored agents.  You can now do this straight from the console:

You can input credentials or use existing RunAs accounts if those have enough rights to perform this action.

I have an environmental issue that caused my Ubuntu server to fail. 

Review:

Now at this point, we would check the OpsMgr event logs on our management servers, check for any new or strange alerts coming in, and ensure that there are no issues after the update.

Known issues:

See the existing list of known issues documented in the KB article.

I previously wrote about the new agent control panel applet with SCOM 2012 here:

http://blogs.technet.com/b/kevinholman/archive/2011/11/10/opsmgr-2012-new-feature-the-agent-control-panel-applet.aspx

There will be times that we want to make changes to our agent configuration, and often times a script is the simplest way to do this on a large number of agents.  Perhaps we want to add an additional management group to the agent, or enable/disable Active directory integration? 

The most common scenario will be when multi-homing agents in a side by side SCOM 2007 to SCOM 2012 migration, to have an automated way to remove the old SCOM 2007 management group.

The agent configuration objects are documented here:  http://msdn.microsoft.com/en-us/library/hh328967.aspx

ManagementServiceConfigurationClass.AddManagementGroup
This method adds a new, but inactive, management group to the agent.
 
ManagementServiceConfigurationClass.DisableActiveDirectoryIntegration
This method prevents an agent from querying Active Directory or Active Directory Domain Services (AD DS) for the list of the management groups in which this agent participates.
 
ManagementServiceConfigurationClass.EnableActiveDirectoryIntegration
This method allows an agent to query Active Directory or AD DS for the list of the management groups in which this agent participates.
 
ManagementServiceConfigurationClass.GetActiveDirectoryIntegrationEnabled
This method returns a Boolean value indicating whether or not true Active Directory integration is enabled for the agent.
 
ManagementServiceConfigurationClass.GetManagementGroup
This method returns a ManagementServiceConfigurationClass Object object.
 
ManagementServiceConfigurationClass.GetManagementGroups
This method returns a ManagementGroupCollectionClass Object object.
 
ManagementServiceConfigurationClass.ReloadConfiguration
This method reloads the updated agent configuration.

ManagementServiceConfigurationClass.RemoveManagementGroup
This method removes an active management group from the agent.
 
ManagementServiceConfigurationClass.UpdateActionAccount
This method updates the existing action account for a given management group with the given account.
 

Here are some code examples that run in VBScript.  I choose VBscript because not all agent managed machines will have PowerShell installed (Server 2003, and 2008 by default).

Add a management group to an existing agent

Option Explicit
Dim objMSConfig
Set objMSConfig = CreateObject("AgentConfigManager.MgmtSvcCfg")' Add a management group
Call objMSConfig.AddManagementGroup ("ManagementGroupName", "ManagementServer.domain.com",5723)

Add a management group to an existing agent, and initiate a restart of the agent to immediately accept the changes

Option Explicit
Dim objMSConfig
Set objMSConfig = CreateObject("AgentConfigManager.MgmtSvcCfg")' Add a management group
Call objMSConfig.AddManagementGroup ("ManagementGroupName", "ManagementServer.domain.com",5723)
Call objMSConfig.ReloadConfiguration

Remove a management group from an agent, and restart

Option Explicit
Dim objMSConfig
Set objMSConfig = CreateObject("AgentConfigManager.MgmtSvcCfg")' Remove a management group
Call objMSConfig.RemoveManagementGroup ("ManagementGroupName")
Call objMSConfig.ReloadConfiguration

Disable AD Integration on an agent (then restart) which will delete all AD integrated management groups from the agent.

Option Explicit
Dim objMSConfig
Set objMSConfig = CreateObject("AgentConfigManager.MgmtSvcCfg")' Disable AD Integration
Call objMSConfig.DisableActiveDirectoryIntegration()
Call objMSConfig.ReloadConfiguration

You can get pretty fancy with your scripts – to add error detection, if/then, to make a lot of actions in one push.  Here is an example written by Joe Thompson, from http://www.systemcentercentral.com/forums-archive/topic/deploying-scom-2012-agents-using-sccm-2012/

I will insert his code example directly here:

Option Explicit 
On Error Resume Next
Dim objMSConfig, objMG, isChange 
isChange = 0
Set objMSConfig = CreateObject(“AgentConfigManager.MgmtSvcCfg”) 
If Err <> 0 Then  
wscript.echo “Agent not installed or extension error!”  
wscript.quit(Err) 
End if
'See if Mgmt Group exists 
Set objMG = objMSConfig.GetManagementGroup (“MYNEWMG”) 
If Err <> 0 Then 
‘New Mgmt not set.  
’Add a management group  
Call objMSConfig.AddManagementGroup (“MYNEWMG”, “mymanagementserver.contoso.com”,5723)  
objMSConfig.ReloadConfiguration  
isChange = isChange + 1 
End If
WSCript.Sleep 15000
‘Remove a management group if it exists 
Set objMG = objMSConfig.GetManagementGroup (“MYOLDMG”) 
If Err = 0 Then  
Call objMSConfig.RemoveManagementGroup (“MYOLDMG”)  
objMSConfig.ReloadConfiguration  
isChange = isChange + 1 
End If
Wscript.Echo “Compliant”
WScript.Quit

There are also good samples on how to make a SCOM task with a script like this – to add or remove management groups straight from your existing SCOM deployment:  http://scomandplus.blogspot.com/2012/07/adding-scom-agent-task-to-update.html

Wrapping it up in a management pack:

I am going to use all of this above – to create a management pack.  The purpose of this MP will be to discover which agents are multi-homed, and then provide an agent based task in the new management group – to remove the old management group.

I will start with a simple class and discovery, which will discover any healthservice that has an HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Agent Management Groups key. 

Next, I will create a monitor, that will look for the existence of a Registry Key, which I wrote about here:  http://blogs.technet.com/b/kevinholman/archive/2010/07/29/how-to-create-monitor-for-existence-of-a-registry-key.aspx  We can use this to detect the existence of the unwanted management group.

Last, we will create a task, and target it to our new class.

Here is the XML of the MP.  It is very simple… a class (based on Local Application) with a simple registry discovery that should discover all agents.  Then a monitor to inspect for your “old” management group.  Then a console task (which will show up when you look at the state view included) to remove the management group (this is hard coded to my test MG name, but you just need to edit the script to change it).

<ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><Manifest><Identity><ID>Example.SCOMMigration</ID><Version>1.0.0.9</Version></Identity><Name>Example.SCOMMigration</Name><References><Reference Alias="SC"><ID>Microsoft.SystemCenter.Library</ID><Version>6.1.7221.0</Version><PublicKeyToken>31bf3856ad364e35</PublicKeyToken></Reference><Reference Alias="Windows"><ID>Microsoft.Windows.Library</ID><Version>6.1.7221.0</Version><PublicKeyToken>31bf3856ad364e35</PublicKeyToken></Reference><Reference Alias="Health"><ID>System.Health.Library</ID><Version>6.1.7221.0</Version><PublicKeyToken>31bf3856ad364e35</PublicKeyToken></Reference><Reference Alias="System"><ID>System.Library</ID><Version>6.1.7221.0</Version><PublicKeyToken>31bf3856ad364e35</PublicKeyToken></Reference></References></Manifest><TypeDefinitions><EntityTypes><ClassTypes><ClassType ID="Example.SCOMMigration.OldMG" Accessibility="Internal" Abstract="false" Base="Windows!Microsoft.Windows.LocalApplication" Hosted="true" Singleton="false"/></ClassTypes></EntityTypes><MonitorTypes><UnitMonitorType ID="Example.SCOMMigration.OldMGExists.MonitorType" Accessibility="Internal"><MonitorTypeStates><MonitorTypeState ID="RegKeyExists" NoDetection="false"/><MonitorTypeState ID="RegKeyMissing" NoDetection="false"/></MonitorTypeStates><Configuration /><MonitorImplementation><MemberModules><DataSource ID="RegDS" TypeID="Windows!Microsoft.Windows.RegistryProvider"><ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName><RegistryAttributeDefinitions><RegistryAttributeDefinition><AttributeName>OldMGExists</AttributeName><Path>SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Management Groups\OMMG</Path><PathType>0</PathType><AttributeType>0</AttributeType></RegistryAttributeDefinition></RegistryAttributeDefinitions><Frequency>60</Frequency></DataSource><ConditionDetection ID="CDExists" TypeID="System!System.ExpressionFilter"><Expression><SimpleExpression><ValueExpression><XPathQuery Type="String">Values/OldMGExists</XPathQuery></ValueExpression><Operator>Equal</Operator><ValueExpression><Value Type="String">true</Value></ValueExpression></SimpleExpression></Expression></ConditionDetection><ConditionDetection ID="CDMissing" TypeID="System!System.ExpressionFilter"><Expression><SimpleExpression><ValueExpression><XPathQuery Type="String">Values/OldMGExists</XPathQuery></ValueExpression><Operator>Equal</Operator><ValueExpression><Value Type="String">false</Value></ValueExpression></SimpleExpression></Expression></ConditionDetection></MemberModules><RegularDetections><RegularDetection MonitorTypeStateID="RegKeyExists"><Node ID="CDExists"><Node ID="RegDS"/></Node></RegularDetection><RegularDetection MonitorTypeStateID="RegKeyMissing"><Node ID="CDMissing"><Node ID="RegDS"/></Node></RegularDetection></RegularDetections></MonitorImplementation></UnitMonitorType></MonitorTypes></TypeDefinitions><Monitoring><Discoveries><Discovery ID="Example.SCOMMigration.OldMGDiscovery" Enabled="true" Target="Windows!Microsoft.Windows.Server.OperatingSystem" ConfirmDelivery="false" Remotable="true" Priority="Normal"><Category>Discovery</Category><DiscoveryTypes><DiscoveryClass TypeID="Example.SCOMMigration.OldMG"/></DiscoveryTypes><DataSource ID="DS" TypeID="Windows!Microsoft.Windows.FilteredRegistryDiscoveryProvider"><ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName><RegistryAttributeDefinitions><RegistryAttributeDefinition><AttributeName>AgentRegExists</AttributeName><Path>SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Agent Management Groups</Path><PathType>0</PathType><AttributeType>0</AttributeType></RegistryAttributeDefinition></RegistryAttributeDefinitions><Frequency>3600</Frequency><ClassId>$MPElement[Name="Example.SCOMMigration.OldMG"]$</ClassId><InstanceSettings><Settings><Setting><Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Name><Value>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value></Setting><Setting><Name>$MPElement[Name="System!System.Entity"]/DisplayName$</Name><Value>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</Value></Setting></Settings></InstanceSettings><Expression><SimpleExpression><ValueExpression><XPathQuery Type="String">Values/AgentRegExists</XPathQuery></ValueExpression><Operator>Equal</Operator><ValueExpression><Value Type="String">true</Value></ValueExpression></SimpleExpression></Expression></DataSource></Discovery></Discoveries><Tasks><Task ID="Example.SCOMMigration.RemoveOldMGTask" Accessibility="Internal" Enabled="true" Target="Example.SCOMMigration.OldMG" Timeout="300" Remotable="true"><Category>Maintenance</Category><WriteAction ID="Script" TypeID="Windows!Microsoft.Windows.ScriptWriteAction"><ScriptName>RemoveOldMG.vbs</ScriptName><Arguments /><ScriptBody><![CDATA[On error resume next
Dim objMSConfig
Set objMSConfig = CreateObject("AgentConfigManager.MgmtSvcCfg")'See if Mgmt Group exists 
Set objMG = objMSConfig.GetManagementGroup ("OMMG") 
If Err <> 0 Then 
wscript.echo "OMMG management group does not exist on this agent"
wscript.quit
End If'Remove AD int or manually configured management group'Check if AD Integration is enabled 
objADint = objMSConfig.GetActiveDirectoryIntegrationEnabled()
If objADint <> 1 then
wscript.echo "AD Integration is not enabled on this agent"
wscript.echo "Removing old manually configured management group"
Call objMSConfig.RemoveManagementGroup ("OMMG")
else
wscript.echo "AD Integration is enabled and returned value: " & objADint'Disable AD Integration
wscript.echo "Disabling AD Integration"
Call objMSConfig.DisableActiveDirectoryIntegration()
End If'Restart agent healthservice out of band
wscript.echo "Attempting to restart Healthservice out of band"
    dim strServiceName, objWMIService, colListofServices, objService
    strServiceName = "HealthService"
    dim sFilePath
    Dim objFSO 'As FileSystemObject
    Dim objTextFile 'As Object
    Dim oShell
    Set oShell = CreateObject( "WScript.Shell" )
    temppath=oShell.ExpandEnvironmentStrings("%TMP%")'wscript.echo "Temp Path" & temppath
    sText="net stop Healthservice && net start Healthservice"
    sFilePath=temppath & "\sshs.bat"'wscript.echo "Writing to " & sFilePath
    Set objFSO = CreateObject("Scripting.FileSystemObject")
    Set objTextFile = objFSO.CreateTextFile(sFilePath, True)' Write a line.
    objTextFile.Write (sText)
    objTextFile.Close
    oShell.run sFilePath]]></ScriptBody><TimeoutSeconds>60</TimeoutSeconds></WriteAction></Task></Tasks><Monitors><UnitMonitor ID="Example.SCOMMigration.OldMgExistsMonitor" Accessibility="Internal" Enabled="true" Target="Example.SCOMMigration.OldMG" ParentMonitorID="Health!System.Health.ConfigurationState" Remotable="true" Priority="Normal" TypeID="Example.SCOMMigration.OldMGExists.MonitorType" ConfirmDelivery="true"><Category>Custom</Category><OperationalStates><OperationalState ID="UIGeneratedOpStateId12568c009a744c66a11a3d10f605a46a" MonitorTypeStateID="RegKeyExists" HealthState="Warning"/><OperationalState ID="UIGeneratedOpStateIdfb9c9eca86164bdf99d155617a574b9e" MonitorTypeStateID="RegKeyMissing" HealthState="Success"/></OperationalStates><Configuration /></UnitMonitor></Monitors></Monitoring><Presentation><Views><View ID="Example.SCOMMigration.NewElement" Accessibility="Internal" Enabled="true" Target="Example.SCOMMigration.OldMG" TypeID="SC!Microsoft.SystemCenter.StateViewType" Visible="true"><Category>Custom</Category><Criteria /></View></Views><Folders><Folder ID="Example.SCOMMigration.FolderRoot" Accessibility="Internal" ParentFolder="SC!Microsoft.SystemCenter.Monitoring.ViewFolder.Root"/></Folders><FolderItems><FolderItem ElementID="Example.SCOMMigration.NewElement" Folder="Example.SCOMMigration.FolderRoot"/></FolderItems></Presentation><LanguagePacks><LanguagePack ID="ENU" IsDefault="true"><DisplayStrings><DisplayString ElementID="Example.SCOMMigration"><Name>Example SCOM Migration MP</Name><Description /></DisplayString><DisplayString ElementID="Example.SCOMMigration.FolderRoot"><Name>Example SCOM Migration</Name><Description /></DisplayString><DisplayString ElementID="Example.SCOMMigration.NewElement"><Name>Example SCOM Migration</Name><Description /></DisplayString><DisplayString ElementID="Example.SCOMMigration.OldMG"><Name>Old Management Group Class</Name></DisplayString><DisplayString ElementID="Example.SCOMMigration.OldMGDiscovery"><Name>Old Management Group Class Discovery</Name><Description /></DisplayString><DisplayString ElementID="Example.SCOMMigration.OldMGExists.MonitorType"><Name>Old MG Exists MonitorType</Name><Description /></DisplayString><DisplayString ElementID="Example.SCOMMigration.OldMgExistsMonitor"><Name>Old Management Group Exists Monitor</Name><Description /></DisplayString><DisplayString ElementID="Example.SCOMMigration.OldMgExistsMonitor" SubElementID="UIGeneratedOpStateId12568c009a744c66a11a3d10f605a46a"><Name>RegKeyExists</Name></DisplayString><DisplayString ElementID="Example.SCOMMigration.OldMgExistsMonitor" SubElementID="UIGeneratedOpStateIdfb9c9eca86164bdf99d155617a574b9e"><Name>RegKeyMissing</Name></DisplayString><DisplayString ElementID="Example.SCOMMigration.RemoveOldMGTask"><Name>Remove Old ManagementGroup</Name><Description /></DisplayString></DisplayStrings></LanguagePack></LanguagePacks></ManagementPack>

My script is pretty simple – borrowing from a few examples above:

On error resume next
Dim objMSConfig
Set objMSConfig = CreateObject("AgentConfigManager.MgmtSvcCfg")'See if Mgmt Group exists 
Set objMG = objMSConfig.GetManagementGroup ("OMMG") 
If Err <> 0 Then 
wscript.echo "OMMG management group does not exist on this agent"
wscript.quit
End If'Remove AD int or manually configured management group'Check if AD Integration is enabled 
objADint = objMSConfig.GetActiveDirectoryIntegrationEnabled()
If objADint <> 1 then
wscript.echo "AD Integration is not enabled on this agent"
wscript.echo "Removing old manually configured management group"
Call objMSConfig.RemoveManagementGroup ("OMMG")
else
wscript.echo "AD Integration is enabled and returned value: " & objADint'Disable AD Integration
wscript.echo "Disabling AD Integration"
Call objMSConfig.DisableActiveDirectoryIntegration()
End If'Restart agent healthservice out of band
wscript.echo "Attempting to restart Healthservice out of band"
    dim strServiceName, objWMIService, colListofServices, objService
    strServiceName = "HealthService"
    dim sFilePath
    Dim objFSO 'As FileSystemObject
    Dim objTextFile 'As Object
    Dim oShell
    Set oShell = CreateObject( "WScript.Shell" )
    temppath=oShell.ExpandEnvironmentStrings("%TMP%")'wscript.echo "Temp Path" & temppath
    sText="net stop Healthservice && net start Healthservice"
    sFilePath=temppath & "\sshs.bat"'wscript.echo "Writing to " & sFilePath
    Set objFSO = CreateObject("Scripting.FileSystemObject")
    Set objTextFile = objFSO.CreateTextFile(sFilePath, True)' Write a line.
    objTextFile.Write (sText)
    objTextFile.Close
    oShell.run sFilePath

Here is the view:

Health explorer for the monitor:

You can multi-select many agents and run the task:

Note – you MUST run the task as a user account that has local administrator rights on each agent.  If you run the task as the default agent action account (local system) the service will stop but not restart.  It is quite complicated to make a SCOM task that can reliably restart the SCOM service:

The output:

I previously wrote about some updated Base OS Monitoring Packs that shipped, adding many new features and fixes for monitoring the OS, and some issues that the changes created.  You can read the old article here:  http://blogs.technet.com/b/kevinholman/archive/2011/11/17/opsmgr-logical-disk-free-space-alerts-don-t-show-percent-and-mb-free-values-in-the-alert-description.aspx

One of the areas this new MP focused on, was changing a lot of the “average threshold” monitors to “consecutive sample” monitors.  This helps control the noise when there are short term fluctuations in a performance value, or when some counters can spike tremendously for a very short time, skewing the average.  So for the most part – changing these over to consecutive samples is a good thing.  That said, one of the changes made was to the Logical Disk free space monitors, both for Windows Server 2003, 2008, and 2012 disks.

The script used to monitor logical disk free space in previous versions of the Monitoring Pack would output two additional propertybags for free space in MB and Percent.  This was very useful, because these values could easily be added to the alert description, alert context, and health explorer.  This was very beneficial, because the consumer of the alert in a notification knew precisely how much space was left for each and every alert generated.  Here are some examples of how it looked previously:

Now – when the new MP shipped – this script was changed to support the new consecutive samples monitortype, and was completely re-written.  When it was rewritten, the script no longer returned these propertybags, so they were removed from the alert description, alert context, and health explorer.  The current MP (6.0.6958.0) looks like this:

The monitor still works perfectly as designed, and you are alerted when thresholds that you set are breached.  The only negative side effect is the loss of information in the alert description.

Several customers have indicated that they preferred to have these values back in the alert description.  The only real way to handle this scenario, until the signed and sealed MP gets updated at some point in the future, is to disable the built in monitor, and enable a new monitor with an alert description that you like.

I have written three addendum MP’s attached at the bottom of this article, which do exactly that – I created new monitors (essentially the same monitors from the previous older version of the Base OS MP’s) and included overrides which disable the existing monitors from the sealed MP’s.  These new monitors are essentially exact copies of the monitors before they got updated.  They run once per hour and have all the default settings from the previous monitors.

With the addendum MP imported – health explorer looks like the following:

Note the new name for the addendum monitor, and the fact that the existing “Logical Disk Free Space” monitor is unloaded as it is disabled via override.

These addendum MP’s for Windows Server 2003, 2008, and 2012 each simply include a script datasource, monitortype, and monitor to use instead of the items in the current sealed Base OS MP’s.  These addendum MP’s are unsealed, so you have two options:

1. Leave them unsealed, and use them as-is.  This allows you to be able to tweak the monitor names, alert descriptions, and any other settings further.
2. Seal the MP’s with your own key (recommended) after making any adjustments that you desire.  This will be necessary in order to create overrides for existing groups in other MP’s should you desire to use those.

One caveat to understand– is that any overrides you have created on the existing Base OS free space monitors will have to be re-created here on these new ones.  There is no easy workaround for that.

Let me know if you have any issues using these addendum MP’s (which are provided as a sample only) and I will try to address them.

Credits – to Larry Mosley at Microsoft for doing most of the initial heavy lifting writing the workaround MP.

Another approach:  Daniele Grandini has authored a different solution to this issue.  What he has done, is to add diagnostics to the existing sealed Logical Disk Free space monitors, which will add the actual disk free space in MB and % to Health explorer, so console users can have this information in real time as they use alert/health explorer to troubleshoot a free space issue.  His solution will not be able to add these values to the alert description to be sent in an email notification/pager/ticket, but for those companies that use the console and health explorer, it is a more graceful solution in that you don’t have to re-engineer all your existing overrides, and you still get the benefit of having consecutive samples.  It is worth a look:  http://nocentdocent.wordpress.com/2011/11/19/opsmgr-logical-disk-free-space-alerts-dont-show-percent-and-mb-free-values-in-the-alert-description/comment-page-1/#comment-1018

Had a customer asking about how to create a monitor that would count the number of files in a folder, and then run a script based recovery to take an action (restart a service) afterwards.

This is not a complicated request, but probably a common scenario.  There are lots of examples on the web for the pieces and parts.  Lets just put it all together.

This MP will be using:

The file count script from: http://www.scom2k7.com/scom-2007-script-to-monitor-file-count-inside-a-directory/

The script restart from: http://blogs.catapultsystems.com/cfuller/archive/2011/07/06/automating-the-restart-of-a-service-in-opsmgr.aspx

I will add the event logging from: http://blogs.technet.com/b/kevinholman/archive/2009/07/22/101-using-custom-scripts-to-write-events-to-the-opsmgr-event-log-with-momscriptapi-logscriptevent.aspx

You can create this simple MP in the SCOM UI (two state monitor, script based) or any other authoring tool.  I’ll be showing the XML

The manifest is super simple:

<Manifest><Identity><ID>Demo.ScriptMonitor.Files</ID><Version>1.0.0.1</Version></Identity><Name>Demo.ScriptMonitor.Files</Name><References><Reference Alias="Windows"><ID>Microsoft.Windows.Library</ID><Version>6.1.7221.0</Version><PublicKeyToken>31bf3856ad364e35</PublicKeyToken></Reference><Reference Alias="System"><ID>System.Library</ID><Version>6.1.7221.0</Version><PublicKeyToken>31bf3856ad364e35</PublicKeyToken></Reference><Reference Alias="SystemCenter"><ID>Microsoft.SystemCenter.Library</ID><Version>6.1.7221.0</Version><PublicKeyToken>31bf3856ad364e35</PublicKeyToken></Reference><Reference Alias="Health"><ID>System.Health.Library</ID><Version>6.1.7221.0</Version><PublicKeyToken>31bf3856ad364e35</PublicKeyToken></Reference></References></Manifest>

The monitor is a simple Microsoft.Windows.TimedScript.TwoStateMonitorType

It runs a script (see below) every 10 minutes, counting files in a folder.  We pass two parameters, the folder location and the file count threshold.

<Monitors><UnitMonitor ID="Demo.ScriptMonitor.Files.FileCountMonitor" Accessibility="Public" Enabled="true" Target="Windows!Microsoft.Windows.Server.OperatingSystem" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="Windows!Microsoft.Windows.TimedScript.TwoStateMonitorType" ConfirmDelivery="false"><Category>Custom</Category><AlertSettings AlertMessage="Demo.ScriptMonitor.Files.FileCountMonitor_AlertMessageResourceID"><AlertOnState>Warning</AlertOnState><AutoResolve>true</AutoResolve><AlertPriority>Normal</AlertPriority><AlertSeverity>Warning</AlertSeverity><AlertParameters><AlertParameter1>$Data/Context/Property[@Name='ret2']$</AlertParameter1><AlertParameter2>$Data/Context/Property[@Name='ret']$</AlertParameter2></AlertParameters></AlertSettings><OperationalStates><OperationalState ID="Demo.ScriptMonitor.Files.FileCountMonitor.Good" MonitorTypeStateID="Success" HealthState="Success"/><OperationalState ID="Demo.ScriptMonitor.Files.FileCountMonitor.Bad" MonitorTypeStateID="Error" HealthState="Warning"/></OperationalStates><Configuration><IntervalSeconds>600</IntervalSeconds><SyncTime /><ScriptName>CountFiles.vbs</ScriptName><Arguments>"C:\test" 5</Arguments><ScriptBody>Dim oAPI, oBag, objFSO, objFldr, bSendError, strOut
bSendError = False
Set oAPI = CreateObject("MOM.ScriptAPI")
Call oAPI.LogScriptEvent("CountFiles.vbs",6001,0,"Starting countfiles script") 
Set oBag = oAPI.CreateTypedPropertyBag(StateDataType)
Set eBag = oAPI.CreateTypedPropertyBag(StateDataType)
Set oArgs = WScript.Arguments
If oArgs.Count &lt; 2 Then
strReturn = "Script aborted. Not enough parameters provided"
Call eBag.AddValue("State","BAD")
Call eBag.AddValue("ret",strReturn)
Call oAPI.Return(eBag)
WScript.Quit -1
End If 
strOut = checkfolder(oArgs(0),int(oArgs(1)))
If bSendError Then
strReturn = strOut
Call oBag.AddValue("State","BAD")
Call oBag.AddValue("ret2", objFldr.Files.Count)
Call oBag.AddValue("ret",strReturn)

Else
'WScript.Echo("GOOD "&amp; vbNewLine &amp; strOut)
Call oBag.AddValue("State","GOOD")

End If
if 0 &lt;&gt; Err.number Then
strReturn = "An Error occured: " &amp; Err.Description
Call eBag.AddValue("State","BAD")
Call eBag.AddValue("ret",strReturn)
Call oAPI.Return(eBag)
else
Call oAPI.Return(oBag)
end if
Function checkfolder(strfldname,numberfiles)
Set objFSO=CreateObject("Scripting.FileSystemObject")
Set objFldr=objFSO.GetFolder(strfldname)
If objFldr.Files.Count &gt; numberfiles Then
checkfolder = numberfiles
bSendError = True
End If
End Function </ScriptBody><TimeoutSeconds>60</TimeoutSeconds><ErrorExpression><SimpleExpression><ValueExpression><XPathQuery Type="String">Property[@Name='State']</XPathQuery></ValueExpression><Operator>Equal</Operator><ValueExpression><Value Type="String">BAD</Value></ValueExpression></SimpleExpression></ErrorExpression><SuccessExpression><SimpleExpression><ValueExpression><XPathQuery Type="String">Property[@Name='State']</XPathQuery></ValueExpression><Operator>Equal</Operator><ValueExpression><Value Type="String">GOOD</Value></ValueExpression></SimpleExpression></SuccessExpression></Configuration></UnitMonitor></Monitors>

Next we add a recovery.  This simple recovery script restarts the spooler service anytime the monitor goes into an unhealthy state.

<Recoveries><Recovery ID="Demo.ScriptMonitor.Files.RecoveryRestartService" Accessibility="Public" Enabled="true" Target="Windows!Microsoft.Windows.Server.OperatingSystem" Monitor="Demo.ScriptMonitor.Files.FileCountMonitor" ResetMonitor="false" ExecuteOnState="Warning" Remotable="true" Timeout="300"><Category>Custom</Category><WriteAction ID="Demo.ScriptMonitor.Files.WA" TypeID="Windows!Microsoft.Windows.ScriptWriteAction"><ScriptName>RestartService.vbs</ScriptName><Arguments /><ScriptBody>Option Explicit 
Dim oAPI, strServiceName, objWMIService, colListOfServices, objService
Set oAPI = CreateObject("MOM.ScriptAPI") 
Call oAPI.LogScriptEvent("RestartService.vbs",5555,2,"Recovery - Starting recovery script to restart service") 

WScript.sleep 3000 

Call oAPI.LogScriptEvent("RestartService.vbs",5556,2,"Recovery - Attempting service stop")'Stop Service 
strServiceName = "spooler" 
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2") 
Set colListOfServices = objWMIService.ExecQuery("Select * from Win32_Service Where Name ='" &amp; strServiceName &amp;"'") 
For Each objService in colListOfServices 
objService.StopService() 
Next 

WScript.sleep 5000 

Call oAPI.LogScriptEvent("RestartService.vbs",5557,2,"Recovery - Attempting service start")'Start Service 
strServiceName = "spooler" 
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2") 
Set colListOfServices = objWMIService.ExecQuery ("Select * from Win32_Service Where Name ='" &amp; strServiceName &amp;"'") 
For Each objService in colListOfServices 
objService.StartService() 
Next 

WScript.sleep 5000

WScript.Quit</ScriptBody><TimeoutSeconds>60</TimeoutSeconds></WriteAction></Recovery>

That’s it!

I am attaching the sample XML below.

Check it out:

http://www.scom2k7.com/scom-2012-maintenance-mode-scheduler/

This is a very polished new tool, that enabled you to create schedules for agents and groups to go into maintenance mode.

It is essentially a web service, with a VERY simple UI, to allow users to create schedules for maintenance mode, or for on-demand maintenance mode.  It even includes a nice tool/icon to place on all your servers desktops, to allow server admins to immediately place a server into maintenance mode from the server itself (which communicates with the central web service).

On top of that, it includes a Windows 8 app as well as a front end to the web service.

Very, very nice!

Turn on agent proxy for all agents where it is disabled:

get-SCOMagent | where {$_.ProxyingEnabled -match "False"} | Enable-SCOMAgentProxy

Turn on agent proxy as a default setting for all new agents to be deployed, never to have to mess with this again:

add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";
new-managementGroupConnection -ConnectionString:scomserver.domain.com;
set-location "OperationsManagerMonitoring::";
Set-DefaultSetting -Name HealthService\ProxyingEnabled -Value True

Thanks for Daniele Muscetta and John Erskine for the references on the default-setting.

Tao has updated his MP.  This is a really cool concept of taking some of the most common issues, misconfigurations, and errors that occur with SCOM 2012, and creating a management pack to watch for them.

His most current MP as of this post is http://blog.tyang.org/2014/02/23/opsmgr-2012-self-maintenance-management-pack-update-version-2-3-0-0/

If you want to better understand what his MP is looking for, check out some of the previous posts:

http://blog.tyang.org/2013/03/03/opsmgr-self-maintenance-management-pack/

http://blog.tyang.org/2013/08/04/opsmgr-self-maintenance-management-pack-version-2-0-0-0/

There is a link on his blog to download it and it comes with documentation on how to use it.  Very nice community MP that you should consider checking out for your deployments.  Also follow his blog if you don’t already, there is TONS of good stuff there.