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.
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:
If you want the super-fast version of the idea, it goes like this:
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:
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.
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.
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:
For more details and a video on this process, see https://kb.policypak.com/kb/article/791-policypak-cloud-groups-cse-updates/
There are two ways to make rings when you have machines joined to Active Directory: Use some 3rd party software installation mechanism, or use the PolicyPak built-in CSE updater.
Chances are you already have some kind of on-prem software deployment system to perform your software updates, such as:
Whichever software deployment tool you are using, we recommend you make the following three rings for your CSE rollout:
The idea of rings (or collections, groups, etc.) varies from tool to tool in the following ways.
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.)
Not everyone has a 3rd 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:
You can read exactly how to do this here.
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:
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/
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:
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.
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:
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.
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.