You are browsing the archive for Uncategorized.

Disabling or modifying controls in existing SCSM forms

10:52 pm in Uncategorized by Jan Van Meirvenne

In this post, I explain how we can use the existing techniques of adding controls to an existing form to also modify exiting ones.

Make any configuration- or work-item multi-tenant aware by adding extra fields

11:30 pm in Uncategorized by Jan Van Meirvenne

In the previous post I talked about the basic idea of setting up SCSM as a multi-tenant platform in your organization.

This post will show you how to make any CI/WI multi-tenant aware by adding custom list-fields.

Setting up SCSM in a multi-tenant environment

1:32 am in Uncategorized by Jan Van Meirvenne

This is the first post in a series about how to setup and extend SCSM to make it shine in an environment where multi-tenancy is required.

Full article here

Beware of the Service Manager SMLETS’ SMDefaultComputer variable

12:09 am in Uncategorized by Jan Van Meirvenne

During a SCSM migration, I encountered some issues when moving data with the smlets module.

All information here:

Store Bitlocker Information in Azure AD without needing InstantGo

12:08 am in Uncategorized by Jan Van Meirvenne

I found a workaround to the scenario where AAD-joined devices without InstantGo do not store their Bitlocker info in AAD. Read about it here:

The SCSM Webhook Activity

11:56 pm in Uncategorized by Jan Van Meirvenne

I build a webhook activity for Service Manager that allows you to connect your service request process to the cloud!

Read all about it here:

Copy subscriptions across management groups

10:06 pm in Uncategorized by Jan Van Meirvenne

It is common to have multiple SCOM management groups in an organization. For example a test MG to stage changes and a production one for day-to-day operations. If your monitoring processes rely heavily on SCOM subscriptions (for automation with command channels, or just mail for example), it might be tedious to keep them in sync across all the different management groups. Creating or copying subscriptions by GUI is click-intensive and prone to error. By automating this part of the monitoring process, it can greatly speed-up and simplify things.

A customer of mine relies on subscriptions for integration with other systems. Per monitored service, a subscription exists that passes all relevant service alerts through an executable that performed a part of the integration. Just like the service monitoring itself, the subscription is created in a test environment, validated and then copied to production. The script I am showcasing has limited (only single-channel mail- or command channel based subscriptions are supported) but worry-free capabilities for quickly copying a subscription. This is done by passing the to-copy subscription’s displayname, a management server for the source management group and one for the target management group. For now, you need to run the script with an account that has administrator rights in both locations. A nice feature is that if the source subscription already exists in the target MG, it will only sync the configuration without fully deleting or recreating it!

Check it out on GitHub

I hope it can be of use!

Jan out

Add a SCOM runas-account with a space in the username (pre-R2)

8:42 pm in Uncategorized by Jan Van Meirvenne


Although it rarely occurs it is sometimes necessary to work with a runas-credential that contains a space in the username (eg a web-service authentication). In pre 2012 R2 environments, spaces are apparently not allowed in the username when entering it through the SCOM console GUI.

Lukcily, the PowerShell interface does not contains such restrictions, and if upgrading to R2 is not an option, you can use the following set of commands to create and distribute a runas-account that contains spaces:

# setup variables
$user = ‘user with spaces’
$pass = ‘mypassword’
$scomserver = ‘scom01′

# create a PS credential from the user/password variables 
$securepass = $pass|ConvertTo-SecureString -AsPlainText -force
$cred = new-object System.Management.Automation.PSCredential ($user,$securepass)

# Connect to the SCOM environment
Import-Module operationsmanager
New-SCOMManagementGroupConnection $scomserver

# Retrieve the agents, management servers or pools to distribute the account to (can be an array of a combination of these object types, use Get-SCOMAgent, Get-SCOMManagementServer or Get-SCOMResourcePool to populate)
$pool = Get-SCOMResourcePool

# create a simple (or basic) runas-account using the PS credential
$runas = Add-SCOMRunAsAccount -Simple -Name $user -RunAsCredential $cred

# distribute the account
Set-SCOMRunAsDistribution -RunAsAccount $runas -MoreSecure -SecureDistribution $pool

After running these commands, you can verify (but not modify!) the changes in the GUI:


Assigning this account to a profile afterwards is perfectly doable with the GUI however!

Although this post revolves around bypassing a GUI restriction, you can use the same commands of course to administer any runas-account in the context of automation or general nerdyness Smile

Let me know if you have further question on this topic! Jan out!

MP Viewer 2012…reloaded!

9:42 pm in Uncategorized by Jan Van Meirvenne

One of the great things that comes forth out of a technology community are the custom tools. Tools that make life a little easier and provide functionalities not always found in the original product.

One of the tools I use very often is MPViewer. A simple tool that can read and report on management pack contents without needing a management group connection or other heavy interface. Just run this little gem, point to a MP / XML / MPB Management Pack, and boom…you see what’s inside. It is a great value to quickly create a report of do a pre-import assessment.

Big was my disappointment when I heard that the original authors abandonded the project.

Since the original code was shared on Github (thank god!) I decided to use my own developer knowledge to research, maintain and extend the code. I got to the point were I am confident to do a first release to the world, and I hope you have as much fun using it as I had creating it. Bear in mind though that I am not a professional developer, so the ride may be bumpy and dirty from time to time.

New Features

  • The MPViewer can now open multiple management packs in one go, allowing easier documentation of an entire workload instead of separate files
    • Each item will have a column stating the MP it resides in, so you will always know the source MP!
    • A separate table ‘Management Packs’ shows all the MP’s that are loaded



  • Management Packs can now be loaded from a live Management Group in addition of files. Multiple MP’s can be selected, just like the file-based approach!



  • Modules are now included in the overview, including the full XML configuration!


  • OpenWith is now supported: associate the MPViewer with the XML, MP or MPB file extension and MPViewer will load the file when you double-click on it in explorer!

Known Issues

  • First release, so expect some bugs here and there. Feedback is welcome through the issues-page
  • Command-Line support removed due to the addition of the OpenWith feature. I will research the possibility of combining both features
  • GUI is quirky at some points
  • Code is a mess in some areas


Thank you in advance for giving the tool a spin and providing your own contributions and feedback! I hope to be able to keep this small gem alive and up-to-date so that there will be a continued benefit for those in need of a good Management Pack tool!

Jan Out!

Building your own incident update form for Service Manager

6:52 am in Uncategorized by Jan Van Meirvenne


I love developing…to the extent that I sometimes wonder why I chose the IT Pro life in the first place. But I love versatility as well: not being limited to a single set of skills. This empowers me to not only implement and maintain various processes and platforms, but also understand their core workings and if needed…modify them. The beautiful thing about the System Center and in extension the Azure stack is that it is extensible, moldable. Functionality can be added with relative ease as long as you have an understanding how code works and also tons of patience and perseverance.

The nice thing about having this skillset is that certain requests I receive might have been answered with a ‘not possible’ or ‘there is a paid addon’, but got the ‘yes, I can build it if you agree that it might take some time’ line instead.

One of these type of requests (they occur far too few sadly) involved an issue were the customer wanted to force the input of a resolution category and comment if an incident’s status was updated to the resolved-status. Although this functionality exists in some standard forms, it is not enforced consistently, posing a risk in process integrity.

So I drew the ‘I’ll built it’ card and went on my merry way. My idea was to create a new incident task which would contain a Windows Form that allows the analyst to choose a new incident status. There would also be an option to enter a comment. In the case that the analyst would select ‘resolved’ as status, an additional input would appear to allow the selection of the resolution category. Also, the comment entered would not be logged as analyst comment, but as resolution detail.

Some restrictions would need to be in effect to ensure the process was respected: if the status is set to ‘resolved’, choosing a resolution category and entering a comment must be a mandatory action, and if the analyst fails to do so, the update action needs to be blocked.

Although I have knowledge of the basic principles of development, I needed to get some insights and inspiration for SCSM-specific authoring. I came across the following interesting posts:

How does it work?

The SCSM SDK provides the option to define a task handler. This handler provides an interface in both the management group the console is connected to, and the selected objects on which the task is activated. You can use these interfaces to query and modify virtually any aspect in your management group. In my setup, I build a task handler that gets the incident information from the selected item and uses it to display a custom form, where the analyst can update the status. The handler and the form are stored in a Class Library better known as a DLL.

Alongside this DLL I build a management pack that does 2 things: expose the task-handler as a button in the main SCSM console, and hide the default tasks that it replaces. This is contained in a SCSM management pack project (which comes with the Visual Studio Authoring Extensions). Important here is to create a reference to the DLL-project where the task-handler and form reside, and specify that they should be ‘packaged to bundle’. This will create a MPB when the MP project is build, containing both the MP XML as well as the DLL-file. When this MPB is imported, SCSM will know that the DLL in the MPB must be activated when the custom task in the MP is triggered (see Github comments for more info).


How can I create my own awesome tasks?

Before I start evangelizing the power of Visual Studio, first I want to point out that there is a much easier way to get simple tasks going: by using the standard custom task feature of SCSM. You can use PowerShell or any other script type or executable to perform virtually any action. The benefit of using Visual Studio is that native, integrated code is easier to manage (no external tools that need to be present on a share somewhere, versioning,…). Also, while a GUI can be build with PowerShell, it is much easier in Visual Studio thanks to the visual tools. Finally, the feeling of accomplishment us much stronger when getting a native task to work Smile.

The tools you need to get going are:

Visual Studio 2012, 2013 or 2015 (Preview 15 is not supported yet in the VSAE). If you want to build something for production use, then a Professional or Enterprise edition is required. If you just want to mess around a bit, then you can use the free Community Edition (only available starting from VS 2013).

After VS is installed, you need to install the System Center Visual Studio Authoring Extensions (now that’s a mouthful). This enables you to create management packs for SCOM and SCSM right from VS.

I also recommend to install the Service Manager Authoring Tool, as it brings a lot of DLL’s and MP’s that are vital / useful to reference in most SCSM projects.

Now, open up Visual Studio and create a new C# class library. Make sure that the target .NET Framework is 3.5. This is the version where SCSM has been compiled with. Name the solution and project accordingly (use a naming convention to standardize your code). Also, make sure to specify GIT as source control, this makes it easy to protect and version your code (more on this later).



In order to be able to use SCSM-specific functions, you’ll need to add references (similar to management pack references) to some SCSM DLL’s that contain the code we need to use.

Right-click on references, and then choose add.


Add the following DLL’s (having the SCSM authoring and regular console installed helps in easily acquiring the necessary files):


You should be able to locate them in “C:\Program Files (x86)\Microsoft System Center 2012\Service Manager Authoring\PackagesToLoad” or “C:\Windows\assembly\GAC_MSIL” folders.

Once all references are added you can start building your task!

The project starts by default with a single class creatively called ‘Class1’ and a namespace called ‘ClassLibrary1’. It is useful to change this asap to improve readability. You can do this in the project properties and the class1.cs file (you need to change both to ensure your custom namespace name is reused everywhere). Prompts for rename can safely be allowed in this case. Also, it is advised to rename the actual filename from Class1.cs to the name of your class (eg EditTask.cs)

Why a rename is important? The management pack we will see later on refers to both the namespace and classname of the custom task in order to execute its code. Having something clear like ‘MyTasks.EditTask’ will help in identifying which class performs which task.






In order to add a GUI to our task, we need to add a Windows Form class to our project. Windows Presentation Foundation, a more modern graphical platform would be a better choice, but for novice developers it is easier to use the older Windows Forms. You can do this by right-clicking on your project and adding a Windows Form:


You can now use the graphical tools to create a GUI that fulfills your needs:


There is a code-behind section where you can add code to the various form events (load, button click, close). You can also add parameters so that you can pass objects from and to the form. I use this to pass the SCSM connection object so that the form can retrieve data and the task code can retrieve the user-input afterwards. To access this code-behind, the simplest way is to double click on the form or one of the controls to instantly create a handler function for the clicked item (eg double-click on a button to immediately be able to add code for when it is clicked at runtime).


Notice the ‘using’-lines in my code. These are used to include pieces of the references we added to our projects, making it easier to use the SCSM specific code.

Now to make use of this form in the SCSM console, and bind it to data we select, we need to define a task handler. Remember the library class we renamed first after creating the project? We will use it to define a task handler.

First, we need to mark our class as a task handler. This is done by specifying the ConsoleCommand interface. An interface is kind of a template you use to make a class adhere to the requirements of a platform / function. In this case we use it to make our class usable by SCSM by ensuring the correct functions are present. We can specify our interface by adding its name after our class-name, separated by a ‘:’. This will cause a prompt to implement the functions specified in the interface. You can use this to immediately add all necessary functions, in this case a function ‘ExecuteCommand’ will be added. ‘ExecuteCommand’ is the function SCSM will call when you click the linked task in the console, and pass data from the selected item to it.


From then on it is easy to build the task logic. The only things left worth mentioning are:

You can get a connection object which you can use to perform any SCSM SDK action using this code:

IManagementGroupSession emg = FrameworkServices.GetService<IManagementGroupSession>();

This will use the existing connection of the analyst console, including its security constraints.

You can get the selected item’s GUID (and use it to retrieve the object) this way:

EnterpriseManagementObject IncidentObject = emg.ManagementGroup.EntityObjects.GetObject<EnterpriseManagementObject>(new Guid(nodes[0]["$Id$"].ToString()), ObjectQueryOptions.Default);

You can summon a GUI and pass data from / to it like this:

AssignmentForm form = new AssignmentForm();
           form.emg = emg.ManagementGroup;
           // we need to convert the tier-class representing the incident status to a guid-format used by the GUI
           ManagementPackEnumeration SelectedStatus = (ManagementPackEnumeration)IncidentObject[IncidentClass, "Status"].Value;
           form.StatusTier = SelectedStatus.Id;
           // show the GUI as a dialog (popup) and record the outcome of it (OK or cancel)
           DialogResult r = form.ShowDialog();

You can use the Github link below to browse all the commented code, so I will not dig deeper into the C# part right now (phew Smile). Lets take a look at the accompanying management pack instead, where we need to define our task and link it to our custom code.

First, you need to add a SCSM MP project (with a logical name) to the existing solution where your task library already resides.


Add a reference to the existing task library project. This way we can reference the assembly in our MP XML.


When the reference is added, make sure you set its ‘Package To Bundle’ property to ‘true’, so that it gets added to the MP Bundle when building the MP project.


Now you can add a MP Fragment, and start writing XML code!


The management pack is rather simple in comparison to the library part. It contains the following parts:

We need to define the MP as being a native SCSM one. This is important because otherwise it will be interpreted as a SCOM MP, resulting in tasks not being displayed among other things.

    <!– We must specify the management pack as a SCSM type, else the tasks won’t be shown (they would be perceived as SCOM tasks and hidden) –>
    <Category ID="Custom.SM.Incident.ChangeStatus.MP.CATEGORY_MP" Value="MESUC!Microsoft.EnterpriseManagement.ServiceManager.ManagementPack">


In order to replace the default incident status tasks, we need to hide them. This can be done by tagging them with a specific category, instructing the console not to show the items.

<Category ID="Custom.SM.Incident.ChangeStatus.MP.CATEGORY_HIDEConsole" Target="SIL!System.WorkItem.Incident.StatusGroup.Task" Value="MESUC!Microsoft.EnterpriseManagement.ServiceManager.UI.Console.DonotShowConsoleTask" />
    <Category ID="Custom.SM.Incident.ChangeStatus.MP.CATEGORY_HIDEForm" Target="SIL!System.WorkItem.Incident.StatusGroup.Task" Value="MESUC!Microsoft.EnterpriseManagement.ServiceManager.UI.Console.DonotShowFormTask" />
    <Category ID="Custom.SM.Incident.ChangeStatus.MP.CATEGORY_HIDEConsole2" Target="SIL!System.WorkItem.Incident.ChangeStatusCommand.Task" Value="MESUC!Microsoft.EnterpriseManagement.ServiceManager.UI.Console.DonotShowConsoleTask" />
    <Category ID="Custom.SM.Incident.ChangeStatus.MP.CATEGORY_HIDEForm2" Target="SIL!System.WorkItem.Incident.ChangeStatusCommand.Task" Value="MESUC!Microsoft.EnterpriseManagement.ServiceManager.UI.Console.DonotShowFormTask" />

Next, we define our task. We target the incident-class in order to make our task show up if an incident is selected. We first refer to the built-in SDK assembly, in order to launch the framework code, and as parameter we pass our task’s assembly and class name. Notice that it is possible to add additional arguments which are passed to your code if needed.

      <!– This is the actual task definition for the custom form, it refers to the assembly we define later on so that it gets initialized when the users launches the task–>
      <ConsoleTask ID="Custom.SM.Incident.ChangeStatus.MP.T_Update" Target="SWIL!System.WorkItem.Incident" Accessibility="Public" RequireOutput="false">
          <Argument Name="Assembly">Custom.SM.Incident.ChangeStatus.UI</Argument>
          <Argument Name="Type">Custom.SM.Incident.ChangeStatus.UI.ConsoleTask</Argument>

To make things more sexy, we assign some existing icon to our task.

      <!– We assign a standard image icon of the original task to our custom one (great artists steal :)–>
      <ImageReference ElementID="Custom.SM.Incident.ChangeStatus.MP.T_Update" ImageID="SIL!IncidentMgmt_IncidentStatusChange_16"/>

At the end of the management pack, we define our assembly. Thanks to the existing project reference, most of the definition should auto-complete when using IntelliSense:

    <!– Here we define that we want to include a custom library in our management pack. It is important to reference the library project (that contains the task handler and GUI) in Visual Studio (it needs to be a project in the same solution as the MP), and to set the ‘package to bundle’ property to true –>
    <Assembly ID="Custom.SM.Incident.ChangeStatus.MP.ASS_Base" FileName="Custom.SM.Incident.ChangeStatus.UI.dll" QualifiedName="Custom.SM.Incident.ChangeStatus.UI, Version=, Culture=neutral, PublicKeyToken=null" Accessibility="Public" />

When building the MP, a MPB is created containing both the MP code as well as the assembly. No copying of DLL’s required! Make sure to copy the MPB to a temporary location as it will be locked by SCSM when importing it, preventing a subsequent build from succeeding.

If all went well, you should see your new task pop-up. Click it to let the magic start!



Magic?! The only magic I get is a nasty exception. What now?

Debugging your library code is rather easy. You need to attach your Visual Studio solution to your SCSM console process and then force the exception to occur.


When it hits, you should enter into the stack trace in your code and be able to see where and why things go south. Fix it, rebuild it, and reimport it and test again! It might be useful to reopen your console with the clearcache switch to make sure you are using the latest code when running the task.

Patrick Sundqvist of Litware has written a nice post on debugging these kind of projects.

Keep your code safe!

Congratulations! You’ve made your first addon for SCSM! But how do your protect your precious code?


The benefit of using Visual Studio is the native integration possibilities with code repositories like GitHub and Visual Studio Online. Both are free cloud services (if you can live with your code being publically viewable on GitHub). When finished, just commit and push your code to the cloud to keep it safe, and even better, be able to share it!


And….finally but not least:

Check out the full code

If you have questions or other feedback on this topic, feel free to comment! Thanks for the read and until next time! Jan out.