WSUS Administration, WSUSPool, web.config, settings enforcement via Configuration Items

Just in case you got here via other means, I recommend checking out this information as well, with links to more maintenance routines and information--> https://deploymentresearch.com/Research/Post/665/Fixing-WSUS-When-the-Best-Defense-is-a-Good-Offense

A recent new storm (see here, Jeff Carreon's blog) of Clients’ software update scanning issues had our team re-evaluating all of our existing wsuspool , web.config, and wsus administration settings on our Software Update points. As some of you CM Admins may recall, there has been multiple times over the last few years where due to various and assorted things outside of our control, like metadata size for Windows Updates, we as CM admins have had to manually adjust settings in WSUS configuration. At my company, we had a few Configuration Items enforcing and monitoring those settings, but not all of them.

The below settings may or may not be the ones which are the settings YOU have in your environment. You are free to take them and modify them for whatever makes the most sense for your particular configuration. For us, these are the settings we’ve determined we want to monitor and enforce… at least at this time. It seems like the settings required for a healthy SU scanning environment seem to change every 18 months—at least here—so don’t presume these settings are the end-all be-all of golden configuration. Everyone is different, and things change. But hopefully, if you do need to monitor or set these in your environment, these examples can assist you in getting to your Golden Configuration.

Keep in mind this blog is written from the standpoint of a System Center Configuration Manager person, who has created these rules using what is called “Configuration Items”. The way I structured it was One Rule Per Configuration Item, at my company. However, one could just as easily have created one Configuration Item—and have multiple rules inside it. It’s more personal preference than anything else in this case. In my case, since I was building and testing the rules one by one, I wanted a clear separation in case I messed something up while testing in the lab.

“The Easy Button” – I exported the rules from my lab, and they are available --> here <--. You can import them into your System Center Configuration Management console, and adjust or review them there, and test them.  The exported rules are 14 CIs. To deploy them, you'd create a Baseline, add all 14 CIs to the Baseline.  Prior to saving the Baseline, modify each rule to be "optional" instead of "required".  Once saved, deploy the baseline to a test machine in "monitor" mode only--just to see what differences you might have.  You may want to modify multiple rules, or discard some as not necessary for you to monitor/remediate.  Once you are comfortable, deploy with 'remediation' and test again.

Occasionally, I’ve had requests to list out exactly what is inside each rule, usually because for whatever reason the import isn’t working as expected so the recipients can’t see what’s inside. So here is what is inside each Configuration Item… this will be long, but hopefully useful!

First of all, for each Configuration Item, I elected to make it an “Application” type. That because even though I’ve targeted the baseline just to the servers which I ‘know’ have the WSUS Feature installed, if someone were to accidentally deploy a baseline containing these rules to other devices, I want the CI to ‘not bother’ to run the CI test or remediation inside. It would be pointless and potentially confusing to people looking at reports. The “Detection” script for the Application is a Powershell Script type, this one line:

(Get-WmiObject -Namespace root\cimv2 -class win32_serverfeature -Filter "Name = 'WINDOWS SERVER UPDATE SERVICES'").Name

If anything is returned (the name), then the CI will assume the application is installed, and it will continue. If nothing is returned, it won’t continue.

Second, just about every single test requires the powershell model webadministration, using import-Module webadministration

Hopefully, your WSUS / Software Update point servers by default were installed with the add-windowsFeature Web-Server.Web-Scripting-Tools, but if you try to run these scripts interactively on a Software Update Point server, you get ‘failed to import webadministration module’, you’ll want to confirm that the web-scripting-tools component is installed—otherwise none of this will work.

Below are 14 Configuration Items we’re currently testing in our lab environment (will be moved to production once testing is complete). If you can’t import the .cab file attachment, worst case you can create your own Configuration Items using the below information.

 

CI 1

 

Title:

WSUS Administration Max Connections Should be Unlimited

Detection:

import-Module webadministration ; (get-itemproperty IIS:\Sites\'WSUS Administration' -name limits.maxConnections.Value)

Remediation Script:

import-Module webadministration ; set-Itemproperty IIS:\Sites\'WSUS Administration' -Name limits.maxConnections -Value 4294967295

Compliance Rule:

4294967295

CI 2

 

Title:

WSUS Administration MaxBandwidth should be unlimited

Detection:

import-Module webadministration ; (get-itemproperty IIS:\Sites\'WSUS Administration' -name limits.maxbandwidth.Value)

Remediation Script:

import-Module webadministration ; set-Itemproperty IIS:\Sites\'WSUS Administration' -Name limits.maxBandwidth -Value 4294967295

Compliance Rule:

4294967295

CI 3

 

Title:

WSUS Administration TimeOut should be 320

Detection:

import-Module webadministration

(get-itemproperty IIS:\Sites\'WSUS Administration' -Name limits.connectionTimeout.value).TotalSeconds

Remediation Script:

import-Module webadministration ; set-Itemproperty IIS:\Sites\'WSUS Administration' -Name limits.connectionTimeout -Value 00:05:20

Compliance Rule:

320

CI 4

 

Title:

WSUS ClientWebService web.config executionTimeout should be 7200

Detection:

import-Module webadministration

$FullFileName = (Get-WebConfigFile 'IIS:\Sites\WSUS Administration\ClientWebService').fullname

[XML]$xml = Get-Content $FullFileName

((($xml.configuration).'system.web').httpRunTime).executionTimeout

Remediation Script:

import-Module webadministration

$FullFileName = (Get-WebConfigFile 'IIS:\Sites\WSUS Administration\ClientWebService').fullname

$acl = get-acl $FullFileName

$ar = NewObject system.security.accesscontrol.filesystemaccessrule("NT Authority\SYSTEM","FullControl","Allow")

$acl.SetAccessRule($Ar)

Set-ACL $FullFileName $acl

[XML]$xml = Get-Content $FullFileName

$ChangeThis = ((($xml.configuration).'system.web').httpRunTime)

$ChangeThis.SetAttribute('executionTimeout', '7200')

$xml.Save($FullFileName)

Compliance Rule:

7200

 

NOTE: when setting the Compliance Rule, also check the box for “Report NonCompliance if this setting instance is not found”, because in some default installs of wsus, the web.config file doesn’t have this particular value at all. Checking that box there would ensure that it would be added if missing completely.

CI 5

 

Title:

WSUS ClientWebService web.config maxRequestLength should be 20480

Detection:

import-Module webadministration

$FullFileName = (Get-WebConfigFile 'IIS:\Sites\WSUS Administration\ClientWebService').fullname

[XML]$xml = Get-Content $FullFileName

((($xml.configuration).'system.web').httpRunTime).maxRequestLength

 

Remediation Script:

import-Module webadministration

$FullFileName = (Get-WebConfigFile 'IIS:\Sites\WSUS Administration\ClientWebService').fullname

$acl = get-acl $FullFileName

$ar = NewObject system.security.accesscontrol.filesystemaccessrule("NT Authority\SYSTEM","FullControl","Allow")

$acl.SetAccessRule($Ar)

Set-ACL $FullFileName $acl

[XML]$xml = Get-Content $FullFileName

$ChangeThis = ((($xml.configuration).'system.web').httpRunTime)

$ChangeThis.maxRequestLength = "20480"

$xml.Save($FullFileName)

Compliance Rule:

20480

CI 6

 

Title:

WSUS Service Should Be Running

Detection:

(Get-Service "WSUS Service").Status

Remediation Script:

Start-Service "WSUS Service"

Compliance Rule:

Running

CI 7

 

Title:

WSUSPool Application Pool Should be Started

Detection:

import-Module webadministration ; (Get-WebAppPoolState WSUSPool).Value

Remediation Script:

import-Module webadministration ; Start-WebAppPool -Name "WSUSPool"

Compliance Rule:

Started

CI 8

 

Title:

WSUSPool CPU ResetInterval should be 15 min

Detection:

import-Module webadministration ; (get-itemproperty IIS:\AppPools\Wsuspool -Name cpu.resetInterval.value).minutes

Remediation Script:

import-Module webadministration ; set-Itemproperty IIS:\AppPools\Wsuspool -Name cpu -Value @{resetInterval="00:15:00"}

Compliance Rule:

15

CI 9

 

Title:

WSUSPool Ping Disabled

Detection:

import-Module webadministration ; (get-itemproperty IIS:\AppPools\Wsuspool -Name processmodel.pingingEnabled).value

Remediation Script:

import-Module webadministration ; set-Itemproperty IIS:\AppPools\Wsuspool -Name processmodel.pingingEnabled False

Compliance Rule:

False

CI 10

 

Title:

WSUSPool Private Memory Limit should be 0

Detection:

import-module webadministration

$applicationPoolsPath = "/system.applicationHost/applicationPools"

$appPoolPath = "$applicationPoolsPath/add[@name='WsusPool']"

(Get-WebConfiguration "$appPoolPath/recycling/periodicRestart/@privateMemory").Value

 

Remediation Script:

import-module webadministration

$applicationPoolsPath = "/system.applicationHost/applicationPools"

$appPoolPath = "$applicationPoolsPath/add[@name='WsusPool']"

Set-WebConfiguration "$appPoolPath/recycling/periodicRestart/@privateMemory" -Value 0

 

Compliance Rule:

0

CI 11

 

Title:

WSUSPool queueLength should be 30000

Detection:

import-Module webadministration ; (get-itemproperty IIS:\AppPools\Wsuspool | Select queuelength).queueLength

Remediation Script:

import-Module webadministration ; set-Itemproperty IIS:\AppPools\Wsuspool -name queueLength 30000

Compliance Rule:

30000

CI 12

 

Title:

WSUSPool RapidFail Should be Disabled

Detection:

import-Module webadministration ; (get-itemproperty IIS:\AppPools\Wsuspool -name failure.rapidFailProtection).Value

Remediation Script:

import-Module webadministration ; set-Itemproperty IIS:\AppPools\Wsuspool -name failure.rapidFailProtection False

Compliance Rule:

False

CI 13

 

Title:

WSUSPool Recycling Regular Time interval should be 0

Detection:

import-Module webadministration ; ((get-itemproperty IIS:\AppPools\Wsuspool -name recycling.periodicRestart.time).Value).TotalMinutes

Remediation Script:

import-Module webadministration ; set-Itemproperty IIS:\AppPools\Wsuspool recycling.periodicRestart.time -Value 00:00:00

Compliance Rule:

0

CI 14

 

Title:

WSUSPool requests should be 0

Detection:

import-module webadministration

$applicationPoolsPath = "/system.applicationHost/applicationPools"

$appPoolPath = "$applicationPoolsPath/add[@name='WsusPool']"

(Get-WebConfiguration "$appPoolPath/recycling/periodicRestart/@requests").Value

 

Remediation Script:

import-module webadministration

$applicationPoolsPath = "/system.applicationHost/applicationPools"

$appPoolPath = "$applicationPoolsPath/add[@name='WsusPool']"

Set-WebConfiguration "$appPoolPath/recycling/periodicRestart/@requests" -Value 0

 

Compliance Rule:

0

 

 

  • Created on .

Example of Custom SQL Job to log to Application Event Viewer for ConfigMgr

This issue:  https://mnscug.org/blogs/sherry-kissinger/477-configmgr-current-branch-topic-id-611-swd-state-messages-flood, where Console admins accidentally checking the box for "Use Server Groups", where all members of that collection then start sending state messages every 1 minute, failing to patch, and potentially affecting State Message processing ... that occurred again in our environment.  We got lax in interactively checking for whether or not a collection accidentally had that done.  Since we have System Center Operations Manager for monitoring, and SCOM can trigger on EventIDs, we made a custom SQL Job to run multiple times a day, and if any collections (not already exempted/expected to have that setting) were to get that setting, that job will drop an Error into the Application Event Log on the Server.  A custom SCOM rule, and we'll now get alerted if this happens again.

In case someone else might find this useful, here is what we did. 

1) TEST first.  Create a collection with 1 member in it, and set that checkbox (so that you can test).  In SSRS itself, as a new query run this...modifying both of the "c3.name not in " entries for any known exceptions your environment already has.  Use Server Groups might be a valid and expected setting for servers in a Server Cluster, for example.  This is only to help assist when that setting is accidentally checked.

if (select case when count(c1.UseCluster) > 0 then 0 else 1 end as [result]
from CEP_CollectionExtendedProperties c1
join collections_g c2 on c2.collectionid=c1.collectionid
join v_collection c3 on c3.collectionid=c2.siteid
where c1.UseCluster=1
and c3.name not in ('Known Collection Name that Should Have that option checked','Another Collection that should be OK'))=0
BEGIN
 DECLARE @CollectionIDAndName nvarchar(200) = (
  select top 1 c2.siteid + ', ' + c3.name as [ValueToLog] from CEP_CollectionExtendedProperties c1
   join collections_g c2 on c2.collectionid=c1.collectionid
   join v_collection c3 on c3.collectionid=c2.siteid
   where c1.UseCluster=1
   and c3.name not in ('Known Collection Name that Should Have that option checked','Another Collection that should be OK')
)
 DECLARE @VALUE nvarchar(MAX) = ('At least 1 collection has Use Server Group Enabled: ' + @CollectionIDAndName + ' To resolve, either edit the SQL Job on the server to include this collection as a known exception, or edit that collection and uncheck Use Server Group. A possible consequence of that setting is machines in that collection may be unable to patch, and may also cause a state message backlog due to submitting state messages every minute')
 RAISERROR (@Value, 16, 1) with LOG
END

When you run that against your cm_xxx database in SSRS, because you created a test collection with that option checked, you should get an Error message in the Application Event Log on the server holding the cm_xxx database.  To test again, edit the properties of the collection and uncheck the box.  Then re-run the query to confirm it does NOT create an Application Event Log error message.  Once you have confirmed that an Event Log Error entry is created and works as you expect it to work, you can continue.

2) In SQL Server Management Studio, Create a new job, give it any name; but make it one you might understand when you or a coworker looks at sql jobs and is trying to make sense of it a year from now.  The Owner is your known standard owner, if you have a standard.  If you do not have a specific standard, try using sa or NT Authority\System.  (You just don't want to use your own individual personal ID--that is poor practice) You may also want to input as much of a description as possible.  For Steps, there will be only 1 step.
Type:  Transact-SQL script (T-SQL)
Run as:  <blank>
Database:  Your CM_xxx database
into the Command: area, input your entire tested sql script you tested successfully.

Under Advanced--use whatever Actions are your standards.  If you don't have a specific standard, we have "on success, quit the job reporting success", on Failure "Quit the job reporting failure".  0 retries, no output file, no log to table, run as user is blank.

Save the job (with no schedules for now).

3) test your job by editing the properties on a test collection and setting the "use Server Group" enabled.  Then in SQL SSRS, Jobs, right-click your job and  Run the Job from Step... and confirm you do get a new EventLog entry.  Remove the setting, and test again--ensuring you do NOT get a new EventLogEntry

4) Once you are satisfied it works as expected, using your favorite monitoring tool, whatever that might be (for us it was SCOM), set it up to monitor for Application Event Log, SOURCE: MSSQLSERVER  EventID: 17063  (that's what we got... confirm that is what you get in Application Event Log--I assume that is universal... but I've been wrong before, many many times)

5) Confirm your monitoring tool correctly reports on any new events, by again enabling Use Server Group on a test collection, run the job, removing, run the job.

6) Once confirmed; edit the job and add a Schedule or Schedules.  How frequently you would like this to run, and potentially alert on the issue, is up to your own standards and discretion.

Done!  With this in place, we hope we will get monitoring alerts about this situation... instead of alerts about a state message backlog.

  • Created on .

Configmgr Reports Leveraging SrsResources.dll display #Error instead of localized error descriptions

Issue:  Leveraging SrsResources.dll using ConfigMgr Reporting Services Reports used to work... but after an upgrade or reconfiguration any reports using the expression "=SrsResources.Localization.GetErrorMessage(Fields!ErrorCode.Value, User!Language) "  in the report just says #Error

Resolution:

I'll give the quick resolution here, and the long explanation later.

  1. Get the absolute latest version of SrsResources.dll you have, by looking at any CM Administration Console installation, in the \bin folder.
  2. On the Server which has your ConfigMgr Reporting Services Role, on the same drive where you have that role, make a directory (call it whatever you like, but for this example, I'm calling it CMSrsResources, and for me, the drive was S:.  Copy that latest SrsResources.dll to S:\CMSrsResources folder.
  3. On the Server which has your ConfigMgr Reporting Services role, you will have had to install SQL Reporting Services.  Find that installed location, it might be on C:, D:, or elsewhere.  The folder will likely be "something like" ....\MSRS13.MSSQLServer\Reporting Services\ReportServer.  In that location will be a rssrvpolicy.config file.  Edit rssrvpolicy.config in notepad, and look for the reference to SrsResources.dll.  It is most likely pointing to ...\MSRS13.MSSQLServer\Reporting Services\ReportServer\bin\SrsResources.dll.  CHANGE that to point instead to what you did in Step 2.  In my case, it would be S:\CMSrsResources\SrsResources.dll.  Save the config file.  (if it won't LET you save the config file, go to Services, and stop the SQL Reporting Services 'service', then save it.)
  4. Restart the service for SQL Reporting Services, or Restart the Server.

Done.

The long Explanation...

We have multiple custom reports, especially for Application Deployments, where knowing what an errorcode number means in a localized language (in our case, usually English) is very handy, instead of looking at that information in the console.  SQL reports are preferred in many instances.  In order to get that localization, according to multiple sources, the way to do that using ConfigMgr is 3 steps:

  1. rssrvpolicy.config for your SQL Reporting Services needs to have the SCCM Assembly referenced, pointing to the location of the SrsResources.dll file.
  2. that SrsResources.dll file has to exist in that location identified in the .config file.
  3. for any individual Report for ConfigMgr, for the report properties, on the 'References' tab, add the SrsResources assembly. Inside that report, presuming an error code is one of the values of your dataset, you can use the expression =SrsResources.Localization.GetErrorMessage(Fields!ErrorCode.Value, User!Language to get that information displayed in legible english (if you are english speaking, french if you're french, etc. etc.)

I noticed after CM 1610, and then again after CM 1702, apparently what is done "for me" is either permissions are reset, or something else fun is happening--maybe it's only when you are using SQL 2016, I don't know (all my labs and production are SQL 2016 latest).  But the .config file, if it's pointing to the Reporting Services\ReportServer\Bin location... It just won't read it and use it.  What the report displays instead of a nice handy english-y message is just #Error .  If I instead copy the .dll elsewhere, and edit the .config file to say "go find it over here" -- it uses it just fine.

Here's hoping this might help others if they like leveraging the SrsResources.dll within ConfigMgr reports, and they are doing everything by the book... and yet it still doesn't work.  You might just need to copy the .dll elsewhere and edit the config file.

CM12

  • Created on .

Using Package Status MIF Files in a Task Sequence

Recently we internally had a need for technical people, but not necessarily people extremely versed in reading Task Sequence log files, to be able to tell via a report only why some step in a Task Sequence failed to trigger.

Pre-requisites and lessons learned during testing:

  1. Package/Program(s) defined with the source files containing 1 file:
     --> CreateMIF.ps1 <--
  2. The mif file has some specific structural requirements.  All Fields have to have a value, a returned value of “” (nothing) is not acceptable and won’t be picked up and forwarded.  So hard coding “ENU” for language and “NIL” for Serial Number is done in-script. (You can change the language if you like; but they have to match; in the script and in the Package Language)
  3. In order for CM client to match the .mif file correctly, several elements need to “match”; the filename, the Manufacturer, the PackageName, the Version, and ENU.
  4. In order for CM client to ‘find’ the mif file to forward to the MP, the mif file needs to be in the %windir% folder.

The remainder of this document is illustrating it’s use using a simple example:  Where a pre-requisite check for “is there enough hard drive space”, failed.  This is useful in reports for a verbose status description to help people via reporting only (without reading a long local log file on a client) determine why a step failed.

The steps of the script are essentially this:

  1. Grab the 6 required parameters

  2. Create the MIF in %windir%

Package Properties, note the values for 1, 2, 3, 4. NOTE that the script itself hard codes the value for “language” as ENU—so that has to be ENU on the General Tab here, item #4.

For Status MIF Matching on the Package, note values 1, 2, 3, and 5

In the program Command Line, note the values for 1, 2, 3, and 5; how they have to match the 1, 2, 3 in Package General Tab, and Reporting Tab.

Here’s a sample Task Sequence, using that package.

 

If it’s working, you’ll see this in execmgr.log on a client:

 

 

Using this additional SQL line in some specific reports, you’ll be able to see the “Description”, whatever it may be:
, StatusMifDescription= (select sstring.InsStrValue3 from vStatusMessagesWithStrings sstring where sstring.messageid in (10007,10009) and sstring.recordid=stat.recordid)
in "__History of a Task Sequence Deployment on a Computer"

 

For the curious... why did I use such an odd number for "enough free disk"; because that's about what was free on the test box.  so I could easily test for that, over and over again.

 

If for whatever reason you can't get the attached .zip file, below is the script:

<#
.SYNOPSIS
 This script creates a System Center Configuration Manager compliant status.mif file
.DESCRIPTION
 This script creates a specifically formated text file ending in '.mif' in the $windir folder.
.PARAMETER MIFFileName
 The Name to give the .mif filename, excluding the .mif extension.  This must match the filename in ConfigMgr package status mif matching.
.PARAMETER Company
 The Company or Manufacturer must match the Manufacturer as defined in the Package Properties in ConfigMgr
.PARAMETER Package
 This must match the Package name as defined in the Package Properties in ConfigMgr
.PARAMETER Version
 This must match the version as defined in the Package Properties in ConfigMgr
.PARAMETER Description
 This can be any sentance or phrase, up to 254 characters
.PARAMETER Status
 The only acceptable values are SUCCESS or FAILURE
.EXAMPLE
 Create-MIF.ps1 -MIFFileName ABC12345 -Company 'Acme Corporation' -Package 'Widgets' -Version '3.0' -Description 'Requirement of enough disk space not met' -Status 'Failure'
.EXAMPLE
 Create-MIF.ps1 -MIFFileName ABC12345 -Company 'Acme Corporation' -Package 'Widgets' -Version '3.0' -Description 'Requirement enough disk space met' -Status 'Success'
.NOTES
 On Package Properties in ConfigMgr, the Language of ENU must exist
 The resulting MIF file created needs be in the %windir% folder for ConfigMgr to utilize it.
.VERSION
 1.0 Sherry Kissinger 03-27-2017
#>
[CMDletBinding()]
Param (
 [Parameter(Mandatory=$true)]
 [string]$MIFFileName,
 [Parameter(Mandatory=$true)]
 [string]$Company,
 [Parameter(Mandatory=$true)]
 [string]$Package,
 [Parameter(Mandatory=$true)]
 [string]$Version,
 [Parameter(Mandatory=$true)]
 [string]$Description,
 [Parameter(Mandatory=$true)]
 [ValidateSet('Failed','Success')]
 [string]$Status  
)
$Locale = "ENU"
$SerNum = "NIL"
$FileName = $Env:WinDir+'\'+$MIFFileName + '.mif'
$DoubleQuote = '"'
"START COMPONENT" | Set-Content $FileName
"NAME = " + $DoubleQuote + "WORKSTATION" + $DoubleQuote | Add-Content $FileName
"  START GROUP" | Add-Content $FileName
"    NAME = " + $DoubleQuote + "ComponentID" + $DoubleQuote | Add-Content $FileName
"    ID = 1"  | Add-Content $FileName
"    CLASS = " + $DoubleQuote + "DMTF|ComponentID|1.0" + $DoubleQuote | Add-Content $FileName
"    START ATTRIBUTE" | Add-Content $FileName
"      NAME = " +$DoubleQuote + "Manufacturer" + $DoubleQuote | Add-Content $FileName
"      ID = 1" | Add-Content $FileName
"      ACCESS = READ-ONLY" | Add-Content $FileName
"      STORAGE = SPECIFIC" | Add-Content $FileName
"      TYPE = STRING(64)" | Add-Content $FileName
"      VALUE = " + $DoubleQuote + $Company + $DoubleQuote | Add-Content $FileName
"    END ATTRIBUTE" | Add-Content $FileName
"    START ATTRIBUTE" | Add-Content $FileName
"      NAME = " + $DoubleQuote + "Product" + $DoubleQuote | Add-Content $FileName
"      ID = 2" | Add-Content $FileName
"      ACCESS = READ-ONLY" | Add-Content $FileName
"      STORAGE = SPECIFIC" | Add-Content $FileName
"      TYPE = STRING(64)" | Add-Content $FileName
"      VALUE = " + $DoubleQuote + $Package + $DoubleQuote | Add-Content $FileName
"    END ATTRIBUTE" | Add-Content $FileName
"    START ATTRIBUTE" | Add-Content $FileName
"      NAME = " + $DoubleQuote + "Version" + $DoubleQuote  | Add-Content $FileName
"      ID = 3"  | Add-Content $FileName
"      ACCESS = READ-ONLY"  | Add-Content $FileName
"      STORAGE = SPECIFIC" | Add-Content $FileName
"      TYPE = STRING(64)" | Add-Content $FileName
"      VALUE = " + $DoubleQuote + $Version + $DoubleQuote | Add-Content $FileName
"    END ATTRIBUTE" | Add-Content $FileName
"    START ATTRIBUTE" | Add-Content $FileName
"      NAME = " + $DoubleQuote + "Locale" + $DoubleQuote  | Add-Content $FileName
"      ID = 4" | Add-Content $FileName
"      ACCESS = READ-ONLY" | Add-Content $FileName
"      STORAGE = SPECIFIC" | Add-Content $FileName
"      TYPE = STRING(16)" | Add-Content $FileName
"      VALUE = " + $DoubleQuote + $Locale + $DoubleQuote  | Add-Content $FileName
"    END ATTRIBUTE" | Add-Content $FileName
"    START ATTRIBUTE" | Add-Content $FileName
"      NAME = " + $DoubleQuote + "Serial Number" + $DoubleQuote  | Add-Content $FileName
"      ID = 5"  | Add-Content $FileName
"      ACCESS = READ-ONLY" | Add-Content $FileName
"      STORAGE = SPECIFIC" | Add-Content $FileName
"      TYPE = STRING(64)" | Add-Content $FileName
"      VALUE = " + $DoubleQuote + $SerNum + $DoubleQuote  | Add-Content $FileName
"    END ATTRIBUTE" | Add-Content $FileName
"    START ATTRIBUTE" | Add-Content $FileName
"      NAME = " + $DoubleQuote + "Installation" + $DoubleQuote | Add-Content $FileName
"      ID = 6" | Add-Content $FileName
"      ACCESS = READ-ONLY" | Add-Content $FileName
"      STORAGE = SPECIFIC" | Add-Content $FileName
"      TYPE = STRING(64)" | Add-Content $FileName
"      VALUE = " + $DoubleQuote + "DateTime" +$DoubleQuote | Add-Content $FileName
"    END ATTRIBUTE" | Add-Content $FileName
"  END GROUP" | Add-Content $FileName
"  START GROUP" | Add-Content $FileName
"    NAME = " + $DoubleQuote + "InstallStatus" + $DoubleQuote  | Add-Content $FileName
"    ID = 2" | Add-Content $FileName
"    CLASS = " + $DoubleQuote + "MICROSOFT|JOBSTATUS|1.0" + $DoubleQuote | Add-Content $FileName
"    START ATTRIBUTE" | Add-Content $FileName
"      NAME = " + $DoubleQuote + "Status" + $DoubleQuote | Add-Content $FileName
"      ID = 1"  | Add-Content $FileName
"      ACCESS = READ-ONLY" | Add-Content $FileName
"      STORAGE = SPECIFIC" | Add-Content $FileName
"      TYPE = STRING(32)" | Add-Content $FileName
"      VALUE = " + $DoubleQuote + $Status + $DoubleQuote | Add-Content $FileName
"    END ATTRIBUTE" | Add-Content $FileName
"    START ATTRIBUTE" | Add-Content $FileName
"      NAME = " + $DoubleQuote + "Description" + $DoubleQuote | Add-Content $FileName
"      ID = 2" | Add-Content $FileName
"      ACCESS = READ-ONLY" | Add-Content $FileName
"      STORAGE = SPECIFIC" | Add-Content $FileName
"      TYPE = STRING(128)" | Add-Content $FileName
"      VALUE = " + $DoubleQuote + $Description + $DoubleQuote | Add-Content $FileName
"    END ATTRIBUTE" | Add-Content $FileName
"  END GROUP" | Add-Content $FileName
"END COMPONENT" | Add-Content $FileName
Exit 0
 

 

CM12

  • Created on .

ConfigMgr CCMRecentlyUsedApps blank or mtrmgr.log with StartPrepDriver - OpenService Failed with Error Issue

Issue:  ConfigMgr Clients which should be reporting via hardware inventory "CCMRecentlyUsedApps" have nothing to report.  An analysis of the client indicates there is nothing in WMI root\cimv2\sms\ccm_recentlyusedapps TO report, and mtrmgr.log on the client contains lines like "StartPrepDriver - OpenService Failed with Error".  See --> KB3213242 <-- at Microsoft for more details.  UPDATE to script on 2018-01-31

Remediation: What worked for us was to re-register the 'prepdrv.inf', and then restart SMS Agent Host (aka ccmexec)

Before you do anything suggested below--confirm this will fix the issue you are seeing.  Login to a box or two with the issue, and from an elevated cmd prompt, run the "remediation" powershell script below.  Watch mtrmgr.log; and manually check that root/cimv2/sms select * from ccm_recentlyusedapps gets information.  Once you see info, do a hardware inventory, and confirm that box now reports information up to your database, as you expect it to.  If manually remediating works, then you can look to completing the steps below to automate the fix across your environment.

What we did to remediate the 'StartPrepDriver - OpenService Failed with Error' using a Configuration Item and Baseline was this:

It is assumed that you are using a "custom client agent setting" for enabling CCM_RecentlyUsedApps, since you normally do NOT want to target "every client".  Usually you don't want to target heavily used Application Servers, or Citrix Servers--since hundreds of userIDs can 'launch' applications, the results of CCMRUA on those types of machines often won't process (the MIF file will be bigger than 50mb) and isn't that useful anyway.  So go check, in your Custom Client Agent Settings, which collection you are targeting to enable 'ccm recently used apps'.  Once you know that, then continue.

1) first, determine with SQL query how big of an issue it might be; maybe it was only a couple of boxes; and you can address them manually. Depending upon the count returned, it'll be up to you if you want to pursue this as a Configuration Item, or manually address.

   Declare @CollID as nvarchar(8) = (Select collectionid from v_collection c where c.name = 'The Collection Name You figured out has CCMRUA as a HINV rule')
   select count(ws.resourceid) [Count]
   from v_gs_Workstations_Status ws
   where ws.LastHWScan is not null
   and ws.resourceid not in (select resourceid from v_gs_ccm_recently_used_apps)
   and ws.resourceid in (select resourceid from v_fullcollectionmembership_valid fcm where [email protected])

2) Create the Collection Query, to target.

   - Create a new Collection, using the "limit to collection" as the collection you use for targeting when CCM Recently Used Apps information should be reported via Hardware Inventory. (the one you figured out above)

   - The collection query rule should have two conditions... where:
      SMS_G_System_WORKSTATION_STATUS.LastHardwareScan is not null
      and
      SMS_R_SYSTEM.ResourceId not in (Select ResourceId from SMS_G_System_CCM_RECENTLY_USED_APPS)

3) If the count of the SQL query, and the count of the Collection query are the same (or close enough); then you can continue to creating the ConfigItem, and deploying the Baseline to remediate the issue.

4) Create the Configuration Item, where the Detection and Remediation Logic are at the end of this blog post.  Both are Powershell scripts. for "what means compliant", it will be a String, equals "Compliant". Make sure you check the box about Remediate if non-compliant.

5) After you create the Configuration Item, create a Baseline, add the CI to the baseline, and deploy the baseline, with remediation, to the collection you created above. (you may want to do a pilot, to a subset of 2 or 3 specific boxes, just to be sure it will all work as you expect it to work)

UPDATE 2018-02-02:  Discovered that machines were "re-breaking".  So I ended up targeting 'every box' with the Remediation script--it'll only remediate if problem found.  Note in my production remediation script, I comment out the ccmexec restart.  CCMEval takes care of that overnight, so it's OK.

6) That's it... then it's just a waiting game.  You are waiting for the Baseline to run, remediate the issue by doing the rundll routine, restart ccmexec.  Once that is done, in a minute or two mtrmgr.log will start to begin recording information into the root\cimv2\ccm_recentlyusedapps WMI location.  Once there is information there, then at the next hardware inventory, presuming this client is asked via hinv policy to report that information, it will have something to report.  So how long it takes completely depends upon YOUR schedules, that you defined.  How frequently the Baseline evaluates, and how frequently your clients do the scheduled HINV action.

PS: you might be tempted to "let me just add a line to the remediation script, to trigger a hinv right at the end".  I wouldn't bother.  It takes a few minutes for the client, after the ccmexec restart, to populate WMI.  It'll all shake out quickly enough.

######### DETECTION Powershell Script for the CI #####################
<#
.SYNOPSIS
   This Script is for Detection of a known condition for the inability of CM Client to initialize the StartPrepDriver
.DESCRIPTION
   This script finds the CM mgrmgr.log file, and reads it for a known good, or known error, condition.
   "what means good" =  mtrmgr.log contains lines like this
        PREP driver successfully initialized 
        or
        Termination event received for process
   "what means bad" = mtrmgr.log contains lines like this
        StartPrepDriver - OpenService Failed with error
.NOTES
   Steps are to
    1) read the regkey for CM Client to find the correct log file location
    2) Look for good or Bad entries in the file
    3) Exit with 'Compliant' or 'Non-Compliant' depending upon the results
.VERSION
    1.0 Sherry Kissinger  2017-03-30
1.1 Sherry Kissinger 2018-01-31 (added -Tail 10 for better accuracy)
#>
$ErrorActionPreference = 'SilentlyContinue'
#Get the LogDirectory for CM Client
$CMLogDir = (Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\CCM\Logging\@Global" -Name LogDirectory).LogDirectory
#Define the LogFile to Read
$CMLogFile = $CMLogDir + '\mtrmgr.log'
#Read the Log file for the Error Phrase
$GotErrors = (Get-Content -Path $CMLogFile -Tail 10 | where-object {$_ -like '*StartPrepDriver - OpenService Failed with error*'})
#Read the Log File for a known good condition phrases
$GotGoodEntry = (Get-Content -Path $CMLogFile -Tail 10 | where-object {($_ -like '*PREP driver successfully initialized*') -or ($_ -like '*Termination event received for process*')})
if ($GotGoodEntry) {
  write-host 'Compliant'
  }
else {
  if ($GotErrors) {
     write-host 'Non-Compliant'
  }
}

############## REMEDIATION Powershell Script for the CI  ##########################
<#
.SYNOPSIS
   This Script is for Detection and Remediation of a known condition for the inability of CM Client to initialize the StartPrepDriver
.DESCRIPTION
   This script finds the CM mgrmgr.log file, and reads it for a known good, or known error, condition.
   "what means good" =  mtrmgr.log contains lines like this
        PREP driver successfully initialized 
        or
        Termination event received for process
   "what means bad" = mtrmgr.log contains lines like this
        StartPrepDriver - OpenService Failed with error
.NOTES
   Steps are to
    1) read the regkey for CM Client to find the correct log file location
    2) Look for good or Bad entries in the file
    3) Exit with 'Compliant' or if 'Non-Compliant', to run the fix
       3a) the fix is two steps
            RUNDLL32.EXE SETUPAPI.DLL,InstallHinfSection DefaultInstall 128 C:\WINDOWS\CCM\prepdrv.inf
            Restart-Service ccmexec
.VERSION
    1.0 Sherry Kissinger  2017-03-30
1.1 Sherry Kissinger 2018-01-31 (added -Tail 10 for better accuracy)
#>
$ErrorActionPreference = 'SilentlyContinue'
#Get the LogDirectory for CM Client
$CMLogDir = (Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\CCM\Logging\@Global" -Name LogDirectory).LogDirectory
#Define the LogFile to Read
$CMLogFile = $CMLogDir + '\mtrmgr.log'
#Read the Log file for the Error Phrase
$GotErrors = (Get-Content -Path $CMLogFile -Tail 10 | where-object {$_ -like '*StartPrepDriver - OpenService Failed with error*'})
#Read the Log File for a known good condition phrases
$GotGoodEntry = (Get-Content -Path $CMLogFile -Tail 10 | where-object {($_ -like '*PREP driver successfully initialized*') -or ($_ -like '*Termination event received for process*')})
if ($GotGoodEntry) {
  write-host 'Compliant'
  }
else {
if ($GotErrors) {
 Try { Set-ExecutionPolicy -ExecutionPolicy 'Bypass' -Scope 'Process' -Force -ErrorAction 'Stop'}
 Catch {}
 $CMClientDIR = (Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\SMS\Client\Configuration\Client Properties" -Name 'Local SMS Path').'Local SMS Path'
 $ExePath = $env:windir + '\system32\RUNDLL32.EXE'
 $CLine = ' SETUPAPI.DLL,InstallHinfSection DefaultInstall 128 ' + $CMClientDIR + 'prepdrv.inf'
 #Parse the Parameters
 $Prms = $Cline.Split(" ")
 #Execute the fix with parameters
 & "$Exepath" $Prms
 #Restart ccmexec service
 #CCMExec should be restarted; If you'd rather wait for a natural client reboot, comment out this line.
 #Note that this CI will continue to attempt to remediate until a ccmexec restart or reboot
 restart-service ccmexec
  }
}

 

 

CM12

  • Created on .

Copyright © 2018 - The Minnesota System Center User Group