In this article we’re going help you answer the question "How can I best pre-test a PolicyPak client-side extension (CSE) rollout, before deploying it to all my end-computers?" Now, you might be wondering why you shouldn’t just send the latest CSE to all your machines all at once, always, whenever a new version is released.

The answer to this is that while PolicyPak acts as part of the operating system and helps you manage important security and configuration items, no product is bug free and, therefore, PolicyPak cannot guarantee that any updated CSE will work 100% with what you already have. As such, you should pre-test newly provided CSEs to a small group first and verify if they are working the way you expect before you deploy them out to all your machines.

What we want to avoid is a situation where you mass-deploy an untested CSE to 100% of your machines and THEN find that you have some problem you need to back out of since this can be very time consuming and difficult to do. Instead, if you pre-test the CSE before mass rollout you will have increased confidence to roll it out estate-wide.

Understanding the Microsoft "Ring" Model for Rollouts

PolicyPak is not alone in wanting to ensure your confidence during Windows 10 updates. Indeed, Microsoft themselves have this exact same concern and recommendation. Ever since Windows 10 shipped, Microsoft has recommended a "ring" approach to updating Windows.

This is because Windows is constantly updated: every month (bug fixes), and twice a year (huge upgrades).

When Windows itself gets updated, there are controls available to help you "draw lines" around machines so you can know in advance which machines will get which new software. These lines are known as "deployment rings," "update rings," or just "rings." We recommend you get familiar with Microsoft’s idea of rings using the following resources:

1. Microsoft: https://docs.microsoft.com/en-us/windows/deployment/update/waas-deployment-rings-windows-10-updates
2. Using PolicyPak to manage Windows Update for Business Rings: https://www.policypak.com/pp-blog/windows-update-business
3. Microsoft Ignite talk about Rings: https://www.youtube.com/watch?v=omwelzp-Hlw
4. Jeremy’s MDM book (Chapter 9): MDMandGPanswers.com/book

If you want the super-fast version of the idea, it goes like this:

1. Allocate 2–5% of your computers to get the latest update (as soon as possible). If something goes wrong, you will know about it NOW, and not later when you’ve rolled it out to your whole estate.
2. Then, if all goes well, increase it to 10–50%.
3. Then, if all goes well, increase that to 51–100%.

These segmentations are what is referred to as "rings." Here’s an image of Microsoft updates, courtesy (https://docs.microsoft.com/en-us/windows/deployment/update/waas-wufb-csp-mdm ). The basic idea is that you put a “Delay” between your rings.

In this picture, Microsoft is showing an example of three rings:

1. Initial Pilots (2-5%): No delay…. Get the Micorosft updates immediately.
2. Fast Ring (10-50%): 5 day delay.
3. Slow Ring (51-100%): 10 day delay.

Microsoft updates can be a little complicated because they also deal with "channels," or the types of versions you want to install. Additionally, Microsoft’s model is more complex than PolicyPak’s model, because the updates are required and forced. Microsoft Quality Updates (i.e., bugfixes) are required to be performed within 30 days (or they will be installed automatically) and Microsoft Upgrades (i.e., new versions of Windows) are required to be performed within 365 days (or they will be installed automatically.)

But PolicyPak doesn’t have any of those requirements or any method to force an update. Instead, our lifecycle is pretty simple.

1. Every 4 to 6 weeks, PolicyPak ships a new CSE with bug fixes and new features.
2. That version goes into the PolicyPak Portal and is also then available for use within PolicyPak Cloud.
3. When the monthly update occurs, we notify all customers (primary and secondary technical contacts).
4. If some known issue occurs within the month, we will occasionally release a hotfix build and generally make NO announcement.
5. Whichever is the latest CSE in the Portal or PolicyPak Cloud is the only version of the PolicyPak CSE that is supported.

This means that you only need to keep one simple MSI up to date on your endpoints to be at the latest build.

Remember that when you use PolicyPak with Active Directory (SCCM or GPO) or with your MDM service, the latest CSE isn’t magically "pushed" from us at PolicyPak down to your PCs. And for PolicyPak Cloud customers, the latest CSE isn’t dictated to your endpoints either. In ALL cases it’s an admin’s choice to opt-in to use the latest CSE and specify where exactly he or she wants to get started using it.

In the follow sections, we’ll provide our recommendations for various PolicyPak products on how to implement a ring policy for PolicyPak CSE updates.

Recommendations when using PolicyPak Cloud: Rings and Rollouts

In PolicyPak Cloud, because the concept of "groups" is baked in, you can use a PolicyPak Cloud Group like a ring. Simply choose a group and manually specify to use a particular version of the CSE on that group. You can also specify to use a particular version of the CSE everywhere (using the special ALL groups).

Therefore, our advice would be to do the following:

1. Set up a group of 2–5% of your computers. When a new CSE is released, you should opt in and use this group to start testing and verify success. If there’s a problem you can raise it to the PolicyPak support team and we’ll work with you.
2. If all goes well, you can roll out the latest CSE to more PolicyPak Cloud Groups. It only takes one click within the group to select the CSE. Your target rollout for the new CSE should be around 30–50% of your Windows 10 machines. Again, at this point if there’s a problem, you can raise it to support and we’ll work with you.
3. Then, after you’ve rolled out to 50% of your machines, you should be confident enough to roll it out to all machines.
4. When ready again, simply pick the remaining PolicyPak Cloud Groups and select the latest Client Side Extension to opt-in more groups.
5. Alternatively, use the special All group to finish your upgrade and mass upgrade the remaining PCs all at once (again, after you’ve done some pre-testing.)

For more details and a video on this process, see https://kb.policypak.com/kb/article/791-policypak-cloud-groups-cse-updates/

Recommendations when using PolicyPak with your Active Directory: Rings and Rollouts

There are two ways to make rings when you have machines joined to Active Directory: Use some 3^rd party software installation mechanism, or use the PolicyPak built-in CSE updater.

Active Directory Option 1: Making Rings with 3^rd Party software deployment tools (recommended)

Chances are you already have some kind of on-prem software deployment system to perform your software updates, such as:

1. PDQ Deploy (recommended by us here at PolicyPak for on-prem software installs)
2. Microsoft SCCM
3. KACE
4. Many, many others.

Whichever software deployment tool you are using, we recommend you make the following three rings for your CSE rollout:

1. Allocate 2–5% of your computers to get the latest CSE update (as soon as possible). If something goes wrong, you will know about it NOW and can get support.
2. Then, if all goes well, increase it to 10–50%.
3. Then, if all goes well, increase that to 50–100%.

The idea of rings (or collections, groups, etc.) varies from tool to tool in the following ways.

1. For SCCM, you use collections (and make them act like rings.) (See this official document: https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/collections/create-collections.) The rule you create would essentially look for NO CSE or an earlier Client Side Extension version.
2. For PDQ Deploy, you use targets (and make them act like rings.) You can select Active Directory groups, text files with specific computers, PDQ Inventory groups, and other group lists. (See the details here: https://documentation.pdq.com/PDQDeploy/13.0.3.0/index.html?optimize-deploy.htm.)
3. For other on-prem tools, see your corresponding documentation.

Note: While it’s possible to deploy the PolicyPak CSE via Microsoft’s Group Policy Software Installation, it is not recommended. Our official recommended way to deploy the PolicyPak CSE should you have NO on-prem software deployment tool is the free version of PDQ Deploy. (See the video series at https://www.policypak.com/integration/policypak-and-pdq.html.)

Active Directory Option 2: Using the Built-in PolicyPak CSE Update mechanism (also, an excellent choice)

Not everyone has a 3^rd party software deployment tool. Note: While it’s possible to deploy the PolicyPak CSE via Microsoft’s Group Policy Software Installation, it is not recommended. Our official recommended way to deploy the client is, again, via a tool like PDQ Deploy, SCCM, etc.

As an ALTERNATIVE, you can use the PolicyPak CSE Auto-Updater.  The general idea is that if you put the CSE in the Central Store, then the CSE will automatically look for updates, perform the update, and optionally report on the update.

Tip: This is the original video on the subject, BUT the XML parameters have changed since build 2785. https://kb.policypak.com/kb/article/495-auto-updating-the-cse/

To be consistent with the idea of Rings, we have added this capability to the configurable options of the CSE Auto-Updater. The CSE Auto-Updater will honor one of two types of rings:

1. Ring Type 1: Using specific dates and times to make rings and perform a rollout. In this style you will set specific dates and times for the machines to get the updates.
2. Ring Type 2: Using relative number of hours to make rings and perform a rollout. In this style you will set your rings apart with number of hours between updates.

You can read exactly how to do this here.

https://kb.policypak.com/kb/article/1128-how-can-i-roll-out-latest-policypak-cse-with-active-directory-in-a-controlled-manner-using-rings/

Active Directory Option 3: Using the Built-in PolicyPak CSE Update mechanism in an “alternate” manner.

You can use a similar technique as Option 2 which uses an update.config file; but in the “reverse.” Here’s the outline of these steps:

1. Place the updated CSE in the central store.
2. Create the update.config file, but specifically specify that the technique will be disabled and always be off. You would do this with the “Enabled=False” parameter.  
3. Clients can ONLY be upgraded when an admin (or system wide script) runs a special command:  ppupdate /cseupdatenow /force .
4. This command will override the Enabled=False parameter and force-update the client with the latest CSE from the Central Store.
5. You can automate this “signal” to them using a script, PolicyPak Scripts & Triggers, SCCM or any other another technique… and the machine will upgrade.

Active Directory Option 4: Using PolicyPak Remote Work Delivery Manager to specify an update (Not strongly recommended; but could work for your situation)

Another way to make rings would be to use Group Policy to deliver a CSE update via PolicyPak Remote Work Delivery Manager.  You could create the rings using Active Directory groups or any other targeting, then, shoot down a CSE update to specific machines as you saw fit.

KB on the idea: https://kb.policypak.com/kb/article/1044-how-do-i-use-policypak-remote-work-delivery-manager-to-update-the-client-side-extension/

Video on the idea: https://kb.policypak.com/kb/article/1087-using-remote-work-delivery-manager-to-update-the-policypak-client-side-extension/

Recommendations when using PolicyPak with your MDM: Rings and Rollouts

The concept of rings with regard to Windows 10 updates and upgrades is built into Microsoft Intune (and perhaps other MDM services). You can see Microsoft Intune’s example of rings here: https://www.anoopcnair.com/software-update-patching-options-with-intune/.

But the specific idea of using rings to deploy other software (any software), like the PolicyPak CSE, is not something native in an MDM service. Therefore, you will need to create computer groups, then assign software to those groups.

In Intune (and most other MDM services), groups can be simple or dynamic. You might want to create three groups like this:

1. Simple group: Hand-picked machines which represent 2–5% of your estate.
2. Dynamic group at 30%: A group you define with 30% of your Windows 10 computers.
3. Dynamic group at the remainder (31-100%): A group you define with the remainder of your Windows 10 computers.

By making the groups dynamic, as computers get enrolled into your MDM service they will automatically be part of the first or second dynamic group. But because the first group is a simple group with hand-specified machines, those machines are the only ones that will get the initial rollout of a new CSE. Then, because the PolicyPak CSE is an MSI, you can use the MSI deployment method with your MDM service to target to these groups.

How to Stay Supported

Earlier we stated that the latest CSE in the Portal or PolicyPak Cloud is the only supported version.

The latest version is the one with the most fixes and features.

You might be wondering if only the very latest CSE version is supported, does that mean that you lose support if you are unable to stay current (or nearly current) with the PolicyPak CSE rollouts. The answer in summary is no; you are always supported, regardless of the CSE version you have on your machine. You are always welcome to ask questions and open support tickets for "how do I questions," and so on.

However, if you find a bug, problem, inconsistency, or other issue, then PolicyPak support will direct you to update (at least) one machine with the very latest CSE on it for investigation. And we will ask for log files from that machine after you have reproduced the issue. In other words, as a general rule, we will typically not begin to investigate your issue unless you can reproduce it on a machine with the latest CSE. There is no value in investigating old CSE behavior because the problem could already be fixed in the latest version. And, logging improvements could be present in the latest CSEs. Additionally, if your request involves us investigating the log files, similarly, we will not ask for nor investigate any log files unless the problem is reproducible on the latest CSE.

From a practical perspective though, you should attempt to have your Windows 10 machines on a Client Side Extension which was at least shipped within the last full year. Six months is better, and three months is even better. Upgrades should go smoothly from any Client Side Extension to any other Client Side Extension, but those are not expressly tested. We really only test the "previous Client Side Extension to current Client Side Extension" upgrade path. Therefore, when you stay as close to our currently shipping Client Side Extension as possible, you’re likely going to get the best experience and latest testing and fewest problems overall.

Furthermore, because corporate PCs are typically full of applications, system software, and possibly other unusual circumstances, we strongly recommend you have at least one "very clean" machine for ongoing testing. A "very clean" machine would have:

1. Latest version of Windows 10
2. Latest version of Microsoft Edge
3. Latest version of Chrome or other browsers
4. ONLY software which PolicyPak might be controlling, such as required with PolicyPak Application Manager, PolicyPak Least Privilege Manager, PolicyPak Start Screen & Taskbar Manager, etc.
5. Not much else, and most specifically, no 3rd party system software or A/V software other than PolicyPak

In this way, you can hand-install the latest PolicyPak CSE, do some pre-flight testing before you even get to your rings. Then if you encounter a bug, you can quickly validate your bug report, and collect logs from a machine that’s close to you and available whenever you need it, not just when the user is available.

Final Thoughts and Recap

A Windows 10 rollout incorporates the concepts of rings so you can confidently roll out Windows 10 as new versions come out, month after month and year after year. PolicyPak encourages you to utilize the same parallel concept of rings when rolling out the PolicyPak CSE either for the first time or at update time.

Use your software deployment mechanism (either an on-prem system, or via MDM or PolicyPak Cloud) to make the rings you need. Keep in mind that you typically want to update 2– 5% of your computers for a quick check, then feather it out to about 30%. Finally, after ensuring that everything is working properly, you can roll it out to the remainder.

If you fall behind, PolicyPak has no "force update" mechanism. You can stay behind and "out of date" for the PolicyPak CSE as long as you want (again, the practical outside length in this is about a year.). As stated, we don’t recommend this, because in doing so, you specifically lose out on new features and fixes in latest CSE.

With that being said, even if you fall out of date with the latest PolicyPak CSE, you are still entitled to support. Just remember that you will have to reproduce the issue on a machine with the latest CSE and be prepared to get logs from a "very clean" machine.