SCOM - GSM to Azure Application Insights Migration Walkthrough (Part 1)

In my previous post, I talked about the recently announced retirement of the Global Service Monitor (GSM) feature and the need to start migrating your existing web application tests to Azure Application Insights. In this post, I'll walk through the migration process to help get you started.

Prerequisites

The migration script has the following prerequisites:

• Azure Subscription -  your subscription name can be found in the Subscriptions view within the Azure portal.
• ResourceGroupName - refers to the resource group in Azure where all the tests will be migrated to. If you don't have a resource group created in Azure, the script will create a resource group with the name you provided in the parameters.
• ResourceLocation - refers to the location of the resource group metadata in Azure.
• Azure PowerShell Module - needs to be installed (download available here). Be aware that his module requires PowerShell version 5 or higher to be installed so if you're installing on a Windows Server 2012 R2 server, there's a good change that you'll need to reboot to meet this requirement.
• SCOM PowerShell Module - needs to be installed if you're running the script from anywhere other than a SCOM server (installer can be found on the SCOM media).
• Internet Connectivity - you'll need a working internet connection on the computer that you choose to launch the migration script from.

Limitations

You'll also need to be aware of the following limitations in Application Insights:

• Application Insights has a maximum capacity of 800 web availability tests per resource group and there's a limit of 100 web availability tests for each application component you need to monitor.
• GSM allows you to enable alerts based on a specific HTTP status code. For HTTP status code 200 in Application Insights, you will see a Success returned and for all other codes, they will show a Failure.
• GSM allows you to create Alerts on content match. Application Insights only supports the 'Content must contain' parameter.
• GSM allows Performance monitoring for a website based on a number of performance metrics (shown in the following screenshot) however, Application Insights does not have a mapping to automatically collect these performance metrics for websites. You would only see the Response Time for tests; the other Performance metrics on the list will not be monitored.

Reviewing GSM Test Configurations

Before you kick off the migration script, it'd be a good idea to take a note of the existing configuration settings of your GSM tests in SCOM so you can validate those configuration settings come over to Azure Application Insights. For my demo SCOM environment, I've currently got the following two GSM web application tests configured....

One of these GSM tests performs external monitoring for a legacy demo web application (DinnerNow) that I sometimes use in my Application Performance Monitoring (APM) presentations and the other GSM test is monitoring the URL to this blog. In the following few screenshots, we'll dig into the configuration of the GSM test that's monitoring my blog URL.

This screenshot shows the actual URL that is to be monitored with GSM....

Here, we can see all of the external locations that GSM is configured to monitor my blog URL from. I've chosen five different locations around the globe and my expectation would be that if I migrate this test up to Azure Application Insights, these locations would be configured there as external monitoring points for the test.

In the next screenshot, I get a summary of the test locations along with an understanding of the Test Frequency (1 hour) and estimated monthly external transaction count (3,600). The lower I configure the Test Frequency setting here, the higher the number of monthly transactions. Again, these configuration settings are something that I would expect the migration over to Azure Application Insights to retain.

Here's a final summary of the configuration settings for my external blog URL monitor....

Once you've confirmed the configuration settings of your existing GSM tests, it's time to get down to the migration stage.

Note: Keep in mind that if things go horribly wrong with the migration, your existing GSM tests still remain unchanged in SCOM and there's no 'point-of-no-return' stage whereby you have to confirm deletion of them.

Running the Migration Script

The following steps will walk you through what you need to do to get the migration of your GSM tests to Azure Application Insights kicked off (these steps assume you have all prerequisites configured and in place)..

Login to your subscription in the Azure portal and create a new resource group to be used for the newly migrated GSM tests.

Note: Manually creating a new resource group is an optional step and the migration script will do this automatically for you if you have specified a resource group name that doesn't exist. For testing purposes, I prefer to keep control of where my resources are created and if things go wrong with the migration, I can always then just delete the resource group and start again.

Here's a screenshot of a new empty resource group titled GSM2AppInsights - which I've created specifically for this migration demo...

Save the script from the Microsoft Download Center here to a local folder on the machine that you want to run the tool from (we’ll use a SCOM Management Server in this example).

Launch a PowerShell session with Administrative permissions, browse to the directory that you’ve saved the script to and run the following command (example shown in the following screenshot):

.\MigrateGSMToAI.ps1 -SubscriptionName "<AZURE_SUBSCRIPTION_NAME>" -AzureResourceGroupName "<RESOURCE_GROUP_NAME>" -ResourceLocation "<RESOURCE_LOCATION>"

At the Security Warning prompt, type R to run the script once as shown here....

When the Sign in window presents itself, key in the relevant credentials with access to the Azure subscription you wish to migrate the GSM test to.

After the script launches, you'll be presented with various pieces of information on its progress - similar to what's shown in the following screenshot....

The script shouldn't take too long to run (dependent of course, on the number of GSM tests you have to migrate) and soon, you should be presented with a message stating that everything has been migrated successfully along with a reference to where you can find the migration log file.

If I browse to the location on my server where the log file can be found, I can see that there's a specific log file for each migrated GSM test as well as the MigrationLog.txt file shown here...

Clicking in to MigrationLog.txt gives me confidence that my tests have all been migrated to Azure Application Insights successfully.

Confirming the Migration

Once the script has completed and the log files have been checked, it's time to jump back into the Azure portal to take a look at our newly migrated GSM tests.

In the following screenshot we can see that the script has created two new Azure Application Insights web application tests within my GSM2AppInsights resource group.

After a short while of waiting, I can see each of my GSM tests light up with availability data. Here's the two migrated GSM tests now actively monitoring web availability within Azure Application Insights...

From there, I can pivot into the specific web availability test that I had configured to monitor my blog URL. All of the external locations that the original GSM test was configured for can now be seen as monitoring locations within Application Insights as shown here....

If I edit this test, I can see all of the original settings that I had in GSM have been migrated over.

Clicking on any of the green (or red) dots from within the Application Insights availability test view, I'm presented with an End-to-End view of the transaction - including details about each of the response headers the test has encountered (awesome!)

Conclusion

After working through this migration process from start-to-finish in less than an hour, I can confirm that the GSM migration script works really well and as expected. The script leaves your existing GSM tests in place and working back in SCOM so if things don't quite work out for you the first time round, you can always delete the resources in Azure and start it again.

In my next post on this topic, I'll walk through configuring Azure alerts for the newly migrated web application tests along with demonstrating how to get visibility of these tests back in SCOM using the latest Azure Management Pack.