Thursday, February 9, 2012

SCOM 2012 - Run Remote Desktop from any alert in the Console

It has been a real busy few weeks for me in work and I've hardly had any time to blog/tweet about System Center 2012 since the middle of January!

Since my last post, I've been working on a mixture of System Center and Hyper-V projects both day and night so a severe lack of sleep distracted me from posting this really neat trick I've worked out to make managing and resolving alerts in SCOM much easier from the console.

The steps outlined in this post although referencing System Center 2012 Operations Manager, will work exactly the same for System Center Operations Manager 2007 R2.

I was working on System Center 2012 Operations Manager (SCOM) yesterday and was tuning out some alerts generated by some new management packs I had deployed when I found myself having to logon to the servers generating the alerts using Remote Desktop quite regularly.

Now, if the alert generated in SCOM is from the 'Windows Server Operating System' management pack, then this management pack comes with some built in 'Tasks' that can be run from the 'Tasks/Actions' menu on the right hand side of the screen.

These tasks can be seen from the Monitoring window below once you have clicked on an alert in the Console that was generated by the Windows Server OS MP

A closer look shows us all of the available tasks that we can run under this context

As we can see from above, one of these Windows Server Operating System Management Pack tasks is the ' Remote Desktop' task

When you click on the 'Remote Desktop' task, it then opens up the RDP application (mstsc.exe) with the computer name of the server that generated the alert in SCOM and all you have to do is click once to connect to the server to carry on your troubleshooting and alert tuning.

Now, this is all well and good if you are troubleshooting an alert that is related to the Windows Server Operating System Management Pack. What if the alert has been generated by another Management Pack? The answer is simple enough - you don't get the Remote Desktop task!!

The screenshots below show an example of the different tasks/actions that come with the SQL Management Pack

The tasks that come with the SQL Management Pack are specific to SQL Server troubleshooting and completely different to the Windows Server Operating System Management Pack tasks. Although the Management Pack specific tasks are really helpful and can assist in resolving most alerts quickly, if I wanted to Remote Desktop to the SQL server generating the alert above, I would either have to initiate an RDP connection myself from the 'Run' command using 'mstsc.exe' or if I wanted to use SCOM to initiate the RDP connection, I'd have to browse to the 'Windows Server' view or the 'Discovered Inventory' view to kick off the connection.

I just found having to carry out these extra steps on a constant basis was getting to be a bit of a pain and I started out looking for a solution to enable the RDP connection from any alert within the SCOM Console irregardless of the Windows Server OS Management Pack.

The solution to this problem is to create our own custom RDP task that will run independently of any management pack but with the same parameters as the 'Windows Server OS MP' RDP task.

To begin creating the new task, open up the System Center 2012 Operations Manager Console and click on the 'Authoring' tab from the wunderbar down the bottom left hand side.

Now click on 'Tasks' on the left hand side and then 'Change Scope' from the middle of the screen and modify the search scope to be just 'Windows Server'

You should see all of the tasks associated with the 'Windows Server Operating System' Management Pack as below

Double click on the 'Remote Desktop' task in the central window and have a look at the pre-defined parameters

Copy the text from the 'Application' line in the window above into a text editor such as Notepad and you should have a line like this:


Note that the 'Parameters' line of the screen above has a specific parameter that defines the 'Microsoft.Windows.Computer' class. There's no point in copying this line to your text editor as it won't work when we go to create our new custom RDP task.

Close the RDP task properties that's open from above and then select the 'Create New Task' option from either the 'Task' menu on the right hand side or by right mouse clicking on the 'Tasks' link on the left hand side.

When the 'Create Task Wizard' opens up, click on the 'New' button to create a new custom unsealed management pack so as to store the new custom task

Input a name and description into the relevant fields for the custom unsealed management pack and then click 'Next'

In the final screen of the 'Create a Management Pack' wizard, click on the 'Create' button and you will then return to the 'Create Task Wizard' screen with your new unsealed management pack selected as a destination as shown below.

Make sure you select the 'Alert Command Line' option under 'Console Tasks' and then click 'Next' to continue

From the screen below, enter a task name such as 'Run Remote Desktop' (try not to name it simply 'Remote Desktop' as you may get mixed up at a later date if you are trying to troubleshoot issues with this task or the original 'Remote Desktop' task from the 'Windows Server OS' MP. Type a description and then click 'Next' to continue

Now, it's at this step that you will run into problems (as I did when I got to this point initially!), if you don't enter in the information exactly as I specify.

In the 'Application' field, copy the text path to your RDP application from your text editor that you had saved earlier and you should have something like:


I ran into problems when trying to find a parameter that would work that could automatically add in the computer name reference that was generating the alert in the SCOM Console once the RDP connection prompt opened up. Thankfully after loads of searching and reading up on SCOM powershell commands, I came up with the 'secret sauce' solution to make this work!!

If you want to run the 'mstsc.exe' application while specifying a server, you need to use the /v:servername switch. However as we won't be entering in a new server name manually each time we fire up an RDP connection, I needed to find the correct reference that SCOM uses and I came across $MonitoringObjectPath$

With the above syntax worked out, all we need to type into the 'Parameters' field is the following:

/v: $MonitoringObjectPath$

The last setting we need to make in the screen above is to de-select the 'Display output when this task is run' option and then click on the 'Create' button to complete the process

Now, if you go back to the 'Monitoring' tab of the SCOM Console and click on any alert, you should now see an additional 'Alert Tasks' menu on the right hand side of the screen with an entry for 'Run Remote Desktop' as the two screens below show.

This new 'Alert Tasks' menu will appear above the specific management pack tasks menu every time you click on an alert. The example above shows the 'SQL' specific tasks along with the new 'Alert Tasks' option and the screen below shows the 'Windows Server 2008 Logical Disk Tasks ' also with the new 'Alert Tasks' option above it.

If the alert that is being generated in the SCOM Console has been generated by a Windows Server with the SCOM agent installed, then your new 'Run Remote Desktop' custom task will run every time making it nice and easy to troubleshoot and keeping all administrative duties within the single SCOM Management Server.


  1. I think using $NetbiosComputerName$ instead of $MonitoringObjectPath$ will work better. It he source of the alert is from a hosted instance then the $MonitoringObjectPath$ will contain the complete path.

    1. hey, so I have the exact problem you described. I have an OpsLogix MP that provides the bridge for our VM's. using $MonitoringObjectPath$ alerts generated from this MP the RDP task does pull the computer name correctly but adds the "Group" it's in to the name ex. "Server01" becomes "Server01;ProductionVM" I attempted your suggestion using $NetbiosComputerName$ but this wouldn't even pull the correct computer name. any other ideas what might work in this situation?