SCOM – Quick Tip: Exchange Queue Length Monitor

July 11, 2018


I’m currently busy at several customers setting up SCOM infrastructures. At one of those customers there were complaints by users that email messages were queued. When looking at the queues on the exchange servers they were actually HUGE.

Due to the fact Exchange was already monitored in SCOM I thought we would have seen this but that was not the case. In the Exchange Management pack there is NO monitor to check the actual queue length although there are rules which collect the queue lengths. I think this is not OK as it is really important to be notified when messages get queued in Exchange.

Therefore I created a custom Powershell monitor to check this. I created the monitor using the SquaredUp Powershell management pack, this management pack adds Powershell support everywhere throughout SCOM (where you would expect that by default :)) The management pack can be downloaded here:

This is the powershell script itself:

# Any Arguments specified will be sent to the script as a single string.
# If you need to send multiple values, delimit them with a space, semicolon or other separator and then use split.

$ScomAPI = New-Object -comObject “MOM.ScriptAPI”
$PropertyBag = $ScomAPI.CreatePropertyBag()

# Example of use below, in this case return the length of the string passed in and we’ll set health state based on that.
# Since the health state comparison is string based in this template we’ll need to create a state value and return it.
# Ensure you return a unique value per health state (e.g. a service status), or a unique combination of values.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn;

$queue = ((Get-Queue | Select-Object @{ n = “MessageCount”; e = { [int]($_.MessageCount) } }).MessageCount | measure-object -sum).sum


if($queue -gt 500) {

# Send output to SCOM

The monitor will become critical when the messagecount exceeds 500 messages, this can be increased or decreased if needed by changing “$queue -gt 500” accordingly.


This monitor has helped my customer to prevent this issue from happening again.

Hope this helps!


Best regards,




SCOM – Powershell Recovery Action – Stopped Windows Service

August 31, 2017


Today I was at a customer who had a really specific question regarding monitoring of Windows Services with Operations Manager (SCOM).

We had already set up some basic recovery actions which restart the service automatically after it was stopped.

For some other services the customer wanted to add extra functionality: The recovery action should retry starting the service a maximum of 3 times, if the service wasn’t started after 3 tries the customer wanted to receive an email telling them the recovery action failed. Out-of-the-box SCOM is unable to do stuff like that, therefore I used Powershell to accomplish this.

Sidenote: To be able to use Powershell as a recovery action you can use the free management pack provided by the community & SquaredUp, it can be downloaded from this website: This management pack adds Powershell everywhere it is missing in Operations Manager, this is one of the default management packs I always install at customers.


To be fully functional different components are needed:

  • A monitor that checks the status of the service
    • This monitor can be created from the Authoring pane of the SCOM console using the Windows Service template


  • A recovery action for the monitor created previously
    • The recovery action can be created from health explorer1
  • A rule that picks up the event created by the recovery action Powershell script
    • This is an Alert Generating Rule (NT Event Log), the configuration is linked to the type and location of the event logged during the script2
  • A subscription on the rule to send the email.

The powershell script:

# Fill in the service name here

$ServiceName = “LPD Service”

$ServiceStarted = $False

$i =0;

#Create Eventlog source, erroraction Ignore is neededbecause once the source is created an error is thrown because the source already exists

New-Eventlog -LogName Application -Source “Powershell – Restart Service” -ErrorAction Ignore


# In second or third run, wait a minute before trying
to start the service

if ($i -gt 0){Start-Sleep -s 60}

#Try to start the service

Start-Service $ServiceName

$Service Get-Service -Name $ServiceName

     if($Service.Status -eq “Running”)


    $ServiceStarted = $true



    if (($i -eq 3) -and ($ServiceStarted $false))


    $eventmessage = $Servicename failed to restart after $i attempts, exiting script”

    #Log error event in eventviewer

    Write-Eventlog -LogName Application -Source “Powershell – Restart Service” -EntryType Error -Eventid 101 -Message $eventmessage




Until ($ServiceStarted = $true)

 $eventmessage = $ServiceName restarted after $i attempt(s)”

Write-Eventlog -LogName Application -Source “Powershell – Restart Service” -EntryType Information -Eventid100 -Message $eventmessage

 If you have any difficulties doing this, don’t hesitate to drop a comment below.

If you find this post useful, please consider buying me a virtual beer with a bitcoin donation: 3QhpQ5z5hbPXXRS8x6R5RagWVrRQ5mDEZ1


Best regards,


Add URL to customized Windows 10 Start Menu

September 1, 2016


Since more and more of our customers are adopting Windows 10 in their environment we start to learn more tricks every day.

An important component of Windows 10 is the start menu. Administrators could apply a default startmenu layout for all users by using a GPO but downside of this approach is that the user isn’t able to add any custom applications himself. That’s why I prefer to set the startlayout during the Windows 10 deployment task sequence using a Powershell script.

Afterwards the default layout is set when the user first logs in, from then on the user can edit his start menu as he likes. Adding “classical” applications such as Word, Excel and Powerpoint is quite easy as those applications are already present when the user first logs in. Adding a shortcut to a website might be a little bit harder, in this post I’ll be explaining the steps that need to be taken to accomplish this. It’s a combination of Powershell, SCCM  (also applicable for MDT) and Group Policy Preferences. Let’s get started

First of all start by customizing the start menu as you like on a test machine. The start menu I want is the one shown below. We’ll be focusing on the highlighted icon in the start menu as this is a URL, other shortcuts are applications.


When the start layout is finished, launch powershell and execute the following command to export the startlayout:

Export-Startlayout -Path “C:\windows\temp\Startlayout.xml”

The XML generated looks as follows (text in bold is related to the Citrix URL):

<LayoutModificationTemplate Version=”1″ xmlns=””&gt;
<LayoutOptions StartTileGroupCellWidth=”6″ />
<defaultlayout:StartLayout GroupCellWidth=”6″ xmlns:defaultlayout=””&gt;
<start:Group Name=”Webbrowsers” xmlns:start=””&gt;
<start:DesktopApplicationTile Size=”2×2″ Column=”0″ Row=”0″ DesktopApplicationID=”Microsoft.InternetExplorer.Default” />
<start:Group Name=”Office ” xmlns:start=””&gt;
<start:DesktopApplicationTile Size=”2×2″ Column=”2″ Row=”0″ DesktopApplicationID=”{7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}\Microsoft Office\Office15\WINWORD.EXE” />
<start:DesktopApplicationTile Size=”2×2″ Column=”0″ Row=”0″ DesktopApplicationID=”Microsoft.Office.OUTLOOK.EXE.15″ />
<start:DesktopApplicationTile Size=”2×2″ Column=”0″ Row=”2″ DesktopApplicationID=”{7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}\Microsoft Office\Office15\POWERPNT.EXE” />
<start:DesktopApplicationTile Size=”2×2″ Column=”2″ Row=”2″ DesktopApplicationID=”{7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}\Microsoft Office\Office15\EXCEL.EXE” />
<start:Group Name=”” xmlns:start=””&gt;
<start:DesktopApplicationTile Size=”2×2″ Column=”2″ Row=”0″ DesktopApplicationID=”Microsoft.SoftwareCenter.DesktopToasts” />
<start:DesktopApplicationTile Size=”2×2″ Column=”0″ Row=”0″ DesktopApplicationID=”Microsoft.Windows.ControlPanel” />
<start:Group Name=”” xmlns:start=””&gt;
<start:DesktopApplicationTile Size=”2×2″ Column=”0″ Row=”0″ DesktopApplicationID=”; />

Now create an SCCM Package containing the XML file and a Powershell script with the following content:

Import-StartLayout -LayoutPath $PSScriptroot\StartLayout.xml -MountPath $env:systemdrive\

Now this can be executed using a Run Powershell Script during the SCCM OSD task sequence.

Without performing further actions when a user first logs in the start menu will be generated but the URL to will not be present. To make sure it’s there we need to create a Group Policy Preference to put the exact URL in the start menu for the user. Pay close attention because the target URL specified in the GPP must EXACTLY match the value of DesktopApplicationID (without the “”)


Now when the user (for which the GPP is applied) logs on for the first time on a Windows 10 computer, the default Start layout will be applied properly and the URL will also appear.

Hope this helps!


Best regards,




Configuration Manager 2012 R2 Powershell Application Detection Method #RDProud

July 2, 2015

Hi all,

This blog post describes how to enable .NET Framework 3.5 on Windows 8.1 after the computers already have been deployed.This can be quite annoying because the SXS source folder is needed when installing + this bug ( can also kick in.

The installation is done using an SCCM application containing an installation powershell script and powershell detection method. An easier alternative is using a package and task sequence to run the powershell script (no detection method needed here). Using the application has the advantage that it can be used as dependency and requirements can be added.

The installation script contains different phases

  • Downloading the source to a local folder in C:\windows\temp\NetFX3
    • This folder contains the installation powershell script and the SXS folder from the Windows 8.1 PRO ISO
  • Installing KB2966828 (to avoid the bug)
  • Enable .NET Framework using the downloaded SXS folder as source
  • Detect if .NET Framework was installed successfully
  • Delete temp folder C:\windows\temp\NetFX3

First of all a little thing about using Powershell as an Application Detection Method

The main purpose is to make sure the detection method exits with exit code = 0 (no errors during the script)  + Depending on the value of STDOUT (Write-Output) the detection method will return that the application is installed or not installed.

Script exit code Data read from STDOUT Data read from STDERR Script result Application detection state
0 Empty Empty Success Not installed
0 Not empty Empty Success Installed

Additional details:

Now we’ll try to apply this to the .NET Framework 3.5 feature we want to get installed here, the script I use is this:

$Framework = Get-windowsoptionalfeature -FeatureName NetFx3 -Online | Select-Object -ExpandProperty State

if ($Framework -eq “Disabled”)


  exit 0




  Write-Host “.NET Enabled”

  exit 0


This script is quite easy to understand and does the following

  • If .NET is not installed (disabled): exit script with exit code 0 –> Detection method sees this as “Application Not Installed”:
    • Exit code = 0
    • STDOUT (Write-Host) = Empty
  • If .NET is installed (enabled): exit script with exit code 0 –> Detection method sees this as “Application Installed”:
    • Exit code = 0
    • STDOUT (Write-Host) = Not Empty

Now let’s start adding this into SCCM: Create an Application and give it a suitable name. When creating a Deployment type give in the path to the source and the commandline. This is the commandline I used: “Powershell.exe -executionpolicy Bypass -file .\install.ps1” (without quotes)


When prompted for the detection method, select “Use a custom script to detect the presence of this deployment type and Click Edit, Select powershell and copy the detection method script in here


Finish creating the deployment type adding needed requirements (here I have added Operating System = Windows 8.1 x64)

After the application is created, update distribution points, deploy it to a test machine and see the result

Using the “Retrieve Machine Policy” on the test client we should rapidly see the new deployment, but this didn’t happen. I went to look into the ConfigMgr Client logs and found something interesting in the AppDiscovery.log

The Detection method couldn’t be run because it was not signed “CScriptHandler::DiscoverApp failed (0x87d00327).” I stumbled upon this post by someone who experienced the same error So I did what he highlighted: Enabling the Powershell Bypass option for the ConfigMgr Client.

A next test should result in the application being successfully added in the Software Center doesn’t it? Yes, it’s there but it says “Installed” while the .NET Framework wasn’t installed . Let’s go back to the AppDiscovery.log. Now no errors were listed but only warnings stating the script returned some error message (The application is detected as shown in the log “Detected App Deployment Type…”, but the application is not installed)


This one was tackled by disabling by unchecking “Run script as 32-bit process on 64-bit clients” on the detection method


After this little adjustment and another try everything looked good. The application was listed as “Available” in Software Center and the AppDiscovery.log showed the following: The App Deployment type was not detected.


Great! Hope this helps in helping you guys out!

Best regards,


Orchestrator run .NET version

June 22, 2015



We’re using a simple script to enumerate all AD groups containing info in a notes field in Orchestrator.

The script is this :

import-module activedirectory -force

$ArrayProcessList = @()

$Searchbase = “OU=Security Groups,OU=Groups,DC=localdomain,DC=com”

$results = get-adgroup -filter {info -like “*”} -searchbase $searchbase

foreach ( $result in $results )


$ArrayProcessList += $result.distinguishedname



When running in the runbook tester with an admin user all works fine. However when testing with a calling runbook so the runbook is executed on the runbook server using service acocunts I recieve an error:


Hmm strange.

Digging into this issue I noticed that the powershell version running using the run .net script is a V2.0 X86 powershell edition ( thank for that Thomas 🙂 )

As you can see in the default V3 version the import-module works.


And this doesn’t work in the V2 version :


Okay , so we have identified the issue , how to resolve it ?

We like this :

Modify the script so it starts a new powershell session and pass the output


So start with a variable and run powershell { command} after this, make sure you output the desired result and then pass the initial variable as published data.


And check result !



Yes ! Success.


Gino D

Quick Tip ! Redistribute failed packages in ConfigMgr #RDProud

May 26, 2015


We were having issues with several packages not being distributed correctly in a large sccm 2012 environment. If we redsitribute the failed packages on a specific dp then the issue is resolved.

We’ll perform a root cause analysis next time, let’s focus on getting our content to the DP’s for now.

So I have created a powershell script ( based on ) that will take all the failed distributions on a specifc DP and refresh them.

Here it is ( replace XXX with your site code):


$failures = Get-WmiObject -Namespace root\sms\site_XXX -Query “SELECT packageid FROM SMS_PackageStatusDistPointsSummarizer WHERE (State = 3 AND SourceNALPath like ‘$fileserver’ )”

foreach ( $failure in $failures )


$id = $failure.PackageID

write-host $id

$DP = Get-WmiObject -Namespace root\sms\site_XXX -Query “SELECT * FROM SMS_DistributionPoint WHERE (ServerNALPath like ‘$fileserver’ and PackageID=’$id’ )”

write-host $DP




If you combine this with content validation on a schedule and the report ->

Software Distribution -> Content -> All active content distribution -> failed


You can export to csv and have a nice filtered excel that can be used as in order to select the correct DP.



Gino D

Add a password to task sequence ConfigMgr #rdproud

May 19, 2015



Say you want to add a password to a task sequence ?

Yes, you can do that starting from PXE but not starting from the OS (out-of-the-box) so let’s modify.

First create a simple posh Script ,

# Script can be used in order to ask a password in SCCM task sequence

# Requries vPassword to be created in TS , if input equals then vContinue will be set to OK


# Gino D’hoker


# 4/05/2015

$password = Read-host “Please enter the password.” -AsSecureString

# Prompt for input

$password = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($password))

$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment

If ($password -eq $tsenv.Value(“vPassword”))





This will ask for input, check if the answer is identical to a ts variable called vPassword and then set a variable called vContinue to OK.

Now let’s create the ts, you’ll need the MDT package for Serviceui.exe in order to allow interaction with the ts


Step 1 will only be applied if not in WinPE


Now use the mdt package and perform a custom action for asking input


Because we’ll use the same ts from PXE and from OS we’ll need to set the vContinue to OK if started from PXE



And now just continue the rest of the ts only of the vContinue is OK


So what does this look like ? Step 1 you receive the default warning


Step 2 the script asks for the password.


If incorrect it will not perform the reinstallation.

P.S I know the dos box isn’t state of the art, I’ll check into the Powershell forms the next time to get a more fancy request for input

The rest you know.


Gino D