You are browsing the archive for Azure.

Use OMS to calculate SCCM patch window

4:12 pm in Azure, OMS, SCCM by Dieter Wijckmans

This blog post is part of the Coretech Global Xmas blogging marathon. To find all cool content please take a look at

Recently I have been exploring OMS a lot and came across a cool user scenario which really showcases the benefits of having all data in one place. Using this big data to connect the dots between different systems and creating even more insights in your environment and the relationships between the different systems.

One demo which really had some eyes popping was in fact the calculation of the SCCM patch window with OMS. A lot of people already know that there’s a specific System Update Assessment solution which points out which machines are missing which updates. But there’s more to this solution that meets the eye on first sight.

You can use this solution, but also the data gathered by OMS for all your updates, to calculate very precisely how long it will take to patch a particular machine to create a patch window accordingly.

Let’s get started shall we!

For this demo I presume you already have an active OMS subscription + workspace. For more info please refer to my OMS quick start guide to get you going fast:

Log on to your workspace and make sure you have machines connected + the solution installed:

First click on Solutions Gallery:

printscreen-23-12-2015 0000

Find System Update Assessment Solution and make sure it is added to your workspace. If it’s not yet added make sure to click the icon and add in the next screen

printscreen-23-12-2015 0001

Make sure to add the Solution to your workspace

printscreen-23-12-2015 0002

If you add the Solution for the first time it will perform an Assessment to gather the data for your environment:

printscreen-23-12-2015 0003

When the Initial Assessment has been complete you will get your info on the tile which represents the System Update Assessment:

printscreen-23-12-2015 0004

TIP: No worries my environment is not that badly patched but if you are looking into taking this solution for a test drive you can always install Azure VM’s with an earlier image (a couple of patch Tuesday’s ago) to have a machine which is in fact missing updates)

Click on the tile to open the detailed pane shown below:


printscreen-23-12-2015 0005

Click on the Required Missing updates pane:

printscreen-23-12-2015 0006

The next window will give you by default a graphical overview of the patches missing + the days ago the patches were released. This gives you a nice overview of how severe your machines are not patched. You also get a nice pie chart to give you an overview on how many patches are missing + the category of the patches.

printscreen-23-12-2015 0007

Note on the right there’s an indication in minutes how long it will take on Average to install these missing updates:

printscreen-23-12-2015 0011

This is not just a “Guesstimate” but OMS is actually using data out of the logs collected by all machines to give you an accurate time of install of this particular set of patches missing on this machine.

The number (in this case 81) is indicating that in fact they have data for all patches missing regarding the install time they will take to install.

At this time you can clearly state that the machine will probably be patched in approximately 14 minutes. You can build in some margin but definitely don’t need an hour to patch this machine.

Create your own insights!

printscreen-23-12-2015 0012

This is just the pretty eye candy view of the Solution!

If you want to have the data by update you can dive into the big data gathered and create your own insights in your patch strategy. This can be achieved by using the “raw data” in the Search Query view and creating your own views. Let’s see how we can find out for example which patches will take more than 60 seconds to install so we can put them in a different patch group:

Click on “results” next to updates right underneath the search query window

printscreen-23-12-2015 0007

At this point you get the 81 results with all their data but… no install time?


printscreen-23-12-2015 0008

Click “Show More” on the bottom of the screen to unveil the InstallTimeAvailable / InstallTimePredictionSeconds / InstallTimeDeviationRangeSeconds properies

printscreen-23-12-2015 0009

 printscreen-23-12-2015 0010       

This is the data gathered for all the updates which are identified as missing on my systems.

InstallTimeAvailable: Will give you an indication whether enough data is gathered in the OMS system to give you an actual prediction of the install time. For new updates it can take some time to find the right data to be reliable to give you an accurate prediction of course.

InstallTimePredictionSeconds: This is the prediction based on all the data gathered through the OMS system (note this is not only based on your environment but across all environments connected to OMS showing the huge advantages of the Big Data approach of Microsoft Operations Management Suite.

InstallTimeDeviationRangeSeconds: Will give you an indication how much fluctuation is possible on the prediction. In this case the value is 0,83 meaning this can either be minus or plus.

Now to find out how many of the updates (81 of them) have an install time of more than 60 seconds we need to use the Search Query power:

Click in the Search Query window on the top of the screen and start typing Install at the end of the line:

printscreen-23-12-2015 0013

OMS will give you suggestions on which parameter you want to search. In this case we are going to search on “InstallTimePredictionSeconds =”

So just click on it to get it into the Search query as shown below. At this point we can put “Greater than” 60 and run the search query by clicking the search Icon on the right or hitting Enter:

printscreen-23-12-2015 0014

There we go… We have 6 patches will take longer than 60 seconds to install so we can take appropriate action regarding these patches in SCCM:

printscreen-23-12-2015 0015


This is just a small example of the huge amount of insights you can create with OMS to help you further tune the management of your environment.

SCOM: Connect management groups between on-prem and Azure

4:27 pm in Azure, SCOM 2012, sysctr by Dieter Wijckmans


During a recent project I explored the benefits on hosting a 2 legged SCOM environment for both on-prem and cloud services. Although this is possible with just one management group and site to site VPN to the cloud they opted for a 2 management group approach to keep a certain sort of divider between the on-prem and the cloud.

In this blog post (who knows it could become a series) I’ll show you how to connect the management groups to each other so they can exchange alerts and use 1 console but benefit from presence of a management group on both platforms.


In this scenario I’m going to use connected management groups. As explained here

Connecting management groups in SCOM 2012 gives you a couple of benefits. The biggest one in my opinion is the fact you can have multiple management groups with different settings but use 1 console to get all the alerts. The customer wanted the ability to monitor their clients on different thresholds than their own systems. The own systems were mainly situated on site although the other systems were at the clients site or in the cloud.

The management group which will have the consolidated view is called the local management group. In my example it is VLAB which is on prem. The other management groups are called “connected management groups” in this case VCLOUD.

They relate to each other in a hierarchical fashion, with connected groups in the bottom tier and the local group in the top tier. The connected groups are in a peer-to-peer relationship with each other. Each connected group has no visibility or interaction with the other connected groups; the visibility is strictly from the local group into the connected group.

So in this scenario it’s a good idea to connect these management groups to see all data in 1 console for both on-prem and client based. In VCLOUD it’s not possible to see the alerts of VLAB but the other way around it’s possible.

So what do we need to do to obtain this (even without different AD domains and firewalls in between).

First of all prep the VCLOUD in Azure:

Create endpoints on Azure machine

In order to be able to resolve the Azure management group from the on prem we need to make sure that connection is possible to the VCLOUD management server. This is done through port 5723 and 5724.

Open the Azure management portal:

My server is called vcloud-ms1


Open the endpoints and add 5723 and 5724 to the endpoints. This in fact opens the firewall of azure to your machines. All communication will happen over these 2 ports.


Click add and fill in the endpoints as shown below.


Next find the following

  • The Public Virtual IP address (VIP) and take a note. In my case it’s
  • The DNS name: in my case



Prepare the onsite management server

Now that the management server of our VCLOUD management group is configured we need to configure the management server in our VLAB environment to become the local management group which will receive the alerts.

First we need to make sure that the onsite server can resolve AND reach the server in VCLOUD management group.

This can be done by changing the hosts file on the VLAB management server.

Go to c:\windows\system32\drivers\etc\ and open the hosts file:


Note: I’ve deleted the last 3 digits of all the IP addresses above you need to fill in the full IP address as documented in the Windows Azure console.

Let’s check whether this works now from the VLAB management server. Doing THE route check: ping the hostname:


hmmm not working. Did we configure something incorrect? Check, double check. NO.

Well this makes perfect sense because: PING IS DISABLED towards Azure machines. Therefore you will get a Request timed out all the time you test no matter what you configure!

Connecting the management groups

Now that we have both ends configured it’s time to see whether we can connect the management groups. Remember: initiate the connection from the local management group (the one who needs to see all alerts and is on top of the hierarchy)

So let’s connect to the management server in VLAB:

Open the Administration pane and select Connected Management Groups and click


Right click and choose Add Management Group


Fill in all the data requested:

  • Management Group Name: The name of the VCLOUD management group
  • Management Server: The name of the management server in VCLOUD (make sure to use the exact name as filled in in the host file)
  • Account: Because the account we use as SDK service resides in the VLAB AD and is not known in the VCLOUD we need to use the VCLOUD credentials


Note: You need to initiate this from the management server where you have changed the host file so make sure there’s a console on there

You will get the message below because it’s not possible to validate the account in the local AD:


Just click next and normally you should be connected at this point:



So now all we have to do is configure what we want to show on the local management group.


I’ll explain this further in the next blog in this series.