Starting to use PM Cloud now and looking to see if it is possible to update group assignment using a local scripting job. We used to do this before with stopping services, changing some registry keys, and starting services.
This is helpful if we want group membership to change dynamically based on something that might not be in AD.
Best answer by Paul
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.
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
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.
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:
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.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
