Starting with build 2862, PolicyPak Preferences will automatically be "forced disabled" when detected licensed on domain joined machines; even if there is a valid corresponding Universal or Legacy license which would normally enable it.
Note: This restriction is only forced for domain joined machines, and doesn't impact non-domain joined machines.
PolicyPak Preferences' job is to deliver GPPreferences settings to machines when PolicyPak Cloud or alongside your MDM service. The TYPICAL use case is when the machine is NON-domain joined and you want to get GPPreferences items to your endpoints, like Registry, Shortcuts, Drivemaps and Printers.
When the machine is NOT domain joined, there isn't a problem with PolicyPak Preferences. PolicyPak Preferences will take ANY GPPreferences setting and get it delivered (and undelivered) as expected.
But when the machine is domain joined AND GPPreferences policies are being delivered from Group Policy; the PolicyPak Preferences component can have an issue because of timing outside of our control between the Group Policy / GPPreferences engine and PolicyPak. This has been a known issue for years, and can be seen in this KB article: https://kb.policypak.com/kb/article/413-why-do-i-see-slowdowns-on-my-machines-when-policypak-preferences-is-licensed-and-computers-domain-joined-can-this-be-worked-around/
As such, previous guidance to minimize conflicts has been:
<component id="f8357ae4-f4e0-49ec-ae9d-61078938e7cd" name="PolicyPak Application Manager" />
<component id="608ba33d-af06-46f9-9e6c-62495560024e" name="PolicyPak Preferences" enabled="false" />
<component id="e0088a46-ab54-4fbd-a733-303c58244c5e" name="PolicyPak Administrative Templates Manager" />
Customers must change this value if they wish to enable this component (which they may want to; as explained later.)
In logs, CSE shows a message: "Your PPPrefs license disabled because this machine is DOMAIN JOINED. Please forcefully turn it on with the ADMX setting entitled 'Specifically enable PolicyPak Preferences (Original version) if licensed.'"
So, again, if when your LICENSE REQUEST has DOMAIN JOINED machines, we attempt to automatically send you a license in return with Policypak Preferences automatically set with the ENABLED=FALSE flag, as expressed earlier. But there are times when license files might be sent with this omitted, thus turning on PolicyPak Preferences and causing conflicts in a domain.
Therefore, as an additional precaution to prevent conflicts in domain joined machines, staring in build 2682 this license must be set to ENABLED=TRUE (or omitted) AND we now require this component (and only this component) to be explicitly ENABLED via ADMX setting, like what's seen here:
Therefore starting in build 2682 it will now take TWO steps for PolicyPak Preferences to be enabled:
Step 1: The Universal license file must have the line
<component id="608ba33d-af06-46f9-9e6c-62495560024e" name="PolicyPak Preferences" enabled="true" />
or
<component id="608ba33d-af06-46f9-9e6c-62495560024e" name="PolicyPak Preferences"/>
Then and only then will PolicyPak Preferences attempt to process GPPreferences items with domain joined machines.
If your machine is non-domain joined and you wish to have PolicyPak deliver GPPreferences using PolicyPak Preferences, you only need to have one step:
PolicyPak + an MDM service like Intune + Non Domain joined machines: You need to ensure your Universal license has the PolicyPak Preferences line enabling (or omitting) enablement.
<component id="608ba33d-af06-46f9-9e6c-62495560024e" name="PolicyPak Preferences" enabled="true" />
or
<component id="608ba33d-af06-46f9-9e6c-62495560024e" name="PolicyPak Preferences"/>
If your machine is ONLY domain joined, there is really no good reason to enable this license which could cause conflicts.
However, you might want to turn on the license and then enable this setting if your machine is domain joined, BUT you deploy GPPreferences from PolicyPak Cloud or using PolicyPak and your MDM service like Intune.
Remember though, the problem arises when you deliver GPPreferences settings from MULTIPLE sources, say, on-prem GPOs and also PolicyPak Cloud. Or on-prem GPOs and with PolicyPak and your MDM service.
When you attempt to deliver GPPreferences from MULTIPLE SOURCES, then this is not supported; and you're much likelier to have a conflict.
The key takeaway here is to use ONE SOURCE for delivering Group Policy Preferences items and not two.
Either
-or-
This protection is put in place starting with build 2682 when computers are DOMAIN JOINED so they don't have conflicts with on-prem GPPreferences.
We recommend you keep this component disabled unless you know you need it, or you plan to migrate away from on-prem GPPreferences and use CLOUD or MDM with PolicyPak exclusively.
Note that if PolicyPak Preferences license is disabled by ADMX policy (https://share.getcloudapp.com/wbu6mk2A) that will always win (even if Specifically enable PolicyPak Preferences (Original version) if licensed" ADMX is set.
In the future, we plan for PolicyPak Preferences to evolve to enable co-existence from multiple sources; this KB will be updated when that time arises.