I am not fully understanding what you try to accomplish. Your previous option of stopping the service is still there and allows you to do the same.

I would like understand why and what we try to accomplish, and I might be able to give you a way better answer.

Hi ​@dennedy, before we delve into what might be possible, can I check what problem\scenario you are trying to solve for here? Are you trying to apply a different experience to a given user - if so, what’s the nature of the different experience (e.g., is it assigning a whole different workstyle, or do they just need access to some different apps) and what outside change would usually drive this scripting? 
 

Thanks for the responses and interest. The basic functionality is that we want to put some devices into a BETA group to receive policy updates first before them going to the entire world. But we would want that change to beta group or change to non-beta group to be dependent on some other kind of flag file/reg key, etc.

So, flag file exists puts them into computer group that gets policy updates first. Flag file removal puts them back into the main group.

In that case, using the Computer Group objects and policy version assignment within PM Cloud is probably the best way to handle this, and saves you having to orchestrate something at the client side outside the product.

You can easily move machines between groups via the UI, or via the API if you want to automate it.  Each group can have different revisions of the same policy applied, and you can use RBAC to separate who can assign policy changes to your production group to ensure you don’t make assignment errors during testing. 

It’s quite common for customers to construct their “route to live” with a handful of different computer groups (increasing in size) which are running different versions of the production policy which are working their way through their change control processes into live. 

For testing and validation, I typically have four groups:

1. Production (Production PCs)
2. Pilot (Testers of MS updates and PM Policy)
3. Pre-Pilot ( IT, people who manage policy etc.)
4. Test Temp. ( Users you fix issues for )

I would have a similar policy design, except that the Pre-pilot policy would be assigned to groups 3 and 4.

Then, migrate the policy from Pre-pilot to Pilot, and later from Pilot to Production.

This allows me to make changes to the policy and test the outcome on groups 3 (Pre-pilot) and 4 (Test Temp.). Once the policy is matured and has been through the processes of Pilot and ended in Production, I empty my Test Temp group back to the Production group.

With the new policy comparison tool in PM Cloud, you can compare policies for your change requests.

The API is also an option for moving computers around; it works great, and the Swagger for PM Cloud is awesome.

https://YourPMCloudinstance-services.pm.beyondtrustcloud.com/management-api/swagger/index.html?urls.primaryName=v2

I could see a PowerShell script being used to check if a registry string value exists. It would move the client computer from A to B or C, depending on that value. However, it can also be done in the GUI, which might save some effort.