How to Create and Use Patch Chains

Last updated on July 30, 2021.

Last Reviewed and Approved on PENDING REVIEW

Overview

Certain patches require one or more legacy patches to be installed before the current patch will run or install successfully. When this happens, a patch stream is created containing all the required versions of the patch. This is called a patch chain.

How is a Patch Chain Different from a Patch Stream?

Patch chains and patch streams are both created using the New-RPSPatchStream cmdlet. However, a patch chain is a patch stream which contains multiple versions of one specific patch type. In contrast, a patch stream may contain many different application types. When a patch chain is loaded, the application versions will be sorted and installed in sequential order. This is similar to a Dependency, except that the patch names much be identical in a patch chain, and the version numbers determine the order of patching. For more information on Dependencies, see the DependsOn Element section in the RPS Patch Manifest Definition article.

How a Patch Chain Works

Patch chains must have identical Patch Name values, (which are case sensitive), and include the Patch Version in the name as well. The Patch Version determines the order that the patches will be installed. When the LCM (Local Configuration Manager) executes on a target, it will attempt to install the next highest version of a patch in a chain. If none of the patches in the chain are installed, then it will start installation with the lowest version, then work its way up the version chain until the highest version is installed.

There are two events that can cause a chain to stop processing all patches:

An error occurs during installation of the previous patch in the chain.
The patch is outside the current Maintenance Window. For more information on Maintenance Windows, see How to Use Maintenance Windows.

Warning

Patches with a version less than the currently installed patch in the chain will no longer be tested by DSC to verify installation status. To resolve this, the highest installable patch in the chain must be uninstalled and the target system must re-install the entire chain by starting over with the lowest version.

Patch Version Constraints

Version numbers consist of two to four segments: major, minor, build, and revision, as discussed in the table below:

Segment	Type	Segment	Description
Major	Required	First	Major rewrite of product between major numbers. Backwards compatibility cannot be assumed.
Minor	Required	Second	Indicates significant enhancement with the intention of backwards compatibility where all major numbers are the same.
Build	Optional	Third	Indicates when processor, platform, or compiler changes.
Revision	Optional	Fourth	Usually indicates a minor fix or patch for security hole.

Example: .NET Framework 4.7.0

Where the 4 is the major and indicates that this may not be backwards compatible with .NET versions where majors are lower than 4. For example: .NET Framework 4.7.0 may not be backwards compatible with .NET Framework 3.5.0.
Where the 7 is the minor and indicates there has been an enhancement added to version 4, typically backwards compatible with lower minor numbers where the major number is the same. For example: .NET Framework 4.7 would be backwards compatible with .NET Frameworks 4.5, but not .NET Framework 3.5.
Where the 0 is the build and indicates that this is the first release of version 4.7.0. Higher build numbers indicate minor changes and are backwards compatible with .NET Framework applications where the major and minor numbers are the same.

To Create a Patch Chain

To ensure a patch chain is created properly, the following conditions apply:

Each of the patches in the chain must have the exact same name when they are created in REACTR, with version numbers following the conventions stated above. An example follows:

Correct:
```
.NET Framework 4.7.0
.NET Framework 4.8.0
.NET Framework 5.0.0
```
Notice that the name .NET Framework is the same in all three versions of the application. Variations of the application name will not be executed properly. An example follows:

Incorrect:
```
MS .NET Framework
.NET Frmwork 3.5
.NET_Framework4_7
```
Note
Patch names are case sensitive and must be exact to be processed sequentially.
When patches are copied to the RPS node to create the patch chain, all patches must reside in the same folder.
Create the patch chain using the New-RPSPatchStream cmdlet as shown in the following example:
```
New-RPSPatchStream -Name MyPatchChainExample -Path C:\MyPatchChain
```
For more information on how to use the New-RPSPatchStream PowerShell cmdlet, see How To Load a Patch Stream.
Approve the Patch Chain. See How to Approve and Reject Patch Streams for detailed instructions on accomplishing this step.

Once the patches sync through the CDN (Content Delivery Network) and are loaded onto the RPS node, the DSC (Desired State Configuration) will run to make sure the patch chain installs the applications in the right order.