Part 4 – Deploying the SCOM Azure Management Pack
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:
** Challenge with Instance id’s **
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.