Managing Workstation Uptime with Compliance Settings

Ken Smith (PFE) — Tue, 04 Nov 2014 08:47:55 GMT

Background

I was recently approached by one of my customers who was looking for a way to force their users to reboot their workstations at least once every 7 days for maintenance reasons. In the past, I’ve seen this handled via a combination of DCM/Compliance Settings, collections, and package/program deployments. While this approach works well, a more streamlined approach can be taken by utilizing the remediation capability we get natively in ConfigMgr 2012. In today’s blog post, we’re going to discuss how to accomplish this without involving collection refresh schedules and persistent package deployments.

Creating the Configuration Item

First, we’ll need to create a Configuration Item that will detect the uptime for a workstation and includes a remediation that will initiate a reboot. On the “Assets and Compliance” tab, we want to create a new configuration item under the “Compliance Settings” folder. Name the configuration item and make sure the type is set to “Windows”. On the “Supported Platforms” step, it is generally a good idea to limit the scope of your CI to the platforms that will be targeted. In this case, we don’t want any servers to reboot once a week, so we’ll include only workstation operating systems. Finally, on the “Compliance Rules” step, we’ll create a new setting. Our setting type will be a script and the data type returned by the script will be an integer. Our discovery script will need to detect the system uptime and report back whether or not the system has an uptime greater than 7 days. To accomplish this, we’ll use a simple PowerShell script that reads the last boot time from WMI and calculates the uptime for us.

#Use Get-WMIObject to read the Win32_OperatingSystem class            
$Win32OS = Get-WMIObject -Class Win32_OperatingSystem            
            
#Calculate the uptime based on the LastBootUpTime property and the local date and time            
$Uptime = $Win32OS.ConvertToDateTime($Win32OS.LocalDateTime) - `
$Win32OS.ConvertToDateTime($Win32OS.LastBootUpTime)            
            
#Check if the total number of days in our uptime calculation is greater than 7            
#Return a 0 for a non-compliant system and a 1 if the system is compliant            
if ($Uptime.TotalDays -gt 7){            
 $compliant = 0            
}            
else {            
 $compliant = 1            
}            
            
echo $compliant

Next, we’ll need to create a remediation script. This will run when a system is detected as being non-compliant and is the magic that lets us avoid having to deal with collection refresh timers and perpetual package/program deployments. Instead, we’ll use a PowerShell script that initiates a shutdown with a 60 minute countdown. To modify the countdown time, just change the value of the “/t 3600” argument. The message displayed on the reboot pop-up can be changed by modifying the text for the “/c” argument.

Start-Process shutdown -ArgumentList `
'/r /t 3600 /c "It has been more than 7 days since the last system reboot."' `
-wait -NoNewWindow -PassThru

For our compliance rule, we want to create a value rule that checks for our value echoed in our detection script to be equal to 1. If the workstation has been up for longer than 7 days and the script returns a 0, the compliance will fail and our remediation script will run. Be sure to check the “Run specified remediation script…” option to ensure that the shutdown command is issued to non-compliant workstations.

Now that we have both our setting and our compliance rules created, we can finish the “Create Configuration Item” wizard.

Creating the Baseline

With our Configuration Item created, we next move on to creating a baseline. Here, we will add the configuration item we just created.

Deploying the Baseline

In our final step, we’re going to deploy the baseline that was created to a collection of workstations on which we’d like to enforce our 7 day reboot policy. Be sure to check the “Remediate noncompliant rules when supported” and “Allow remediation outside the maintenance window” (if you have maintenance windows configured for your workstations). Set the schedule to be frequent enough to catch machines in a reasonable timeframe after hitting 7 days of uptime, but not so aggressive as to affect system performance. I recommend every 1 day as a happy medium.

Migrating the Content Library between Distribution Points in SCCM 2012 SP1

Ken Smith (PFE) — Thu, 01 Aug 2013 11:04:00 GMT

I recently had a very good question from one of my customers regarding how to migrate content from one DP to another, avoiding the need to re-distribute content over the WAN. In the SMS 2003 and SCCM 2007 days, we used the preloadpkgonsite.exe tool to accomplish the job. With the switch to the content library in SCCM 2012, however, that is no longer an option. In today’s blog, we’re going to cover how to accomplish this same task with PowerShell. If you would like to download the script to follow along, you can find it in the Technet Gallery. The process for migrating content from the content library of one DP to another can be broken down into three basic steps:

Create prestage content files for all content on the source distribution point
Run the ExtractContent.exe tool on the target DP to load the pre-stage content into the content library
Assign the content for distribution to the target DP

The workhorse for step 1 of this task will be the new “Publish-CMPrestageContent” commandlet released with the SP1 update of the SCCM PowerShell module. This commandlet was not around in the RTM release of SCCM 2012, so you must be on SP1, at a minimum. Before we get too heavily into the code, a couple of prerequisites should be mentioned. First, the PowerShell module for Configuration Manager is a 32-bit module, so you will need to make sure you are running the 32-bit version of PowerShell. Second, the Publish-CMPrestageContent command will actually download the content from the source DP to the computer that is running the PowerShell module. If you run this command from your workstation that is across the WAN, it will have the unintended consequence of transferring all of our package content across the WAN as well. To avoid this, you will need to have the SCCM console installed on the DP you will be using as your source DP. Third, our script uses environment variables to automatically detect where the console is installed. This allows us to handle cases where it is not installed to the default folder, but requires that the environment variable has been created on the system. If you have freshly installed the SCCM console, you’ll need to log out and back in to ensure that the environment variable can be read by PowerShell.

Step 1) – Create prestage content files

In our example script, we’ll execute the script in prestage mode with the required parameters:

PS C:\>.\CloneDP.ps1 -Prestage -SourceDP sccm01.contoso.com -TargetDP 
DP01.contoso.com -ContentShare \\dp01.contoso.com\c$\pkgx

In this example, we’re cloning all of the content from the SCCM01 DP to the DP01 DP. The prestage files will be put in the “Pkgx” folder on DP02 using the admin share, though you can select any network share on the LAN to store the prestage content that we will later import. Following along in the example script, you can see that before we can begin creating our prestage commands, we need to grab a list of deployment packages that have been deployed to our source DP so that we can begin to loop through them:

         
$DeploymentPackages = Get-CMDeploymentPackage -DistributionPointName $SourceDP

One of the key things to note with the Publish-CMPrestageContent commandlet is that there is a different parameter you must specify depending on the type of content you are prestaging. As a result, we’ll use a variable ($command) and build the command syntax as we go along. To start, we’ll add the commandlet to the variable:

$command = "Publish-CMPrestageContent "

We can then use a switch statement to build the parameters required depending on what type of deployment package we are currently working with:

Switch ($DeploymentPackage.ObjectTypeID) {            
        2  { $command += "-PackageID $($DeploymentPackage.PackageID) " }
        14 { $command += "-OperatingSystemInstallerId $($DeploymentPackage.PackageID) "}           
        18 { $command += "-OperatingSystemImageId $($DeploymentPackage.PackageID) "}
        19 { $command += "-BootImageId $($DeploymentPackage.PackageID) "}  
        23 { $command += "-DriverPackageID $($DeploymentPackage.PackageID) "}
        24 { $command += "-DeploymentPackageID $($DeploymentPackage.PackageID) "}
        31 { $command += "-ApplicationName '$($DeploymentPackage.Name)' "} 
    }

All of the parameters for the various content types will use the PackageID to identify what content we are looking to prestage, with the exception of the Application content type. In this case, the application name is the most easily accessible property gathered by the Get-CMDeploymentPackage commandlet, so we use that instead. See the table below for a list of ObjectTypeIDs and the content types they refer to:

Name	PackageType
Package	2
Driver Package	23
Task Sequence Package	20
Software Updates Package	24
Device Setting Package	21
Virtual App	31
Application	31
Image Package	18
Boot Image Package	19
Operating System Install Package	14

Finally, we can add the parameters that are universal to all of the various content types. For these parameters, we’ll have the pre-stage file initially created in the %temp% folder and get the content from the source DP passed via the script parameters:

$command += "-FileName '$($env:TEMP)\$($DeploymentPackage.PackageID).pkgx'” `

+ “ -DistributionPointName $($SourceDP)"

Now that our command syntax is fully built, we’ll call the command using Invoke-Expression before finally using Move-Item to move the prestage file to a share on our target DP:

Invoke-Expression $command

           
            
Move-Item "$($env:TEMP)\$($DeploymentPackage.PackageID).pkgx" `

"$($ContentShare)\$($DeploymentPackage.PackageID).pkgx" -Force

At this point, we should have a folder full of prestage content files on our target DP that should look something like the image below.

Step 2) – Extract the prestage files

For this step we’re going to use the ExtractContent.exe utility that is automatically installed when you install the DP role on a server. It will be located in the tools folder in the DP install directory, which in our case is “c:\SMS_DP$\sms\Tools\ExtractContent.exe”. If you have UAC enabled, be sure to run your command prompt with administrative credentials. As you can see from the image above, the basic argument we want to give the ExtractContent.exe tool is the /P command to point it at our folder of prestage packages. A nice feature to note is that we can point this at either an individual “.pkgx” file or an entire folder of them, which in our case will be “c:\Pkgx”. We’ll run “ExtractContent.exe /P:c:\Pkgx” to extract the content out of our “.pkgx” files and into the content library. The output isn’t very verbose, but you can monitor the “PrestageContent.log” in the log folder of the DP install directory while the command is running. Once everything is complete and you have reviewed the “PrestageContent.log” file, you can delete the folder containing all of your “.pkgx” files, as they are no longer needed.

Step 3) – Assign content to your target DP

If you are using distribution point groups to assign your content rather than selecting individual DP’s, at this point you can add the target DP to the distribution point group. Otherwise, we’ll use the finalize mode of the sample script to target all of the content that has been prestaged to the target DP. Using either method will utilize the extracted content on the target DP rather than re-distributing the files from the primary site.

PS C:\>.\CloneDP.ps1 -Finalize -SourceDP SCCM01.contoso.com 
-TargetDP DP01.contoso.com

When in finalize mode, we once again use the Get-CMDeploymentPackage to get a listing of packages on the source DP. We will once again use the $command variable to build our syntax:

"Start-CMContentDistribution "

The Start-CMContentDistribution commandlet uses the same parameters to identify the content ID as the Publish-CMPrestageContent commandlet, so we reuse the same switch statement to include those parameters into our command line. Finally, we complete the $command string with the target DP and then Invoke-Expression to initiate the deployment:

$command += "-DistributionPointName $($TargetDP)"

Invoke-Expression $command

Get the code!

If you haven’t already done so, you can grab the code for the sample script from the TechNet Gallery!

Ken Smith's ConfigMgr Blog