How To Choose The Right Windows 10 Deployment Ring Enrollment Criterion For Your Organization

Over the past three years. I have probably spoken to dozens if not hundreds of IT managers, executives, schedulers, and other folks involved in Windows-as-a-Service management, and there is one common thread. They are all wondering how they can lower the risk of business disruption while getting through this upgrade as efficiently as possible to be able to prepare for the next. 

The best answer — next to creating a repeatable, scalable and automated process managed by an IT Transformation tool like Dashworks, of course — is to utilize the concept of Windows Deployment Rings, Microsoft's preferred way of rolling out new feature updates. However, that begs another question — maybe the biggest practical implementation question that IT managers have regarding deploying Windows-as-a-Service: "What criteria do you use to enroll users and devices into deployment rings that still achieves the velocity required while managing the risk of accelerated upgrades?

[Want more? This article is part of the Definitive Guide To Windows 10 Servicing blog series.]

While Microsoft's rapid upgrade process serves the software giant as somewhat of an internal showcase of how fast an enterprise could migrate to the next version of their OS, it is an example most commercial enterprises would not want to follow. The company utilizes user research to identify problem applications and drivers and only tests about 1-5% of their (absolute mission-critical) apps. The rest are tested in-flight.

To help other organizations accomplish a similar velocity, Microsoft talks a lot about their deployment ring concept (Insider, Pilot, Broad), but much less about how to identify who should be placed in each ring. Understandably, this leads to a lot of trial and error and even myths surrounding deployment rings — myths which I want to help dispel today by showing you which enrollment criteria we recommend to our clients.

5+ Ways To Approach Windows Deployment Rings

There are five major strategic ways that you can approach your Windows Deployment Ring enrollment. Below, I want to briefly explore each way and showcase some of the pros and cons.

1. Application-centric approach: Most organizations will probably take an application-centric approach to their deployment ring strategy given the fact that app compatibility is still one of the biggest hurdles they have to overcome in this process. To do so, you will have to first individually identify all of your applications that require testing by determining each product's criticality to the business. Once you have tested those with a thorough process, you will be able to drive deployments based on app readiness. Of course being able to prioritize that testing to achieve readiness velocity will be key to success.

2. Machine-centric approach: You could also enroll your devices into your deployment rings based on their spread of application usage and wider scale testing that can be achieved. In other words, put the machines with the widest application spread into ring 0 to achieve your testing and readiness. You will have to test all in-scope machines based on their app installation and identify those machines that provide the greatest app coverage (mission critical / important apps) and rely on individuals to test and give feedback. You can turn those apps green that have received no negative feedback and accelerate your deployment this way.

3. User-centric approach: Another popular approach is the user-centric approach, which is exactly the same as the machine-centric enrollment, but with users as the selected starting point.

4. Volunteer-based approach; If your user base is accustomed to self-service IT, you could ask for some tech-savvy volunteers from each business unit that are willing to accept Ring 0 and test everything in-flight. You essentially test as you go, knowing that Ring 0 has the highest risk, Ring 1 the second highest risk, and so on.  

5. Business-based approach: Last, but not least, the business-based approach is popular with extremely large organizations with almost autonomous business units. They don't want to "salt & pepper" users as they are ready, but would rather drive the migration effort unit by department. Therefore. you would spread your business users across each deployment ring and drive velocity department by department. 

In addition to those five approaches, organizations can also create their own hybrid by combining two of the above, e.g., a user-centric business unit-based enrollment or a volunteer-based application-centric approach. Whichever approach you choose to adopt, you will need to factor in your rollout schedule methodology — which can either be:

1. Schedule-driven: set the deployment ring start --> end dates and work backwards to ready users, computers and applications for those dates
2. Activity-driven: as your applications and any other readiness items turn green, they will then trigger next stage (migrate me now).

Which methodology you choose for your enrollment criteria selection and rollout schedule strategy depends on your unique scope and situation. I, therefore, strongly recommend that you get a detailed and actionable picture of your entire estate before making a choice. 

Deployment Ring Enrollment Considerations

Before you start picking your criteria, there are a few considerations you should know about:

• Overcome your traditional project management limitations! Traditional desktop transformation projects commonly focus on one coordinated significant bang migration of a single location or business unit at a time. Such projects are usually managed with outdated spreadsheets, and all in-scope users have to be migrated before moving onto to the next location or business unit. Because of the inability to manage schedules based on live updates, flexibility is limited. However, in most cases all of the Windows-as-a-Service upgrades are in-place upgrades. Therefore, they should require few or no floor walkers (the biggest reason to keep it in one location).

• Embrace Evergreen IT: It is time to let go of old fears and embrace an Evergreen IT management approach that caters to multiple teams, locations, or business units, so application/user/device readiness can take precedence over organizational boundaries. In other words, with a centralized command and control platform of a sophisticated IT Transformation management tool, users across the entire organization, regardless of their location or business unit, can (and should) be upgraded as soon as they are ready.

• Finish your application testing as soon as possible. It is crucial that you achieve your application testing in a set time frame or the devices in each ring will be not be able to migrate! To do so, look into automating the process using automated app packaging and testing tools — preferably ones that integrate with your IT Transformation management tool for seamless workflows. This will allow you to set the app as green and trigger other workflows automatically, significantly accelerating your process. 

• Long rollout schedules mean more application certification.  When choosing a business unit-based approach, it is almost guaranteed that you will be working on different platforms (e.g., Windows 10 1709 and 1803) for a period of time. Now, each existing and new application may need to be certified on several platforms (e.g.,, an application upgrade to an existing app currently running on >1 OS version). By supporting applications across multiple OS versions, you are also always working to the lowest common denominator. This might also mean that you cannot move a department until every app is done, which is mathematically not at all efficient. 

• Re-think your attitude toward risk. We asked more than 400 enterprise IT managers and executives what their biggest fear regarding WaaS is and 65% answered they were most afraid of the potential business disruption and the impact of the frequent updates. To minimize the risk involved, it helps to categorize your highest-impact as well as your most-used applications. Then ask yourself: How many users can you afford to be down after the upgrade?

• Business restraints: I am sure you have heard the saying that "life gets in the way" of the best laid plans. Be sure to minimize interruptions by considering any important business restraints as you plan. These could be change freezes, important events or milestones, plan organizational restructuring efforts, etc. Then decide how you will have to manage the deployment calendar.

• Bandwidth & IT constraints: Another very real constraint is bandwidth. This will determine how many updates you can run on any given night or at any point in time. Are there any other IT capacity considerations you have to account for company- or business-wide? A common example might be how many problem tickets you might expect at the help desk post-upgrade.

Conclusion

The bottom line is this: There are many different options available, but everyone has to decide for themselves which strategy suits their needs the best. While the deployment ring based methodology is best practice right now, we believe that the world will move to an activity-driven approach where apps are categorized for testing and the deployment waves are identified simply by who is ready to go. In the future, you will simply manage these feature updates in a Business-as-Usual way where you place users automatically in an earlier deployment if you know there are no issues holding them back from receiving the latest OS release.