This is Part 2 in a series of posts described here:  https://blogs.technet.microsoft.com/kevinholman/2016/06/04/authoring-management-packs-the-fast-and-easy-way-using-visual-studio/

Now we will start with our first example fragment – discovering an app and creating a class for it.

Step 1:  Download and extract the sample MP fragments.  These are available here:  https://gallery.technet.microsoft.com/SCOM-Management-Pack-VSAE-2c506737

I will update these often as I enhance and add new ones, so check back often for new versions.

Step 2:  Open your newly created MP solution, and open Solution Explorer.

We want to keep things organized – so we want to create folders to organize our solution as we go.  This wont affect anything in the MP XML, it just keeps the solution organized.

Right click “Fab.DemoApp” and choose Add > New Folder

Name the folder “Classes”

Step 3:  Add the class fragment:  Right click “Classes” and choose Add > Existing Item.

Browse to where you extracted my sample fragments, and choose the Generic.Class.And.Discovery.Registry.KeyExists.Fragment.mpx.

Select this fragment which now shows up under classes in solution explorer, and you should see the XML pop up in Visual Studio.

Step 4:  Find and Replace!

This is the area where I tried to make using Visual Studio and VSAE MUCH easier.  I cam up with a standard item list that you will need to commonly replace in your XML, and enclosed each item with “##” to make them easy to find.  I also included notes at the top of each fragment, explaining what the fragment does, and what you need to replace.

This allows you to create LOTS of monitoring ins SECONDS  simply using Find and Replace.

For this example, we to replace ##CompanyID##, ##AppName##, ##RegistryKey##

CompanyID is easy – for my demo’s that’s my company abbreviation, or “Fab”.

AppName in this case, is a fake application I called “DemoApp”

RegistryKey is simply going to be the path in the registry which designates that “DemoApp” is installed.

I start with replacing ##CompanyID## with “Fab”

Edit > Find and Replace > Quick Replace

There is a “Replace All” button at the red arrow above.

Now I repeat this for ##AppName##

And lastly – the ##RegistryKey””##.

My Registry Key for this app is HKEY_LOCAL_MACHINE\SOFTWARE\DemoApp

However, in SCOM “HKEY_LOCAL_MACHINE” is already hard coded in the code, and if you look at the sample XML – SOFTWARE is already present:

              <Path>SOFTWARE\##RegistryKey##</Path>

So all I need to do is replace ##RegistryKey## with “DemoApp”

Done!

Three quick find/replace actions, and we have a working class definition, with a registry discovery.  Look through the XML to familiarize yourself with all that you just created.  There is a TypeDefinitions section with your Class definition, along with a Discovery to discovery all machines with the registry key.

Step 5:  Build the MP.  Then import it as a test.

Open Discovered Inventory in the SCOM console – Change Target type – and find the class you just created

After a few minutes, the agents should download this MP, run the discovery, and any agents with that registry key will show up as an instance of our new class:

Congrats!  You have dynamically discovered all computers with the “DemoApp” application in your company.  Start to finish, about 1 minute.  5 minutes tops if you are learning VSAE for the first time.

This is Part 3 in a series of posts described here:  https://blogs.technet.microsoft.com/kevinholman/2016/06/04/authoring-management-packs-the-fast-and-easy-way-using-visual-studio/

In our next example fragment – we will monitor a service by creating a monitor that targets our custom class.

Step 1:  Download and extract the sample MP fragments.  These are available here:  https://gallery.technet.microsoft.com/SCOM-Management-Pack-VSAE-2c506737

I will update these often as I enhance and add new ones, so check back often for new versions.

Step 2:  Open your newly created MP solution, and open Solution Explorer.  This solution was created in Part 1, and the class was created in Part 2.

Step 3:  Create a folder and add the fragment to it. 

Create a folder called “Monitors” in your MP:

Right click Monitors, and Add > Existing item.

Find the fragment named “Generic.Monitor.Service.WithAlert.Fragment.mpx” and add it.

Select Generic.Monitor.Service.WithAlert.Fragment.mpx in solution explorer to display the XML.

Step 4:  Find and Replace

Replace ##CompanyID## with our company ID which is “Fab”

Replace ##AppName## with our App ID, which is “DemoApp”

Replace ##ClassID## with the custom class we created in Step 2.  This was “Fab.DemoApp.Class” from our previous class fragment.

Replace ##ServiceName## with the short name of any service.  For this Demo, since “DemoApp” is a made up example, we will just use the spooler service.  So replace with “spooler”

That took all of 2 minutes.  Take another few minutes to review the XML we have in this fragment.  It is a simple monitor definition, that will generate an alert and change state when the spooler service isn’t running.  There are also display strings which can be modified for the monitor display name, alert name, and alert description.

Step 5:  Build the MP.   BUILD > Build Solution.

Step 6:  Import or Deploy the management pack.

When enough time passes, the agent will get the new MP, and will load the new monitor.  In our discovered inventory view – we should be able to see the state change from “Unmonitored” to “Healthy” because our custom class now gets health rollup from the monitor we just created.

Step 7:  Test the MP.

Stop the Print Spooler service.  Verify we see a state change and the alert we expect:

Nice!   And easy.

This is Part 4 in a series of posts described here:  https://blogs.technet.microsoft.com/kevinholman/2016/06/04/authoring-management-packs-the-fast-and-easy-way-using-visual-studio/

In our next example fragment – we will monitor the event log for a specific event, and generate an alert if it occurs.

Step 1:  Download and extract the sample MP fragments.  These are available here:  https://gallery.technet.microsoft.com/SCOM-Management-Pack-VSAE-2c506737

I will update these often as I enhance and add new ones, so check back often for new versions.

Step 2:  Open your newly created MP solution, and open Solution Explorer.  This solution was created in Part 1, and the class was created in Part 2.

Step 3:  Create a folder and add the fragment to it. 

Create a folder called “Rules” in your MP:

Right click Rules, and Add > Existing item.

Find the fragment named “Generic.Rule.AlertGenerating.EventLog.Fragment.mpx” and add it.

Select Generic.Rule.AlertGenerating.EventLog.Fragment.mpx in solution explorer to display the XML.

Step 4:  Find and Replace

Replace ##CompanyID## with our company ID which is “Fab”

Replace ##AppName## with our App ID, which is “DemoApp”

Replace ##EventID## with an event.  I will use “100”

Replace ##EventSource## with a valid Event Source for our event, I will use “TEST”

Replace ##ClassID## with the custom class we created in Step 2.  This was “Fab.DemoApp.Class” from our previous class fragment.

Replace ##LogName## with the event log you want to monitor.  I will use “Application”

That took all of 2 minutes.  Take another few minutes to review the XML we have in this fragment.  It is a simple rule definition, that will generate an alert when the event is seen in the log.  There are also display strings which can be modified for the rule display name, alert name, and alert description.

Step 5:  Build the MP.   BUILD > Build Solution.

Step 6:  Import or Deploy the management pack.

Step 7:  Test the MP.

We need to wait for the agent to get the new MP version.  You wcan watch for this in the agents OperationsManager event log.

We will see a 1200, 1201, then 1210 event sequence:

Once you get the 1210 – you can test the MP.

I will use EVENTCREATE to test this rule.  At an elevated command prompt, run:

eventcreate /T ERROR /ID 100 /L APPLICATION /SO TEST /D “This is a Test event 100″

Verify you get the event:

Verify you got the alert:

All done!  Time to hit the easy button.

This is Part 5 five in a series of posts described here:  https://blogs.technet.microsoft.com/kevinholman/2016/06/04/authoring-management-packs-the-fast-and-easy-way-using-visual-studio/

In our next example fragment – we will create a rule to collect Windows Performance data.

Step 1:  Download and extract the sample MP fragments.  These are available here:  https://gallery.technet.microsoft.com/SCOM-Management-Pack-VSAE-2c506737

I will update these often as I enhance and add new ones, so check back often for new versions.

Step 2:  Open your newly created MP solution, and open Solution Explorer.  This solution was created in Part 1, and the class was created in Part 2.

Step 3:  Create a folder and add the fragment to it.

Create a folder called “Rules” in your MP, if you don’t already have this folder.

Right click Rules, and Add > Existing item.

Find the fragment named “Generic.Rule.Performance.Collection.Perfmon.Fragment.mpx” and add it.

Select Generic.Rule.Performance.Collection.Perfmon.Fragment.mpx in solution explorer to display the XML.

Step 4:  Find and Replace

Replace ##CompanyID## with our company ID which is “Fab”

Replace ##AppName## with our App ID, which is “DemoApp”

Replace ##ClassID## with the custom class we created in Step 2.  This was “Fab.DemoApp.Class” from our previous class fragment.

Replace ##ObjectName## with a valid perfmon object.  I will use “Print Queue”

Replace ##CounterName## with a valid perfmon counter.  I will use “Total Jobs Printed”

Replace ##CounterNameWithoutSpaces## with the same as above, but remove any spaces.  I will use “TotalJobsPrinted”

Replace ##InstanceName## with a valid perfmon instance.  I will use “_Total”

(Note:  If your counter doesn’t have instances – you can just remove this in the XML so it looks like <InstanceName></InstanceName> )

That took all of 2 minutes.  Take another few minutes to review the XML we have in this fragment.  It is a simple rule definition, that collect windows performance counters.

Step 5:  Build the MP.   BUILD > Build Solution.

Uh Oh!

Error    80    Cannot resolve identifier Perf!System.Performance.OptimizedDataProvider in the context of management pack Fab.DemoApp. Unknown alias: Perf    C:\Program Files (x86)\MSBuild\Microsoft\VSAC\Microsoft.SystemCenter.OperationsManager.targets    255    6    Fab.DemoApp

This is simple.  We simply are calling on a module in our XML – but we haven’t added the MP that contains this module in our references.  Lets do that now.

In Solution Explorer – add a reference by right clicking “References” and choose “Add Reference”

VSAE came with a bunch of common reference files – so browse to C:\Users\<username>\Documents\Visual Studio 2013\References\ folder.  Pick the version of SCOM you want to be able to import this into, and select the “System.Performance.Library.mp”.

Highlight this MP in Solution Explorer under References, and in the properties window you will see the default Alias used, which you can change if necessary.  I used the default VSAE reference aliases in all my fragments.

Ok, lets try again.  Save All, then Build.

Grrrrrrrrr.

Error    80    Cannot resolve identifier MSDL!Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData in the context of management pack Fab.DemoApp. Unknown alias: MSDL    C:\Program Files (x86)\MSBuild\Microsoft\VSAC\Microsoft.SystemCenter.OperationsManager.targets    255    6    Fab.DemoApp

Same issue – because we need a reference for the data warehouse library in order to save performance data to the warehouse.  So lets add another reference, for Microsoft.SystemCenter.DataWarehouse.Library.mp

Save All, then Build.

SUCCESS!!!!!!

This was a little painful given how easy MP fragments are, because we got some errors.  However, it is a good exercise in understand how Visual Studio tells us what is wrong, and some simple ways to go and fix them.  Once we add references to our project, it will only need to be done once, so we wont have to go thought this again each time we add a performance rule.  The hard part is over.

Take a break and get a coffee if you need to, but I recommend importing it first in the next step…. it takes a while after import before we can test our rule. 

Step 6:  Import or Deploy the management pack.

Step 7:  Test the MP.

We need to wait for the agent to get the new MP version.  You can watch for this in the agents OperationsManager event log.

We will see a 1200, 1201, then 1210 event sequence:

Once you get the 1210 – you can normally test the MP.

However, for performance collection, we need to wait about 10 minutes after the agent gets a copy of the MP and makes it active, because performance data takes a little longer to show up in the console.

After 10 minutes or so – find the instance of your class in Discovered Inventory, right click it, and choose Open > Performance View

This will show all performance data associated with our custom class.  Our default interval was every 5 minutes, so you need to wait considerable time before you will see lines in the chart.  In order to test this one – you can actually print some notepad jobs to the “Microsoft XPS Document Writer” to change the counter values seen in perfmon.

This is Part 6 in a series of posts described here:  https://blogs.technet.microsoft.com/kevinholman/2016/06/04/authoring-management-packs-the-fast-and-easy-way-using-visual-studio/

In our next example fragment – we will create a folder and views to see our monitoring data we have generated thus far.

Step 1:  Download and extract the sample MP fragments.  These are available here:  https://gallery.technet.microsoft.com/SCOM-Management-Pack-VSAE-2c506737

I will update these often as I enhance and add new ones, so check back often for new versions.

Step 2:  Open your newly created MP solution, and open Solution Explorer.  This solution was created in Part 1, and the class was created in Part 2.

Step 3:  Create a folder and add the fragment to it.

Create a folder called “Views” in your MP, if you don’t already have this folder.

Right click Views, and Add > Existing item.

Find the fragment named “Generic.Folder.State.Alert.Perf.Views.Fragment.mpx” and add it.

Select Generic.Folder.State.Alert.Perf.Views.Fragment.mpx in solution explorer to display the XML.

Step 4:  Find and Replace

Replace ##CompanyID## with our company ID which is “Fab”

Replace ##AppName## with our App ID, which is “DemoApp”

Replace ##ClassID## with the custom class we created in Part 2 of the series.  This was “Fab.DemoApp.Class” from our previous class fragment.

That took all of 2 minutes.  Take another few minutes to review the XML we have in this fragment.  It is a simple set of view definitions for Alerts, Performance, and State, along with DisplayStrings for displaynames for each.

Step 5:  Build the MP.   BUILD > Build Solution.

Step 6:  Import or Deploy the management pack.

Step 7:  Test the MP.

Open the Monitoring pane of the console – you will have a new folder and views:

From here you will see the alerts scoped to our custom app class, along with any performance and health state data for all discovered instances.

This is part 7 in a series of posts described here:   https://blogs.technet.microsoft.com/kevinholman/2016/06/04/authoring-management-packs-the-fast-and-easy-way-using-visual-studio/

In our next example fragment – we will create custom groups and add them to our MP.

Groups are a critical part of any management pack.  We will use them for overrides, to scope monitoring views, and to scope subscriptions.

I like to consider adding three different groups to most of my custom application MP’s, depending on how you use SCOM.

First – a group of all instances of my custom class.

I will use this for overrides, and subscriptions, where needed.

Second – a group of all Windows Computer objects that contain an instance of my custom class. 

I will use this to scope console views so I can expose more monitoring data about the computers running my app – to app owners.  It can also be used for subscriptions and overrides, since these computers host (and therefore contain) my class.

Third – a group of all Windows Computer objects AND their corresponding Health Service Watcher objects, that contain an instance of my custom class.

I will use this group when I need to allow app owners know when their computers are down – so they can see “heartbeat” and “computer down” alerts.

I have created three fragments which add these groups independently, so you can pick and choose.  Don’t just add them all for every MP you make, because if you are a large enterprise, you might end up with too many groups (I’m talking >1000 here), which can cause SCOM to get overloaded.

Step 1:  Download and extract the sample MP fragments.  These are available here:  https://gallery.technet.microsoft.com/SCOM-Management-Pack-VSAE-2c506737

I will update these often as I enhance and add new ones, so check back often for new versions.

Step 2:  Open your newly created MP solution, and open Solution Explorer.  This solution was created in Part 1, and the class was created in Part 2.

Step 3:  Create a folder and add the fragment to it.

Create a folder called “Groups” in your MP, if you don’t already have this folder.

Right click Groups, and Add > Existing item.

Find the fragment named “Generic.Class.Group.ClassInstances.Fragment.mpx” and add it.

Select Generic.Class.Group.ClassInstances.Fragment.mpx in solution explorer to display the XML.

Step 4:  Find and Replace

Replace ##CompanyID## with our company ID which is “Fab”

Replace ##AppName## with our App ID, which is “DemoApp”

Replace ##ClassID## with the custom class we created in Part 2 of the series.  This was “Fab.DemoApp.Class” from our previous class fragment.

That took all of 2 minutes.  Take another few minutes to review the XML we have in this fragment.  It is a simple class definition for our group, a discovery to populate the group, along with DisplayStrings for displaynames for each.

Step 5:  Build the MP.   BUILD > Build Solution.

DOH!

Error    92    Cannot resolve identifier MSIL!Microsoft.SystemCenter.InstanceGroup in the context of management pack Fab.DemoApp. Unknown alias: MSIL    C:\Program Files (x86)\MSBuild\Microsoft\VSAC\Microsoft.SystemCenter.OperationsManager.targets    255    6    Fab.DemoApp

This is because the group fragment needs a reference to the Instance Group Library.

In Solution Explorer – add a reference by right clicking “References” and choose “Add Reference”

VSAE came with a bunch of common reference files – so browse to C:\Users\<username>\Documents\Visual Studio 2013\References\ folder.  Pick the version of SCOM you want to be able to import this into, and select the “Microsoft.SystemCenter.InstanceGroup.Library.mp”.

Highlight this MP in Solution Explorer under References, and in the properties window you will see the default Alias used, which you can change if necessary.  I used the default VSAE reference aliases in all my fragments.

Now Save All, then BUILD again.

Boom!

Step 6:  Import or Deploy the management pack.

Step 7:  Test the MP.

Open the Authoring pane of the console – and select “Groups” 

Find your new DemoApp Instance group:

Right click and View Group Members:

(Note:  This may take a few minutes in your environment for Group Population to run, and generate new config)

At this point – you can repeat these same steps for the other two group fragments:

Generic.Class.Group.WindowsComputers.Fragment.mpx

Generic.Class.Group.WindowsComputersAndHealthServiceWatchers.Fragment.mpx

This is Part 8 in a series of posts described here:   https://blogs.technet.microsoft.com/kevinholman/2016/06/04/authoring-management-packs-the-fast-and-easy-way-using-visual-studio/

In our next example fragment – we will create Monitor for Windows Performance for our MP.

Step 1:  Download and extract the sample MP fragments.  These are available here:  https://gallery.technet.microsoft.com/SCOM-Management-Pack-VSAE-2c506737

I will update these often as I enhance and add new ones, so check back often for new versions.

Step 2:  Open your newly created MP solution, and open Solution Explorer.  This solution was created in Part 1, and the class was created in Part 2.

Step 3:  Create a folder and add the fragment to it.

Create a folder called “Monitors” in your MP, if you don’t already have this folder.

Right click Monitors, and Add > Existing item.

Find the fragment named “Generic.Monitor.Performance.ConsecSamples.TwoState.Fragment.mpx” and add it.

Select Generic.Monitor.Performance.ConsecSamples.TwoState.Fragment.mpx in solution explorer to display the XML.

Step 4:  Find and Replace

Replace ##CompanyID## with our company ID which is “Fab”

Replace ##AppName## with our App ID, which is “DemoApp”

Replace ##ClassID## with the custom class we created in Part 2 of the series.  This was “Fab.DemoApp.Class” from our previous class fragment.

Replace ##ObjectName## with a valid perfmon object.  I will use “Print Queue”

Replace ##CounterName## with a valid perfmon counter.  I will use “Total Jobs Printed”

Replace ##CounterNameWithoutSpaces## with your counter, but remove any spaces.  I will use “TotalJobsPrinted”

Replace ##InstanceName## with a valid perfmon instance.  I will use “_Total”

Replace ##Threshold## with a valid threshold for the monitor.  I will use “5”

That took all of 2 minutes.  Take another few minutes to review the XML we have in this fragment.  It is a simple monitor definition, it checks every minute, and when 5 consecutive samples are over a threshold value of “5”, it will change state and alert.   

Step 5:  Build the MP.   BUILD > Build Solution.

Step 6:  Import or Deploy the management pack.

Step 7:  Test the MP.

Open the Monitoring pane of the console – and find your folder you created in Part 6.

Open the state view.

Open Health Explorer for an instance of your class.

To test this perf counter, you can print dummy jobs from Notepad to the Microsoft XPS document writer, to get the value over the threshold.

After 5 consecutive samples, based on our interval (every 60 seconds) I should see a statechange after 5 minutes.

Boom:

When we write scripts for SCOM workflows, we often log events as the output, for general logging, debug, or for the output as events to trigger other rules for alerting.  One of the common things I need when logging, is the ability to write parameters to the event.  This helps in making VERY granular criteria for SCOM alert rules to match on.

One of the things I HATE about the MOM Script API LogScriptEvent method, is that it places all the text into a single blob of text in the event description, all of this being Parameter 1.

Luckily – there is a fairly simple method to create paramitized events to output using your own PowerShell scripts.  I got this from Mark Manty, a fellow PFE.

Here is a basic script that demonstrates the capability:

#Script to create events with parameters

#Define the event log and your custom event source
$evtlog = "Application"
$source = "MyEventSource"

#These are just examples to pass as parameters to the event
$hostname = "computername.domain.net"
$timestamp = (get-date)

#Load the event source to the log if not already loaded.  This will fail if the event source is already assigned to a different log.
if ([System.Diagnostics.EventLog]::SourceExists($source) -eq $false) {
    [System.Diagnostics.EventLog]::CreateEventSource($source, $evtlog)
}

#function to create the events with parameters
function CreateParamEvent ($evtID, $param1, $param2, $param3)
  {
    $id = New-Object System.Diagnostics.EventInstance($evtID,1); #INFORMATION EVENT
    #$id = New-Object System.Diagnostics.EventInstance($evtID,1,2); #WARNING EVENT
    #$id = New-Object System.Diagnostics.EventInstance($evtID,1,1); #ERROR EVENT
    $evtObject = New-Object System.Diagnostics.EventLog;
    $evtObject.Log = $evtlog;
    $evtObject.Source = $source;
    $evtObject.WriteEvent($id, @($param1,$param2,$param3))
  }


#Command line to call the function and pass whatever you like
CreateParamEvent 1234 "The server $hostname was logged at $timestamp" $hostname $timestamp 

The script uses some variables to set which log you want to write to, and what your custom source is.

The rest is pretty self explanatory from the comments.

You can add additional params if needed to the function and the command line calling the function.

Here is an event example:

But the neat stuff shows up in the XML view where you can see the parameters:

http://www.silect.com/content/mp-author-professional

Building on the simple-to-use, free MP Author tool, they released MP Author Professional.  It adds/extends many more monitoring scenarios to the basic version.

The free version of Silect’s MP Author just released a new version:  7.0

http://www.silect.com/mp-author

June 2016: MP Author Version 7.0

The enhancements in MP Studio and MP Author consist of a number of changes to improve reliability and performance including the following:

• “Event Description” has been added as an expression option for both event monitors and rules
• Added support for “CONTAINS” as a comparison for Registry discovery for new classes
• Support for alert suppression for rules
• Added full support for alert parameters for event rules (to bring it to parity with event monitors)
• Updates to the User Guide and Installation Guide
• Recover and continue from SDK calls for MPB format MPs that result in exceptions
• Various other fixes and performance improvements

The SQL Management packs have been updated.  This is the first major release since 6.6.4.0, back in late 2015.

I will list all the SQL MP below.  Don’t import all of them unless you need each specialization.  For instance, don’t import the reporting and analysis services MP’s if you really only want alerting and monitoring for the SQL Database Engines.

The latest versions of ALL SQL MP’s and locations below, as of 7/11/2016:

System Center 2016 and Windows Server 2016 will be launched at the Microsoft Ignite conference in September 2016.

Read about it here:  https://blogs.technet.microsoft.com/systemcenter/2016/07/12/system-center-2016-to-launch-in-september/

Just a quick notice to let everyone know I updated my SQL RunAs Addendum MP’s.

If you haven’t read about this, it is a new way to configure security for the SQL management packs which eases administrative burden with traditional RunAs accounts.  Read more about the solution here:    https://blogs.technet.microsoft.com/kevinholman/2016/04/26/sql-mp-run-as-accounts-no-longer-required/

In this update:

• Version 6.7.2.0 – Update
  • Added support for SQL 2016
  • Added additional monitors to check for ability to connect to SQL and sysadmin role check
  • Removed any alerting by default to reduce noise.
  • Added new task to configure Healthservice login for LOW PRIV to SQL
  • Added folders, and state views to ease configuration and running tasks.

You can download the updated MP’s on TechNet Gallery:

https://gallery.technet.microsoft.com/SQL-Server-RunAs-Addendum-0c183c32

Normally – when you have a trust with a remote account domain, and you want to add users from the rote domain to SCOM, things go perfectly.

However, if the user account in the remote domain uses a different UPN name than the SAM account name – the SCOM UI block’s it.

For instance, I have a SCOM infrastructure in OPSMGR.NET (OPSMGR), but want to grant users in DMZ.CORP (DMZ) domain access.  This works fine, if the UPN domain name for my user is the same as the SAM account name.

In the image – I am trying to add DMZ\sqlmondmz account to my SQL Ops Team role:

When I check names – I can see the UPN domain is different, than the actual DNS domain name of DMZ.CORP:

This results in the following error:

Date: 7/19/2016 2:25:18 PM
Application: Operations Manager
Application Version: 7.1.10226.1177
Severity: Error
Message:

Microsoft.EnterpriseManagement.Common.UserRoleUserUnresolvedException: Unable to resolve the user sqlmondmz@zzz.com associated with the user role. Error code 1332. Check your active directory configuration.
   at Microsoft.EnterpriseManagement.Common.Internal.ServiceProxy.HandleFault(String methodName, Message message)
   at Microsoft.EnterpriseManagement.Common.Internal.SecurityConfigurationServiceProxy.UpsertUserRolesV2(ICollection`1 urUpdateResults, ICollection`1 urScopeUpdateResults, ICollection`1 urViewScopeUpdateResults, ICollection`1 urTaskScopeUpdateResults, ICollection`1 urConsoleTaskScopeUpdateResults, ICollection`1 urTemplateScopeUpdateResults, ICollection`1 urDashboardReferenceScopeUpdateResults, ICollection`1 urUserUpdateResults)
   at Microsoft.EnterpriseManagement.SecurityConfigurationManagement.UpdateUserRoles(ICollection`1 userRoles)
   at Microsoft.EnterpriseManagement.Mom.Internal.UI.Console.ConsoleJobExceptionHandler.ExecuteJob(IComponent component, EventHandler`1 job, Object sender, ConsoleJobEventArgs args)

The workaround?

Use PowerShell to add these users to the role:

$Role = Get-SCOMUserRole -Name “SQL Ops Team”
$Role | Set-SCOMUserRole -User ($Role.Users + “DMZ\sqlmondmz”)

This doesn’t have the same UI restriction:

The base operating system MP’s have been updated:

https://www.microsoft.com/en-us/download/details.aspx?id=9296

Previously, there were a couple interim releases that were pulled due to issues, mostly affecting older operating system versions.  This was due to the MP focusing on changes for Windows Server 2016.  This MP update addresses those issues caused by the interim MP changes.  The previous stable MP version was 6.0.7297.0 so I will focus on changes since that MP:

Changes in version 6.0.7303.0

• MP used to discover physical CPU, which performance monitor instance name property was not correlated with Windows PerfMon object (expecting instance name in (socket, core) format). That affected related rules and monitors. With this release, MP discovers logical processors, rather than physical, and populates performance monitor instance name in proper format
• Microsoft.Windows.Server.ClusterSharedVolumeMonitoring.mp and Microsoft.Windows.Server.Library.mp scripts code migration to PowerShell in scope of Windows Server 2016 Nano support (relevantly introduced in Windows Server 2016 MP version 10.0.1.0).
• Updated Microsoft.Windows.Server.ClusterSharedVolumeMonitoring.ClusterSharedVolume.Monitoring.State monitor alert properties and description. The fix resolved property replacement failure warning been generated on monitor alert firing.

Changes in version 6.0.7310.0

• Several bugs located in Cluster Shared Volumes MP were fixed (see below); error handling migrated to common recommended scenario. Enabled Quorum monitoring via changing the monitoring logic. The monitoring logic is splitting for Nano Server (with usage of PowerShell) and all other operation systems.
• Fixed bug: disk free space monitoring issue on Quorum disks in failover clusters; the monitor was displayed as healthy, but actually it did not work and no performance data was collected.
• Fixed bug: logical disk discovery did not discover logical disk on non-clustered server with Failover Cluster Feature enabled.
• Fixed bug: Clustered Shared Volumes were being discovered twice – as a Clustered Shared Volume and as a logical disk; now they are discovered as Clustered Shared Volumes only.
• Fixed bug (partially): mount points were being discovered twice for cluster disks mounted to a folder – as a cluster disk and as a logical disk. See Troubleshooting and Known Issues section for details.
• Fixed bug: Cluster Shared Volume objects were being discovered incorrectly when they had more than one partition (applied to discovery and monitoring): only one partition was discovered, while the monitoring data was discovered for all partitions available. The key field is changed, and now partitions are discovered correctly; see Troubleshooting and Known Issues section for details.
• Error handling was corrected. Logical disk correct discoveries on non-cluster server with Failover Clustered Server Feature is installed.
• Created new overrides for Cluster Shared Volume MP, as long as the old ones did not work.
• Cluster disk monitors alert messages: alert title might be disorienting and was corrected.

Changes in version 6.0.7316.0

• Due to incompatibility issues in monitoring logic, several Cluster Shared Volumes MP bugs remained in version 6.0.7310.0. These are now fixed in the current version (see the complete list of bugs below). To provide compatibility with the previous MP versions, all monitoring logic (structure of classes’ discovery) was reverted to the one present in version 6.0.7297.0.
• Fixed bug: disk free space monitoring issue on Quorum disks in failover clusters; the monitor was displayed as healthy, but actually it did not work and no performance data was collected.
• Fixed bug: logical disk discovery did not discover logical disk on non-clustered server with Failover Cluster Feature enabled.
• Fixed bug: Clustered Shared Volumes were being discovered twice – as a Clustered Shared Volume and as a logical disk; now they are discovered as Clustered Shared Volumes only.
• Fixed bug (partially): mount points were being discovered twice for cluster disks mounted to a folder – as a cluster disk and as a logical disk. See Troubleshooting and Known Issues section for details.
• Fixed bug: Cluster Shared Volume objects were being discovered incorrectly when they had more than one partition (applied to discovery and monitoring): only one partition was discovered, while the monitoring data was discovered for all partitions available. The key field is changed, and now partitions are discovered correctly; see Troubleshooting and Known Issues section for details.
• Fixed bug: physical CPUs are now discovered on Windows Server 2008 R2 platforms; logical CPUs are no longer discovered, see Troubleshooting and Known Issues section for details.
• Fixed bug: Windows Server 2008 Max Concurrent API Monitor did not work on Windows Server 2008 platform. Now, it is supported on Windows Server platforms starting from Windows Server 2008 R2.
• Fixed bug: when network resource name contained more than 15 symbols, the last symbols of the name were cut off, which was resulting in cluster disks and Cluster Shared Volume discovery issues.
• Cluster disk monitors alert messages: alert title might be disorienting and was corrected.

I have been running this version for a few weeks now, and I haven’t seen any major issues.  However, like ALL MP’s, I recommend careful testing and evaluation in your lab and test environments before moving to production.

Over the years I have written many articles dealing with RunAs accounts.  Specifically, the most common need is for monitoring with the SQL MP.  I have explained the issues and configurations in detail here:  Configuring Run As Accounts and Profiles in OpsMgr – A SQL Management Pack Example

Later, I wrote an automation solution to script the biggest pain point of RunAs accounts:  distributing them, here:  Automating Run As Account Distribution – Finally!  Then – took it a step further, and built this automation into a management pack here:  Update-  Automating Run As Account distribution dynamically

Now – I want to show a different approach to configuring monitoring for the SQL MP, which might make life a lot simpler for SCOM admins, and SQL teams.

What if I told you – there was a way to not have to mess with RunAs accounts and the SQL MP at all?  No creating the accounts, no distributing them, no associating them with the profiles – none of that?    Interested?   Then read on.

The big challenge in SQL monitoring is that the SCOM agent runs as LocalSystem for the default agent action account.  However, LocalSystem does not have full rights to SQL server, and should not ever be granted the SysAdmin role in SQL.  This is because the LocalSystem account is quite easy to impersonate to anyone who already has admin rights to the OS.

We can solve this challenge, by introducing Service SID’s.  SQL already uses Service Security Identifiers (SID’s) to grant access for the service running SQL server, to the SQL instance.  You can read more about that here:  https://support.microsoft.com/en-us/kb/2620201

Service SID’s were introduced in Windows Server 2008 and later.

We can do the same thing for the SCOM Healthservice.  This idea was brought to me by a fellow MS consultant – Ralph Kyttle.  He pointed out, this is exactly how OMS works to gather data about SQL server.  We have an article describing this recommended configuration here:  https://support.microsoft.com/en-us/kb/2667175

Essentially – this can be accomplished in two steps:

1. Enable the HealthService to be able to use a service SID.
2. Create a login for the HealthService SID to be able to access SQL server.

That’s it!

This creates a login in SQL, and allows the SCOM agent to be able to monitor SQL server, without having to maintain another credential, deal with password changes, and removes the security concern of a compromised RunAs account being able to access every SQL server in the company!  No more configuration, no more credential distribution.

I even wrote a Management Pack to make setting this initial configuration up much simpler. 

*** Updated 7-13-2016 for MP version 6.7.2.0

Let me demonstrate:

First, we need to ensure that all SCOM agents, where SQL is discovered – have the service SID enabled.  I wrote a monitor to detect when this is not configured, and targeted the SQL SEED classes.  For each SQL version, there is an Addendum MP which shows the SEED classes:

This monitor will show a warning state when the Service SID is not configured for any agent where we discover an instance of a SQL SEED class.

The monitor has a script recovery action, which is disabled by default.  You can enable this and it will automatically configure this as soon as SQL is detected, and will restart the agent.

Alternatively – I wrote two tasks you can run – the second one configures the service SID, but will wait for the next reboot (or service restart) before this actually becomes active.  The first task configures the service AND then restarts the agent Healthservice.  You can multi-select items in this view and run against multiple agents, making this one-time configuration easy.

Here is what it looks like in action:

So – once that is complete – we can create the login for SQL.

In the Addendum MP for each SQL version – there is a state view for the DB engine.  If you switch to this view, or any Database Engine view – you will see two new tasks show up which will create a SQL login for the HealthService.  One creates the login and assigns it the SysAdmin role to the instance.  The other creates the login and configures the login for Low Priv mode.  You just need to choose whichever you want to use for your organization.

If you run this task, and don’t have rights to the SQL server – you will get this:

Have your SQL team run the task and provide a credential to the task that will be able to create a login and assign the necessary SysAdmin role to the service:

Voila!

What this actually does – is create this login on the SQL server and set it to SysAdmin role:

All of these activities are logged for audit in the Task Status view:

To further assist with this configuration, I added two additional monitors:

The first monitor turns unhealthy if we cannot connect to SQL at all:

The second monitor turns unhealthy if we CAN connect to SQL, but we detect that the login for “NT Service\HealthService” does not have the “SysAdmin” role.  You should use this monitor if you are granting the SysAdmin role to the Healthservice, and you should disable it if you are using Lowest Priv.  It specifically checks to see if the Healthservice login is configured as a SysAdmin:

None of the monitors generate alerts by default, to limit adding noise to SCOM.  If you want alerting you can enable that in the MP and configure it as you wish.

***NOTE:  These monitors run every 4 hours by default, so after making the changes to add the NT Service\Healthservice to SQL, it will take that long before the monitors change state, unless you bounce the health service on the agent to speed that up.  So be aware.

Now – as new SQL servers are added over time – the Service SID can automatically be configured using the recovery, and the SQL team will just need to add the HealthService login as part of their build configuration, or run this task one time for each new SQL server to enable it for monitoring.

I find this to be much simpler than dealing with RunAs accounts, and it appears to be a more secure solution as well.  I welcome any feedback on this approach, or for my Management Pack Addendum.

I have included my SQL RunAs Addendum MP’s to be available below:

• Version 6.6.4.0 – Original release of the addendum MP’s.
• Version 6.7.2.0 – Update
  • Added support for SQL 2016
  • Added additional monitors to check for ability to connect to SQL and sysadmin role check
  • Removed any alerting by default.
  • Added new task to configure Healthservice login for LOW PRIV to SQL
  • Added folders, and state views to ease configuration and running tasks

https://gallery.technet.microsoft.com/SQL-Server-RunAs-Addendum-0c183c32

KB Article for OpsMgr:  https://support.microsoft.com/en-us/kb/3183990

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

NOTE:  I get this question every time we release an update rollup:   ALL SCOM Update Rollups are CUMULATIVE.  This means you do not need to apply them in order, you can always just apply the latest update.  If you have deployed SCOM 2012R2 and never applied an update rollup – you can go straight to the latest one available.  If you applied an older one (such as UR3) you can always go straight to the latest one!

Key Fixes:

• Network discovery fails because of monitoring host crash if no paging file is set on the operating system
  When no paging file is set on the operating system, the page file size is implicitly set to 0. This causes the monitoring host to crash. This update fixes such an exception.
• Backport PuTTY 0.64 and 0.66 updates from 2016 release
  Operations Managers ssh-based administration of UNIX/Linux computers (agent discovery and installation, upgrade, uninstallation) now supports UNIX and Linux computers that are configured to require SHA2 HMACs and those with Key Exchange Algorithm changes, as specified in RFC 4419 (Ubuntu 15.10, 16.04 LTS).
• Update Register-SCAdvisor cmdlet for WEU workspaces
  This update adds support to register the Operations Manager Management group to workspaces in regions other than Eastern US by using the Register-SCAdvisor cmdlet. The cmdlet takes an additional optional parameter (SettingServiceUrl), which is the URL for setting the service in the region of the workspace. If it is not specified, the workspace is assumed to be in the Eastern US.
• ACS eventschema.xml has incorrect parameter mappings for multiple audit events
  The report named Usage_-_Sensitive_Security_Groups_Changes used to say n/a\n/a for some events in the Changed By column. And in some events, the Member User column contained the account name of the user who made the change instead of the account that was added or removed. This fix resolves this issue, as the Changed By column now contains the account name of the user who made the change, and the Member User column contains the name of the added or removed account, where applicable.
• Memory leak when monitoring network devices by using SNMPv3
  This update fixes a memory leak in Network Monitoring area that occurs while monitoring network devices by using SNMPv3.
• Web Console user can view datawarehouse performance or SLA widget data outside of their scoped dashboard views
  This update implements verification of the logged-in user to confirm that the user has access to the opened dashboard before loading the same.
• Downtime duration doesn’t take business hour into consideration
  Business hours are being calculated even when the Business hours check box is cleared. This update resolves this issue.
  The updated RDL files are located in the following location:

  %SystemDrive%\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\Reporting

  To update the RDL file, follow these steps:

  1. Go to http://MachineName/Reports_INSTANCE1/Pages/Folder.aspxMachineName //Reporting Server.
  2. On this page, go to the folder to which you want to add the RDL file. In this case, click Microsoft.SystemCenter.DataWarehouse.Report.Library.
  3. Upload the new RDL files by clicking the upload button at the top. For more information, see the Upload a File or Report (Report Manager) topic on the Microsoft Developer Network website.
• Cisco 3172 PQ network device certification issues
  This update fixes issues in monitoring the Cisco 3172 PQ network device and its components.
• Adding SCOM assessment links in the Operations Management Suite view in the SCOM console
  Links for Operations Manager Assessment and Pre-Configuration steps for Operations Manager Assessment are added in the Operations Management Suite Connection node under the administration pane. SCOM assessment solution in OMS is currently in private preview, please reach out to your “TAM or other Microsoft contact” to obtain access to the solution.
• SQL Server Seed relationship with a server that is running Windows
  The dynamic members of the group are not populated if the dynamic rule is based on a hosted relationship with Windows Server. This fix enables retrieval of hosting entity.
• Alert subscriptions are not always fired for 3 state monitors
  This update allows for configuration of a 3 state monitor to raise alerts; whose severity is in sync with monitor’s health state. One can create a subscription to be notified on modification of alert severity. Even if the monitor’s state keeps toggling between warning and critical, severity of the alert keeps being updated, and a notification fired on an update to the severity of an alert.
• When you connect SCOM to OMS, Availability monitors health state of some management servers changes to Warning state
  If OMS workspace is configured to collect certain event logs and if those event logs are not present on the management servers that are connected to that workspace, the “Availability” monitor’s health state on those management servers that are used to change the Warning state. This state change scenario is fixed. This prevents the switch to Warning state.
• RunAs Account password expiration does not work with Active directory Password Settings Objects that breaks the validation of LOCAL User Accounts
  Local Accounts could not be validated by using ADSystemInfo. Therefore, when any local account is added into RunAs account, an Error event is logged in Event Viewer for an exception in validating the local account. After this update, local accounts are validated.
• MPB Entries in Catalog database for the VersionIndependentGuid column is updated
  This update enables the SCOM console to show the correct mpb installation status in the management server when it tries to connect to an online catalog to update mpbs.
• If the first try of importing MPB failed then re-importing the MPB was not possible until the SCOM console is closed and reopened
  This update enables re-download and installation of an mpb, without closing and reopening the SCOM console, even if the first try installation of that mpb failed because of a dependency issue.
• Change of the displayname field for a group in a sealed or unsealed management pack
  Renaming a group through PowerShell cmdlets was not displaying the new group name in the SCOM console. This update resolves this issue and the renaming of a group correctly displays the renamed group name in the SCOM console.

New Linux operating system versions supported

• Ubuntu Linux 16.04 LTS (x86 and x64) is now supported in System Center 2012 R2 Operations Manager.

Issues that are fixed in the UNIX and Linux management packs

• During UNIX/Linux computer discovery, the GetOSVersion.sh script is run with sudo elevation if a sudo-enabled user is selected for Discovery. This update prevents the GetOSVersion.sh script from being run with sudo elevation and does not have to be authorized in the /etc/sudoers folder.
• Scripts executed by the ExecuteScript method in Management Packs always run from the /tmp folder. With this update, the temporary folder for scripts is now configurable. To use another folder, update the symbolic link to link to a temporary folder of your choice:

  /etc/opt/microsoft/scx/conf/tmpdir

• UNIX or Linux computers together with sshd versions that implement the Key Exchange Algorithms described in RFC 4419, such as Ubuntu 15.10, cannot be discovered with the Discovery Wizard.
• Network statistics collected on AIX servers are reset when another tool such as NetStat is also used.
• Physical disks are shown incorrectly as offline if an LVM snapshot is taken.

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
   • Audit Collection servers 
   • Gateway servers
   • Web console server role computers
   • Operations console role computers
2. Apply SQL scripts.
3. Manually import the management packs.
4. Update Agents

Additionally, we will add the steps to update Linux management packs 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 role to the SQL 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 usually does not provide any feedback that it had success or failure. 

You can check the application log for the MsiInstaller events to show completion:

Log Name:      Application
Source:        MsiInstaller
Date:          8/31/2016 9:01:13 AM
Event ID:      1036
Description:
Windows Installer installed an update. Product Name: System Center Operations Manager 2012 Server. Product Version: 7.1.10226.0. Product Language: 1033. Manufacturer: Microsoft Corporation. Update Name: System Center 2012 R2 Operations Manager UR11 Update Patch. Installation success or error status: 0.

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:

Additional Management Servers:

I now move on to my additional management servers, applying the server update, then the console update and web console update where applicable.

On this next management server, I will use the example of Windows Update as opposed to manually installing the MSP files.  I check online, and make sure that I have configured Windows Update to give me updates for additional products: 

The applicable updates show up under optional – so I tick the boxes and apply these updates.

After a reboot – go back and verify the update was a success by spot checking some file versions like we did above.

Updating ACS (Audit Collection Services)

You would only need to update ACS if you had installed this optional role.

On any Audit Collection Collector servers, you should run the update included:

A spot check of the files:

Updating Gateways:

I can use Windows Update or manual installation.

The update launches a UI and quickly finishes.

I was prompted for a reboot.

Then I will spot check the DLL’s:

I can also spot-check the \AgentManagement folder, and make sure my agent update files are dropped here correctly:

***NOTE:  You can delete any older UR update files from the \AgentManagement directories.  The UR’s do not clean these up and they provide no purpose for being present any longer.

2. Apply the SQL Scripts

In the path on your management servers, where you installed/extracted the update, there are two SQL script files: 

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

(note – your path may vary slightly depending on if you have an upgraded environment or clean install)

First – let’s run the script to update the OperationsManagerDW (Data Warehouse) database.  Open a SQL management studio query window, connect it to your Operations Manager DataWarehouse database, and then open the script file (UR_Datawarehouse.sql).  Make sure it is pointing to your OperationsManagerDW database, then execute the script.

You should run this script with each UR, even if you ran this on a previous UR.  The script body can change so as a best practice always re-run this.

If you see a warning about line endings, choose Yes to continue.

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:   “Command(s) completes successfully”

Next – let’s run the script to update the OperationsManager (Operations) database.  Open a SQL management studio query window, connect it to your Operations Manager database, and then open the script file (update_rollup_mom_db.sql).  Make sure it is pointing to your OperationsManager database, then execute the script.

You should run this script with each UR, even if you ran this on a previous UR.  The script body can change so as a best practice always re-run this.

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.  

I have had customers state this takes from a few minutes to as long as an hour. In MOST cases – you will need to shut down the SDK, Config, and Monitoring Agent (healthservice) on ALL your management servers in order for this to be able to run with success.

You will see the following (or similar) output: 

or

IF YOU GET AN ERROR – STOP!  Do not continue.  Try re-running the script several times until it completes without errors.  In a production environment with lots of activity, you will almost certainly have to shut down the services (sdk, config, and healthservice) on your management servers, to break their connection to the databases, to get a successful run.

Technical tidbit:   Even if you previously ran this script in any previous UR deployment, you should run this again in this update, as the script body can change with updated UR’s.

3. Manually import the management packs

There are 55 management packs in this update!   Most of these we don’t need – so read carefully.

The path for these is on your management server, after you have installed the “Server” update:

\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\Management Packs for Update Rollups

However, the majority of them are Advisor/OMS, and language specific.  Only import the ones you need, and that are correct for your language.  I will remove all the MP’s for other languages (keeping only ENU), and I am left with the following:

What NOT to import:

The Advisor MP’s are only needed if you are using Microsoft Operations Management Suite cloud service, (Previously known as Advisor, and Operations Insights).

The APM MP’s are only needed if you are using the APM feature in SCOM.

Note the APM MP with a red X.  This MP requires the IIS MP’s for Windows Server 2016 which are in Technical Preview at the time of this writing.  Only import this if you are using APM *and* you need to monitor Windows Server 2016.  If so, you will need to download and install the technical preview editions of that MP from https://www.microsoft.com/en-us/download/details.aspx?id=48256

The TFS MP bundle is 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.

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

I import all of these shown without issue.

4.  Update Agents

Agents should be placed into pending actions by this update for any agent that was not manually installed (remotely manageable = yes):  

One the Management servers where I used Windows Update to patch them, their agents did not show up in this list.  Only agents where I manually patched their management server showed up in this list.  FYI.   The experience is NOT the same when using Windows Update vs manual.  If yours don’t show up – you can try running the update for that management server again – manually.

If your agents are not placed into pending management – this is generally caused by not running the update from an elevated command prompt, or having manually installed agents which will not be placed into pending.

In this case – my agents that were reporting to a management server that was updated using Windows Update – did NOT place agents into pending.  Only the agents reporting to the management server for which I manually executed the patch worked.

I manually re-ran the server MSP file manually on these management servers, from an elevated command prompt, and they all showed up.

You can approve these – which will result in a success message once complete:

Soon you should start to see PatchList getting filled in from the Agents By Version view under Operations Manager monitoring folder in the console:

5.  Update Unix/Linux MPs and Agents

The current Linux MP’s can be downloaded from:

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

7.5.1060.0 is current at this time for SCOM 2012 R2 UR11.

****Note – take GREAT care when downloading – that you select the correct download for SCOM 2012 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.   These are mine for RHEL, SUSE, and the Universal Linux libraries. 

NOTE:  Upon first import – you might see that “Linux Operating System Library” (Microsoft.Linux.Library.mp) file fails to import.  If this happens, simply make sure you have imported version 7.5.1060.0 of UNIX/Linux Core Library (Microsoft.Unix.Library.mp) FIRST, then you can import “Linux Operating System Library” (Microsoft.Linux.Library.mp) without issue.

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 – you need to restart the “Microsoft Monitoring Agent” service on any management servers which manage Linux systems.  I don’t know why – but my MP’s never drop/update in the \Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits folder until this service is restarted.

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.

Finally:

6.  Update the remaining deployed consoles

This is an important step.  I have consoles deployed around my infrastructure – on my Orchestrator server, SCVMM server, on my personal workstation, on all the other SCOM admins on my team, on a Terminal Server we use as a tools machine, etc.  These should all get the matching update version.

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.

1.  Many people are reporting that the SQL script is failing to complete when executed.  You should attempt to run this multiple times until it completes without error.  You might need to stop the Exchange correlation engine, stop all the SCOM services on the management servers, and/or bounce the SQL server services in order to get a successful completion in a busy management group.  The errors reported appear as below:

——————————————————
(1 row(s) affected)
(1 row(s) affected)
Msg 1205, Level 13, State 56, Line 1
Transaction (Process ID 152) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
Msg 3727, Level 16, State 0, Line 1
Could not drop constraint. See previous errors.
——————————————————–

Yes, yes, I know.  Late to the party.  Better late than never.   

For those that don’t know – SCOM 2016 was released at Ignite this year, on Sept 29th.

It hit the GA milestone on October 12th, which is the date it becomes Generally Available on Volume License media and MSDN, along with the date it becomes officially supported.

You can download the 180 day EVAL – which is available at:  https://www.microsoft.com/en-us/evalcenter/evaluate-system-center-2016

The EVAL version is fully capable of being licensed with your key from MSDN or Volume Licensing, later after you deploy.

Want to know more?

UR1 is available:

https://blogs.technet.microsoft.com/momteam/2016/10/14/update-rollup-1-for-system-center-2016-operations-manager-is-now-available/

https://blogs.technet.microsoft.com/kevinholman/2016/10/22/ur1-for-scom-2016-step-by-step/

New feature on tuning MP’s:

https://blogs.technet.microsoft.com/momteam/2016/10/18/system-center-2016-operations-manager-data-driven-alert-management-tune-management-packs/

New feature on recommended MP’s and MP updates:

https://blogs.technet.microsoft.com/momteam/2016/10/18/system-center-2016-operations-manager-mp-updates-and-recommendations-management-pack-assessment/

New feature on HTML based Web Console:

https://blogs.technet.microsoft.com/momteam/2016/10/18/html-based-web-console/

http://thoughtsonopsmgr.blogspot.com/2016/09/scom-2016-web-console-no-more.html

Improvements in console UI speed:

https://blogs.technet.microsoft.com/momteam/2016/10/18/improved-ui-responsiveness-for-system-center-2016-operations-manager/

New tools for improving the network monitoring MP authoring experience:

https://blogs.technet.microsoft.com/momteam/2016/10/20/system-center-operations-manager-extensible-network-monitoring/

https://stefanroth.net/2016/10/19/scom-extensible-network-monitoring-management-pack-generator-tool/

New feature for Scheduled Maintenance mode:

https://scomandothergeekystuff.com/2016/07/13/new-features-in-scom-2016-maintenance-schedules/

New Unix/Linux features and improvements:

https://stefanroth.net/2016/08/24/scom-2016-whats-new-unixlinux-series-file-system-discovery-e-g-exclude-tmp/

https://stefanroth.net/2016/08/24/scom-2016-whats-new-unixlinux-series-monitors-and-rules-running-any-script-e-g-perl/

https://stefanroth.net/2016/08/16/scom-2016-whats-new-unixlinux-series-agent-tasks-running-scripts-e-g-perl/

https://stefanroth.net/2016/08/15/scom-2016-whats-new-unixlinux-series-discovery-wizard-provide-runas-account/

VSAE has been updated for SCOM 2016.

Get it here:

https://www.microsoft.com/en-us/download/details.aspx?id=30169

Works great with my fragment library – which you can download and try out here:

https://blogs.technet.microsoft.com/kevinholman/2016/06/04/authoring-management-packs-the-fast-and-easy-way-using-visual-studio/

Even if you ARE running SCOM 2016 – I still recommend choosing SCOM 2012R2 – so any MP’s you author will be compatible with either version. 

There is already a very good deployment guide posted on TechNet here:   https://technet.microsoft.com/en-us/system-center-docs/om/deploy/deploying-system-center-2016-operations-manager

The TechNet deployment guide provides an excellent walkthrough of installing OpsMgr 2016 for the “all in one” scenario, where all roles are installed on a single server.  That is a very good method for doing simple functionality testing and lab exercises.

The following article will cover a basic install of System Center Operations Manager 2016.   The concept is to perform a limited deployment of OpsMgr, only utilizing as few servers as possible, but enough to demonstrate the roles and capabilities in OM2016.  For this reason, this document will cover a deployment on 3 servers. A dedicated SQL server, and two management servers will be deployed.  This will allow us to show the benefits of high availability for agent failover, and the highly available resource pool concepts.  This is to be used as a template only, for a customer to implement as their own pilot or POC, or customized deployment guide. It is intended to be general in nature and will require the customer to modify it to suit their specific data and processes.

This also happens to be a very typical scenario for small environments for a production deployment.  This is not an architecture guide or intended to be a design guide in any way. This is provided “AS IS” with no warranties, and confers no rights. Use is subject to the terms specified in the Terms of Use.

Server Names\Roles:

• SQL1             SQL Database Services, Reporting Services
• SCOM1         Management Server Role, Web Console Role, Console
• SCOM2         Management Server Role, Web Console Role, Console

Windows Server 2016 will be installed as the base OS for all platforms.  All servers will be a member of the AD domain.

SQL 2016  will be the base standard for all database and SQL reporting services.

High Level Deployment Process:

1.  In AD, create the following accounts and groups, according to your naming convention:

• DOMAIN\OMAA                 OM Server Action Account
• DOMAIN\OMDAS               OM Config and Data Access Account
• DOMAIN\OMREAD             OM Datawarehouse Reader Account
• DOMAIN\OMWRITE            OM Datawarehouse Write Account
• DOMAIN\SQLSVC               SQL Service Account
• DOMAIN\OMAdmins          OM Administrators security group

2.  Add the OMAA, OMDAS, OMREAD, and OMWRITE accounts to the “OMAdmins” global group.

3.  Add the domain user accounts for yourself and your team to the “OMAdmins” group.

4.  Install Windows Server 2016 to all server role servers.

5.  Install Prerequisites and SQL 2016.

6.  Install the Management Server and Database Components

7.  Install the Reporting components.

8.  Deploy Agents

9.  Import Management packs

10.  Set up security (roles and run-as accounts)

Prerequisites:

1.  Install Windows Server 2016 to all Servers

2.  Join all servers to domain.

3.  Install the Report Viewer controls to any server that will receive a SCOM console.  Install them from https://www.microsoft.com/en-us/download/details.aspx?id=45496  There is a prereq for the Report View controls which is the “Microsoft System CLR Types for SQL Server 2014” (ENU\x64\SQLSysClrTypes.msi) available here:   https://www.microsoft.com/en-us/download/details.aspx?id=42295

4.  Install all available Windows Updates.

5.  Add the “OMAdmins” domain global group to the Local Administrators group on each server.

6. Install IIS on any management server that will also host a web console:

Open PowerShell (as an administrator) and run the following:

Add-WindowsFeature NET-WCF-HTTP-Activation45,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Request-Monitor,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,Web-Metabase,Web-Asp-Net,Web-Windows-Auth –Restart

 

Note:  The server needs to be restarted at this point, even if you are not prompted to do so.  If you do not reboot, you will get false failures about prerequisites missing for ISAPI/CGI/ASP.net registration.

7. Install SQL 2016 to the DB server role

• Setup is fairly straightforward. This document will not go into details and best practices for SQL configuration. Consult your DBA team to ensure your SQL deployment is configured for best practices according to your corporate standards.
• Run setup, choose Installation > New SQL Server stand-alone installation…

• When prompted for feature selection, install ALL of the following:
  • Database Engine Services
  • Full-Text and Semantic Extractions for Search
  • Reporting Services – Native

• On the Instance configuration, choose a default instance, or a named instance. Default instances are fine for testing, labs, and production deployments. Production clustered instances of SQL will generally be a named instance. For the purposes of the POC, choose default instance to keep things simple.
• On the Server configuration screen, set SQL Server Agent to Automatic.  You can accept the defaults for the service accounts, but I recommend using a Domain account for the service account.  Input the DOMAIN\sqlsvc account and password for Agent, Engine, and Reporting.  Set the SQL Agent to AUTOMATIC.
• Check the box to grant Volume Maintenance Task to the service account for the DB engine.  This will help performance when autogrow is needed.

• On the Collation Tab – you can use the default which is SQL_Latin1_General_CP1_CI_AS
• On the Account provisioning tab – add your personal domain user account and/or a group you already have set up for SQL admins. Alternatively, you can use the OMAdmins global group here. This will grant more rights than is required to all OMAdmin accounts, but is fine for testing purposes of the POC.
• On the Data Directories tab – set your drive letters correctly for your SQL databases, logs, TempDB, and backup.
• On the Reporting Services Configuration – choose to Install and Configure. This will install and configure SRS to be active on this server, and use the default DBengine present to house the reporting server databases. This is the simplest configuration. If you install Reporting Services on a stand-alone (no DBEngine) server, you will need to configure this manually.
• Choose Install, and setup will complete.
• You will need to disable Windows Firewall on the SQL server, or make the necessary modifications to the firewall to allow all SQL traffic.  See http://msdn.microsoft.com/en-us/library/ms175043.aspx
• When you complete the installation – you might consider also downloading and installing SQL Server Management Studio Tools from the installation setup page, or https://msdn.microsoft.com/en-us/library/mt238290.aspx           

SCOM Step by step deployment guide:

1.  Install the Management Server role on SCOM1.

• Log on using your personal domain user account that is a member of the OMAdmins group, and has System Administrator (SA) rights over the SQL instances.
• Run Setup.exe
• Click Install
• Select the following, and then click Next:
  • Management Server
  • Operations Console
  • Web Console
• Accept or change the default install path and click Next.
• You might see an error from the Prerequisites here. If so – read each error and try to resolve it.
• On the Proceed with Setup screen – click Next.
• On the specify an installation screen – choose to create the first management server in a new management group.  Give your management group a name. Don’t use any special or Unicode characters, just simple text.  KEEP YOUR MANAGEMENT GROUP NAME SIMPLE, and don’t put version info in there.  Click Next.
• Accept the license.  Next.
• On the Configure the Operational Database screen, enter in the name of your SQL database server name and instance. In my case this is “DB01”. Leave the port at default unless you are using a special custom fixed port.  If necessary, change the database locations for the DB and log files. Leave the default size of 1000 MB for now. Click Next.
• On the Configure the Data Warehouse Database screen, enter in the name of your SQL database server name and instance. In my case this is “DB01”. Leave the port at default unless you are using a special custom fixed port.  If necessary, change the database locations for the DB and log files. Leave the default size of 1000 MB for now. Click Next.  
• On the Web Console screen, choose the Default Web Site, and leave SSL unchecked. If you have already set up SSL for your default website with a certificate, you can choose SSL.  Click Next.
• On the Web Console authentication screen, choose Mixed authentication and click Next.
• On the accounts screen, change the accounts to Domain Account for ALL services, and enter in the unique DOMAIN\OMAA, DOMAIN\OMDAS, DOMAIN\OMREAD, DOMAIN\OMWRITE accounts we created previously. It is a best practice to use separate accounts for distinct roles in OpsMgr, although you can also just use the DOMAIN\OMDAS account for all SQL Database access roles to simplify your installation (Data Access, Reader, and Writer accounts). Click Next.
• On the Microsoft Update screen – choose to use updates or not.  Next.
• Click Install.
• Close when complete.
• The Management Server will be very busy (CPU) for several minutes after the installation completes. Before continuing it is best to give the Management Server time to complete all post install processes, complete discoveries, database sync and configuration, etc. 10 minutes is typically sufficient.

2.  (Optional)  Install the second Management Server on SCOM2.

• Log on using your domain user account that is a member of the OMAdmins group, and has System Administrator (SA) rights over the SQL instances.  
• Run Setup.exe
• Click Install
• Select the following, and then click Next:
  • Management Server
  • Operations Console
  • Web Console
• Accept or change the default install path and click Next.
• Resolve any issues with prerequisites, and click Next.
• Choose “Add a management server to an existing management group” and click Next.
• Accept the license terms and click Next.
• Input the servername\instance hosting the Ops DB. Select the correct database from the drop down and click Next.
• Accept the Default Web Site on the Web Console page and click Next.
• Use Mixed Authentication and click Next.
• On the accounts screen, choose Domain Account for ALL services, and enter in the unique DOMAIN\OMAA, DOMAIN\OMDAS accounts we created previously.  Click Next.
• On the Diagnostic Data screen – click Next.
• Turn Microsoft Updates on or off for SCOM, Next.
• Click Install.
• Close when complete.

3.  Install SCOM Reporting Role on the SQL server.

• Log on using your domain user account that is a member of the OMAdmins group, and has System Administrator (SA) rights over the SQL instances.
• Locate the SCOM media. Run Setup.exe. Click Install.
• Select the following, and then click Next:
  • Reporting Server
• Accept or change the default install path and click Next.
• Resolve any issues with prerequisites, and click Next.
• Accept the license and click Next.
• Type in the name of a management server, and click Next.
• Choose the correct local SQL reporting instance and click Next.
• Enter in the DOMAIN\OMREAD account when prompted. It is a best practice to use separate accounts for distinct roles in OpsMgr, although you can also just use the DOMAIN\OMDAS account for all SQL Database access roles to simplify your installation. You MUST input the same account here that you used for the OM Reader account when you installed the first management server.  Click Next.
• On the Diagnostic Data screen – click Next.
• Turn Microsoft Updates on or off for SCOM, Next.
• Click Install.
• Close when complete.

You have a fully deployed SCOM Management group at this point.

What’s next?

Once you have SCOM up and running, these are some good next steps to consider for getting some use out of it and keep it running smoothly:

1.  Apply the latest Update Rollup.  At the time of this blog posting that is UR1.  But you should always find and apply the most current CUMULATIVE update rollup.

• https://support.microsoft.com/en-us/kb/3190029
• https://blogs.technet.microsoft.com/kevinholman/2016/10/22/ur1-for-scom-2016-step-by-step/

2.  Manually grow your Database sizes and configure SQL

• When we installed each database, we used the default of 1GB (1000MB). This is not a good setting for steady state as our databases will need to grow larger than that very soon.  We need to pre-grow these to allow for enough free space for maintenance operations, and to keep from having lots of auto-growth activities which impact performance during normal operations.
• A good rule of thumb for most deployments of OpsMgr is to set the OpsDB to 50GB for the data file and 25GB for the transaction log file. This can be smaller for POC’s but generally you never want to have an OpsDB set less than 10GB/5GB.  Setting the transaction log to 50% of the DB size for the OpsDB is a good rule of thumb.
• For the Warehouse – you will need to plan for the space you expect to need using the sizing tools available and pre-size this from time to time so that lots of autogrowths do not occur.  The sizing helper is available at:   http://www.microsoft.com/en-us/download/details.aspx?id=29270

3.  Deploy an agent to the SQL DB server.

• This process has not changed from OpsMgr 2012, so you would use the typical mechanism to push or manually install. You can also refer to: https://technet.microsoft.com/en-us/system-center-docs/om/manage/managing-discovery-and-agents
• You could also deploy any additional agents at this point.

4.  Import management packs. Also refer to: https://technet.microsoft.com/en-us/system-center-docs/om/manage/using-management-packs

• Using the console – you can import MP’s using the catalog, or directly importing from disk.  I recommend always downloading MP’s and importing from disk.  You should keep a MP repository of all MP’s both current and previous, both for disaster recovery and in the case you need to revert to an older MP at any time.
• Import the Base OS and SQL MP’s at a minimum.

5.  Enable Agent Proxy

• I prefer to simply enable agent proxy for all agents.  The BEST way to do this is to enable Agent Proxy as a default setting.  That way you will never have to mess with this again:
• https://blogs.technet.microsoft.com/kevinholman/2014/02/11/opsmgr-2012-enable-agent-proxy-on-all-agents/

6.  Configure your OpsMgr environment to accept manually installed agents.

• The default is to block manually installed agents.  I recommend setting this to “Review new manual agent installations”

7.  Configure Notifications:

• http://blogs.technet.com/b/kevinholman/archive/2012/04/28/opsmgr-2012-configure-notifications.aspx

8.  Deploy Unix and Linux Agents

• http://blogs.technet.com/b/kevinholman/archive/2012/03/18/deploying-unix-linux-agents-using-opsmgr-2012.aspx

9.  Configure Network Monitoring

• http://blogs.technet.com/b/kevinholman/archive/2011/07/21/opsmgr-2012-discovering-a-network-device.aspx

10.  Configure SQL MP RunAs Security:

• http://blogs.technet.com/b/kevinholman/archive/2010/09/08/configuring-run-as-accounts-and-profiles-in-r2-a-sql-management-pack-example.aspx
• https://blogs.technet.microsoft.com/kevinholman/2016/04/26/sql-mp-run-as-accounts-no-longer-required/

11.  Create a dashboard view:

• http://technet.microsoft.com/en-us/library/hh230752.aspx#bkmk_howtocreateadashboardview

12.  Continue with optional activities from the Quick Start guide on TechNet:

• http://technet.microsoft.com/en-us/library/hh230738.aspx

13.  Configure your management group to support APM monitoring.

• http://technet.microsoft.com/en-us/library/hh543994.aspx
• Import supporting management packs for IIS 7 and 8, and APM Web for IIS 7 and 8.

14.  Deploy Audit Collection Services

• http://technet.microsoft.com/en-us/library/hh298613.aspx
• Install the audit collector on a management server, and create a database on a SQL server.
• Upload the reports for ACS, my command is:  UploadAuditReports.cmd “DB1” “http://db1/ReportServer” “c:\acs”
• Create and set a filter:  http://technet.microsoft.com/en-us/library/hh230740.aspx
• You will need to grant NETWORK SERVICE full control to the AdtServer registry key to set a filter at the command line:  http://social.technet.microsoft.com/Forums/en-US/operationsmanagerreporting/thread/ab22685e-36a1-49a9-b90e-d39ead31901f
• My initial filter for lab use is:   adtadmin /setquery /query:”SELECT * FROM AdtsEvent WHERE NOT (EventId=4768 OR EventId=4769 OR EventId=4624 OR EventId=4634 OR EventId=4672 OR EventId=4776)”

15.  Learn MP authoring.

• Fragments the fast and easy way with Visual Studio:  https://blogs.technet.microsoft.com/kevinholman/2016/06/04/authoring-management-packs-the-fast-and-easy-way-using-visual-studio/
• Download MPAuthor:  http://www.silect.com/mp-author/