Microsoft recommends that you adhere to the idea of "Rings" when performing rollouts of their updates and patches. As such, PolicyPak also strongly recommends you do the same.

Please familiarize yourself with this article BEFORE continuing: https://kb.policypak.com/kb/article/1094-using-rings-to-test-and-update-the-policypak-client-side-extension-and-how-to-stay-supported/

If you wish to configure or fine-tune the CSE auto-download process, you may create a file called update.config, which must be placed within the PolicyPak Central Storage CSE folder, as seen below.

This file can be manually created in order to configure or fine-tune the CSE auto-download process, this file should be created in the PolicyPak Central Storage CSE folder, and the file name "update.config" must match exactly, otherwise, the file is ignored. The CSE attempts to read this file once every 90 minutes, but that is configurable in the update.config file itself.

There are two ways to use the newly updated updates.config file:

• Using specific dates and times to make rings and perform a rollout
• Using relative number of hours to make rings and perform a rollout

The idea is that you specify which computers are in what ring. You may have as many rollout rings as you like. Then, you can use the RingCatchAll which will automatically work  for computers which are not specified to be in any ring.

WARNING: You must pick ONE style and NOT mix the styles.

Therefore, if first Ring element uses DateTime then RingCatchAll MUST use DateTime too. If first Ring element uses HoursBeforeUpdate then RingCatchAll MUST use HoursBeforeUpdate too.

Some notes:

• <DateTime>2021-12-05 15:00:00</DateTime>: This is YEAR-MONTH-DAY  and 24:00:00 format.
• <RandomOffset>60</RandomOffset>: Is optional parameter but doesn't work by itself.
• <RingCatchAll> is optional. If a computer is not specified within a specific ring, then it will automatically know it should be in the <RingCatchAll> ring.

Example 1: Using specific dates and times to make rings and perform a rollout

Example 2: Using relative number of hours to make rings and perform a rollout. In style you will set your rings apart with number of hours between updates.

Tip: Use the <HoursBeforeUpdate> value to specify how many hours to delay. Note that if <HoursBeforeUpdate> is 0, then the update should perform immediately after the CSE checks in and sees what ring it is in.

Breakdown of the parameters for the update.config file and how to use them:

Note: The ReportsRoot value should be set if GenerateReports is enabled (true).

Tip: ReportsRoot and MSIROOT parameters supports environment variables, such as %LogonServer% and so on, if you care to use them.

Setting up the Reports Share and Verifying Reports Are Working:

The share for reports should have the following permissions:

1. Administrator should be set to Read/Write (owner)
2. Domain Computers should be set to Read, Write, Create (but not Delete)
3. NTFS permissions should allow for All.

NTFS permissions should be set up as shown below, where Domain Computers has all rights, except Full Control.

This way, domain computers (that is, endpoints) will be able to write reports but not delete reports that they create. When enabled and configured, inside the share, you’ll see log files named in the following way:

<ReportsRoot>\<fully qualified computer name>.log. An example of this naming convention would be: \\dc\Reports\WIN7COMPUTER32.fabrikam.com.log

When you look inside the file, you will see something similar to the following text, with one line for each CSE update that is performed.

Fri Mar 15 22:54:25 2013: CSE has been updated from 3.7.545 to 4.1.711
Sat Mar 16 23:09:46 2013: CSE has been updated from 4.1.711 to 4.2.721

Manually Triggering Updates:
PolicyPak products have three command-line commands to help with updating on demand.

1. ppupdate /cseupdatering. Forces a machine to check if the machine is in the update.config file.
2. ppupdate /cseupdate. When run from a target computer, this command will instruct the CSE to reread the update.config file, which is present in the SYSVOL. You might want to do this if you recently updated the update.config file and would like the client to know about those changes. Note that this command will not perform the actual update of the CSE, instead it will simply read the file and honor the new schedule and any changes.
3. ppupdate /cseupdatenow. When run from a target computer, this command will instruct the CSE to reread the update.config file and perform any needed updates immediately.
4. ppupdate /cseupdatenow /force. When run from a target computer, this command will instruct the CSE to reread the update.config file and perform any needed updates immediately.

NOTE: This is necessary only when the update.config file’s enabled variable is set to "False" and, thus, not performing any updates normally.

Troubleshooting CSE Automatic Updates:
All machines should report something to the log files share (if set up in the update.config file) and produce either a success or failure message. If you do not see a particular machine update or perform a report, you can troubleshoot that machine individually. On the client machine, inspect the following two PolicyPak On-Prem Suite’s log files:

1. PolicyPak MSI logs are generated in %programdata%\PolicyPak\ppInstall-<build>.log.
2. Additional logs (to see if the CSE is finding the update.config file at all) are found in %programdata%\PolicyPak\ppWatcher.log (for 32-bit machines) or %programdata%\PolicyPak\ppWatcher_x64.log (for 64-bit machines).