You are browsing the archive for Uncategorized.

Upgrading to Service Manager 2016

11:38 pm in Uncategorized by Jan Van Meirvenne

Looking for the best way to upgrade to SCSM 2016. You can read my experiences here.

Slow loading of CMDB picker controls in the SCSM portal

3:42 pm in Uncategorized by Jan Van Meirvenne

In this post, I describe how to troubleshoot slow SCSM portal performance regarding CMDB pickers:

Slow loading of CMDB picker controls in the SCSM portal

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!