Package Software While You Sleep Using the SCCM Application Packager Script – Part 2

, , , , , , , , ,

Welcome to Part 2 of the 2-part series about the SCCM Application Packager Script! If you have not yet read Part 1, I highly recommend doing so before continuing.

The SCCM Packager Tool works by parsing and processing XML files known as “recipes”. Recipes provide the instructions to the SCCM Application Packager Script that allow it to create applications in SCCM. Recipes are broken down into 5 main nodes. This post will cover each of the nodes, many of the tags and properties found in each node, and their purpose. Once a general understanding of the recipes and their properties are established, we will dissect the 7-Zip recipe for further insights. Please note that there are more properties available than the ones explained here. All available properties and options are documented in the Template.xml file located in the “Recipes” folder of the SCCM Application Packager Script.

Application Node

The Application Node contains information for the application that will be visible to the end user when the it is deployed. Essentially, the Application Node defines what will be seen in Software Center for each application. The Application Node does not have many options overall, so they are all broken down below:

  • Name – The name of the application as shown in SCCM and the Software Center
  • Description – The description of the application in Software Center. Also sets the “Administrative Comments”
  • Publisher – The application publisher as shown in Software Center
  • AutoInstall – Whether to allow the application to install during a task sequence or not
  • UserDocumentation – Link for the application to provide the end user with more information
  • Icon – The filename of the application icon in the icon repository folder

Downloads Node

The Downloads Node is responsible for downloading and copying the application installers and any associated files to the application share. Multiple downloads can be specified (for things like 32 and 64-bit downloads), and each download should be named to correspond with a “DeploymentType” in the Deployment Types Node. Different destinations can also be specified for each download (see the Template.xml file for more information). The Downloads Node also has just a few options, the most common are as follows:

  • PrefetchScript – The prefetch script can be used to download the software or find the URL of the download for the application if a direct link to the application download isn’t available.
  • URL – The link to download the latest version of the application.
  • DownloadFileName – Specify the name of the file when it is downloaded
  • Version and FullVersion – These can be blank, but MUST be present in each download definition
  • DownloadVersionCheck – This can be used to check the version of the application that was downloaded. If the version can’t be checked directly, additional processing can be done here as well
  • AppRepoFolder – Allows different folders to be specified on the application share per download
  • ExtraCopyFunctions – If additional files like configurations, installation scripts, or “.mst” files are needed, they can be copied to the content share here

Deployment Types Node

The Deployment Types Node is where all the magic really happens. In the Deployment Types Node, multiple deployment types can be specified for a single application. At this time, Script and MSI deployment types are supported. Each deployment type supports things like: Custom installation and uninstall commands, Custom and multiple detection methods including script detection methods, Installation behavior, and dependencies. The number of options available are too great to list for the deployment types, so it is recommended to check out the Template.xml to see the options available.

Distribution Node

The Distribution Node is responsible for distributing the content to SCCM distribution points. Generally, only one option will need to be specified here, and that is whether or not to distribute the content. If the “DistributeContent” property is set to “True”, the content for the application will automatically be distributed to the distribution point group specified in SCCMPackager.prefs. The following options are also available in the Distribution Node:

  • DistributeContent – Set to True to distribute content, Set to false to skip distributing content
  • DistributeToGroup – Distribution Point group to distribute content to
  • DistributeToDPs – Distribution Point to distribute content to

Deployment Node

The Deployment Node is similar to the Distribution Node. It has very few options and, generally, the only option that needs to be set is “DeploySoftware”. If the “DeploySoftware” property is set to “True”, the software will automatically be deployed as available to the default collection specified in SCCMPackager.prefs. Additionally, a collection other than the default can be specified for deployment. Other options available in the Deployment Node are as follows:

  • DeploySoftware – Set to True to deploy the software, Set to false to skip deploying software
  • DeploymentCollection – Specify the name of a collection to deploy to other than the default


Recipe Breakdown – 7-Zip.xml

Now that we have a general idea of the purpose of recipes and the features available to them, let’s break down a simple one to demonstrate a real life example. The recipe for 7-Zip is relatively simple, containing two downloads and two MSI deployment types. One of these deployment types also contains a requirements rule. Below, each node of the 7-Zip recipe will be dissected and discussed.

7-Zip Application Node

    <Description>7-Zip is a file archiver with a high compression ratio. Free and Open Source Software</Description>
    <Publisher>Igor Pavlov</Publisher>

As described earlier, the Application Node is fairly simple overall. The 7-Zip application will be packaged with the name “7-Zip <Version>”, the Description as shown in Software Center will be: “7-Zip is a file archiver with a high compression ratio. Free and Open Source Software”. The Publisher and Link provided in Software Center will be “Igor Pavlov” and “” respectively. The SCCM Application Packager Script will also mark the option to allow the packaged application to be installed during a Task Sequence, and will choose the icon file “7Zip.ico” from the icon repository specified in SCCMPackager.prefs.

7-Zip Downloads Node

    <Download DeploymentType="DeploymentType1">
        <PrefetchScript>$URL = "$((Invoke-WebRequest |Select -ExpandProperty Links |where -Property href -like "*-x64.msi")[0].href)"</PrefetchScript>
        <DownloadVersionCheck>[String]$Version = ([String](Get-MSIInfo -Path $DownloadFile -Property ProductVersion)).TrimStart().TrimEnd()
        $Version = ($version.Split('.'))[0..1] -join "."</DownloadVersionCheck>
    <Download DeploymentType="DeploymentType2">
        <PrefetchScript>$URL = "$((Invoke-WebRequest |Select -ExpandProperty Links |where -Property href -like "*.msi")[0].href)"</PrefetchScript>
        <DownloadVersionCheck>[String]$Version = ([String](Get-MSIInfo -Path $DownloadFile -Property ProductVersion)).TrimStart().TrimEnd()
        $Version = ($version.Split('.'))[0..1] -join "."</DownloadVersionCheck>

The Downloads Node for 7-Zip has a bit more going on than the Application Node. Upon initial inspection, we can see that there are 2 “DeploymentType(s)” specified, one is tied to “DeploymentType1”, and the other is tied to “DeploymentType2”. We can also tell pretty quickly based on the “DownloadFileName(s)” properties of these downloads that they download the 64-bit and 32-bit msi installers of 7-Zip respectively.

You will notice that a URL is not provided in either of the downloads, however, each download has a “PrefetchScript”, that sets a variable called “$URL”. Let’s look at what the “PrefetchScript” in the “DeploymentType1” download does:

$URL = "$((Invoke-WebRequest |Select -ExpandProperty Links |where -Property href -like "*-x64.msi")[0].href)"

We can see that this script is setting a $URL variable, it just so happens that the $URL variable is tied to the URL tag in the recipe, which is what the SCCM Application Packager Script will attempt to download. That means that whatever we set $URL to in the prefetch script will be downloaded by the Packager Script. If we break down the command a bit more, and run the command found in the inner-most parenthesis in PowerShell:

PS C:\Users\Andrew> (Invoke-WebRequest |Select -ExpandProperty Links |where -Property href -like "*-x64.msi")

innerHTML : Download
innerText : Download
outerHTML : <A href="a/7z1900-x64.msi">Download</A>
outerText : Download
tagName   : A
href      : a/7z1900-x64.msi
innerHTML : Download
innerText : Download
outerHTML : <A href="a/7z1604-x64.msi">Download</A>
outerText : Download
tagName   : A
href      : a/7z1604-x64.msi
innerHTML : Download
innerText : Download
outerHTML : <A href="a/7z920-x64.msi">Download</A>
outerText : Download
tagName   : A
href      : a/7z920-x64.msi

we will see that it returns 3 possible download links to 7-Zip MSIs. If we expand a bit and run everything found in the outer-most parenthesis:

PS C:\Users\Andrew> $((Invoke-WebRequest |Select -ExpandProperty Links |where -Property href -like "*-x64.msi")[0].href) 

we are greeted with a file path for the latest 7-Zip MSI file. Finally, if we run the entire “PrefetchScript” script block:

PS C:\Users\Andrew> $URL = "$((Invoke-WebRequest |Select -ExpandProperty Links |where -Property href -like "*-x64.msi")[0].href)"
PS C:\Users\Andrew> Write-Output $URL

we can see that it returns a full URL. If we go ahead and point our browser to that $URL, we can see that it is a direct download of the latest 7-Zip MSI file. This clarifies the purpose of the “PrefetchScript” Property, it allows the Packager to find the latest download link, even when a hotlink to the latest version is not provided. Crafting a good “PrefetchScript” is one of the harder things to do when creating a recipe, it can take much trial and error. A suggestion for creating a “PrefetchScript” is to build it outside of the packager, and only add it in once it is perfected as it’s own little script.

Moving on, the final thing we will look at in the Downloads Node is the “DownloadVersionCheck”. This property is also just a PowerShell script block. The goal of the “DownloadVersionCheck” is to provide the proper version of the application to the Packager so that it can determine if this download is a new version, and package it if it is new. The “DownloadVersionCheck” script for this recipe is fairly simple:

[String]$Version = ([String](Get-MSIInfo -Path $DownloadFile -Property ProductVersion)).TrimStart().TrimEnd()
$Version = ($version.Split('.'))[0..1] -join "."

First, the “ProductVersion” is grabbed by the “Get-MSIInfo” function, any leading or following white space is trimmed, and the string is saved to the “$Version” variable. Now, this version string will be something like “” which is great and all, but 7-Zip does not even use the last two 0’s on their version string. So, for the sake of consistency with the vendor, we split the “” version string by the “.” and only keep the first two array values (“19” and “0”), then we join those back together with a “.” and assign the joined string back to “$Version”.

Now you may notice, just like there is a $URL that corresponds to the URL tag in the XML, there is also a “Version” tag in the XML; if you were thinking that the “$Version” variable ties to the “Version” tag in the XML, you would be exactly right! It is also important to note that having a Version assigned to every application packaged is a very important aspect to the packaging process. The “Version” property plays an important role, not only in the naming of the application, but in the folder structure on the application share.

7-Zip Deployment Types Node

    <DeploymentType Name="DeploymentType1">
        <DeploymentTypeName>7Zip Silent Install x64</DeploymentTypeName>
        <Comments>Silent Installer for 7Zip</Comments>
            <RuleName>Existential of AutoPackage - OSArchitecture x64 Not Equal to 0</RuleName>
    <DeploymentType Name="DeploymentType2">
        <DeploymentTypeName>7Zip Silent Install x86</DeploymentTypeName>
        <Comments>Silent Installer for 7Zip</Comments>

Alright here we are, the meat of the Recipe. The Deployment Types Node usually ends up being the largest part of any Recipe (depending of course on how tough it is to scrape the latest download for an application).

Looking over the Deployment Types Node, we can see that there are two “DeploymentType” objects with the names “DeploymentType1” and “DeploymentType2”, which correspond with the downloads we saw earlier with the same names. There is also a “DeploymentTypeName” specified in each deployment type, but don’t let that fool you, the “DeploymentTypeName” tag only specifies the name of the deployment type in SCCM. Looking over the rest of the deployment type properties, most of the options should look familiar if you have ever created an application in SCCM before.

We can also see that the 64-bit deployment type has a “Requirements” tag with an associated “RuleName”. These properties specify that a requirements rule with the name “Existential of AutoPackage – OSArchitecture x64 Not Equal to 0” should be added to the application. By default, on it’s first run, the SCCM Application Packager Script will create a few Global Conditions for use when packaging; one of which is “Existential of AutoPackage – OSArchitecture x64” which returns a “1” on a 64-bit operating system. Therefore, this rule will ensure that the 64-bit version will only install on 64-bit computers, while the 32-bit install will run on anything else.

Some other options of note for this recipe are:

  • InstallationType – This sets the type of installation for the deployment type. The MSI “DeploymentType” is nice because if you provide an MSI, SCCM will automatically provide things like Install/Uninstall commands and a detection method. You will notice that specific install and uninstall commands are not specified in this recipe, however they can be added to MSI deployment types in the Packager
  • InstallationMSI – This is the MSI provided to SCCM for it to generate the Install/Uninstall commands and the detection method
  • DetectionMethodType – This specifies that the MSI file should be used to generate the detection method automatically, instead of using a script, file, or registry key for the detection method

7-Zip Distribution Node


Now that we have covered all of the complex parts of the recipe, we can end on a much more gentle note. The Distribution Node for the 7-Zip application only contains a single property. The “DistributeContent” property for 7-Zip is set to “True” meaning it will be distributed to the default distribution point group specified in the preferences file.

7-Zip Deployment Node


Last but not least, the Deployment Node for the 7-Zip recipe also contains just a single Property. The “DeploySoftware” property here is also set to “True” meaning the software will be deployed as available to the default collection specified in the preferences file. I will note that this is the default for all of the recipes provided, but can be changed per recipe depending on your specific needs.

7-Zip Application End Result

This post went a bit long, so I am going to let the results speak for themselves here:

This slideshow requires JavaScript.

The SCCM Application Packager Script is a very powerful tool. Its recipes were designed for ultimate flexibility with the intention of automating the packaging of just about any application in SCCM. Creating your own recipes can be a time consuming process, however, the end result will end up saving a ton of time. In my own production environment, I have saved an estimated 220 hours a year with this tool, and that number will only grow as more recipes are created, and more application updates are released per month.

Thank you for taking the time to read this post and your interest in the SCCM Packager Script! I created this tool with the intention of saving people time and energy, and was able to deepen my knowledge in SCCM and PowerShell as a result. If you are interested in contributing your own recipes to the project, feel free to submit pull requests to the GitHub repository.

Andrew Jimenez

Twitter: @AndrewJimenez_

Troubleshooting and Upgrading AD FS Farms

, ,

Troubleshooting and Upgrading an AD FS farms is usually a straightforward and easy task. There are many blogs detailing the process from Server 2012R2 to Server 2016/2019. Here are the general steps for upgrading a farm.

  1. Setup up a new server and install the AD FS role.
  2. Add the server to the existing farm.
  3. Set the new server as the primary server.
  4. Point the other servers to the new primary server.
  5. Install additional servers to the AD FS farm.
  6. Uninstall AD FS on the old servers to remove them from the farm.

What are your options when this process doesn’t work? In my case, I could not add a new server to the farm. PowerShell and the GUI both returned errors when attempting to add a new Windows Server 2019 to the farm. I started looking at troubleshooting options and eventually decided to proceed with an attempt to in-place upgrade the Server 2012R2 farm to Server 2019.


Microsoft provides some powerful tools for troubleshooting AD FS issues. AD FS Help provides several troubleshooting guides and diagnostic tools that can help resolve issues with your AD FS farm. The tools are located here:

The AD FS Diagnostic Analyzer tool can provide a health check for you AD FS farm. To use the AD FS Diagnostic Analyzer, you need to install the AD FS Toolbox PowerShell Module.

Install-Module -Name ADFSToolbox -Force

Import-Module ADFSToolbox -Force

Once the AD FS Toolbox is installed, run the Export-AdfsDiagnosticsFile command which will generate a JSON file for upload. The command will run against the local AD FS server unless the farm is Windows Server 2016 or higher. You can also list the servers with the -adfsServers parameter. The -adfsServers parameter is required for 2012R2 farms. Upload the JSON file to the site and the site will display the Health Test Results. The site will detail any problems and offer step by step guides or links to documentation to remediate the issues.

Backup and Restore

There is also the AD FS Rapid Restore Tool found here: The tool backs up the following AD FS configuration data:

  • AD FS database
  • Configuration file
  • Automatically generated token signing and decrypting certificates and private keys
  • SSL certificate and any externally enrolled certificates and corresponding private keys
  • The custom authentication providers, attribute stores, and local claims provider trusts that are installed

Unfortunately, the Restore Tool only supports a restore to the same version as the backup. This means that you cannot use this method to restore AD FS to a newer version of AD FS. You could restore the AD FS farm to a new set of servers and attempt to add upgraded servers to the farm as outlined above.

Other Tools

The site provides a number of other tools and support options. There is a full list of AD FS event items for 2012R2/2016/2019 with ID, Name, and Description. Claims X-Ray assists with debugging claims issues in your applications. The AD FS Event Module provides tools to gather and review the events from multiple servers. There are several more tools available as well.

In-Place Upgrade

Even after running the diagnostic tools several times and making the recommended changes, I still was unable to add a new server to the existing farm. The other option is to attempt an in-place upgrade of the servers in the AD FS farm. Technically, this is not supported as upgrading Windows Server with AD FS installed will uninstall the AD FS role. Prior to attempting this method, I made a snapshot (Hyper-V virtual Machines) of the AD FS servers and a backup of the AD FS farm’s current state. I started by upgrading the secondary AD FS server first. If I was unable to add the server back into the farm and promote it to the primary server, then my plan was to use the AD FS Restore Tool and rebuild the farm. These are the steps I took for the in-place upgrade.

  1. Upgrade the secondary AD FS server to Server 2019.
  2. Install the AD FS role.
  3. Add the upgraded server back into the farm.
  4. Set the server as the primary AD FS server in the farm.
  5. Verified that AD FS was still working for our services.
  6. Upgrade the former primary server, reinstall the AD FS role and set it as the primary server.

I also did an in-place upgrade of the Web Application Proxy server and added it to the farm with the Install-WebApplicationProxy cmdlet. The final step is raising the farm functional level with the Invoke-AdfsFarmBehaviorLevelRaise cmdlet. This will enable the new features to Verify the update completed with the Get-AdfsProperties | Select CurrentFarmBehavior cmdlet.

While it is not a supported option, the in-place upgrade of my AD FS farm worked perfectly. Hopefully, it is not an option you will need.

read more Troubleshooting and Upgrading AD FS Farms

SCCM Reboot DECODED:: How to make a PC Cancel, Start, Extend or Change mandatory reboot to non-mandatory on the fly.

, , , , , , , , ,

SCCM Reboot DECODED:: How to make a PC Cancel, Start, Extend or Change mandatory reboot to non-mandatory on the fly.

SCCM Reboot DECODED:: How to make a PC Cancel, Start, Extend or Change mandatory reboot to non-mandatory on the fly.

In the past to stop a PC from rebooting when you didn’t want it to people would stop the ccmexec service and do a shutdown /a

But here is the problem with that..

  1.  Shutdown /a will normally tell you that no shutdown is pending.
  2.  Any number of things can restart ccmexec.

First, how to check if a reboot is pending VS a reboot is GOING to happen

On a win10 PC or has powershell 5 installed, use this

#Detect pending reboot:
Invoke-CimMethod -Namespace root/ccm/ClientSDK -ClassName CCM_ClientUtilities -MethodName DetermineIfRebootPending

On a win7 or old powershell 2 you need to use these.


It will spit out something like this..

#PC with no pending reboot.

DisableHideTime     : 12/31/1969 2:00:00 PM
InGracePeriod       : False
IsHardRebootPending : False
NotifyUI            : False
RebootDeadline      : 12/31/1969 2:00:00 PM
RebootPending       : False
ReturnValue         : 0
PSComputerName      :

#PC with pending NON-mandatory reboot.

DisableHideTime : 12/31/1969 12:00:00 PM
InGracePeriod : False
IsHardRebootPending : False
NotifyUI : True
RebootDeadline : 12/31/1969 12:00:00 PM
RebootPending : True
ReturnValue : 0
PSComputerName :

#PC with pending mandatory reboot, notice the time stamp.

DisableHideTime : 5/1/2019 3:28:56 PM
InGracePeriod : True
IsHardRebootPending : False
NotifyUI : True
RebootDeadline : 5/1/2019 11:28:56 PM
RebootPending : True
ReturnValue : 0
PSComputerName :


Now for the magic…..

Everything that SCCM uses for knowing when and if it should reboot comes from here.

HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Reboot Management\RebootData

On a PC with no reboot pending, this key is empty.

So starting with that, this is how we can CANCEL a pending reboot.

#CANCEL a pending reboot
Remove-Item -path 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Reboot Management\RebootData';
Remove-Item -path 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Updates Management\Handler\UpdatesRebootStatus\*';
Remove-ItemProperty -name * -path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired';
#on PS2.0, "Remove-ItemProperty" doesn't work, so use this.
#Remove-Item -path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired';
shutdown -a 
Restart-Service ccmexec -force

But what if you just want to cancel the mandatory reboot and change it to a non-mandatory reboot so the user will still get the popup telling them they “need to” reboot?

#change mandatory reboot to  non-mandatory reboot
Set-Itemproperty -path 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Reboot Management\RebootData' -name 'RebootBy' -value 0;
Restart-Service ccmexec -force

What if we just want to extend the time of a mandatory reboot?

Example: In your client settings you have your reboot countdown set to 10 hours…. A user calls and says it’s going to reboot in 10 min and needs it extended… This will reset that users countdown timer back to 10 hours.

#Reset SCCM reboot countdown timer.
$time = [DateTimeOffset]::Now.ToUnixTimeSeconds()
Set-Itemproperty -path 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Reboot Management\RebootData' -name 'RebootBy' -value $time;
Restart-Service ccmexec -force

What if you want to kick off the built in SCCM reboot WITH the client settings countdown timer?
NOTE: Setting $Time to 0 will popup the non-mandatory reboot window.

$time = [DateTimeOffset]::Now.ToUnixTimeSeconds()
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Reboot Management\RebootData' -Name 'RebootBy' -Value $time -PropertyType QWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Reboot Management\RebootData' -Name 'RebootValueInUTC' -Value 1 -PropertyType DWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Reboot Management\RebootData' -Name 'NotifyUI' -Value 1 -PropertyType DWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Reboot Management\RebootData' -Name 'HardReboot' -Value 0 -PropertyType DWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Reboot Management\RebootData' -Name 'OverrideRebootWindowTime' -Value 0 -PropertyType QWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Reboot Management\RebootData' -Name 'OverrideRebootWindow' -Value 0 -PropertyType DWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Reboot Management\RebootData' -Name 'PreferredRebootWindowTypes' -Value @("4") -PropertyType MultiString -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Reboot Management\RebootData' -Name 'GraceSeconds' -Value 0 -PropertyType DWord -Force -ea SilentlyContinue;


NOTE:: In all my tests after you run The powerShell command it takes about 30 seconds for the client to respond since after you restart the service it has to do all it’s internal checks to figure out what’s new.


Read more SCCM Reboot DECODED