For a clearer picture

Category: SCOM

Part 4 – Deploying the SCOM Azure Management Pack

Part 4 – Deploying the SCOM Azure Management Pack

Download details

The latest version of the Azure Management Pack is available here.

I’ll run through installing the Azure Management Pack and carrying out the configuration which will involve:

  • Configuring the connection to Azure
  • Running the Authoring Template wizard to configure the monitoring

So having downloaded the MP, read the management pack guidelines and ensured that I have the following complete:

  • Created a Resource Pool for Azure Monitoring
  • Ensured the Management Servers (or Gateway Servers) that are in the Resource Pool are added to the resource pool, have internet connectivity and .Net Framework 4.5.2 installed
Extract Management Pack

I’m ready to go. Lets extract the Management Pack by running the .msi

Accept the license agreement.

Location to extract to:

And go ….

And finish …

And we’ll see 2 Management Pack bundles that we need to import to SCOM.

Let’s import them:

Configure Management Pack Administration details

And then start the Azure configuration process. You’ll notice that on the Administration blade; there is now an Azure icon.

And then choose to add an Azure subscription. The first question you will get is how to authenticate to Azure.

A User Principal Name (UPN) is simpler to configure, but it does not work when multi-factor authentication is enforced.

A Service Principal Name (SPN) works in any environment and allows assigning permissions in a more flexible way. Using a service principal allows the management pack to be used in environments with multi-factor authentication. Ideally you should create the Service Principal Name ahead of deployment but I’m going to take the lazy route for this demonstration and let the configuration wizard create it on the fly.

More on SPNs here

I don’t of any reason why you would need to change the Azure endpoints so leave these on the defaults.

And then select auto-created SPN and enter the details requested.

Then click Add Subscription to start the configuration of the subscription:

Confirm that it has worked:

And then select the SCOM Resource Pool that will be responsible for the Azure monitoring. Note that the Management Servers or Gateway Servers in the resource pool do not need direct internet connectivity; there is the option here to configure communication via a proxy.

You’ll be shown a list of subscriptions to choose to monitor. I’ve only got the one so will just select that.

And that is the Administration configuration complete. At this moment we have no monitoring in place. We still need to run the authoring template wizard. But we have the framework in place to start monitoring.

Azure Monitoring Template Wizard

Sadly you can only run the wizard once per subscription which means that you can’t slice and dice your Azure monitoring into more granular logical management packs.

Lets’ run the wizard:

Enter a Name and Management Pack to save the configuration into:

Select the subscription and do a full Azure scan. Take note of the comments at the bottom of the window; a full scan can take 1 to 2 hours for 1000 Azure resources. After the initial full scan you can just do refreshes but I am concerned about enterprise scalability.

You then get a list of all the discovered Azure resources and can select the items that you want to monitor. I’ve just selected my Microsoft.insights resources.

  • Alert Rules – I’ll look at in the next article in this series
  • Components – this is the Azure Resource Name (top level – ping-SCOM_Prod1)
  • Web Tests – the actual URL tests themselves
    • If you want to exclude specific Azure Resources you can do so here:

      Select the data you want SCOM to collect. Be aware that the URL tests just collect the top line item “Test Duration” (which equates to response time) so even though you might select all the performance counters; you won’t be able to actually collect them.

      You can also select to alert on conditions; such as Test Duration > 1200 milliseconds.

      Once you click Finish; you’ll see a Microsoft Azure folder on the Monitoring blade and you’ll be able to see the performance metrics and the Resource State:

      Performance View

      State View

      ** Challenge with Instance id’s **

      Alert View

      As you can see; we do get alerts when thresholds are exceeded but the alerts are somewhat cryptic. They are not user friendly and integrating with ticketing systems will be challenging.

Part 2 – Global Service Monitor Migration Script

Part 2 – Global Service Monitor Migration Script

It is important to migrate your GSM scripts using the migration tool as this will tag the Azure Application Insights tests in a way that ensures that you do not have to pay for them. If you manually recreate your GSM monitoring as Azure Application Insights tests then you will fall under Azure licensing charges.

I have only tested the migration script with taking basic URL web tests from SCOM to Azure Application Insights (ping tests). These are generally very basic tests on whether a URL is available along with the response time and the option of content matching and checking returned status codes.

I found the whole process very straight forward and after many tests; I have never seen it fail. I have not however tried to migrate Visual Studio Web Tests. If I find some time I’ll give those a go later.

Let’s take a look at my GSM Tests

I have 2 tests configured:

Each test has 2 distinct URL checks:

Which are monitored from 5 locations:

And I want an alert if the transaction response time is greater than 5 seconds; if the return code is greater than 400 or if the content match doesn’t contain specific text. I’m also collecting performance data. Take note of these settings as when you move to Azure Application Insights the options are much more limited.

So; let’s run the Migration Script.

First up; if you don’t have the Azure PowerShell module installed, you’ll need to get this configured. Here is the walk through.

Install-Module -Name AzureRM

I then connect to my Azure Subscription to confirm some details;

I’ve cropped them out of the screenshot but make a note of the subscription name.

And then we can run the GSM Migration Script. Best practice naming conventions for Azure Resources are listed here.

MigrateGSMToAI.ps1 -SubscriptionName "**Subscription Name**" -AzureResourceGroupName "**Resource Group Name**" -ResourceLocation "**Location**"

And you can watch the migration take place:

And then there are the log files that you can review if there are any issues. I’ve never had the script fail.

Azure Application Insights Resource

Fire up the Azure Portal and go to your Application Insights resource and you’ll see the migrated Global Service Monitor tests.

My initial concerns is that all GSM tests are migrated to a single Application Insights resource. I can’t see anyway to slice and dice this as part of the migration. However, it is possible to run the Global Service Monitor migration script multiple times and you could then edit the resulting Application Insights Resources in the Azure portal. A bit of a pain; it would be neater to be able to do this as part of the migration script.

Viewing Test Data

If you click on the Availability blade then you can see your tests in action.

You can then click on an individual test and see more detailed results.

You can also click on edit test and change the configuration:

  • Test Name – this cannot be edited so you need to get this right in SCOM before the migration.
  • Test Type – this cannot be edited; it is set by the type of Global Service Monitor test you migrated. As my GSM tests were basic URL checks (not Visual Studio Web Tests) they have been migrated as URL Ping Tests.
  • The URL – this can be edited.
  • Test Name – this cannot be edited so you need to get this right in SCOM before the migration.
  • Parse dependent requests – embedded resources such as links and images are parsed.
  • Enable retries – if the test fails then the number of times to retry before a failure is reported.
  • Test Frequency – every 5, 10 or 15 minutes.
  • Test Locations – taken from the Global Service Monitor configuration and can be edited in Azure.
  • Success Criteria – this gives a few options but a lot less than was available in Global Service Monitor. These are quite disappointing:
    • – Test time out greater than 30 seconds (with options of 60, 90 or 120 seconds). This is not the same as setting an alert on response time which can be in either in Azure alerting or via the SCOM Management Pack.
    • – HTTP response – status code =
    • – Content Match – must contain
Quick review

I noticed that the shortest test interval schedule is every 5 minutes. I think this is a lifetime in terms of web site availability but this is a like for like setting with Global Service Monitor.

Part 1 – Overview – What next for Global Service Monitor?

Part 1 – Overview – What next for Global Service Monitor?

Microsoft dropped the bombshell a couple of months ago that Global Service Monitor (available as part of System Center Operations Manager) was being deprecated on November 7th. This doesn’t leave customers with much time to make alternative arrangements.

The Microsoft road map is to migrate the Global Service Monitoring functionality to Azure Application Insights although this will present challenges to customers who haven’t gone down the Azure route; something I will look at later in the series.

In this series I’m going to do a series of posts to help customers who can adopt Azure Application Insights to show:

PowerShell Monitor to monitor number of folders in a folder with diagnostic and recovery

Part 1 – The PowerShell

Part 2 – The Data Source and Probe

Part 3 – The Monitor Type

Part 4 – The Monitor

Part 5 – A diagnostic task to view all the folders in the top level folder

Part 6 – A recovery task to delete all the folders in the top level folder