Of utmost concern to enterprise customers (indeed all customers) who are considering deploying their applications to Microsoft Azure is the security of their underlying data. A sometimes overlooked aspect of data protection is assuring that when disk space is freed and reallocated to other customers that those new owners cannot read the data that was there when the space was released. An extreme form of this is when the drives themselves are removed from the data center for disposal or repurposing for other tasks. The most straightforward way to make such a guarantee would be to overwrite the freed space with zeros or some other pattern before freeing it. Such overwrites can significantly impact performance, so Azure (like most systems) uses more complex but more efficient mechanisms.

In this post, we will find practices implemented in Microsoft Azure and SQL Database to prevent the possibility of data leakage or exposure of one customer’s data to another customer upon deletion of a Microsoft Azure virtual machine instance, virtual machine drives, Drives, Storage data, SQL Database data, or a SQL Database instance itself. The mechanisms vary in detail but are all conceptually similar: no user is ever allowed to read a place on the disk that he/she has not previously written.

For a fuller treatment of Data Protection in Microsoft Azure, please see the latest “Protecting Data in Microsoft Azure” whitepaper here.

Concepts on Data Protection

In practice, disks are allocated sparsely. This means that when a virtual disk is created, disk space is not allocated for its entire capacity. Instead, a table is created that maps addresses on the virtual disk to areas on the physical disk and that table is initially empty. The first time a customer writes data on the virtual disk, space on the physical disk is allocated and a pointer to it is placed in the table. We can see this conceptually in the progression of diagrams below:

Figure 1: Data Blocks Allocated to Users

In Figure 1 above, two users each have two data blocks that have been allocated to them on disk based on their respective write requests.

Figure 2: User Frees Up Data Block

In Figure 2 above, one user “deletes” data that frees up a data block. The data block is marked is free, but is otherwise unaffected.

Figure 3: User Allocated Recently Freed Data Block

In Figure 3 above, upon a write request, a new user is allocated a recently freed data block as well as a data block that has not been previously allocated. The previously freed data block is still unaffected. Essentially, the process is that when a user makes a write request to disk it must be determined whether there is already space on an existing data block allocated to that user that can store the new data. If so, then the new data overwrites the data in the existing block. If not, then a new data block is allocated and data is written to the new block. The logic can be seen in the figure below.

Figure 4: User Requests to Write Data to Disk

Now there is the question regarding the possibility of one customer reading the deleted data of another customer, or an Azure administrator reading a customer’s deleted data. If anyone tries to read a region on virtual disk that they have not yet written to, physical space will not have been allocated for that region and thus only zeroes would be returned. So we can see this logic in the figure below, and the result. Only an Azure administrator could read blocks marked as free, and there are no utilities that would help the administrator figure out who the previous owner of the block was.

Figure 5: User Makes Read Request

Conceptually, this applies regardless of the software that keeps track of reads and writes. In the case of SQL Database, it is the SQL Database service that does this enforcement. In the case of Storage, it is the Storage service. In the case of non-durable drives of a VM, it is the VHD handling code of the host OS. Since customer software only addresses virtual disks (the mapping from virtual to physical address takes place outside of the customer VM), there is no way to express a request to read from or write to a physical address that is allocated to a different customer or a physical address that is free.

Note: in some cases, the logic for writes (see Figure 4) is modified in that if a block is written for a second time that data is not overwritten on disk. Instead, a new block is allocated and the data is written there. The old block is then marked as free. This approach is often referred to as a log-based file system. It may sound inefficient, but it allows most data writes to be to consecutive locations on the physical disk, and this minimizes seek times and yields better performance. This detail is transparent to the customer, but it is relevant because it means that even if a customer were to explicitly overwrite every block on the virtual disk with zeros before freeing it, it would not assure that the customer’s data was not still present on the physical disk.

Data Destruction and Leakage Prevention

Data destruction techniques vary depending on the type of data object being destroyed, whether it be whole subscriptions themselves, storage, virtual machines, or databases. In a multi-tenant environment such as Microsoft Azure, careful attention is taken to ensure that one customer’s data is not allowed to either “leak” into another customer’s data, or when a customer deletes data, no other customer (including, in most cases, the customer who once owned the data) can gain access to that deleted data.

Subscriptions

If a subscription has expired or is terminated, all associated customer data (including storage accounts) is held for a period before it is actually deleted in order to recover from accidental subscription cancellation. That suspension period is 90 days. In no more than 180 days after expiration or termination, Microsoft will disable the account and delete customer data. If a storage account is terminated within an existing subscription (or when a subscription deletion has reached its timeout), the storage account is not actually deleted for another two weeks (again, to prevent mistakes). But once a storage account is finally deleted, or when blob or table data is deleted outside the context of a storage account deletion, the sectors on disk become immediately available for reuse. How long before they are actually overwritten varies, depending on the fullness and activity rate on the server, but is rarely more than two days. This is very different from the experience with a file deleted from a file system such as NTFS, where the space could be reallocated immediately, but in practice may linger for months. A property of log-structured file systems is that all unallocated sectors of the disk are overwritten routinely in the course of copying and compressing logs.

NOTE: If you want to make storage data unrecoverable faster, you should delete tables and blobs individually before deleting the storage account or subscription.

Microsoft Azure Storage

As mentioned above, Storage is built on a log-structured file system, where all writes are written sequentially to disk. This can be more efficient than a conventional file system because it minimizes the number of disk “seeks”, though that benefit is paid for somewhat by the need for updating the pointers to objects every time they are written. But the new versions of the pointers are written sequentially to disk as well. Disk reads do remain random access, but the read load can be reduced through judicious use of caching. A side effect of this design is that if there is a secret on disk, you can’t ensure it is gone by overwriting with other data. The original data will remain on the disk and the new value will be written sequentially. Pointers will be updated such that there is no way to find the deleted value anymore.

Once the disk is full, however, the system has to write new logs onto disk space that has been freed up by the deletion of old data. Instead of allocating log files directly from disk sectors, log files are created in a file system running NTFS. A background thread running on Storage nodes frees up space by going through the oldest log file, copying blocks that are still referenced from that oldest log file to the current log file (and updating all pointers as it goes). It then deletes the oldest log file. So there are two categories of free space on the disk: space that NTFS knows is free, where it allocates new log files from this pool; and space within those log files that Azure Storage knows is free since there are no current pointers to it.

Now when a user asks “Is my deleted data still recoverable from the disk?” it could mean one of two different things:

• First, could a clever person with a disk analysis tool—given the correct blob name and offset—find the value the blob originally held? That would be true if the data and pointers are still in the log files.
• Second, could someone looking at the disk track by track find the data, but have no ability to find out who put it there (unless they could figure that out from the content)? That would be true if the space freed by the deleted log file has not yet been allocated to a new log file and overwritten.

This latter category has no fixed expiration date, and is more akin to a “half-life”. After X number of days, there is a 50% chance it is still on the disk; after 2X number of days, there is a 25% chance it is still on disk, and so on. The probability never goes to zero, and there is no guarantee when particular data is gone, but Microsoft assures customers that their data will indeed be protected from unauthorized access.

Microsoft Azure Virtual Machines

Virtual machines are stored in Storage as blobs, so the deletion rules apply as explained above. When a VM is deleted, the space on disk that held the contents of its local virtual disk is marked as free, but is not zeroed. The space will eventually be used to hold data for some other object, but there is no upper bound on the amount of time the obsolete contents may stay there. The virtualization mechanism, however, is designed to ensure that those spots on the disk cannot be read by another customer (or even the same customer) until data is written again, thus ensuring there is no threat of data leakage. When a new virtual disk is created for a VM, it will appear to the VM to be zeroed, but that illusion is created by explicitly zeroing the buffers when a portion of the virtual disk is read before it is written. If a VM instance is reinitialized in place, it’s the same as if it had been moved to new hardware.

Microsoft Azure VM Drives and Azure Drives (“X-Drives”)

There are two kinds of virtual drives that might be accessible to a VM instance in Microsoft Azure. The C:, D:, and E: drives that exist for Web and Worker roles are backed by disks that are local to the compute node. The data on them is not stored redundantly and must be considered ephemeral. In the event of a hardware failure, the VM instance is moved to a different node and the virtual disk contents are reset to their initial values. If a VM instance is reinitialized in place, the C:, D:, and E: drives revert to their initial states, the same as if it had been moved to new hardware.

Drives (aka “X-Drives”) are also implemented as blobs in Storage. X-Drives are persistent and are not reset unless the customer takes some explicit action to replace them. This data is stored redundantly and survives hardware failures. Deleting a VM instance does not cause data to be deleted in an associated X-Drive. An X-Drive is deleted by deleting the blob itself (or by deleting the storage account containing the blob).

Microsoft Azure SQL Database

With SQL Database, deleted data is marked for deletion, but it is not zeroed. If an entire database is deleted, it is the equivalent of deleting its entire contents. The SQL Database implementation is designed to ensure used data is never leaked by disallowing all access to the underlying storage except via the SQL Database API. That API allows users to read, write, and delete data, but does not have any way to express the idea of reading data that the user has not previously written.

Automatic Backup and Forensics

In the common case, customers want assurance that there is no unauthorized access to their data. In some cases, however, they would like assurance that there is not even any authorized access to deleted data. While there is no way through interfaces exposed to customers to retrieve data once it has been deleted or changed, that data may remain on disks for an extended period and it would theoretically be possible to recover it with internal forensic tools (though the likelihood of the deleted data being present would decline over time). Ultimately, any physical disk is either completely erased or destroyed after being removed from the production environment.

We are contemplating possible future features that would allow deleted data to be recovered (and changed data restored) for a limited period of time without customers having to make explicit backups. Using these tools, a customer could not be assured that the data would be for practical purposes inaccessible by authorized parties immediately after it is deleted. Any such tools will be designed to make deleted data retrievable only for a limited period of time less than 30 days unless the customer opted into some longer backup period. As of this writing, there are unexposed tools that may permit recovery of data deleted from SQL Database databases for 14-21 days. There are no such tools for Storage or Compute ephemeral disks.

As with IaaS ACLs, PaaS ACLs allow you to do the following:

• Selectively permit or deny incoming traffic based on remote subnet IPv4 address range to a virtual machine input endpoint
• Blacklist IP addresses
• Create multiple rules per virtual machine endpoint
• Specify up to 50 ACL rules per virtual machine endpoint
• Use rule ordering to ensure the correct set of rules are applied on a given virtual machine endpoint (lowest to highest)
• Specify an ACL for a specific remote subnet IPv4 address

Network (or Endpoint) ACLs are the key to protecting Web or Worker role public endpoints and controlling that type of access to them. So let’s get started learning how to use them. The first task is to install the Azure SDK 2.3 before getting started in Visual Studio 2013. If you don’t have SDK 2.3 installed, you may not have build problems initially, but at some point you will when you try to package or publish your PaaS application unsuccessfully due to schema issues in your Service Configuration file. I got schema errors when I tried to package the project that only went away once I installed SDK 2.3. So make sure you have SDK 2.3 and let’s get started. Create a new test Cloud project in Visual Studio 2013, as seen below.

Go ahead and add a Web role.

Choose whatever project template you would like.  I chose the MVC template below.

So now we have our project created and we’re good to go. Go ahead and build the project.

Let’s first look at the ServiceDefinition.csdef file, as seen below.  By default on a Web role we have an endpoint named “Endpoint1” on port 80.

Go ahead and open up the ServiceConfiguration.Cloud.csfg file, as seen below.  We will add the necessary ACL configuration here.

From here, you will add in the NetworkConfiguration element with the required ACL information within. Note that you would have already used this to deploy a Web or Worker role if it were participating in a Virtual Network. As seen below, we have a section for Access Controls, creating one ACL with two rules, followed by an Endpoint section that maps the newly created ACL to a specific role and endpoint. This is placed after the role(s) in the service configuration.

Let’s take a closer look at the NetworkConfiguration section we added, as seen below:

<NetworkConfiguration>
  < AccessControls>
    < AccessControl name="test">
      <Rule action="permit" description="test" order="100" remoteSubnet="98.189.223.154/32" />
      <Rule action="deny" description="test" order="200" remoteSubnet="0.0.0.0./0" />
    </AccessControl>
  </AccessControls>
  < EndpointAcls>
    < EndpointAcl role="WebRole1" endPoint="Endpoint1" accessControl="test" />
  </EndpointAcls>
< /NetworkConfiguration>

I’m creating an ACL named “test” that will apply to the endpoint we saw above. In that ACL, I have created “permit” and “deny” rules, which will be evaluated by their numerical order. So rule 100 will be evaluated before 200. In the permit rule, I allowed my IP address to access the Web role (note that this must be in CIDR format, so I have to append with a /32 which denotes a subnet range consisting of this one IP address), but in the second deny rule, I’m denying any and all other IP addresses from accessing the Web role (which includes any Azure machines that access the public endpoint). Now look at the EndpointAcls section. You will see that I have first specified our WebRole1 role, our endpoint named “Endpoint1”, and have specified that this combination of Web role and endpoint will use the ACL named “test”. I then publish the project, as seen below. If there are any issues with your rules below, the publishing process will not complete and will let you know what you need to correct.

I now try to access the Web role using the browser from my office IP address, and I am successful.

I now try to access the Web role from a browser in one of my Azure virtual machines, which fails as it should.

Let’s now add a permit rule so this Azure virtual machine can access the Web role as well. Below, I add the permit rule ahead of the deny rule and publish the cloud service again.

We then return to the Azure virtual machine, and as you can see below, it now has access to the web application from the Azure virtual machine.

We’re all done now. I hope you will enjoy this cool new feature!

Now head over to the Azure SQL Database server you would like to secure, select the Configure tab, and then select the No button for Windows Azure Services, as seen below. You will then have to save this change.

In order to test that I no longer have access to the Azure SQL Database server from within the Azure platform, I try to connect to it from SQL Server Manager on the virtual machine that I want to provide access. As you can see below, the connection fails.

Now I head back to the configuration for the Azure SQL Database server and add a rule to the server whitelist using the external VIP address of the desired virtual machine, as seen below.

I now attempt to connect to the Azure SQL Database server and can successfully connect, as seen below.

We’re now done. If only all things in Azure were this easy!

With SCOM 2012, you see the following instead. Where are the individual role instances? Unfortunately, they’re not there any longer based on the operation of the new SCOM 2012 Management Pack for Windows Azure. Yes, I have asked the Program Manager of the management pack team to restore this functionality, so we’ll see how it goes. For now, though, we will have to find an alternate way to create a performance view targeted towards a specific Azure application. We will accomplish this with groups. Groups are an important feature in SCOM in that they provide you the flexibility to create various types of views by grouping together logical collections of objects. You can use groups to secure views by user role, or you can also specify subgroups, or even exclude objects from a given group. Not all groups, however, will necessarily apply to your Windows Azure applications.

So here is our starting point with a Performance view that displays memory performance for all applications within a given subscription.

Click on the Authoring view, and select the Groups node, as seen below. Right-click on the Groups node and select Create a new group… from the popup menu, which will display the Group creation wizard.

On the first page type a name for the application(s) that you want to group together in your Performance view. Select a management pack in which to store this monitor. Select the Next button when done.

On the Choose Members from a List wizard page, select the Add/Remove Objects… button, which will present a dialog for choosing objects that will be the members of this group.

In the dialog, use the filter to find and add the applications you would like to monitor in this Performance view. You can add each to the list box at the bottom using the Add button, as seen below.

Go ahead and skip through the Create a Membership Formula and Choose Optional Subgroups wizard pages until you reach the Specify Exclude List dialog, as seen below. Choose the Create button.

You should now see your group in the list, as below.

Now head back to the Monitoring view, as seen below. Right-click on your Performance view and select the Properties item in the popup menu, as seen below.

In the Properties dkalog, select the ellipsis button (…) under the Show data contained in a specific group: heading.

You will now see a dialog that will allow you to search through objects and select one, as seen below.

Type in a portion of the text of the group you created previously, as seen below. Select your group and then select the OK button.

You’re now back to the original Properties dialog. Select the OK button.

You should now see your Performance view is properly filtered.

We’re all done. See you next time, when we will cover how to filter Event logs.

This will be a long post with all of the steps detailed. Once you get the hang of it, though, you’ll be ready to create management packs on your own with this powerful new authoring tool in no time. So let’s get going. Go ahead and launch Visual Studio 2010. Create a new project and verify that you have the Management Pack templates installed as seen below. If you do, then select the first template titled Operations Manager 2012 Add-on Management Pack, and select OK. The reason you must select this one is because this template corresponds to the SCOM 2012 schema, while the Operations Manager Core template corresponds to the SCOM 2007 schema. If you select Operations Manager Core, you won’t be able to reference the new Management Pack bundle (.MPB) files that are only compatible with SCOM 2012.

Important Note: Before moving ahead, please verify that the Azure deployment you are monitoring with SCOM 2012 is writing out the performance counters that correspond to the rules you will be creating here. You don’t have to create the same rules as I do. Create the rules for the performance counters that you write. We will do a total of four for training and testing purposes, and then you can go back to the project and add more as needed.

Expand the References node, which should look as seen below.

In order for us to create our new rule(s) for Windows Azure subscriptions, we will need references to existing management pack libraries. In my case, I installed Visual Studio 2010 on the management server, so all of the management pack references will be on the server. If you didn’t install VSAE on your Management Server, then you will want to install any references not already included with VSAE into the Program Files (x86)\System Center 2012 Visual Studio Authoring Extensions\References\OM2012 folder. For more info on reference “do’s and don’ts”, see the TechNet article titled “System Center - Visual Studio Authoring Extensions,” which can be found here. For the purposes of this walkthrough, however, the only management pack we will reference that is not already included with VSAE is the Windows Azure management pack for System Center 2012. So if you are not working on a Management Server, go ahead and download the System Center 2012 Management Pack for Windows Azure from here, and then install it on your workstation. It will place the .mpb files in the Program Files (x86)\System Center Management Packs\System Center 2012 Management Pack for Windows Azure folder.

We will need to reference the Windows Azure management pack for SCOM 2012. Right-click the References node and select the Add References from Management Pack Bundle… from the popup menu, as seen below.

Navigate to the Program Files (x86)\System Center Management Packs\System Center 2012 Management Pack for Windows Azure folder, and find the Microsoft.SystemCenter.WindowsAzure.mpb management pack bundle file. Select the Open button.

Select OK when you see the acknowledgement dialog, as seen below.

You should now see the reference to the Windows Azure management pack in the list of references.

Next, we need to add a reference to the Data Warehouse management pack library. Right-click the References node again, and this time select just the Add Reference… item from the popup menu. Navigate to Program Files (x86)\System Center 2012 Visual Studio Authoring Extensions\References\OM2012.

Select the Microsoft.SystemCenter.DataWarehouse.Library.mp, and then select OK.

Now add another reference from the same location to System.Performance.Library.mp, as seen below.

When you’re done, your Solution Explorer should look as seen below.

Now we’re ready to add our first rule. Right-click on the project and select Add | New Item… from the popup menu. In the Add New Item dialog, select the Code node, and then select the Empty Management Pack Fragment template. Provide a name, such as Rules, then, select the Add button.

Your Visual Studio IDE should now look as seen below. Note in the Rules.mpx file that your management pack “fragment” uses schema version 2.0. Note that the reason this file is called a fragment is because it is only a part of the final management pack. The authoring tool will package up all the fragments and crank out a final management pack for you when you perform a build.

Now what we want is to not reinvent the wheel, so we will grab some XML from an existing management pack in order to create our new rule. Select the View menu, and then select the Management Pack Browser item, as seen below.

Once the browser opens, navigate in the left-hand side of the browser pane, expand the Microsoft.SystemCenter.WindowsAzure [1.0.0.0] node, and then select the Rules node. In the middle pane below select an existing rule (e.g., I have selected the Available Megabytes Performance Counter rule). We are going to grab the XML from an existing rule to create our new rule, which makes our job a lot easier.

Select and copy all of the XML text in the lower middle pane, as seen below.

Now let’s head back to our Rules.mpx file and prepare it for the rule XML we just grabbed. Add the lines as seen below in preparation for the pasting of our rule XML.

Now drop in your rule, as seen below, which we will modify for our own custom rule not included in the out-of-the-box Windows Azure management pack.

Now it is time to setup our aliases so our management pack code matches up with our references. Select the Microsoft.SystemCenter.WindowsAzure reference in the Solution Explorer, and then show the Properties page. As seen below, the default is MSW. We’re going to change this alias to Azure.

Go ahead and change the Alias property in the property page of Microsoft.SystemCenter.WindowsAzure to Azure. In the Rules.mpx file, prepend the TypeID attribute consisting of Microsoft.SystemCenter.WindowsAzure.RoleInstance.PerformanceCounter.CollectionData.DS with Azure followed by the delimiter !, exactly as seen below on Line 7. Don’t forget the delimiter!

Now scroll to the right on Line 4 and do the same with the Target attribute, as seen below.

Now select the Microsoft.SystemCenter.DataWarehouse reference, whose default alias is MSDL, as seen below.

Change the Alias property to SCDW, which will match up with what’s already in the Windows Azure management pack that we copied from.

Select the Microsoft.SystemCenter.Library reference, and verify that its Alias property matches up with the existing alias in our Rules file, as seen below.

Now let’s go ahead and change the existing rule to a different performance counter. As seen below, I’m changing the performance counter to Memory\Committed Bytes. Feel free to use whatever valid performance counter you would like that is being written by your Azure deployment(s).

Let’s now perform our first build. Resolve any issues and don’t move forward until you can successfully build. If you have followed all of the instructions to the letter, your build should be successful.

Build success, as seen below!

Now we need to create the display strings that we will see as the name in the Authoring view of the SCOM Operations Console. Go ahead and add a LanguagePacks (plural) element as seen below, after the Monitoring element.

Now head over to the Management Pack Browser and navigate to the Windows Azure management pack library LanguagePacks node, as seen below. Copy the first line with the LanguagePack (singular) opening element.

Now add the opening LanguagePack element and then add the closing element. Then add the DisplayStrings element, exactly as seen below.

Now head back over to the Management Pack Browser, and copy all of the LanguagePacks element of the Windows Azure management pack library, as seen below.

Open Notepad and copy the text into Notepad. Perform a a search in Notepad on “roleinstance.memory”, which should take you to the display string for the Available Memory performance counter. Copy the entire element, as seen below.

Now paste the display string into your rule as seen below. Note the three values you need to change to the Committed Bytes performance counter.

Next, make the three replacements, as seen below.

Go ahead and perform a build before proceeding.

We can always add more rules to our Rules.mpx file, but there is a better way. Now we will pursue a more automated way to crank out new rules using a template. Right-click on the project and add a new item. Select the Code node under the Management Pack templates, and then select the Snippet Template, as seen below, which has a templatesnippet file extension. Give it a name such as AzureRules and select the Add button.

Now, you will see that it has created a rule template for you, but this isn’t useful to you since it doesn’t use the Windows Azure data sources.

Go ahead and delete the rule in the template snippet, substituting it with the rule you created earlier in the Rules.mpx file, which is seen below.

Now remove the entire existing DisplayString element in the template snippet, and replace it with the DisplayString element from the rule you created earlier, which is seen below.

Your rule template should now look as seen below after grabbing the rule and its display string from the Rules.mpx file.

Now we will insert the variables needed for when we apply the template to create multiple rules from a wizard page (which we will see later, so be patient). Delete the object name in the rule ID attribute as seen below. Place your cursor where you deleted the object name and type Ctrl-<Space>. You will be presented with a popup with substitution options. Select the #text item from the popup menu.

The text variable won’t have a variable value in it, so you will have to provide that value. Type in ObjectName, as seen below.

Now do the same for the short counter name, substituting the text variable with CounterShortName, as seen below.

Within the DataSource element, navigate to the <CounterName> element, and delete the value. Use Ctrl-<Space> to substitute this with a #text variable as well. In this case, substitute with the variable CounterLongName.

Next, substitute the <ObjectName> element value immediately below with a #text variable named ObjectName.

Now scroll the windows over until you see the Target attribute of the rule. Highlight the “Azure” value, as seen below.

Use Ctrl-<Space> to substitute the “Azure” value with a #alias variable as seen below. Insert the value Microsoft.SystemCenter.WindowsAzure, as seen below.

Now find the <DataSource> element, and find the “Azure” value of the TypeID attribute, as seen below.

Substitute the “Azure” value with the value Microsoft.SystemCenter.WindowsAzure, as seen below.

In the <DisplayString> element, find the object and counter values and substitute just as you did for the rule above. You can see the two substitutions below.

Now in the <Name> element, make the necessary substitutions as seen below, and also make the substitutions for the <Description> element as well. You can see the substitutions below.

Go ahead and perform a build. Do not continue until you have a successful build.

Now we’re ready for the wizard page that leverages the template snippet and allows us to crank out rules by simply putting in the desired values. Right-click on the project and add a new item. This time select the Templates node in the Management Pack templates, and then select the Snippet item, as seen below. Provide a name such as AzureRuleGenerator, and then select the Add button.

You will now see a page that asks you to select a snippet type. Click on the button, as seen below.

Go ahead and choose the template snippet you just created, as seen below.

Now enter the values for the new performance counter rules you would like, as seen below. Unfortunately, you will have to enter the values for each time you created a variable, but it will autocomplete so you won’t have to type them again. My understanding is that this will be fixed in a future version so you only have to type a variable once.

When you’re done, just save the page, and the rules will be generated. You can always go back and make changes as well as add new rules. You can even import from a .csv file.

Now locate the rule generator in the Solution Explorer, which has a .mpsd extension. Expand it to find the generated file that has a .mpx extension (which is the same fragment extension as the rule you created manually earlier), and go ahead and open up the .mpx file. You can see below that it has written out all of the rules for you in the file with text and aliases appropriately substituted! When the final management pack is generated, your project will put all of these pieces together into a nice, neat management pack.

Let’s now scroll over and verify that the <Rule> element alias has been successfully substituted as well.

Scroll down to the <LanguagePacks> section, and you will see the display strings are generated as well. Very cool.

Perform a build now, and do not proceed until you have a successful build. We’re getting close to being done, but there is still a bit more work to do.

Now we’re going to create a display name and description for the entire management pack. Right-click on the project and open the properties page, as seen below. Select the link at the bottom titled Find or Create the Management Pack Display Name and Description. It will create a ManagementPack.mpx file and will open the file.

Below is the file Visual Studio just opened with the display strings for the management pack itself, which you can modify.

Below, I have modified the management pack display strings with more descriptive values.

Below, I added two additional elements. The <Presentation> element creates a folder in the SCOM Operations Console Monitoring view for you to use as a container for your management pack objects (such as performance views). We will create a performance view later using the rules we have created. The <DisplayString> element actually adds the text that will be the displayed name of the folder created above in the fragment file.

Below shows the file scrolled over showing what the ParentFolder attribute should look like. After you have finished, go ahead and build your project. Don’t proceed until you have a successful build.

We’re now all done and ready to test drive the management pack!  Navigate to the bin\Debug folder of your project, as seen below. You will import the XML file as we’re not taking advantage of the features of the management pack bundle that was generated.

Go ahead and import the management pack into SCOM 2012, as seen below.

After a few minutes, verify that the management pack now shows up in the management pack list in the Administration view.

Next, head over to the Authoring view and navigate to the Rules node. In the right-hand pane, navigate to the Windows Azure Role Instance item as seen below.

By default, your rules will not be enabled, so right-click on each rule and select Enable from the popup menu.

Now we need to create a performance view to see the results of our new rules. Go to the Monitoring view, and select the folder we created in the authoring tool.

Right-click on the management pack folder. Select New | Performance View, as seen below.

Since in this blog we created Memory and TCPv4 performance objects, enter one of these headings in the name. Then select the button with the ellipsis (“…”) next to the Show data related to: field. In the Select Items to Target dialog, select the View all targets radio button, and then enter a search field such as “role instance”, as seen below. Find the Windows Azure Role Instance item in the list below, and then select the OK button.

Now select the collected by specific rules item in the Select conditions: listbox, as seen below. Next, select the specific link at the bottom of the dialog.

Find the desired rule(s), as seen below that match up with your heading (note that I’m selecting one of the Memory rules that I created). Once you have selected the desired rule(s), select the OK button.

You will now see your rule(s) at the bottom of the dialog. Accept the dialog.

It may take a while, but you should eventually see the list of performance counters that correspond to your rule(s). It is important to note that your deployment must be actually writing these performance counters, so if you don’t see anything after a few minutes, verify that the counters are being written.

Whew! We’re now done! See you again soon for some other System Center 2012 coolness we will be blogging about.

Our walkthrough scenario will look something like the below diagram when we are done. Note that this is slightly modified from the Windows Azure Load Balancing Virtual Machines documentation page, adding Virtual Network to the diagram.

So let’s now begin. From the Windows Azure management portal, select the enormous “+ NEW” button in the lower left hand corner of the portal, and navigate to the creation of a virtual machine as seen below.

From the create a virtual machine wizard, select the image you would like.

Provide a virtual machine name and fill in the remaining values, as seen below.

Now, on the Virtual machine mode page, leave the Stand-alone Virtual Machine radio button checked. Enter a DNS name for your load balanced machines, select the storage account to contain your virtual machine, and then select the virtual network you would like this virtual machine to participate in.

Your portal should look as seen below when you’re done.

Finally, choose an availability set if desired.

Now walk through the steps above again for a new virtual machine, providing a virtual machine name on the Virtual machine configuration page that complements the one created previously.

On the Virtual machine mode page, select the Connect to an Existing Virtual Machine radio button. Select the virtual machine you created previously in the dropdown immediately below. The virtual network dropdown, even though it is grayed, will change on its own to the virtual network associated with the virtual machine you created previously. Go ahead and complete the wizard as before.

Now that you have created the virtual machines, let’s setup the load balanced endpoints for each. Select your first virtual machine in the first column as seen below so that it will take you to its details page.

Select the Endpoints tab, as seen below, and then select the Add button, which will start the endpoint wizard.

Leave the default Add Endpoint radio button selected on the first wizard page, as seen below.

On the next page, provide a name for the endpoint and input your public as well as private ports. As an example, since I’m setting up web servers, both of my ports will be port 80.

When you’re done, you will shortly see a newly configured endpoint.

Now head back to the virtual machines page, and select the first column of the second virtual machine, which will take you to the details page.

As before, select the Endpoints tab, and add an endpoint. On the Add Endpoint page, as seen below, select the Load-balance Traffic on an Existing Endpoint. From the dropdown, select the endpoint name you previously created (which will be appended with the port number).

On the next page, provide a name for the endpoint, and select the checkmark to finish the wizard.

After a short while, your endpoint will be created. Verify that under the Load Balanced column, the value is “Yes.” If you go to the first virtual machine we created and inspect its endpoints page, you will see that its Load Balanced column has changed to “Yes.”

Let’s verify that everything is setup properly now. Navigate to the Cloud Services pane from the left-hand navigation. You should see a cloud service with the DNS name you specified when you created the first load balanced virtual machine. Select the first column of the cloud service to go to the details page.

Select the Instances tab for your cloud service, as seen below. You should see your two virtual machines you just created.

Now let’s verify that the virtual machines are contained within the selected virtual network. Select the Networks pane from the left-hand navigation.

You should see your virtual machines under the Dashboard tab.

You’re now done. You can go ahead and add additional load balanced endpoints if needed.

Let’s go to the Virtual Machines page and locate your virtual machine, as seen below. Select the arrow, which takes you to the detail page for the virtual machine.

The virtual machine detail page should land on the Dashboard tab. Note the OS disk name on the lower part of the page, as seen below. You will need this name when you attach the disk to the new virtual machine we will create.

Now, return to the virtual machines instances page, as seen below. Select the virtual machine you would like to delete (to the right of the name so you won’t go to the detail page), and then select the Delete button on the lower toolbar. This will not delete the underlying disk of the virtual machine, which we will see in just a moment.

Once you receive verification in the status bar that the virtual machine has been deleted, select the Disks tab, as seen below. Locate the virtual machine disk name that you noted earlier, and verify that it no longer has a value in the Attached To column.

We are almost ready to create the new virtual machine, but you must now wait several minutes before attempting to reuse the disk, as putting it back in the disk pool takes some time to process. On the bottom left-hand corner, select the “+ NEW” button, then Compute | Virtual Machine | From Gallery, as seen below.

You will now see the Create a Virtual Machine wizard. Select the “MY DISKS” tab to the left. If you do not see your disk, then you need to exit the wizard and wait a few more minutes. Once you do see the disk, select it and go to the next page.

On the Virtual machine configuration page, give the virtual machine the same name as before, or another name if you so desire. Go to the next page.

On the Virtual machine mode page, provide a unique DNS name, as you will not be able to use the previous DNS name since it is still marked as in use. In the Region/Affinity Group/Virtual Network dropdown, select the desired Virtual Network that you would like to move your virtual machine to.

On the Virtual machine options page, select an availability set or create a new one as desired. Select the final check mark to complete virtual machine creation.

Once the virtual machine has been created, go to your Virtual Network and verify in the dashboard that your virtual machine is there, as seen below. I have moved my virtual machine named w2k8-02 from p2stest to scomp2stest successfully.

And there you have your Virtual Machine now moved to another Virtual Network. See you again soon!

• Discovers Windows Azure Cloud services.
• Provides status of each role instance.
• Collects and monitors performance information per role instance.
• Collects and monitors Windows events per role instance
• Collects and monitors the .NET Framework trace messages from each role instance.
• Grooms performance, event, and the .NET Framework trace data from Windows Azure storage.
• Changes the number of role instances.
• Discovers Windows Azure Virtual Machines
• Provides status of each role instance of the Virtual Machine
• Discovers Windows Azure Storage
• Monitors availability and size of each Storage and optionally alerts
• Discover relationships between discovered Azure resources, to see which other resources a particular Azure resource uses. This information is then displayed in a topology dashboard
• Monitors management and cloud service certificates and alerts if the certificates are about to expire
• Includes a new Distributed Application template that lets you create distributed applications that span Azure as well as on-premise resources, for Hybrid monitoring scenarios.
• Includes a set of dashboards for the Hybrid monitoring scenarios

In this post, I will provide a quick walkthrough of my experience getting the new management pack up and running. It is impressive, and the product group has promised improvements going forward. So let’s get started.

After you download the management pack install, which is a .msi file, you will have to run it so it can extract the two management packs, and write them to your file system. Note that the extensions are .mpb and not .mp, and thus are only compatible with SCOM 2012. Recall that management packs have historically been single XML files either in an .xml format or in a binary format with a .mp extension. The new format, which can consist of multiple XML files has a .mpb extension which means “management pack bundle.” Note the path to the management packs which you will need when you import the management packs into SCOM 2012, as seen below.

Launch the SCOM 2012 Operations Console and select the Administration view. Navigate to the Management Packs node and select the Import Management Packs item from the popup menu, as seen below.

You will now see the Import Management Packs dialog. Select the Add button, which will drop down two selections. Choose the Add from disk… option, as seen below. When you are prompted to search the online catalog, then select the No button.

Locate the management pack bundles and select both, as seen below.

Once the import is done for the two management packs, click the Close button.

In the Search box at the top of the management pack list, enter “azure” and select the Find Now button. It may take a couple of minutes but you should eventually see two management packs:

• Microsoft.SystemCenter.WindowsAzure.Dashboard
• Windows Azure

Verify that the management packs are there, as seen below.

In the old management pack, you head straight to the monitoring wizard, but the new and improved pack works on a subscription boundary so it can discover all of the Azure resources that exist in the subscription. Still, you must select from the available resources the specific resources that you want to monitor. Let’s navigate to the bottom of the Administration explorer view and locate the Windows Azure node. Select the Add subscription link, as seen below.

You will now be presented with a wizard to configure your Azure subscription. Supply the Subscription GUID, the private key of the management certificate that you have uploaded to the management portal, and the certificate password. I’m presuming you have already installed the private key in your Personal and Trusted Root Certification Authorities certificate stores. If not, please see the instructions in my previous post for SCOM 2007 here. The instructions are pretty much identical, and you will also need to follow the procedure to setup your Run As accounts.

In the next page, you will choose the Proxy Agent, which will be this SCOM server. Select the Browse… button, which will launch the Search dialog.

In the Search dialog, select the Search button, and then select your server in the Available items results list. Click the OK button when you’re done.

Now back at the Proxy Agent page, select the Add subscription button.

You will see a warning dialog, as seen below. Allow Operations Manager to distribute the accounts by selecting the Yes button. In this case, the accounts will be distributed to the SCOM server.

You’re now done and can select the Finish button.

Now you’re back at the Windows Azure configuration page, as seen below. We’re all set now to see what SCOM has discovered in your subscription.

Select the Monitoring view in the lower left-hand corner, and then navigate to the Discovered Cloud Services node in the Azure Resource Inventory folder. Your discovered cloud services view should look similar to below. Note that you will have to wait a few minutes for discovery to take place for your subscription. All items in the list will have a “Not monitored” state, which is what we should expect since we have to specifically select what we want to be monitored amongst the resources that have been discovered by SCOM. That is a very nice touch with the new management pack because from the beginning it is conserving resources, allowing you to select what you desire to actively monitor.

Now before we can select what we will monitor, we need to create our own management pack to store information on the resources we decide to monitor. Return to the Administration view, navigate to the Management Packs node and right-click on the node. Select the Create Management Pack item from the popup menu, as seen below.

In the Create a Management Pack wizard, specify the name of your management pack, and provide a version number if so desired, as seen below. Select the Next button.

On the next page of the wizard, select the Create button. Your management pack will now be created.

After a couple of minutes, verify your management pack has been added to the list, as seen below.

Now we can begin monitoring specific resources in your subscription.  Select the Authoring view, and navigate to the Windows Azure Monitoring node. Right-click on the node and select the Add Monitoring Wizard… item from the popup menu, as seen below.

In the Add Monitoring Wizard, select Windows Azure Monitoring as the monitoring type (yes, it is redundant because that is the very reason you right-clicked on the explorer node previously), and select the Next button.

On the General Properties page, note that this is different from the SCOM 2007 R2 management pack. This does not map to a specific cloud service, but can be a combination of things you want to monitor with this particular management pack object. It could be any collection of cloud services, virtual machines, or storage, and can be in any combination of staging or production slots. So provide a name appropriate to what you would like to monitor in this monitoring object. Also, select the management pack you created since you will be putting all of your management objects in your own management pack and not the sealed Windows Azure management pack. When you’re done, select the Next button.

On the next Subscription page, select your subscription you previously configured, as seen below. Select the Next button.

On the Cloud Services page, select the Add button to add your desired cloud services that you want to monitor in this subscription. You will be presented with a Search page.

Run the search based on the desired criteria. From the available services list, add each to the lower selected services list, as seen below. Select the OK button.

You’re now back to the Cloud Services page, where you will see the cloud services you selected. Select the Next button.

On the Virtual machines page, you can now select the IaaS Virtual Machines that you have created in your subscription. In the same manner as you selected the cloud services, select your virtual machines.

When you’re done, you will be back to the Virtual machines page. Select the Next button to continue.

You will now be on the Storage page. In the same manner as you selected cloud services, select the Azure Storage that you would like to monitor. When you’re done, select the Next button.

Finally, you are brought to the Summary page where you can review the objects you have selected for monitoring in your subscription, as seen below. Select the Create button to proceed.

You will subsequently see your new monitoring object has been created, as seen below.

Let’s now return to the Monitoring view. Navigate to the Cloud Service State node under the Monitored Azure Resources folder. You will see here the cloud services you have selected for monitoring. Note that we came here instead of the Discovered Cloud Services node because this node is in the folder that only presents the monitored Azure resources we previously selected. The Discovered Cloud Services will simply display everything that has been discovered.

If we head back to the Discovered Cloud Services node, we will see all of the discovered cloud services. Note that just as above, I have three cloud services that are now being monitored, but two have a critical state. Let’s investigate the cause of the critical state.

Right-click on one of the critical state items, select Open in the popup menu, and then select Health Explorer for <cloud_service_name> in the secondary popup menu.

You will now see the Health Explorer, which can provide specific details regarding where you may have problems with a given object you are monitoring. By default, the view is scoped to unhealthy child monitors (note the scoping in the yellow section immediately above the Health Explorer nodes), and we can see at the bottom of the explorer that it has found my expired certificate which caused it to go into a critical state soon after the object was first monitored.

If  I go ahead and delete the scope to unhealthy child monitors by selecting the “x” next to “Scope is only unhealthy child monitors,” we find even more information on the cloud service, as seen below. Let’s go ahead and close the Health Explorer and go back to the Operations Console (this is a separate window, so closing it won’t close the Operations Console).

Another way to find out the problem is to check the alerts.  Let’s navigate to the Active Alerts node under the Windows Azure folder, as seen below. Notice that the alert tells us the service certificate for this hosted (cloud) service will expire soon. This is a great new feature of the SCOM 2012 SP1 Azure management pack! All I have to do is update the service certificate and my cloud service state will turn back to green. Impressive!

Let’s now navigate to the Storage State node under the Monitored Azure Resources folder. Note that we have a healthy storage account.

Finally, let’s navigate to the Virtual Machine State node under the Monitored Azure Resources folder. Note that we are monitoring healthy virtual machines. One thing to note here is that the management pack does not look at any resources running on the virtual machines such as SQL Server or IIS. This is purely for the overall health of the server itself, and not any installed features or server programs running on the server. If you want that functionality, you will have add these servers to a Virtual Network so that you have IP-level connectivity and can monitor them just as you would an on-premises server. That would also mean adding the appropriate service packs for programs you would like to monitor such as SQL Server 2008/2012 or IIS.

Let’s now go to the Health Explorer for one of the virtual machines, and clear the scope for only unhealthy child monitors. When we expand the Performance node, notice that there are two performance counter monitors. Unfortunately, this is a bug and these monitors should not have been enabled. I know, what a disappointment and I have no idea what it actually is monitoring but I’m trying to find out and will report back when I do. What is working here is the Availability monitor, even though the Performance monitors are not.

It’s not like this can’t be done because MetricsHub (an Azure-based Azure application monitoring and cost-optimization solution recently acquired by Microsoft) does it by providing an agent that you have to manually install on the virtual machine. The agent provides a secure, encrypted public service endpoint that allows MetricsHub to read the performance counters, displaying CPU, Network (Received/Sent), Memory, and Disk (Free Space/Read/Write) performance counters by default in its portal. SCOM can already distribute its own agent to on-premises servers, and to virtual machines that participate in an Azure virtual network and have a VPN connection established.  The VPN connection established from on-premises to a virtual network makes IP-level connectivity to servers in the virtual network seamless. So there is no reason SCOM can’t adopt the same model as MetricsHub for virtual machines that don’t participate in a virtual network coupled with VPN. Until SCOM provides this functionality by providing an agent and updating the management pack to call the agent, you may want to take a look at MetricsHub to augment your monitoring of Azure applications and virtual machines. Out of the box, MetricsHub can display the following counters (the bold ones map to those mentioned above):

• LogicalDisk\% Free Space
• LogicalDisk\Disk Read Bytes/Sec
• LogicalDisk\Disk Write Bytes/Sec
• Memory\% Physical Memory
• NetworkInterface\Bytes Received/sec
• NetworkInterface\Bytes Sent/sec
• Process\% Processor Time
• Process\IO Read Bytes/sec
• Process\IO Write Bytes/sec
• Process\Working Set – Private
• Processor\% Processor Time

I won’t walk through the setup of MetricsHub because it is pretty easy to setup. You will have to go the Windows Azure Store in the management portal to add it, and the best thing is it is currently free. Below in the MetricsHub portal you see a virtual machine that has not yet been configured for monitoring by MetricsHub. You can select the link to download the Agent that must be installed on the virtual machine, as seen below.

After you click the button to install the Agent, you will be provided with instructions to download the MetricsHub Agent and get it installed on your virtual machine, as seen below.

About 30 minutes after installing the Agent, voila! You now have actual, working performance counters for your virtual machine. Some of these performance counters are the same as those presented in the Azure management portal, but you get those and even more from MetricsHub.

If you want to add additional counters to the display, select the Create Chart… button on the same page and you will be presented with a dialog that allows you to select the other available out-of-box performance counters.

If you want to add additional counters, there is a configuration file named MetricsHub.Diagnostics.Monitor.exe.config provided with the agent that has all of the out-of-box counters, so you can use these as templates to add any valid performance counters you wish. Below is a screen shot of section in the configuration file for setting up performance counters.

That ends our walkthrough for now, but we will be looking into finding more information on the new management pack. Stay tuned for much more to come on SCOM 2012 SP1 and Azure. We’re just getting started!

By default, there is already an “out of the box” monitor at the Windows Azure role level which you will find in the Monitors view of the Authoring pane. Navigate to Windows Azure Role | Entity Health | Availability, as seen below. There you will find the monitor titled Role Instance Availability Dependency. Right-click on this item and select the Properties page.

On the Properties page, choose the Alerting tab, where you can verify that by default the alerts are being generated for this monitor, as seen below.

Now if you want to create an individual monitor at the role instance level (whether for all role instances or for individual hosted services) then you can override the out of the box monitor already at that level, which doesn’t generate alerts by default. For our example, we will navigate to the general Windows Azure Role Instance for a specific hosted service, as seen below.

Right-click on the Windows Azure Role Instance Status Monitor item and select the Properties page. If you don’t see it, scroll down to the Generates Alert parameter name, as seen below. Change the Override Value to “True.”

Next, if you don’t see the Enforced column, scroll horizontally until you see it and select Enforced for this monitor, as seen below. When you’re done, select the Apply button, and then select the OK button.

Let’s now right-click on the monitor you just modified, and from the flyout menu select Overrides | Override the Monitor | For all objects of class: Windows Azure Role Instance (your_hosted_service_name).

You will now see the override you just created, as seen below. Go ahead and select the Close button.

We will now go to the Windows Azure management portal and stop the service we desire to test, as seen below.

When we return to the SCOM console and select the Hosted Service State node for our management pack, after a few minutes the service state will change to critical, as seen below.

Shortly after the state change, alerts will show up in the Active Alerts view, as seen below.

If we now select an alert with the name Windows Azure role is not running, we can see that this alert was generated at the level of Windows Azure role, as seen below.

If our role instance level override was setup properly, we should also see a similar alert with the name Microsoft.SystemCenter.Azure.RoleInstance.Status.Monitor. This is the alert we previously (and successfully) configured, as seen below.

In this post, we will create a simple unit monitor based on a performance counter to determine if any role instance of a Windows Azure application has CPU utilization above a specified threshold. If so, it will generate an alert. The idea is to simply respond to specific conditions met by a performance metric using a Unit Monitor. Since SCOM has no knowledge of Windows Azure data sources, we will have to leverage the Authoring Console so we can properly set our data source and then create the monitor. In this post, we will create our own unit monitor that will generate an alert if we have three consecutive samples of processor utilization above 80%. Alternatively, we could simply modify the existing Total CPU Utilization Percentage monitor by overriding the existing processor utilization threshold and adding a diagnostic or recovery task. But for learning purposes this exercise shows you how to do it yourself.

Below you will see that we have the Authoring Console running, and have loaded our management pack previously exported from the Operations Console. For your reference, here are some probable locations of the references the Authoring Console will most likely ask you to resolve before it loads your management pack:

• Microsoft.SqlServer.SqlAzure: C:\Program Files\System Center Operations Manager 2007
• Microsoft.SystemCenter.WebApplication.Library: C:\Program Files (x86)\System Center 2007 R2 Hotfix Utility\KB2495674\ManagementPacks
• Microsoft.SystemCenter.Azure: C:\Program Files (x86)\System Center Management Packs\Monitoring Pack For Windows Azure Applications

In the Health Model view, select the Monitors node, as seen below.

Expand the Windows Azure Role Instance node in the Monitors pane, and then the Performance node, which will have the two out of box monitors listed, as seen below (you will also see two below that I have already added). The out of box monitors are disabled by default (and thus you will see the icons are grayed), but you can enable them by using an override in the Operations Console. Go ahead and right-click on the Performance node, and then select New | Custom Unit Monitor… from the popup menu.

Now you will be asked to give the monitor a unique identifier, as seen below.

You will next see the configuration dialog with the General tab presented. It is already setup with the ID, Target, and Parent Monitor. So just provide a name and description as seen below.

Select the Configuration tab, as seen below. Before you can proceed, you must select a unit monitor type. Select the Browse for a type… link as seen below.

You will now see a dialog that allows you to select your unit monitor type, but you must first narrow your choices down to the unit monitor types in the Windows Azure management pack. So just type “azure” in the Look for: textbox. Your choices for unit monitor types are:

1. Windows Azure Event Log Simple Monitor Type
2. Windows Azure Performance Counter Simple Monitor Type
3. Windows Azure Role Instance Status Monitor Type

Select the second of the three listed above, as seen below. Then click the OK button.

You will now see the desired configuration, where you will need to enter the appropriate values. Enter the values below, but don’t hit the OK button yet because we need to add additional values manually.

• Interval Seconds: 300
• Timeout Seconds: 120
• CounterName: % Processor Time
• ObjectName: Processor
• Threshold: 80
• Direction: greater
• NumSamples: 3

Now you need to select the Edit… button so we can add additional important configuration parameters, namely InstanceName and AllInstances. Be precise as below, or the editor won’t like it when you try to save the configuration. Save the configuration from the File menu and close the editor.

Now we have our final configuration, as seen below. Let’s next select the Health tab.

On the Health tab, enter your desired text in the Operational State fields. Select Critical for the condition True health state, and select Healthy for the condition False health state, as seen below.

Next, we want to setup our alert. Select the “Generate alerts for this monitor” checkbox. Choose “The monitor is in a critical health state” from the dropdown box below. Leave the “Automatically resolve the alert when the monitor returns to a healthy state” checkbox checked. In the Alert name textbox, enter text indicative of the alert. Leave the Priority and Severity dropdowns as they are. Now, select the ellipsis next to the Alert description textbox, which will display the Alert Description dialog.

In the Alert Description dialog, clear out the existing text. From the Data button, select the Value item in the flyout menu. This will then insert the $Data/Context/Value$ parameter in the text box. This value will provide the number of samples, but you also want the sample value which represents the processor percentage. That actually is $Data/Context/SampleValue$, but it isn’t in the flyout menu. What I did was to just cheat and grab the text from the out of box CPU Utilization Percentage monitor, which is as follows:

The threshold for the Processor\% Processor Time\_Total performance counter has been exceeded for $Data/Context/Value$ samples with last value that exceeded the threshold being $Data/Context/SampleValue$.

For a great list of variables, please see Kevin Holman’s blog here, where he indicates the difference between the Value and SampleValue variables we are working with. Another great place to check out for variables is Ben Oostdam’s blog here. When you’re done, select the OK button.

Your dialog should now look similar to below.

Finally, select the Options tab so this will be properly categorized when you setup notifications. Select the PerformanceHealth radio button. When you’re done, select the OK button.

You should now see your unit monitor as below, and you’re ready to export the management pack to your management group. We have covered this in other blogs, so I won’t show how to do it here.

You can see how to setup notifications in the Operations Console based on alerts in my SCOM 2007 R2 Event Log Alerting and Monitoring for Azure Applications blog post. Look for the Setting up Notifications in SCOM section.