Adjusting the ConfigMgr Script Execution Timeout (pre 1810)

, , , , ,

In ConfigMgr, scripts that execute default to having an execution timeout of 60 seconds.  Normally this timeout is fine but you may run into situations where scripts run long and clients start receiving the following error in DcmWmiProvider.log.

In-line script execution time-out…
Failed to process CScriptProvider::PutInstanceAsync.
The script execution has timed out. (Error: 87D00321; Source: CCM)

ConfigMgr 1810 introduced the option to set the script timeout, if you are not up to 1810 yet and need to adjust the timeout then you are in the right place.  User raphael at posted a blog on how to adjust the timeout, this is a good script for a single site infrastructure but the client setting does not flow down from a CAS to primary sites.  For this reason I adapted his original script to handle a multi-level site hierarchy.  Update the variables at the top of the script as required and run it to set the script execution timeout.

$SiteCode = "CM1"
$SiteServer = ""
$ScriptTimeout = 120

$CCMAgents = (gwmi -Namespace root\sms\site_$SiteCode -Class SMS_SCI_ClientComp -ComputerName $SiteServer | where {$_.ClientComponentName -eq 'Configuration Management Agent'})

foreach ($CCMAgent in $CCMAgents)
    $props = $CCMAgent.Props
    for ($i = 0; $i -lt $props.count; $i++)
        if ($props[$i].PropertyName -eq "ScriptExecutionTimeout")
            $props[$i].Value = $ScriptTimeout
    $CCMAgent.Props = $Props

ALSO CHECK : Co-management - Multiple Pilot Policies

Keeping the SCCM Cache Clean with DCM

, , , ,

SCCM Cache Clean

In environments with frequent software distributions the SCCM cache folder can quickly take up large amounts of disk space.  This really becomes problematic on older systems or virtual machines with limited amounts of disk space.  Our support team found themselves having to constantly track down systems with low disk space and clean the cache.  I came up with this DCM configuration item to automatically detect and cleanup content in the cache which is older than the given number of days.  The detection and cleanup scripts both write to their own application event logs so you can see a history of cleanup activities.

Creating the CI

Create a new configuration item and select Windows Desktops and Servers as the type of configuration item.

Choose the appropriate operating systems.  In my case I selected all operating systems as I wanted the cache to be cleaned across the board.

Create a new setting and set it’s type to script and data type to string.

Add a discovery script for detecting old items in the cache folder.  Customize the number of days as you see fit.  You can also modify the event log source if desired.

$MinDays = 30

New-EventLog -LogName SCCM_Cleanup -Source "DCM" -ErrorAction SilentlyContinue
Write-EventLog -LogName SCCM_Cleanup -Source "DCM" -EntryType Information -EventId 1000 -Message "Detection starting for Cleanup CCMCACHE" -ErrorAction SilentlyContinue

$UIResourceMgr = New-Object -ComObject UIResource.UIResourceMgr
$Cache = $UIResourceMgr.GetCacheInfo()
$count = ($Cache.GetCacheElements() | where-object {[datetime]$_.LastReferenceTime -lt (get-date).adddays(-$mindays)} | Measure-object).Count

Write-EventLog -LogName SCCM_Cleanup -Source "DCM" -EntryType Information -EventId 1003 -Message "Total obsolete items found: $count" -ErrorAction SilentlyContinue
Write-EventLog -LogName SCCM_Cleanup -Source "DCM" -EntryType Information -EventId 1001 -Message "Detection ending for Cleanup CCMCACHE" -ErrorAction SilentlyContinue


Next, define a remediation script.  Once again you can customize the number of days and event log name.  The number of days should match your detection script.

$MinDays = 30

New-EventLog -LogName SCCM_Cleanup -Source "DCM" -ErrorAction SilentlyContinue
Write-EventLog -LogName SCCM_Cleanup -Source "DCM" -EntryType Information -EventId 1010 -Message "Remediation starting for Cleanup CCMCACHE" -ErrorAction SilentlyContinue

$UIResourceMgr = New-Object -ComObject UIResource.UIResourceMgr
$Cache = $UIResourceMgr.GetCacheInfo()
$Cache.GetCacheElements() | where-object {[datetime]$_.LastReferenceTime -lt (get-date).adddays(-$mindays)} | foreach { $Cache.DeleteCacheElement($_.CacheElementID) }

Write-EventLog -LogName SCCM_Cleanup -Source "DCM" -EntryType Information -EventId 1011 -Message "Remediation ending for Cleanup CCMCACHE" -ErrorAction SilentlyContinue

The final step is to create your compliance rule.  Set the value to check against to 0 and check the run remediation script checkbox.

Now after you test the new CI assign it to the appropriate baseline(s) for your environment.  Now you can forget about having to manually cleanup the SCCM cache folder ever again.


ALSO CHECK : Have you heard about Get-WQLObject?

Start Windows Update Service Compliance item

, ,

I have seen some environments where they only monitor services but not force them to restart. The logic in here can be used for any other service needed. This is especially helpful for the McAfee Framework Agent and WDS Service in the event the service has stopped. You are able to download a copy of the functional compliance item at the bottom of this post.

First we will stop the service and verify in a number of ways that the service is not running.

1. Powershell

get-service -serviceName wuauserv

2. Launching Services.MSC & searching for Windows Update

3. WMI Explorer

Creating the configuration item

Discovery Script

If ((get-service -name wuauserv).status -eq “Running”) {write-host “true”} Else {write-host “false”}

Remediation Script

get-service -name wuauserv | start-service

Compliance Setting

Create your own configuration baseline and associate it with the configuration we just created.

On my test machine you can see from the earlier screenshots that we WUAUServ was not running. This is reflected as “Not Compliant” in my evaluation.

Select Evaluate and after a refresh I see the system is now compliant meaning this service has been started.

You can track the Compliance item in the log files below.
DCMAgent.log: Records high-level information about the evaluation, conflict reporting, and remediation of configuration items and applications.
CIAgent.log: Records details about the process of remediation and compliance for compliance settings, software updates, and application management.
CMReporting.log : Records information about reporting policy platform results into state messages for configuration items.
DcmWmiProvider.log Records information about reading configuration item synclets from Windows Management Instrumentation (WMI).

EXTRA: I love status messages so here is how you check that.

From SCCM Console search for your compliance Item and make sure you grab the CI Unique ID

Open up the StateMesage.log and filter for the below


Please follow the link below to my TechNet page where you can download this compliance item.