This document is intended to provide best practices and considerations to take into account when creating a custom patch or custom product.
Patch detection can be done via file version comparisons and registry checks. One thing to note is the different comparison options. When using file version comparison, you can specify a comparison type. When specifying a registry key check, the comparison checks to see if the key exists and is equal to the value provided. In this way, registry based detection is less flexible when creating custom patches for a group of system that could have different registry values all apply to a specific patch.
Below are the 2 different methods for detection.
Let's say the target machine being scanned has ShavlikProtect_9.2.5046.exe in the directory C:\Users\Domain\Downloads. If the file version is 9.2.5046.0, or if it's greater than that(such as 126.96.36.199), then the patch will be seen as installed. However, the registry detection is a different story. If the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Shavlik Protect\version has a value of 188.8.131.5246, then the patch is seen as installed. However, if that value were 184.108.40.20646, the patch will show as missing, even though 220.127.116.1146 is greater than 18.104.22.16846. This is one way the exact comparison done by registry checks can affect your scan results.
Patch - Product Mapping
You can use "Targeting" to map a custom patch to a custom product, so that the detection builds off of itself. If a patch is mapped to a product, then Protect won't evaluate that patch unless it first detects that product as installed. It is best practice to create a custom product when applicable, to ensure your custom patches aren't scanned for unless applicable.
It is important to keep in mind that Protect runs deployment operations as the LocalSystem account. If you're deploying patches that make use of an installer not signed by Microsoft, your UAC settings may cause a security prompt to come up, asking for permissions to run the installer. The LocalSystem account cannot accept these prompts, and because of this, your deployment will remain stuck, waiting for input. Because of this, it is important to make sure the installer is already unblocked in the file properties, before the file is pushed out to the target machines.
This document explains what to look for, and how to resolve this issue: Deployment Failures Caused By Blocked Files
In addition to ensuring the installer is not blocked, you'll also want to make sure any extra resources your patch requires (answer file, batch file, etc) are pushed over via Custom Action when the patch is deployed, or already reside on the target machine. Information about custom actions can be found here: How To: Perform a Custom Action Complete Tutorial with Custom Actions
Shavlik Protect 9.x