SCOM 2016 Update Rollup 5 is Now Available

A couple of days ago, Microsoft announced the latest Update Rollup (UR5) for SCOM 2016.

The Fixes

Unlike the last UR4 release, this update comes with a raft of new bug fixes - including a handy one for when you want to co-exist the SCOM and SCSM consoles on the same server along with a fix for a widely reported bug that occurs when performing an in-place upgrade of SCOM 2016 to the Semi-Annual Channel SCOM 1801.

Here's what you get with UR5:

• The SCOM console and Service Manager console for PowerShell modules can now coexist on the same server. (Note Both SCOM Update Rollup 5 (this update) and Service Manager Update Rollup 5 (update KB 4093685) must be installed to resolve this issue.)
• Active Directory Integration rules are not visible or editable in an upgraded 2016 Management Group. This prevents the ongoing management of Active Directory integration assignment in the upgraded Management Group.
• When the UNIX host name on the server is in lowercase, the OS and MonitoredBy information is displayed incorrectly in the Unix/Linux Computers view.
• Active Directory integrated agents do not display correct failover server information.
• Performance views in the web console do not persist the selection of counters after web console restart or refresh.
• The PowerShell cmdlet Get-SCXAgent fails with error “This cmdlet requires PowerShell version 3.0 or greater.”
• During the upgrade from SCOM 2016 to SCOM 1801, if the reporting server is installed on a server other than the management server, the upgrade fails. Additionally, you receive the error message, "The management server to which this component reports has not been upgraded."
• If a group name has been changed through the operations console, the Get-SCOMGroup cmdlet does not retrieve the group data that includes the changed group name.
• Error HTTP 500 occurs when you access Diagram view through the web console.
• When you download a Linux management pack after you upgrade to SCOM 2016, the error "OpsMgr Management Configuration Service failed to process configuration request (Xml configuration file or management pack request)" occurs.
• The SQLCommand Timeout property is exposed so that it can be dynamically adjusted by users to manage random and expected influx of data scenarios.
• The MonitoringHost process crashes and returns the exception "System.OverflowException: Value was either too large or too small for an Int32."
• When company knowledge is edited by using the Japanese version of Microsoft Office through the SCOM console, the error (translated in English) "Failed to launch Microsoft Word. Please make sure Microsoft Word is installed. Here is the error message: Item with specified name does not exist" occurs.
• Accessing Silverlight dashboards displays the "Web Console Configuration Required" message because of a certificate issue.
• Microsoft.SystemCenter.ManagementPack.Recommendations causes errors to be logged on instances of Microsoft SQL Server that have case-sensitive collations.
• Deep monitoring displays error “Discovery_Not_Found” if the installation of JBoss application server is customized.
• Adds support for the Lancer driver on IBM Power 8 Servers that use AIX.
• The ComputerOptInCompatibleMonitor monitor is disabled in the Microsoft.SystemCenter.Advisor.Internal management pack. This monitor is no longer valid.

My Advice

As always, my advice for deploying this update is to head over to Kevin Holman's blog and wait for his handy step-by-step guide to get this up and running in your non-production environments first.

SCOM 2016 and OMS '101' Series

A few years back, Antoni Hanus (Microsoft PFE) released a really useful beginners guide for SCOM titled 'Operations Manager 101'.

This PDF-style guide contained over 100 pages of information and walk-through's designed to get people up and running with SCOM quickly. It was that useful, that I always recommended it to my SCOM customers as a great free learning resource and the feedback on it was always positive.

The only downside to the guide was that it was authored specifically for SCOM 2007 and along with the retro-style Microsoft logo that you can see in the image above, all of the screenshots and content looked way too out-of-date for people dipping their toes with SCOM 2016. There was also no reference to how SCOM can now connect to OMS.

Thankfully, over the weekend I came across a blog post from Antoni where he has taken the opportunity to update this guide and push it out as a combined web-series for SCOM 2016 and OMS.

He's already got over 20 new blog posts linked to this series with more to come and if you're deploying SCOM (or just want to ramp up your SCOM 2016 administration skills), then I encourage you to check it out at the link below:

https://aka.ms/101

Happy reading!

Dude, where's my 'Outside-In' monitoring gone?

If you've been working with SCOM for as long as I have, you'll most likely have come across the very cool Global Service Monitor (GSM) feature that Microsoft first demonstrated way back in 2012 during the release of SCOM 2012 Service Pack 1 at the awesome Microsoft Management Summit in Vegas.

GSM simulates the end-user experience of accessing a web application as it can schedule automatic synthetic transactions from locations around the world - providing an 'Outside-In' availability, performance and reliability monitoring view of your externally facing web applications.

If you purchased a Software Assurance license for System Center 2012, then you were entitled to deploy the GSM management pack into your SCOM environments and use the Global Service Monitor connector shown in the following image to connect GSM in the cloud back into your on-premise SCOM deployment.

I've deployed GSM to a lot of customers over the years and it worked exactly as it was meant to along with adding some nice value when we were modeling IT services that needed an end-user perspective of the availability and performance of specific web applications.

Fast-forward to when SCOM 2016 was first released and although the GSM management pack guide only specified support for SCOM 2012, it still worked and delivered that 'Outside-In' monitoring experience.

Recently however, the GSM connector has stopped working for SCOM 2012 and also for SCOM 2016. If you had GSM running in your SCOM environment, you will probably have noticed an alert relating to a DNS resolution error - which on investigation looks like there's a DNS zone missing on the Microsoft side.

While no official statement has been released by Microsoft as to this connector being deprecated and this DNS issue may still be resolved, it's probably a good time to start thinking of an alternative option to GSM. This is where the Azure-based Application Insights platform comes in.

A few years back I wrote a few blog posts (here and here) that discussed an alternative to GSM when using Application Insights and last week after a discussion between a some MVP friends relating to the Global Service Monitor DNS resolution error in SCOM, Cameron Fuller (Cloud and Datacenter Management legend) put together an awesome walk-through blog post on using Application Insights as an alternative to GSM in SCOM.

Along with showing how to create a web availability test in Application Insights, Cameron also dives into some examples around custom dashboards and automatic application mapping. If you want to learn more, then I totally recommend checking out his post at the link below:

blogs.catapultsystems.com/cfuller/archive/2018/01/22/replacing-gsm-in-scom-with-application-insights/

Enjoy!

SCOM Day Sweden 2017

Next week I 'll be on the road again and heading over to Gothenburg in Sweden to present at the awesome SCOM Day event.

Organised by the team at Approved Consulting, I presented at this event last year and really enjoyed the networking and talking to attendees about all things SCOM. This year, I'll be talking about what's new with SCOM (including some of my favourite community management packs) and I'll also be discussing some new features and changes that are coming to SCOM 2016 over the next few months.

I'll be looking forward to a presentation on the day from Microsoft's Kevin Holman (aka SCOM Ninja/Guru/Legend). Kevin is one of the most prolific SCOM bloggers around and there's always something new to learn from his blog posts and presentations.

If you're based in Scandinavia and want to attend the event (it's kicking off on Wednesday 4th October), then you can register using the link below:

http://www.approved.se/scom-dagen-2017-registrering

Hope to see some of you there!

SCOM 2016 Update Rollup 3 (UR3) Now Available

Yesterday, Microsoft released a new (and widely anticipated) Update Rollup (UR3) for SCOM 2016.

This update contains fifteen documented fixes with one in particular (APM crashing IIS agent) being the most important and a top priority for me and my customers due to the agent IIS crash issue I blogged about a while back.

***Update 6th June 2017: Microsoft has posted more information about this issue remaining after deploying UR3 and have mentioned a hotfix is still in the works. Check out their latest post on this issue here.***

Here's some of the highlights of fixes that are covered in this update:

• The Application Performance Monitoring (APM) feature in System Center 2016 Operations Manager Agent causes a crash for the IIS Application Pool that's running under the .NET Framework 2.0 runtime. Microsoft Monitoring Agent should be updated on all servers that use .NET 2.0 application pools for APM binaries update to take effect. A restart of the server might be required if APM libraries were being used at the time of the update.
• When overriding multiple properties on rules that are created by the Azure Management Pack, duplicate override names are created. This causes overrides to be lost.
• When the heartbeat failure monitor is triggered, a "Computer Not Reachable" message is displayed even when the computer is not down.
• The Get-SCOMOverrideResult PowerShell cmdlet doesn't return the correct list of effective overrides.
• When creating a management pack (MP) on a client that contains a Service Level (SLA) dashboard and Service Level Objects (SLO), the localized names of objects aren't displayed properly if the client's CurrentCulture settings don't match the CurrentUICulture settings. In cases where the localized settings are English English, ENG, or Australian English, ENA, there's an issue when the objects are renamed.
• The Event ID: 26373 error, which may cause high memory consumption and affect server performance, has been changed from a “Critical” message to an “Informational” message.
• The UseMIAPI registry subkey prevents collection of processor performance data for RedHat Linux system. Also, custom performance collection rules are also impacted by the UseMIAPI setting.
• Organizational Unit (OU) properties for Active Directory systems are not being discovered or populated.
• The Microsoft.SystemCenter.Agent.RestartHealthService.HealthServicePerfCounterThreshold recovery task fails to restart the agent.
• An execution policy has been added as unrestricted to PowerShell scripts in Inbox management packs.
• SQL Agent jobs for maintenance schedule use the default database. If the database name is not the default, the job fails.

You can see the full list of fixes from the official UR3 knowledge base article here.

To get access to this update, you can choose to either manually download it from the Microsoft Update Catalog here or you can use Windows Update to pull down the update automatically to your SCOM 2016 environment.

**Note: I've yet to test this update rollup on the existing SCOM 2016 agents that I've previously applied the NOAPM=1 workaround to (mentioned in my post here) and I suspect that a push install of this UR from the console to those agents will fail as the APM binaries are no longer installed. I'll create a new post on updating those agents when I've tested the process fully.**

Whatever method you choose to deploy this update, make sure to read through the full installation instructions as there are some manual tasks to carry out once the update has been applied to each SCOM role and if you're not confident, I'd always recommend waiting for Microsoft's Kevin Holman to add his walk-through post for this UR to his blog here.

Finally, this update is one part of a larger UR3 release for covering other products in the System Center 2016 suite. If you've deployed additional components of the suite alongside SCOM, then you might be interested to check out the updates now available for DPM 2016, SCSM 2016 and SCVMM 2016.

Full details of all the fixes in the main System Center 2016 UR3 downloads can be viewed at:

https://support.microsoft.com/en-ie/help/4020906/update-rollup-3-for-system-center-2016

Monitoring Commvault with SCOM

A common request I get from customers is how to best monitor Commvault backups using SCOM. Commvault are one of the market leaders in enterprise backup technologies and I come across their products in customer sites on a regular basis.

As I don’t have a spare Commvault server to play around with in my demo environment and I’ve never really had the time to document the whole process during an actual customer deployment, a blog post on this topic has remained elusive until now.

A few weeks back I was working on a customer site who needed Commvault monitored and over the course of a lunch break one day, I managed to put some screenshots together to help document the process.

Overall, it’s pretty straight-forward to get up and running and unlike some other enterprise backup vendors, Commvault have made an effort to integrate their product with SCOM. The integration is made possible by initiating the integration from the Commvault CommCell Browser console – which then imports an unsealed management pack into SCOM for monitoring.

The management pack provided by Commvault is basic enough though and you’ll probably want to add some custom monitors and views to it as you see fit.

Management Pack Overview

The unsealed management pack provided contains a discovery rule which targets the Windows Computer class. This discovery rule (shown in the exported Excel sheet below) looks for the presence of the 'Commvault Server Event Manager Service' (the actual service name is GxEvMgrS).

When this service is detected, a new class named 'Commvault CommServer' is then created by the management pack. The class information in the management pack is shown in the image below.

There are three rules in the management pack that can generate Critical, Warning or Informational alerts in SCOM.

These rules target a CSV file named 'GalaxySCOM.csv' as their data source. This CSV file is created automatically by the Commvault application and is stored in the '\Program Files\Commvault\ContentStore\SCOM' directory on the Commvault server.

Getting Started

The first thing I'd recommend you do before deploying the Commvault management pack is to make a full list of all the Windows Services relating to Commvault that you wish to monitor. The reason for this is that the Commvault management pack will only monitor whether or not the 'Commvault Server Event Manager Service' (GxEvMgrS) service is up and running. This may be the only Commvault service you're interested in or most likely, you'll have a few more of them that are important to you.

Use the following line of PowerShell to export a list of all Windows Services on your Commvault server to a CSV file:

Get-Service | Sort-Object -Property DisplayName | Export-CSV -path C:\winserviceexport.csv

Once you've identified the service names you need for Commvault, check out my recent blog post here for a quick and easy way to monitor custom lists of Windows Services in SCOM.

The image below shows an example of the Commvault-specific services a customer recently requested to be monitored on all their Commvault servers:

Deploying the Management Pack

When you have all the Commvault services monitored, launch the CommCell Browser using an account with the required administrative permissions and you should be presented with a view similar to the one in the image below. From there, click the Control Panel button from the navigation bar at the top.

When the Control Panel area opens, you need to click the SCOM option from the Monitoring section as shown here....

This opens up the SCOM dialog box (shown below) and here, you need to input your SCOM server name along with a user account and password that has been assigned SCOM Administrator permissions.

When you've added your credentials, hit the Apply button to confirm and then click Test Configuration to validate communication between Commvault and your SCOM server is working as expected.

When you receive confirmation that the test was successful, hit the Import Management Pack button to begin the import of the unsealed management pack into SCOM.

When the process is complete, you should see a status message similar to the one in the image below that confirms the Commvault management pack has been configured...

A quick check of the Installed Management Packs view in the SCOM console confirms the management pack has been imported and is ready to go...

You should now see the four simple alert views under the CommVault Operations Manager folder in the Monitoring workspace as shown here....

If you want to confirm the new class has been created and discovered, scope your Discovered Inventory view to CommVault CommServer and you should then see all monitored Commvault servers that SCOM knows about.

Opening a Health Explorer view from the newly discovered CommVault CommServer class object shows how basic this management pack actually is with just the one Service Running State monitor in place to let you know the health state of the Commvault Windows Service.

A quick jump over to the Authoring workspace and we can see the three new Commvault alert rules that have been imported (these rules all target the new Commvault CommServer class).

A check of the Data Source properties for each of the rules gives us the location and CSV file name that will be used to collect alert information from the Commvault server...

Each rule's Data Source has been configured with a wildcard Expression value relevant to the type of alert that will fire (e.g. *Critical*, *Warning* or *Informational*).

If you want to change the name or alert description format of the alert response, you can do that from the Alert properties as shown here...

Configuring the Integration

Once the management pack has been imported and your Commvault servers have been discovered, launch the CommCell Browser again, click Alert from the navigation bar and click the Configure Alert option as shown in the following image...

When the Alerts window opens, you'll be presented with a list of all enabled and disabled alerts in Commvault. We'll click the Add button here to begin the process of creating an alert for SCOM.

From the Add Alert Wizard, type a name for the SCOM alert then choose a category and type. In our example we'll create an alert called Failed Backups and we'll choose the Job Management category with a type of Data Protection.

When you're ready, click Next to move on.

At the Entities Selection window, choose the client groups and/or clients that this alert will be scoped to then hit Next to continue.

From the Threshold and Notification Criteria Selection window, use the Alert Criteria section to scope the alert to the criteria that you need. In our example, we're only interested in Job Failed, Job Skipped and Job Succeeded with Errors alerts. Ignore the other options outside the Alert Criteria section and click Next to move on when you've made your criteria selections.

At the Notification Type(s) Selection window, click the SCOM tab then enable the Select [SCOM] for notification check box as shown in the following image...

Hit Next to continue.

At the Token Criteria Selection window you can optionally add rules to the alert that will dictate if the alerts are sent or not. You can get a full list and description of the alert tokens from here.

We won't specify any rules in our example and when you're ready, click Next to move on.

From the Security window, use the Add button to specify the user accounts and groups that you wish to grant permissions for the alert to (we'll configure an admin account with the Alert Owner role for this alert).

Click Next to move on and at the Summary window (shown in the image below), confirm your settings and hit Finish to end the wizard.

Back in the Alerts view of the CommCell Browser, you can check that the new alert has been created and is enabled as shown below...

That's all you should need to do to configure the integration between Commvault and SCOM and the next time an alert condition has been met, you should see the alert dropping into the Monitoring workspace of the SCOM console similar to this one...

If you've create a new distributed application model in SCOM for Commvault and you use either the Windows Computer or CommVault CommServer class in your component groups, these alerts will rollup to change the health of the model as expected.

Conclusion

Using the walk-through in this post should help people get up and running when monitoring Commvault with SCOM and with some additional distributed application service modeling, SLA planning and dashboard design, you can get some really nice visibility of your backup environments all from a single console.

SCOM 2016 Agent Crashing Legacy IIS Application Pools

SCOM 2016 has been generally available since late last year and as is usually the case with new versions of software, compatibility issues begin to rear their heads as more organizations begin to adopt it.

During one of our recent SCOM 2016 deployments we encountered an issue where the agent (referred to as the Microsoft Monitoring Agent) was deployed to an IIS server - initially without any apparent problems. However, when the IIS server was restarted some time later to accommodate some Windows updates, the IIS Application Pools began to crash regularly. A check of the Windows Event Log on the server threw up the following Event ID 1000 error:

Log Name: Application

Source: Application Error

Date: 24.02.2017 10:42:30

Event ID: 1000

Task Category: (100)

Level: Error

Keywords: Classic

User: N/A

Computer: H-SPDEMO01.nimbuscorp.com

Description:

Faulting application name: w3wp.exe, version: 8.0.9200.16384, time stamp: 0x50108835

Faulting module name: PerfMon64.dll, version: 8.0.10918.0, time stamp: 0x577fd168

Exception code: 0xc0000409

Fault offset: 0x0000000000149794

Faulting process id: 0x2c38

Faulting application start time: 0x01d24405d195eb6a

Faulting application path: c:\windows\system32\inetsrv\w3wp.exe

Faulting module path: C:\Program Files\Microsoft Monitoring Agent\Agent\APMDOTNETAgent\V8.0.10918.0\PerfMon64.dll

Identifying the Issue

The 'Faulting Module Path' in the above application error pointing to the Application Performance Monitoring (APM) component of the agent was the first give-away to us that SCOM was the culprit. A quick uninstall of the SCOM 2016 agent and recycle of the Application Pools gave us confirmation when the errors and crashes went away.

The Microsoft Monitoring Agent APM component comes bundled in the form of a Windows service as part of the initial agent installation but is disabled by default as shown below:

APM is typically enabled through the SCOM console on a server-by-server basis and delivers some really nice DevOps scenarios for monitoring .NET workloads at a code level.

I've previously blogged about SCOM APM, presented on it at conferences and even wrote a chapter in the Mastering SCOM 2012 R2 book about it. A number of our customers also use this feature and it's always been very successful.

The weird thing about this particular IIS crashing issue though was that the APM feature was never enabled.

We needed to dig deeper to see how we could continue monitoring this server using SCOM without having the IIS Application Pools crashing and as the faulting module path in the Event Log error referenced the APM component, I decided to focus here first.

If you use the command line to install your SCOM agents, you can specify a parameter that removes the APM feature from the agent installation (check out this link for command line options) and I figured this was the best place to start as the IIS server in question didn't require the APM feature.

Removing the Agent APM Feature

In the following steps, I'll walk you through a process to remove the APM feature on the SCOM 2016 agent using the command line. The first walk-through will perform an in-place repair on an existing agent to save you from having to uninstall the agent first. An added benefit of the repair option is that the agent will stay registered as Remotely Manageable in the console and you'll avoid having to follow this process to change them.

The second walk-through will show you how to use the command line to perform a new agent installation that doesn't contain the APM feature.

(Repair Agent Install Option)

Copy the SCOM 2016 Agent installation folder (amd64) from your SCOM server to the IIS server (this folder is located at "C:\Program Files\Microsoft System Center 2016\Operations Manager\Server\AgentManagement")

Log on to the IIS server and open a command prompt using an administrative account. From there, browse to the location where you saved the SCOM 2016 Agent folder to and run the following command:

msiexec.exe /i momagent.msi NOAPM=1

This command will then launch the Microsoft Monitoring Agent Setup installer shown in the following image..

Click Next and if you've already installed the SCOM 2016 agent to your IIS server, then you'll be presented with the Program Maintenance window shown below.

Select the Repair option and hit Next to move on.

Hit Install at the next window and the agent repair should kick off. After a minute or so, the agent repair job will be complete and you'll be presented with the following confirmation of success...

Now if you open the Windows Services (services.msc) snap-in and check the services listed for the Microsoft Monitoring Agent, you'll see that the APM component is no longer installed as shown here..

With the agent sucessfully repaired, it'd be a good idea to check the Update Rollup version of the agent and if needs be, to re-apply the latest one (UR2 at this time). You can check the UR version of your agent by importing the awesome SCOM Agent Version Addendum Management Pack from Microsoft's Kevin Holman.

Recycle the IIS Application Pools on your IIS server to ensure the new agent changes take affect.

(New Agent Install Option)

If you've already uninstalled the SCOM 2016 agent from your IIS servers or haven't yet deployed it, then follow these steps to get it deployed without the APM feature:

Copy the SCOM 2016 Agent installation folder (amd64) from your SCOM server to the IIS server (this folder is located at "C:\Program Files\Microsoft System Center 2016\Operations Manager\Server\AgentManagement")

Log on to the IIS server and open a command prompt using an administrative account. From there, browse to the location where you saved the SCOM 2016 Agent folder to and run the following command:

msiexec.exe /i momagent.msi NOAPM=1

This command will then launch the Microsoft Monitoring Agent Setup installer where you will need to click Next and then hit the I Agree button in the following window to accept the license agreement.

At the Destination Folder window, confirm the installation path for the agent and click Next to continue.

When you see the Agent Setup Options window, select Connect the agent to System Center Operations Manager (shown below), then hit Next.

At the Management Group Configuration window, fill in the information required to connect the agent to your SCOM environment and remember that the Management Group Name field is case sensitive!

Click Next to continue and at the Agent Action Account window, leave the Local System option selected, then hit Next again.

Review your installation settings at the Ready to Install window, then click Install to deploy the agent without the APM feature.

When the agent has installed, open the Windows Services (services.msc) snap-in and check the services listed for the Microsoft Monitoring Agent, you'll see that the APM component is no longer installed (see image below).

As this is a new manually installed agent, you will need to change the Remotely Manageable status of the agent back to Yes by following the steps in Kevin Holman's post here (although this post references SCOM 2007, the steps are still the same for SCOM 2016).

You will also need to install the latest update rollup - which is currently at UR3 - and if you've set the Remotely Manageable status back, you should be able to push the update rollup out from the SCOM console. Make sure to reference the SCOM Agent Version Addendum Management Pack to deliver easier visibility of your agent UR versions.

Recycle the IIS Application Pools on your IIS server to ensure the new agent changes take affect.

***Update 20th August 2017 - Handy Tip for Reinstalling Agents: Microsoft's Kevin Holman and Brian Barrington have come up with a nice workaround to easily reinstall your agents with the NOAPM switch. Check it out here.***

More Information About This Issue

This issue was the first time in years that I've encountered a scenario where the SCOM agent 'broke' something and as such, I wanted to investigate it a bit further and raise it with Microsoft. One of the massive benefits of being a Microsoft MVP for me is that I get the opportunity to interact with the SCOM Product Group on a regular basis.

After a few emails back and forth, the awesome folks on the Product Group came back to me with the following detailed information about the issue:

• Issue affects only IIS Application Pools running .NET Framework 2.0/3.5 and can be seen on any version of Windows Server or IIS that hosts these pools.
• Switching the IIS pool to .NET Framework 4.0 (or higher) will solve the issue however, this is not a suitable workaround for SharePoint as SharePoint 2010 doesn't support 4.0 pools.
• If you need to deploy to the system with IIS running pools 4.0+ - no action is needed and a default installation of the SCOM 2016 Agent will work fine.
• For now, if you need to deploy to a server running .NET Framework 2.0/3.5 application pools, then you'll need to either install the SCOM 2016 agent with the NOAPM=1 switch (following my walkthrough above) or you can continue to use the SCOM 2012 R2 agent as it’s forward compatible with SCOM 2016 and doesn't crash these application pools.
• A permanent fix for this issue should be included in Update Rollup 3 for the SCOM 2016 agent.

***Update March 21st 2017: The Product Group have also just released a blog on this issue and in their post, they have confirmed that it will be resolved in Update Rollup 3 along with a chance that a hotix may be released sooner. Check out their blog post here.***

***Update 24th May 2017: Microsoft has just released Update Rollup 3 and you can read all about it in my post here.***

***Update 31st May 2017: Microsoft has just posted that this agent crash issue is still not resolved with UR3 (not cool...). I'll update here when we have more info***

***Update 6th June 2017: Microsoft has posted more information about this issue remaining after UR3 and have mentioned a hotfix is still in the works. Check out their latest post here.***

Conclusion

Although this issue has been an annoyance, it's good to know that it only affects a small subset of legacy systems and the workaround is relatively simple to implement. Hopefully this blog post will help to serve people who've already deployed SCOM 2016 (or who are about to deploy it) and need to monitor legacy IIS application pools prior to the release of UR3.

SCOM 2016 - The Curious Case of the Missing Agent Patch List Property and Static Agent Version Value

Last week Microsoft released the second update rollup (UR2) for SCOM 2016 and a common trend I've noticed with these UR's is that the Patch List property is missing from the Agents by Version view in the Monitoring workspace of the console.

This is a bug with the SCOM 2016 agent and a bit of an annoyance when deploying update rollups as it's handy to know which agents need to be upgraded and which ones don't.

A quick check in the Agent Managed view of the Administration workspace will show a version for the agent but this version won't update to any new UR versions. The following image shows the default SCOM 2016 agent version even though I've deployed UR1 to this environment months ago...

Now, if you're thinking that after an update, all agents always drop into the Pending Management view of the Administration workspace and patiently wait until you're ready to upgrade them, then you'd be wrong. Unfortunately, depending on how you deploy the update rollup (e.g. non-admin permissions, manually installed etc.), there's a good chance that some if not all of these agents will not appear in Pending Management and you'll end up with something similar to this...

So, now your only option in the console to upgrade the agents is to run a series of bulk Repair jobs from the Agent Managed view on all of them and then hope for the best that all agents have been successfully upgraded. This is not a fun process and I really don't like not having a central view of all my agent versions direct in the console.

Thankfully Microsoft's Kevin Holman (SCOM Deity and all-round awesome community contributor) has created the new SCOM Agent Version Addendum Management Pack to help address this exact problem!

This management pack runs a script that disables the built in discovery for Microsoft.SystemCenter.DiscoverHealthServiceProperties (which has a display name of 'Discover Health Service Properties') and replaces it with a new discovery that attempts to retrieve the actual update rollup Agent Version value from a DLL file in the agent installation path.

Straight after I import this new MP, my agent version in the Agent Managed view changes to reflect the existing agent versions (the 8.0.10931.0 version shows the UR1 agents that I currently have running) and after I've deployed UR2,  I can select those agents for a Repair job as shown in the image below...

When the Repair job has completed, the version changes to show that my agents have now been updated to UR2 as shown here:

I love this MP as it adds some much needed functionality to the Agent Managed view within the console. An extra bonus is that this MP also works perfectly on SCOM 2012 R2 too!

If you want to know more, check out Kevin Holman's blog post here and you can download it directly from the TechNet Gallery here.

Enjoy!