Introduction

The overall goal is to provide a framework for confident change management process that keeps users happy, administrators happy, and avoid confidence disruptions that can plague deployments and operations teams for a long while after an issue occurs.

Preferable Practices

When it comes to maintaining a production environment, while ensuring proper testing is occurring, the following is a Preferable Practices guide. The aim of this is to provide an overview of potential structures for segregating testing from production and highlight use cases for staging rollouts with computer groups with a focus on stability, confidence, and operational procedures.

> Best Practices are set by each organization and may have different requirements so, please follow your Best Practices as outlined by the change control policies of your organization!

Computer Groups

The core component for this structure is based on Computer Groups in EPM SaaS. Each computer group is assigned a policy with a specified revision number and sets the upgrade management configurations.

While it can be tempting to throw an entire environment into one computer group, e.g. "Prod", "Dev", etc., it is helpful to think of a potentially staggered approach to change management by creating subsections of groups. To subject you to my horrible Visio skills, you can think of it as creating the number of computer groups that's equal to the number of Group Sections x Environments. In some cases, it may make sense to have a single environment and section group for testing both client and policy updates (e.g. pilot team, one-off testing), while others may be better suited for a phased roll-out approach.

Performing Updates and Upgrades

Policy -> Environment Phased Upgrade

When making changes to policy, you can either make changes to the current production policy or duplicate the policy and modify certain sections. Before testing, validate Policy Assistant to see if there are any recommendations on the new definitions that have been put in place to be addressed. If you want to validate that only the expected changes have been made, you can run the policy through Policy Difference against the previous version of the policy. It is highly recommended to add meaningful annotations to the revisions as Policy Difference can help ensure the difference of the two policies match the expected intent.

Once a safe policy version has been created, it is advisable to have a standing Pilot Computer Group for testing policy changes to validate behaviour. With each stage of promoting the policy, it's recommended to run a Policy Difference on the version currently deployed to a computer group against the version to be applied to clearly articulate the changes that will be made. This also ensures that you can capture the previous revision number for a roll-back in a change management ticket.

Documentation: Computer Groups

Note: This is also available via API

Client and Adapter Versions - Environment AND Group Section Phased Upgrades

With Package Manager controlled Client and Adapter versions, the roll-back scenario isn't integrated into the EPM SaaS product, however a granular, phased approach can also ensure that issues are caught earlier on, and the impact of using an MDM to roll-back client and adapter versions is reduced.

Like the policy updates where we're looking to go environment by environment, we're also looking to go group by group within those environments. For instance, after validating with our test group that there's no issues seen with the client & adapter interacting with environmental nuances, we start in Dev with Group A. Once Group A has had time to 'soak' by having the version run for a set amount of time and no issues are seen, and then Dev Group B, and continue until all of Development has completed. Then, move onto the Production environment in the same way. This means that, if there's an incredibly rare occurrence that a catastrophic issue only seen in the production environment and not others, the entire production environment isn't completely down until resolved.

Documentation: Computer Groups

Other Notes

Gotchas

While this does introduce a more granular approach to upgrades and policy testing, this also means that there's more complexity for maintenance. Balancing granularity with operational overhead is a balancing act inherent with policy management, and this provides another area to be mindful of. Ensuring that well-documented procedures and expectations are in place is essential to success, and this is no different than all operational choices of the products.

In terms of human error risk, each 'step' of human intervention introduces a new opportunity for human error. That said, the segmentation also provides a smaller scope of impact if/when human error occurs.

Test Groups

For both Package Manager and Policy Updates, occasionally a test Computer Group will be needed in conjunction to investigating a break/fix incident. This can allow either testing a certain client/adapter version of the product to see if there are changed behaviours, or assigning a one-off test policy that's a clone of the current product policy to troubleshoot a known issue without risk of accidentally deploying to any other environment.

Moving Computers Between Computer Groups

Do you have 1000's of computers to move between Computer Groups? Fantastic! The SwaggerUI can be used with AssignComputersByCsv to bulk change the computer groups of the IDs.

Swagger URL guidance: EPM FOR WINDOWS AND MAC API

API Reference: Retrieves list of Accepted Domains

KB article around CSV ComputerID field: https://beyondtrustcorp.service-now.com/csm?id=kb_article_view&sysparm_article=KB0020236