Report Name: SCCM Site Boundaries

SQL Query:

SELECT distinct
v_BoundaryInfo.DisplayName AS [Boundary Name],
Case v_BoundaryInfo.BoundaryType
When 0 then 'IP Subnet'
When 1 then 'AD Site'
When 2 then 'IPV6 Prefix'
When 3 then 'IP Range'
End As 'Type',
v_BoundaryInfo.Value AS [Value],
v_BoundaryInfo.SiteCode AS [Site Code]
From v_BoundaryInfo WHERE DisplayName LIKE @BoundaryName

Prompts:

Name: BoundaryName

Prompt Text: Boundary Name

Prompt SQL Statement:

begin
if (@__filterwildcard = '')
Select DisplayName from v_BoundaryInfo order by DisplayName
else
Select DisplayName from v_BoundaryInfo where DisplayName LIKE @__filterwildcard order by DisplayName
end

Version 3.4 was finished a while back but I never got time to publish it in this blog. I only emailed 3.4 to few people who contacted me from my blog. Now that I’ve updated it again to 3.5, I thought I’ll just publish version 3.5.

What’s Changed Since 3.3?

1. Added site system name under ‘site systems with issues’ section
2. Detect site components that are missing heartbeats.
3. Changed function Validate-DNSRecord to use Win32_ComputerSystem.caption rather than DNSHostname to retrieve computer name as DNSHostName is not available on computers before Windows 2008.

Update Instruction

A new item has been added to the configuration XML (Health-Check.xml):
   <MaxMissingHeartBeatTolerance>
<Hours>24</Hours>
</MaxMissingHeartBeatTolerance>

As the name suggest, the script raises any site systems as problematic if it has not sent heartbeat for over the X number of hours that you configured in XML (in my example, it’s 24 hours).

You may keep the old XML that you have already configured for your environment as long as you add the following lines in the Health-Check.XML:

You can download version 3.5 HERE.

In all the environments that I implemented this script in command notification channel, there were always some random alerts not been processed.

Few months ago, I was working on another PowerShell script to be used in command notification channel to update a custom field when alerts are created. While I was testing it, I found it has exactly the same problem, the subscription randomly skips alerts and left them not processed.

In the end, I found the cause of the problem: the command line parameters are not configured properly! The details can be found in Steve Rachui’s blog article here: Updating custom alert fields using subscriptions and powershell. Steve explained in the article:

There are several quotation marks in the command line so I’ve listed the text again below in case you want to copy/paste in your environment. Note the highlights above – these are single quotes that go around alert ID as it’s passed to the script. Make sure you include these because if you don’t the alert ID won’t be handled correctly in all cases and the script will not run consistently.

Full path of the command file: c:\windows\system32\windowspowershell\v1.0\powershell.exe
Command line parameters: -Command “& ‘”C:\alertupdater.ps1″‘” ‘$Data/Context/DataItem/AlertId$’
Startup folder for the command line: c:\windows\system32\windowspowershell\v1.0\

So to fix my problem with my Ehanced SCOM Alert Nofication Script, the command line parameter should be:

-Command “& ‘”D:\Scripts\SCOMEnhancedEmailNotification.ps1″‘” -alertID ‘$Data/Context/DataItem/AlertId$’ -Recipients @(‘Tao Yang;Tao.Yang@xxxx.com’,John Smith;John.Smith@xxxx.com‘)

I’ve updated the original Enhanced SCOM Alerts Notification EMails blog article to reflect this change.

Setting up monitors for these processes is easy. However, I went a step further and created a generic write action module to be used as recovery task that restarts the process interactively on the console session.

There is one pre-requisite for the recovery task: I had to use PsExec to launch the process on console session. PsExec can be downloaded here: http://technet.microsoft.com/en-us/sysinternals/bb897553. PsExec needs to be copied locally to the computers that are being monitored.

I’ll now use use an example to go through how I setup the monitor, write action module and recovery task for notepad.exe

01. First of all, I created a class and its discovery to target my test machine “Client01”

02. Added “Microsoft.SystemCenter.ProcessMonitoring.Library” as a reference in my MP.

03. Created a process monitor for notepad.exe

• Monitor Type: Process Instance Count Monitor Type (from “Microsoft.SystemCenter.ProcessMonitoring.Library”)
• Monitor Configuration:

• Note: While I was setting up the monitor, I realised the process name is case sensitive. Also, Frequency is in seconds
• 
• This is pretty much the same as using the Process Monitoring template from from the SCOM operations console (under Authoring Pane) – Except I used my own class rather than targeting to a group. Below is from the process monitoring wizard:
• 

04. Now once I import the MP into my SCOM management group, I can verify it is working (from health explorer):

05. Because the way this monitor works, it is only healthy when the process count is in between MinInstanceCount and MaxInstanceCount (both set to 1 in this case). So the monitor’s health turns to Errorif there are say 2 instance of notepad running. Therefore I need to run a diagnostic task to determine how many instances are actually running because I only want to run the recovery task when the instance count is less than 1. I created a diagnostic task to run when the monitor’s health is in Error state. This diagnostic has only 1 action module: “Microsoft.Windows.ScriptPropertyBagProbe”:

• Module configuration:

• ScriptName	CheckProcessDiagnostic.vbs
  Arguments	notepad.exe
  ScriptBody	refer to the vbscript below
  TimeoutSeconds	60

• Here’s the script:

'==========================================
' AUTHOR:            Tao Yang
' Script Name:        CheckProcessDiagnostic.vbs
' DATE:                27/01/2012
' Version:            1.0
' COMMENT:            - Script to check process state.
'                    - Used for OpsMgr Management Pack diagnostic tasks.
'==========================================
ProcessName = WScript.Arguments.Item(0)
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oBag = oAPI.CreatePropertyBag()
WMIQuery = "Select * From Win32_process WHERE name = '" + ProcessName + "'"
Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
Set colProcesses = objWMIService.ExecQuery (WMIQuery)
Call oBag.AddValue("ProcessName",ProcessName)
If colProcesses.count < 1 Then
Call oBag.AddValue("Result","Positive")
Else
Call oBag.AddValue("Result","Negative")
End If
oAPI.Return(oBag)

• This script returns a property bag variable“Result”. The value of “Result” is “Positive” if there is less than 1 instance of notepad.exe running. otherwise, the value is “Negative”. I will use the the value of “Result” to determine whether to run the recovery task or not by using a condition detection module in recovery task later.

06. Create a Write Actions module for the recovery task. I’m creating a separate module for this so I can use it in recovery tasks of multiple monitors.

• 
• Member Module: “Microsoft.Windows.PowerShellWriteAction”
• 
• Module Configuration:
• 
• While editing this module, Add below secion between </ScriptBody> and </Configuration>:

<Parameters>
<Parameter>
<Name>PsExecPath</Name>
<Value>$Config/PsExecPath$</Value>
</Parameter>
<Parameter>
<Name>PathToExe</Name>
<Value>$Config/PathToExe$</Value>
</Parameter>
<Parameter>
<Name>Context</Name>
<Value>$Config/Context$</Value>
</Parameter>
<Parameter>
<Name>Arguments</Name>
<Value>$Config/Arguments$</Value>
</Parameter>
</Parameters>
<TimeoutSeconds>$Config/TimeoutSeconds$</TimeoutSeconds>

Place the PowerShell script below between <ScriptBody></ScriptBody> section:

#=================================================
# AUTHOR:  Tao Yang
# DATE:    16/01/2012
# Version: 1.0
# COMMENT: Start a exe on console session under LocalSystem Context
#=================================================

param([string]$PsExecPath, [string]$PathToExe, [string]$Context, [string]$Arguments)
# $Context should have only 2 possible values: "System" or "User". "User" needs Auto Admin Logon Enabled
Function Get-ConsoleSessionInfo
{
$results = Query Session
$ConsoleSession = $results | select-string "console\s+(\w+)\s+(\d+)\s+(\w+)"
if ($ConsoleSession)
{
$UserName = $ConsoleSession.Matches[0].groups[1].value
$SessionID = $ConsoleSession.Matches[0].groups[2].value
$State = $ConsoleSession.Matches[0].groups[3].value
$objConsoleSession = New-Object psobject
Add-Member -InputObject $objConsoleSession -Name "UserName" -Value $UserName -MemberType NoteProperty
Add-Member -InputObject $objConsoleSession -Name "SessionID" -Value $SessionID -MemberType NoteProperty
Add-Member -InputObject $objConsoleSession -Name "State" -Value $State -MemberType NoteProperty
} else { $objConsoleSession = $null }
Return $objConsoleSession
}

$Mode = $null
#Determine UserID
If ($Context -ieq "User")
{
$strUserName = $null
$DefaultPassword = $null
#detect if auto admin is enabled, if so, retrieve username and password from registry
$WinlogonRegKey = get-itemproperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\"
If ($WinlogonRegKey.AutoAdminLogon = "1")
{
$DefaultUserName = $WinlogonRegKey.DefaultUserName
$DefaultDomainName = $WinlogonRegKey.DefaultDomainName
$DefaultPassword = $WinlogonRegKey.DefaultPassword
$strUserName = "$DefaultDomainName`\$DefaultUserName"
}

If ($strUserName -and $DefaultPassword)
{
$Mode = "User"
} else {
Write-Error "Owner variable set to `"User`" but Auto Admin Logon is not configured!"
}
} elseif ($Context -ieq "System") {
$Mode = "System"
} else {
Write-Error "Incorrect Owner variable. it can only be `"User`" or `"System`""
}

#$thisScript = Split-Path $myInvocation.MyCommand.Path -Leaf
#$scriptRoot = Split-Path(Resolve-Path $myInvocation.MyCommand.Path)
#$PsExecPath = Join-Path $scriptRoot "PsExec.exe"
If (!(Test-Path $PsExecPath))
{
Write-Error "Unable to locate PsExec.exe in $scriptRoot. Please make sure it is located in this directory!"
} else {
#Get Console Session ID
$ConsoleSessionID = (Get-ConsoleSessionInfo).SessionID
if ($ConsoleSessionID)
{
If ($Mode -eq "User")
{
$strCmd = "$PsExecPath -accepteula -i $ConsoleSessionID -d -u $strUsername -p $DefaultPassword $PathToExe $arguments"
Write-Host "Executing $strCmd`..."
Invoke-Expression $strCmd
} elseif ($Mode -eq "System") {
$strCmd = "$PsExecPath -accepteula -i $ConsoleSessionID -d -s $PathToExe $arguments"
#run app under LOCALSYSTEM context
Write-Host "Executing $strCmd`..."
Invoke-Expression $strCmd
}
} else {
Write-Error "No one is currently logged on to the console session at the moment."
}
}

Note:this PowerShell script uses command “query session” to detect the session ID of the console session.

Note: When you save the configuration of this module, please ignore this error:

Add the following item under Configuration Schema tab:

Note: Make sure “TimeoutSeconds” type is set to “Integer” and others are set to “String”

I also defined “TimeoutSeconds” as an overridable paramter:

Finally, set the Accessibility to Public (so it can be used in other management pack once this management pack is sealed”):

07. Create a recovery task to run after Diagnostic Task that I created from the step 5.

• This recovery task has 2 modules: a condition detection module (System.ExpressionFilter) and an Actions module (From the Write Actions module I created from Step 6)

• Condition Detection Module (System.ExpressionFilter):
• 
• Click Edit and add below:

<Expression>
<SimpleExpression>
<ValueExpression>
<XPathQuery Type=”String”>Diagnostic/DataItem/Property[@Name='Result']</XPathQuery>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value Type=”String”>Positive</Value>
</ValueExpression>
</SimpleExpression>
</Expression>

Actions Module (Module Type from the write action module created in Step 6)

Note: Regarding to the Context variable, I designed the script to launch PsExec to execute the executable either under LOCALSYSTEM (  with –s  operator in PsExec) or under the user that’s configured for Auto Admin Logon (with –u <username> and –p <password> operators in PsExec). Because when Auto Admin Logon is enabled, the default username and password is stored in the registry key (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon). If “Context” is set to “User”, the script reads the username and password from registry and pass them into PsExec. So, if Auto Admin Logon is not configured, the script won’t work if “Context” is set to “User”

Note: In this example, the recovery task simply launch notepad.exe on the console session. I can also tell notepad to open a txt file if I add the path of the txt file to “Arguments”.

Note: This recovery task will error out if no one has logged on to the console session of the target computer.

Now, everything is setup, time to put it to test.

From screen capture below, I can see the monitor’s health became Error at 10:44pm 27/01/2012. After the Diagnostic task determined there is no notepad.exe running, the recovery task kicks in, at 10:45pm, it launched notepad.exe on console session (session ID 2). The PID of notepad.exe is 4000.

Now, when I go to the target computer, notepad is launched on the console session and I can easily get the details of notepad.exe process:

You can see from above screen capture, notepad.exe was started at the same time when the recovery task ran, the session ID is 2, Owner is the account configured for Auto Admin Logon and process ID is same as the output from PsExec. Therefore, this instance of notepad.exe is the one started by the recovery task!

I’ve attached the 2 scripts used in Diagnostic and recovery tasks below. as well as my sample unsealed MP.

Download From Here

Please feel free to contact me if you have any questions or suggestions.

Process performance collections rules are straightforward to setup, as long as there is ONLY ONE instance of the particular process running on the computers that your rule is targeting. Also, each rule can only collect ONE performance counter.

The problem with that is, if I need to collect performance counters for a particular service, i.e. Server Service (lanmanserver) or a particular SQL server instance (when there are multiple SQL instances running on the same server) , I will not be able to do so using the default performance collection module “System.Performance.OptimizedDataProvider” because server service runs under the generic service host svchost.exe. Typically, there are many instances of svchost.exe running for various services:

According to above screen capture, there are 10 instances of svchost.exe running on my computer. And when selecting performance counter in SCOM consoles, there are 10 instances of svchost:

It’s the same if I simply run perfmon on the computer: there are 10 instances of svchost:

There’s actually a blog article on TechNet explaining this issue with perfmon: Perfmon: Identifying processes by PID instead of instance

So, there is a workaround for perfmon, but it doesn’t really help me with my performance collection rule in SCOM.

To overcome this issue, I had to create some customized modules to collect the counters that I’m interested in via WMI. I’ll now explain what I’ve done to achieve the goal.

1. I firstly created a probe action module to run a vbscript to collect ALL the counters I’m interested in via WMI. In the script:

1. takes the service name and computer name from the input parameter, get the PID for the service from win32_service class (note, I had to pass computer name to the script so it can connect to remote computer’s WMI namespace, this is required for agentless monitoring)
2. retrieve the values of the performance counters from Win32_PerfFormattedData_PerfProc_Process class using query “Select * from Win32_PerfFormattedData_PerfProc_Process Where IDProcess = ProcessID” (ProcessID was retrieved from step 1)
3. For each performance counter, create a property bag and add the property bag to MOM.ScriptAPI object
4. Return all property bags.

2. Create a Data Source module which contains 3 modules and the modules are executed on the following order:

1. System.SimpleScheduler (runs according to a schedule)
2. Probe module created from step 1 (retrieve performance counters and return then via property bag)
3. System.Performance.DataGenericMapper (Map the property bag values to performance data)

Now that I’ve created all the required modules, I can then create a SINGLE rule to collect all different counters that I defined in the probe action module. To do so:

1. In Authoring console, create a Custom Rule:

2. Give the rule a name and choose the target:

3. Add the data source module I previously created and configure the variables (service name is the actual service name, NOT service display name):

Note: The Computername variable from above example is “$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$”, this is correct because I’m targeting the rule to Windows Computer. You will have to change it if you are targeting other classes. The best way is to use the prompt and choose the host’s principal name. Below is an example if I target the rule to Windows Operating System:

4. Add 2 Actions module (don’t need to configure them):

1. Microsoft.SystemCenter.CollectionPerformanceData (WriteToDB)
2. Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData (WriteToDW)

Note: The 2nd action module WriteToDW is from Microsoft.SystemCenter.DataWarehouse.Library. you will have to add this library as a reference of your management pack.

Now, the rule is created, you can create a performance view for the rule and make sure it is collecting data:

Below is the VBScript I’ve used in probe action module:

'=========================================================================
' AUTHOR:             Tao Yang
' Script Name:        ProcessPerfMonData.vbs
' DATE:               23/01/2012
' Version:            1.0
' COMMENT:            Script to collect perfmon data for specific service
'=========================================================================
Option Explicit
SetLocale("en-us")
Dim ServiceName, objWMIService,colService, objService, ComputerName
Dim ProcessID, ProcessName, colProcess, objProcess, colPerfData, objPerfData
Dim ElapsedTime, PercentProcessorTime, PercentUserTime, ThreadCount, PageFaultsPersec, IOReadBytesPersec, IOWriteBytesPersec
Dim oAPI, oBag, oInst
ServiceName = WScript.Arguments.Item(0)
ComputerName = Wscript.Arguments.Item(1)
Set oAPI = CreateObject("MOM.ScriptAPI")

Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & ComputerName &"\root\cimv2")
Set colService = objWMIService.ExecQuery("Select * from Win32_Service Where Name = '" + ServiceName + "'")

For Each objService in colService
ProcessID = objService.ProcessID
Next

If ProcessID <> 0 THEN
Set colProcess = objWMIService.ExecQuery("Select * from Win32_Process Where ProcessID = " & ProcessID)
For Each objProcess in colProcess
ProcessName = objProcess.Name
Next
Set colPerfData = objWMIService.ExecQuery("Select * from Win32_PerfFormattedData_PerfProc_Process Where IDProcess = " & ProcessID)
For Each objPerfData in colPerfData
ElapsedTime = objPerfData.ElapsedTime
PercentProcessorTime = objPerfData.PercentProcessorTime
PercentUserTime = objPerfData.PercentUserTime
ThreadCount = objPerfData.ThreadCount
PageFaultsPersec = objPerfData.PageFaultsPersec
IOReadBytesPersec = objPerfData.IOReadBytesPersec
IOWriteBytesPersec = objPerfData.IOWriteBytesPersec
Next
'Elapsed Time
Set oBag = oAPI.CreatePropertyBag()
oBag.AddValue "Object", "Process"
oBag.AddValue "Instance", ServiceName
oBag.AddValue "Counter", "Elapsed Time"
oBag.AddValue "Value", ElapsedTime
oAPI.AddItem(oBag)

'Percent Processor Time
Set oBag = oAPI.CreatePropertyBag()
oBag.AddValue "Object", "Process"
oBag.AddValue "Instance", ServiceName
oBag.AddValue "Counter", "% Processor Time"
oBag.AddValue "Value", PercentProcessorTime
oAPI.AddItem(oBag)

'Percent User Time
Set oBag = oAPI.CreatePropertyBag()
oBag.AddValue "Object", "Process"
oBag.AddValue "Instance", ServiceName
oBag.AddValue "Counter", "% User Time"
oBag.AddValue "Value", PercentUserTime
oAPI.AddItem(oBag)

'Thread Count
Set oBag = oAPI.CreatePropertyBag()
oBag.AddValue "Object", "Process"
oBag.AddValue "Instance", ServiceName
oBag.AddValue "Counter", "Thread Count"
oBag.AddValue "Value", ThreadCount
oAPI.AddItem(oBag)

'Page Faults/Sec
Set oBag = oAPI.CreatePropertyBag()
oBag.AddValue "Object", "Process"
oBag.AddValue "Instance", ServiceName
oBag.AddValue "Counter", "Page Faults/sec"
oBag.AddValue "Value", PageFaultsPersec
oAPI.AddItem(oBag)

'IO Read Bytes/sec
Set oBag = oAPI.CreatePropertyBag()
oBag.AddValue "Object", "Process"
oBag.AddValue "Instance", ServiceName
oBag.AddValue "Counter", "IO Read Bytes/sec"
oBag.AddValue "Value", IOReadBytesPersec
oAPI.AddItem(oBag)

'IO Write Bytes/sec
Set oBag = oAPI.CreatePropertyBag()
oBag.AddValue "Object", "Process"
oBag.AddValue "Instance", ServiceName
oBag.AddValue "Counter", "IO Write Bytes/sec"
oBag.AddValue "Value", IOWriteBytesPersec
oAPI.AddItem(oBag)
ELSE
'Return an empty property bag
Set oBag = oAPI.CreatePropertyBag()
oAPI.AddItem(oBag)
END IF
oAPI.ReturnItems

As you can see, I’m collecting the following 7 counters in the script:

1. Elapsed Time
2. % Processor Time
3. % User Time
4. Thread Count
5. Page Faults/sec
6. IO Read Bytes/sec
7. IO Write Bytes/sec

You will need to modify the script if you are collecting different counters. for details of the counters you can collect, please refer to Win32_PerfFormattedData_PerfProc_Process class documentation here at MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/aa394277(v=vs.85).aspx

I’ve attached the script and the sample unsealed management pack at the bottom of this article. You can modify or recreate your own based on the samples. don’t forget to seal the management pack if you want to use the modules in other MPs.

VBScript: ProcessPerfMonData.txt

Unsealed MP: TYANG.Custom.Performance.Monitoring.xml

Below are 2 examples how to create trigger only probe modules for both PowerShell and VBScript:

1. PowerShell

Member Modules:

Microsoft.Windows.PowerShellPropertyBagTriggerOnlyProbe

Data Types:

Input: Trigger Only

Output: System.PropertyBag Data

2. VBScript:

Member Modules:

System.PassThroughProbe

Microsoft.Windows.ScriptPropertyBagProbe

Data Type:

Input: Trigger Only

Output: System.PropertyBag Data

Actions Module Type: System.CommandExecuter

Module Configuration

Application Name: C:\Windows\System32\cmd.exe

Working Directory: C:\Windows\System32

CommandLine: /c <Path to Batch file> (i.e. /c C:\Apps\DelFile.bat)

TimeoutSeconds: <i.e. 60>

RequiredOutput: true

In PowerShell Datetime object, there is a ToUniversalTime() method that converts local time to UTC time.

However, there isn’t a native way to convert FROM UTC To local time. So I wrote this function:

Function Get-LocalTime($UTCTime)
{
$strCurrentTimeZone = (Get-WmiObject win32_timezone).StandardName
$TZ = [System.TimeZoneInfo]::FindSystemTimeZoneById($strCurrentTimeZone)
$LocalTime = [System.TimeZoneInfo]::ConvertTimeFromUtc($UTCTime, $TZ)
Return $LocalTime
}

In Part 2, I’ll cover the steps involved to create each module type and the rule in this article. all these objects will be created in SCOM 2007 R2 Authoring Console. You can create a new management pack for this or use an existing one.

Firstly, we will need create the probe action and data source modules:

Probe Action Module:

1. Under Type Library pane, go to “Probe Actions” under Module Types and click New—>”Composite Probe Action…”

2. Give it a unique identifier such as “Your.Management.pack.Prefix.Database.Catcher.Probe.Action”

3. in general tab, give it a name:

4. Under Member Modules, add “Microsoft.Windows.PowerShellPropertyBagTriggerOnlyProbe” and give it a Module ID of “PSScript”

5. Click on Edit

6. Enter the ScriptName and TImeoutSeconds. Then Edit again in the Configuration tab of the probe action module

6. When the text editor is launched, Enter the powershell script in between <ScriptBody> and </ScriptBody> tags

7. Below is the script I used in my management pack. please edit it to suit your needs:

#-----------------------------------
#Alarms capture via AuditDB
#Name:        AuditDBAlarmCatcher.PS1
#Param 0:    SQL Database Instance Name
#Param 2:    Database name
#Param 2:    The inteval in seconds
#Author:    Tao Yang
#Date:        07/12/2011
#-----------------------------------

param([string]$SQLInstance,[String]$Database,[Int]$Interval)
$EVENT_TYPE_ERROR = 1
$EVENT_TYPE_WARNING = 2
$EVENT_TYPE_INFORMATION = 4

Function Get-LocalTime($UTCTime)
{
$strCurrentTimeZone = (Get-WmiObject win32_timezone).StandardName
$TZ = [System.TimeZoneInfo]::FindSystemTimeZoneById($strCurrentTimeZone)
$LocalTime = [System.TimeZoneInfo]::ConvertTimeFromUtc($UTCTime, $TZ)
Return $LocalTime
}

$oAPI = New-Object -ComObject "MOM.ScriptAPI"
$oBag = $oAPI.CreatePropertyBag()
$strServer = ".\$SQLInstance"

$ADOCon = New-Object -ComObject "ADODB.Connection"
$oResults = New-Object -ComObject "ADODB.Recordset"
$adOpenStatic = 3
$adLockOptimistic = 3
$ADOCon.Provider = "sqloledb"
$ADOCon.ConnectionTimeout = 60
$nowInUTC = (Get-Date).ToUniversalTime()
$StartTime = $nowInUTC.AddSeconds(-$Interval)
$conString = "Server=$strServer;Database=$Database;Integrated Security=SSPI"
$strQuery = "Select * from V_Audit Where EventTypeCaption LIKE 'Alarm triggered' AND EventDate >= '$StartTime'"
$ADOCon.Open($conString)
$oResults.Open($strQuery, $ADOCon, $adOpenStatic, $adLockOptimistic)
$oBag.AddValue('Interval', $Interval)
If (!$oResults.EOF)
{
If (!([appdomain]::currentdomain.getassemblies() | Where-Object {$_.FullName -ieq "system.core"}))
{
Try {
Write-Host "Loading .NET DLL into Powershell..." -ForegroundColor Green
[Void][System.Reflection.Assembly]::LoadWithPartialName("System.Core")
} Catch {
#We cannot use Write-Error cmdlet here because $ErrorActionPreference is set to "SilentlyContinue" so it won't display on the screen.
Write-Host "Unable to load .NET Framework into Powershell, please make sure it is installed!" -foregroundColor Red
Exit
}
}
$oBag.AddValue('GenerateAlert', 'True')
$arrLogEntries = @()
$oResults.MoveFirst()
Do {
$EventDate = $oResults.Fields.Item("EventDate").Value
$EventDate = Get-LocalTime $EventDate
$Description = $oResults.Fields.Item("Description").Value
$arrLogEntries += "- $EventDate`: $Description"
$oResults.MoveNext()
} until ($oResults.EOF)
$LogDetail = [System.String]::Join("
", $arrLogEntries)
$intEntryCount = $arrLogEntries.count
Remove-Variable arrLogEntries
} else {
$oBag.AddValue('GenerateAlert', 'False')
$intEntryCount = 0
}
$oResults.Close()
$ADOCon.Close()

$oBag.AddValue('LogEntry', $LogDetail)
$oBag.AddValue('LogEntryCount', $intEntryCount)
$oBag

8. Enter below sections after </ScriptBody> and before <TimeoutSeoncds>:

<Parameters>
<Parameter>
<Name>SQLInstance</Name>
<Value>$Config/SQLInstance$</Value>
</Parameter>
<Parameter>
<Name>Database</Name>
<Value>$Config/Database$</Value>
</Parameter>
<Parameter>
<Name>Interval</Name>
<Value>$Config/Interval$</Value>
</Parameter>
</Parameters>

9. Click Save in the text editor and close it. you should now see what you’ve entered in the configuration tab of the probe action module:

10. Click OK to exit the configuration tab. Under Configuration Schema tab, add 3 parameters (in same order) as shown below:

11. Under Data Types, make sure the input and output data is set as below (should be default anyway):

12. Under Options, I left Accessibility to “Internal”, but if you are going to use this module outside of this management pack, set it to public.

13. Now click OK to exit the probe module window. the probe action module is now created. Now it’s a good time to save the management pack.

Data Sources Module:

1. Under Type Library pane, go to “Data Sources” under Module Types and click New—>”Composite Data Source…”

2. Give it a unique identifier such as “Your.Management.pack.Prefix.Database.Catcher.DataSource”

3. Open the data source module you’ve just created and give it a display name under “General” tab:

4. Add 2 member modules:

5. Edit the SimpleScheduler module, for the IntervalSeconds value, click on “promote…”. this will set it to “$Config/IntervalSeconds$”. and leave SyncTime to blank:

6. Edit the probe action module, use promote to set values for all 3 parameters:

7. Configure “Configuration Schema” tab as below (again, make sure these parameters are in the right order”):

8. Configure Overridable Parameters as below:

9. Make sure output data type is set to System.PropertyBagData

10. Set accessibility to “public” if you are going to access this module from other management packs.

Now the data source module is complete. We are going to create the rule next.

Rule:

1. Under Health Model pane, go to “Rules” and click New—>”Custom Rule…”

2. Give it a unique identifier such as “Your.Management.pack.Prefix.Database.Catcher.Rule”

3. Give the rule a display name  and select the target class where you want to run the rule under general tab

4. In Modules tab, create a data source module with the type of the data source module type you’ve created previously. give it a module ID of DataSource

5. Edit the data source module configuration, enter the values for all 3 parameters: SQLInstance, Database and IntervalSeconds:

According to above example, this rule will connect to the database “AuditDB” in the particular SQL instance that you specified and will run in every 5 minutes (300 seconds)

6. Now, create a condition detect module with type: System.ExpressionFilter and Module ID: Filter_AlertCondition

7. Edit the condition detection module, under configuration tab, click on Configure… button.

8. Enter the expression as below:

Parameter Name: Property[@Name='GenerateAlert']

Operator: Equals

Value: True

Click OK to save.

It looks like this when it’s done:

9. Create an Action module. Type: System.Health.GenerateAlert. ModuleID: Alert.

10. Click Edit for the Action module then click Edit again under Configuration tab to edit the XML.

11. Add below section in the XML before </Configuration> tag:

<AlertParameters>
<AlertParameter1>$Target/Property[Type="System!System.Entity"]/DisplayName$</AlertParameter1>
<AlertParameter2>$Data/Property[@Name='Interval']$</AlertParameter2>
<AlertParameter3>$Data/Property[@Name='LogEntryCount']$</AlertParameter3>
<AlertParameter4>$Data/Property[@Name='LogEntry']$</AlertParameter4>
</AlertParameters>

12. save the XML and exit the text editor. then click on Configure to configure the alert. you may use the parameters from previous step to form the alert description.

13.Edit the Production knowledge of this rule if you like. it will also appear with the alert.

Now we are done. You can save this unsealed management pack or seal it using authoring console. please make sure you test it before import it into your production environment.

Below is a sample alert from my test environment:

Few notes:

1. The database that I had to work with was a SQL Express DB. I found this free tool extremely useful since I can’t use SQL management studio to connect to SQL Express databases:  Database Browser. The database table screen capture from Part 1 of this series was from this tool.
2. When testing the PowerShell Script, I needed to run the script under Local Systems as my account did not have access to the database. Since in my script, I connected to the database using integrated security, I had to make sure I run the script under the account which is going to be used to run the rule (in my case, Local Systems), I had to use PSExec from Sysinternals to launch Powershell as it allows me to run executables under Local System.
3. Originally I used a multi-line string variable in PowerShell script to store records returned from SQL query (one record per line). It didn’t work after added the script to the management pack. I figured out i can use the special HTML character for carriage return inside the string variable in Powershell. So the line looks like this:

My sample PowerShell script can be downloaded from HERE.

1. Part 1 includes the background and overview of the rule and it’s workflow
2. Part 2 documents all the steps to create all the module types and the rule itself.

This article is the first part of the 2-part series.

Recently, I’ve been writing a SCOM management pack for a new application that my employer is implementing. This application logs any application related alarms into a SQL express database. One of the requirement for the MP is to catch these alarms from the database and generate alerts based on these alarms.

In the database, I’m interested in any records that has the value of “Alarm triggered” in “EventTypeCaption” column.

The the record is added to the database, the application also adds the time stamp in UTC to the “EventDate” field.

Below is a snapshot of a subset of the database. I’ve highlighted the records that I’m interested in:

To achieve this goal, I’ve written some custom modules and created a rule using these modules.

Rule overview:

As usual, the rule contains 3 modules:

1. Data Source
2. Condition Detection
3. Actions

Below is the flow chat for the entire workflow:

To explain the workflow in details:

1. The workflow takes 3 inputs:
1. IntervalSeconds – how frequent does the rule run
2. SQLInstance – Name of the SQL instance
3. Database – Name of the database
2. The data source member module system.simple.scheduler runs according to the intervalseconds
3. The Probe Action member module (a PowerShell script) takes all 3 inputs:
1. connect to the database in the SQL instance as specified from the input
2. calculate the earliest time (current time minus intervalseconds from the input then convert to UTC). store the earliest time in a datetime variable $starttime
3. Build the SQL query: “Select * from <table name> Where EventTypeCaption LIKE ‘Alarm triggered’ AND EventDate >= ‘$StartTime’”
4. Execute the SQL query.
5. If returned any data:
1. Property Bag value “GenerateAlert” = True
2. For each record, convert the EventDate from UTC time to local time.
3. combine all records from the record set to a multi line string that include converted event date and event description. return this string as Property Bag value “LogEntry”
4. return Property Bag Value “LogEntryCount”
4. Condition Detection module detects Property Bag value “GenerateAlert” = True
5. If passed Condition Detection Module, the Write Action module generates alert with LogEntry and LogEntryCount in alert description field.

Note: I’m using PowerShellPropertyTriggerOnlyProbe rather than VBscript because I found it’s easier to convert UTC and local time back and forth as I can simply use .NET class System.TimeZoneInfo and powershell datetime object ToUTC() method to do the conversion. if we are to use VBScript, there is no equivalent trigger only probe for VBScript. I’ll try to cover this in a separate blog post.

What’s Next?

I’ll go through how to create each module types and the rule itself in part 2 of this series.

To be continued…

Part 2

Here’s the script to run in OpsMgr Command Shell:

$newSMTP = <name of your new SMTP server>
$SMTPChannels = Get-NotificationAction |Where-Object {$_.Name –imatch “smtp”}
Foreach ($item in $SMTPChannels)
{
$item.Endpoint.PrimaryServer.Address = $newSMTP
$item.Endpoint.update()
}

We soon found out it’s because SCCM 2007 is a 32-bit app and DPM PowerShell snapin is only available for 64-bit PowerShell because we could not run the script from a 32-bit PowerShell console.

When a 32-bit application tries to access %WinDir%\system32, Windows redirects it to %WinDir%\SysWOW64. In order for the 32-bit app to access %WinDir%\System32 folder, we have to use %Windir%\sysnative.

So, we set the command line of the program in SCCM package to “%WinDir%\Sysnative\WindowsPowerShell\V1.0\Powershell.exe” –noprofile .\PowerShellScript.ps1 as that’s where the 64-bit version of PowerShell is and the SCCM advertisement ran successfully on the client.

More reading regarding to file system redirection here: http://support.microsoft.com/kb/942589

So I wrote a 2 very simple alert generating rules to detect USB Mass Storage Device creation and deletion WMI event. I set both rules to run every 60 seconds so within 60 seconds of the event, an Information alert is generated in SCOM:

Alert for USB Storage Device Connection Event:

Alert for USB Storage Device Removal Event:

I have also created a dynamic group called Virtual Windows Computers in the MP so I can disable both rules for virtual machines. This is how I defined the group:

Please note this Virtual Machine discovery only detects virtual machines running on Microsoft’s virtual host platform. If you open System Center Internal Library MP in MPViewer and check the Raw XML for discovery “Discover if Windows Computer is a Virtual Machine”, you’ll see it the WQL:

So if you have non-Microsoft virtual machines (i.e. VMware) in your environment and you want to disable these 2 rules for those virtual machines, you will need to modify my group or create your own group in my management pack.

Download: USB Storage Device Detection Management Pack

I’ve been wanting to do this for a while now and finally found some spare time for it. I want to be able to target OpsMgr (SCOM) agents and servers in ConfigMgr (SCCM) in a more granular way (i.e. all OpsMgr agents that are reporting to a OpsMgr Management Server, or all OpsMgr agents within a OpsMgr management group or All OpsMgr management servers)

Therefore, I created these extensions for configuration.mof and sms_def.mof so OpsMgr settings are captured as part of ConfigMgr client hardware inventory.

Once loaded in to ConfigMgr and after clients have retrieved new policy and performed hardware inventory, you will be able to see this in Resource Explorer:

For OpsMgr Agents:

For OpsMgr Servers:

Note: As always, make sure backup both mof files before editing them. once saved, monitor dataldr.log to make sure they are successfully compiled.

Please refer to my previous blog if you decide to remove this mof extention from your ConfigMgr environment.

More Reading about ConfigMgr Hinv (Hardware Inventory):

Technet: About MOF Files Used by Hardware Inventory

Technet Blog: How to Extend Your Hardware Inventory Using the SMS_DEF.MOF File

Collection Query Samples:

All OpsMgr agents in Management Group TYANG:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_CUSTOM_OPSMGR_2007_AGENT_SETTING_2_0 on SMS_G_System_CUSTOM_OPSMGR_2007_AGENT_SETTING_2_0.ResourceId = SMS_R_System.ResourceId where SMS_G_System_CUSTOM_OPSMGR_2007_AGENT_SETTING_2_0.ManagementGroup = "TYANG"

All OpsMgr agents managed by OpsMgr Management Server SCOM02:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_CUSTOM_OPSMGR_2007_AGENT_SETTING_2_0 on SMS_G_System_CUSTOM_OPSMGR_2007_AGENT_SETTING_2_0.ResourceId = SMS_R_System.ResourceId where SMS_G_System_CUSTOM_OPSMGR_2007_AGENT_SETTING_2_0.ManagementServer = "SCOM02.corp.tyang.org"

All OpsMgr Management Servers:

select *  from  SMS_R_System inner join SMS_G_System_CUSTOM_OPSMGR_2007_SERVER_SETTING_2_0 on SMS_G_System_CUSTOM_OPSMGR_2007_SERVER_SETTING_2_0.ResourceId = SMS_R_System.ResourceId where SMS_G_System_CUSTOM_OPSMGR_2007_SERVER_SETTING_2_0.IsServer = 1

If you decide to clean them up, MyITForum.com has a great WIKI page for SCCM hardware inventory which talked about different ways to clean up hardware inventory data.

I have tried the free SiteSweeper tool from SCCMExpert.com which was mentioned in the WIKI page. It’s easy to use and you can remove multiple classes from site database at once:

Other than removing the data from site databases throughout the hierarchy, the WMI class which you defined in the configuration.mof still exists in the client. I didn’t bother to look further to find tools/utilities to delete WMI classes, but simple found a sample vbscript from MSDN to modify WMI classes, and modified a little bit:

DeleteWMIClass.vbs:

wbemCimtypeString = 8             ' String datatype
Set objSWbemService = GetObject("Winmgmts:root\cimv2")
Set objClass = objSWbemService.Get()
objClass.Path_.Class = "<name of WMI class you wish to delete>"

' Remove the new class and instance from the repository
objClass.Delete_()
If Err &lt;&gt; 0 Then
WScript.Echo Err.Number &amp; "    " &amp; Err.Description
Else
WScript.Echo "Delete succeeded"
End If

' Release SwbemServices object
Set objSWbemService = Nothing

To modify it, specify the WMI class you wish to delete on line 4. If the WMI class is not located in root\CIMV2 namespace, change line 2 as well.

I created a package in SCCM and advertised it to all systems.

Note: When you create the program, make sure you use the syntax “Cscript DeleteWMIClass.vbs” so the output is redirected to command prompt rather than a message box.

Unknown error encountered processing an instance of class <name of the WMI class>: 80041001

I checked the SCCM client, the WMI class was created correctly, but the inventory data was not loaded in the SCCM database therefore I could not view it in Resource Manager.

After gone through both configuration.mof and sms_def.mof many times made sure they are 100% correct, I found this error is actually caused by a bug in SCCM 2007.

Because the SCCM client I’m using for testing is a Windows 2008 R2 machine (therefore 64 bit) and the issue with 64 bit client is documented here.

Also, while I was playing with mof files, I found this awesome tool called RegKeyToMOF. The current version is v3.0 and can be found here. It supports SMS 2003, SCCM 2007 and SCCM 2012 Beta 2.

it automatically generates mof extensions for you when you select the registry key that you want to inventory:

If you are planning to use this tool to generate the configuration.mof and sms_def.mof extensions, please make sure you tick “Enable 64bits (for Regkeys not written in Wow6432Node)” if you have 64-bit SCCM clients in your environment (nowadays, I can’t imagine that you don’t!). This is also what above mentioned KB article suggested.

To explain it, let me firstly go through how to do this in SCOM console and then I’ll compare this process with using SCOM PowerShell cmdlets.

So, to add a new network device using SCOM console, it’s pretty easy:

1. Launch Discovery Wizard and choose “Network Devices”

2. Enter the network device information

3. Select the device from discovery result and choose a proxy agent for this network device

Please note the default proxy agent is set to the management server from previous step. it can be changed by click on Change button

It lists all possible proxy agents. There are 3 management servers in my test environment, SCOM01 is my RMS, SCOM02 is a management server and SCOMGW01 is a gateway server located in another untrusted forest. I have highlighted these 3 servers, notice the icon for management servers is different than other normal agents.

4. continue on and complete the rest steps of the wizard.

Now, let’s look at how to do this in PowerShell:

1. Get Network Device monitoring class

$networkdeviceclass = get-monitoringclass -name 'System.NetworkDevice'

2. Create a new DeviceDiscoveryConfiguration object

$dc = new-devicediscoveryconfiguration -monitoringclass $networkdeviceclass –fromipaddress “192.168.1.253” -toipaddress “192.168.1.253”

3. Define SNMP community string

$encoding = new-object System.Text.UnicodeEncoding

$encodedCommunityString = $encoding.GetBytes("tyang")

$dc.ReadOnlyCommunity = [System.Convert]::ToBase64String($encodedCommunityString)

4. Default SNMP version is 2, if the network device requires version 1, set the device discovery configuration to use SNMP version 1:

$dc.snmpversion = 1

5. Define the management server to be used in the discovery

$NWDeviceMS = Get-ManagementServer | Where-object {$_.displayname –ieq “SCOM02.corp.tyang.org”}

6. Start discovery using the management server defined in step 5

$DiscoveryResult = Start-Discovery -managementserver $NWDeviceMS -DeviceDiscoveryConfiguration $dc

7. If discovery is successful, add the device into SCOM.

if ($discoveryresult.monitoringtaskresults[0].status -ieq "succeeded")
{
#code to add the device into SCOM
}

Well, here’s the issue:

if you use the Add-RemotelyManagedDevice cmdlet, you have to use a SCOM AGENT as the proxy agent. You CANNOT choose a management server as the proxy agent for the network devices you are about to add.

The management server is not an agent, get-agent cmdlet does not return management servers:

And if I use the management server in Add-RemotelyManagedDevice cmdlet, it will fail:

Basically, object type mismatch…

So, if we want to use a management server as the proxy agent for network devices, we CANNOT use Add-RemotelyManagedDevice cmdlet. It is a limitation in SCOM PowerShell snap-in. Instead, There is a method in the management server object called “InsertRemotelymanagedDevices”:

we have to use this method to add network devices.  Therefore, the script for step 7 should be:

if ($discoveryresult.monitoringtaskresults[0].status -ieq "succeeded")
{
$NWDeviceMS.InsertRemotelyManagedDevices($DiscoveryResult.custommonitoringobjects)
}

8. Check result:

As you can see, the device has been successfully added.

Anyways, in the last couple of days, I noticed on the 2-Node RMS cluster at work, when RMS is running on Node B, Event ID 29104 is logged in Operations Manager event log:

“OpsMgr Config Service failed to send the dirty state notifications to the dirty OpsMgr Health Services. This may be happening because the Root OpsMgr Health Service is not running.”

This event was only generated when RMS was running on Node B, also, when Node B was the active node, RMS health state was greyed out in SCOM console. If I fail over RMS to Node A, everything is fine.

After spent some time troubleshooting the issue, I have found there are some registry keys mismatch between 2 nodes, they are under HKLM\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Server Management Groups\<Management Group Name>\

On node B, “IsRootHealthService” is set to 0, Node A is set to “1”

Also on node B, there is a set of sub keys “Parent Health Services”. this set of keys should not exist in RMS:

So, to fix the issue, I firstly failed over RMS to node A, then changed “IsRootHealthService” on node B to “1” and deleted “Parent Health Services” key from node B. After that, I failed RMS back to node B, the 29104 events were no longer been logged and the RMS health state is not grey anymore.

Again, I did not consult Microsoft on this one, please take a back up of the registry keys before you change it and I am not responsible for any damages it may cause.

I have scheduled it to run daily on RMS via Windows Task Scheduler.

How does it work:

1. Backup unsealed MPs to a local folder.
2. Delete older backups from local folder
3. robocopy backup from local folder to a remote location using purge option (Anything that not exist from source will be deleted from destination. Therefore old backups are deleted from remote folder as well.)

Preparing the script:

Modify line 21-23 to suit your environment

$backuproot – local folder where MPs are backed up to.

$remoteLocation – Remote location where backups are robocopied to.

$daysToKeep – retention period

Finally, make sure you the account scheduled task runs under has appropriate rights in SCOM.

Download the script HERE.

Symptoms:

When using SCCM Client Center, it shows this particular client (MGMT01) has 3 maintenance windows (service window) assigned to it:

PolicySpy from ConfigMgr 2007 Toolkit also shows the same:

The problem is, there should ONLY be 1 maintenance window for this client:

and actually, there is ONLY 1 maintenance window in total in my entire environment:

I ran “SELECT * from v_ServiceWindow” against the site database and there is only 1 row returned.

Background:

Sometime last year, I installed a new central site called “CEN” and set the existing primary site “TAO” as the child site.

The only legitimate maintenance window in my SCCM hierarchy should be the one showed above in the database, it is created for a collection I created called “All Windows Server 2008 R2 Systems (CEN0000E)” on central site “CEN”.

I suspect I might have created 2 maintenance windows for the 2 built-in collections “All Systems” (SMS00001)” and “All Windows Server Systems (SMS000DS)” on site “TAO” before I configured “TAO” as child primary under “CEN”. but it has been too long and I couldn’t remember it.

Troubleshooting:

1. I tried to reset SCCM clients policies using PolicySpy, it did not help. these maintenance windows came back after machine policy retrieval and evaluation and it is logged in PolicyEvaluator.log:

Updating policy CCM_Policy_Policy4.PolicyID=”SMS00001-{bf9d2dba-eb0a-412f-9147-82f12b4f136a}”,PolicySource=”SMS:TAO”,PolicyVersion=”1.00″    PolicyAgent_PolicyEvaluator    16/08/2011 8:23:41 AM    3624 (0x0E28)

Applying policy SMS00001-{bf9d2dba-eb0a-412f-9147-82f12b4f136a}    PolicyAgent_PolicyEvaluator    16/08/2011 8:23:41 AM    3624 (0x0E28)

2. Since I cannot modify the built-in collections from the child primary sites because they also exist in parent sites, and it is only a test environment, I removed parent-child relationship between CEN and TAO and waited overnight, then checked maintenance windows settings for SMS00001 and SMS000DS on TAO, there are no maintenance windows created for these 2 collections. So this step did not help me resolving the issue.

3. I then had a look at the policy table in both CEN and TAO site databases trying to find the policy for these orphaned maintenance windows using the policyID showed in PolicySpy:

I ran “SELECT * FROM Policy where PolicyID  LIKE ‘SMS%’” on both site databases, “CEN” database returned nothing and “TAO” has returned 2 rows and the policyIDs match the ones for orphaned maintenance windows:

I deleted these 2 rows from Policy table:

delete FROM Policy where PolicyID = 'SMS00001-{bf9d2dba-eb0a-412f-9147-82f12b4f136a}'
delete FROM Policy where PolicyID = 'SMS000DS-{4fe54281-f3f1-4b9f-9d9e-d1eb12b4a87e}'

and from PolicyAssignment table:

delete FROM PolicyAssignment where PolicyID = 'SMS00001-{bf9d2dba-eb0a-412f-9147-82f12b4f136a}'
delete FROM PolicyAssignment where PolicyID = 'SMS000DS-{4fe54281-f3f1-4b9f-9d9e-d1eb12b4a87e}'

Then restarted SMS_EXECUTIVE and SMS_SITE_COMPONENT_MANAGER services on TAO site server (also the MP). – Not sure if this is required, I did it anyway.

Finally, I reset SCCM client policy via PolicySpy and initiated “Machine Policy Retrieval and Evaluation Cycle”

Once evaluation is completed, SCCM Client Center is showing the correct maintenance windows setting:

Since I need to do this to all SCCM clients (because SMS00001 = “All Systems” collection), I’ll create a software package with a batch file as program:

WMIC /Namespace:\\root\ccm path SMS_Client CALL ResetPolicy 1 /NOINTERACTIVE
WMIC /Namespace:\\root\ccm path SMS_Client CALL RequestMachinePolicy 1 /NOINTERACTIVE

Disclaimer: The purpose of this post is only to document the steps I have taken to resolve this particular issue in my TEST environment. I did not consult with any other parties (including Microsoft) during troubleshooting. Even though I have not seen any negative impacts after I implemented this change in my test environment, I am not responsible for any damages it may cause in other SCCM environments.