Tactical considerations for creating Windows deployment rings

In my last post, I discussed deployment rings and the reason they are the hidden gem of Windows as a service. I outlined why they are a critical component in the evolution to the modern workplace, how they can help your deployment strategies evolve in line with other business processes, and how they can enable you as an IT pro to become more agile and responsive.

Today, I’d like to talk about some of the tactical considerations you should look at when creating deployment rings, and how you can use deployment rings to accelerate your ability to more easily and effectively service Windows 10 devices across your organization. While it would be impossible to construct a “one size fits all” plan, let’s dig into some of the specific and practical questions that can help you move forward quickly and efficiently.

Ask the right questions

One of the first questions I usually receive when discussing deployment rings is, “How many rings should we have?” While this is critical, it’s also where I usually take a step back to understand context, posing a few questions of my own:

• “How many PCs do you have?”
• “What does your network look like?”
• “When you look at application compatibility and hardware readiness, how does your environment look?”
• “What would you say is your overall tolerance for risk vs. demand for the latest technology?”

As we progress, each question becomes less straightforward and more subjective. This is the reason there is no hard-and-fast guide to choosing the number of rings. It’s also why a company with 10,000 PCs may have 6-8 rings while a company with 100,000 may only have 4-6 rings, or vice versa!

To put it simply, ring count is not based on the size of the environment alone. In the right environment, you may successfully deliver 25,000 updates per month, while other environments may only get several hundred. In general, however, a minimum of three rings is usually needed to see the benefits.

Every business has its own complexities and risk tolerance. Whether it’s seasonal challenges like those found in retail, or highly regulated industries, or dealing with bandwidth challenges, you will have to adjust your rings to meet your individual needs. This is not unlike how you adjust your initial Windows rollouts today, but potentially adds more data-driven decision points and drives toward validation and the most optimal experience as a continual process.

It’s important to keep in mind that your deployment ring strategy is not something that will remain static. It can (and should) change based on business goals, risk profile, learnings and even user demand. You may also need to alter your strategy, depending on which solution you use to manage your deployments and updates, whether it be Windows Update for Business (WUfB) or System Center Configuration Manager (ConfigMgr) and Windows Server Update Services (WSUS), Microsoft Intune or other management solution. The trick is to gain deployment acceleration quickly while successfully managing risk.

Let’s walk through a hypothetical example of a company with 10,000 devices. As we do so, remember the north star: staying current to help improve security and empower end user productivity.

Checks and balances

Let’s start by defining our checks and balances, which we will use to measure our decisions:

1. User experience. A great experience means smoothly infusing the latest technology to empower us to do our best work.
   • Downtime or interruption: Limiting the number of reboots? Minimizing the duration of device downtime?
   • Delivery speed: Are we delivering fast enough for the business? Is there demand?
   • Communication: What do we need to communicate out? How and when?
2. Risk. Reduce technical risk while also weighing environmental and physical constraints along with user base knowledge.
   • Hardware readiness: Compatible hardware, drivers and applicable tools
   • Application compatibility: This includes whether updated apps are available.
   • Network: Low bandwidth or metered market limitations, including remote users
   • Security: Are third-party agents being used where we need to manage new/existing features? Are uninstall/reinstall task sequences required?
   • Velocity and responsiveness: How quickly can we respond to events, and do we have solid listening channels in place?

3. IT experience. Ring deployments impact the agility of our IT team members and the support teams necessary for our environment.
   • Release features: Are there features that address pain points, open new opportunities, and/or provide a better experience if we adopt them?
   • Help desk readiness: Are they ready and empowered?
   • Feedback readiness: What is our plan to address user feedback and revise communications or make adjustments quickly?
   • Incident response: Is IT enabled to quickly digest deployment signals and rapidly respond in order to react, identify. and remediate with minimal impact?

Groupings

Next let’s look at users and machines, grouping and naming them for reference. Note, groupings and rings are not the same things; instead, groupings are high-level logical units for common generalities and rough timing.

For this example, I’ll use the following four general groupings:

• Explorers. These will be our earliest adopters, often IT folks and potentially a few application owners and/or special project participants that require the latest technology.
• Test pilots. These adopters span further across the company, including those who opt in to receive the latest software (with device compatibility), early business users, and likely all of IT. It may also include our help desk (or a portion of it) to empower support staff to support future rings. This group should include a statistically relevant sample of users, machines, configurations, and apps to yield a data-driven deployment decision.
• Wave riders. This is the largest group and includes most of our organization.
• Trailers. These are our highest risk machines, to which we deploy only when data is available that supports the ability to update or upgrade with minimal impact. This group may include kiosks, point-of-sale devices, or other specialized devices.

Decision criteria

It’s now time to formulate the criteria from which we’ll make the decisions on how to structure the rings for our sample company.

In the flow below, we weigh each decision against our experience goals and criteria, risk tolerance, and any analytics or insights available. From there, we choose the appropriate ring or accept the user’s desire to opt in to early technology adoption. As your process matures, you may also introduce opt-out for early releases and some logic to move a user to a different ring based on their business need.

We want to create statistically relevant rings, which would include:

• Good user and device representation. Complete coverage across users and devices is imperative to gain velocity and reduce risk. This should include varied hardware configurations, not just models. Try to ensure you have users that will create peer support options, too.
• Broad application coverage. I cannot stress enough the importance of having devices that represent broad application coverage as soon as you can. One of the benefits of Windows as a service is that validation naturally occurs, preventing you from having to regression test your apps.
• Logistical coverage (e.g. remote users, home office, branch office, low bandwidth, etc.). You may end up with targeted communications for various groups based on feedback and known logistical items.
• Reliable analytics data and feedback. Continuously monitor your feedback from users and data-driven analytics related to compatibility, performance, and device health.

Putting it all in motion

By applying our decision criteria (balanced with statistical relevance), then evaluating and adjusting our strategy as needed to mitigate risk, we have arrived at the following example for ring definitions:



The breakdown for our user base across various deployment rings would equate to something like the following:

While we started with our four logical groupings, due to logistics and other considerations, we required more than four deployment rings to help mitigate risk and provide the best overall experience. We also used various technologies to provide the best user experience for each situation, such as Delivery Optimization for our mobile clients and Configuration Manager peer caching for our lower bandwidth sites, thereby avoiding unnecessary work attempting to make one method work in all cases.

The total deployment time for our 10,000 seats is roughly 12-14 weeks. In our ring definitions, settings like cache retention will ensure we have locally cached bits available for each ring, and that we are managing the rollback period to consider things like app usage statistics. We would also build peer support resources, or “champions,” to minimize potential help desk calls. Champions are also critical to gaining quick and relevant feedback.

In the deployment example above, if we put this in the context of the Windows 10, version 1903 release (May 21, 2019) and the current date as of this blog (July 10, 2019), this is how our deployment ring strategy would be applied:

• Ring 0 would be on Windows Insider Preview builds for the next release of Windows.
• Ring 1 would be running Windows 10, version 1903 or in process of updating.
• Ring 2 would start to receive the Windows 10, version 1903 update, taking advantage of Delivery Optimization from the devices in Ring 1.
• Rings 3, 4, and 5 would be running Windows 10, version 1809.
• Ring 6 would be in the process of updating to Windows 10, version 1809, likely almost complete, with a few Windows 10, version 1803 devices remaining.

Notice that our corporate standard is not about version, it’s based on time. If you ask where we are three weeks from now, you would see the numbers adjust accordingly. However, the environment is current within our planned window of 12-14 weeks, delivering new technology faster while leveraging the insights from early rings to mitigate risk.

Conclusion

Your deployment timeline might be more or less aggressive than the example outlined in this blog post. It is not uncommon, for example, to see an initial rollout on a rolling 6-month cycle, and see that strategy later tighten up to a 2-3 month cycle over several releases as the process matures. At Microsoft, our IT organization has a schedule that evolved from about one year (to roll out a feature update to approximately 250,000 machines) to just nine weeks. Our deployment window decreased over time and so can yours.

Communicate!

The final piece of the puzzle is to proactively communicate with your all of your users throughout the process. It’s critical to ingest all the feedback you can and revise your communications as you broaden your adoption and repeat the process. If you combine this with data-driven insights, you can minimize risk and maximize velocity in your rollout.

To learn more about how we achieved a faster deployment cycle at Microsoft and download assets, including customizable timelines and communications to help you provide a seamless Windows 10 rollout, check out the resources available from Microsoft IT Showcase.

Stay tuned for my next post, where I’ll discuss moving to Windows Update for Business. In the meantime, to learn more about Windows as a service, check out the Windows as a service gateway on Docs.

Sean McLaren is a PM covering customers in the South Central United States and specializing in Windows deployments. With over 20 years of IT experience, he works directly with Microsoft’s enterprise commercial customers across many industries helping them with strategy and technical guidance around modernizing client endpoint deployment, management and security. In his own words, “I have the privilege to help our customers enable their digital transformation goals by delivering modern devices and the latest technology to their users while lowering costs and streamlining their operations. I also get to take feedback and learnings to our engineering teams and help make our products better.”