What was once a large, complex project that was addressed every few years is now a continuous process with updates released twice a year.

Keeping current will require a well-defined process — one designed to support the continual release of Windows 10 builds. This paper focuses on the design decisions necessary for enterprises to plan and implement the full updating and evergreening of Windows 10.

Design Decision 1: Choose servicing tools

The first design decision is to determine what tools you will use to manage and deliver Windows 10 updates in your environment. This decision will be heavily influenced by how your devices are currently managed — modern or traditional (Figure 1).

Figure 1. Windows as a Service servicing tool options

Traditionally, most enterprises use ConfigMgr or Windows Server Update Services (WSUS) to manage and deliver Windows updates. The new Windows 10 servicing model, Windows Update for Business (WUfB), can also be a viable option for some enterprises. However, WUfB requires the use of telemetry, which may not comply with some enterprise security policies.

Windows Servicing through ConfigMgr can use task sequences or servicing plans to schedule and manage the updates. For most enterprises, using task sequences provides the best control of the updates. However, servicing plans are improving rapidly and should also be considered.

If you’re using an MDM management tool, then your only option is to use this to configure WUfB. If your environment is a mix of traditional and modern, WUfB could be used as a common solution across both, but this will depend on the level of control required for traditional management.

Choosing the management tool will help narrow the options for content delivery. WUfB configured through MDM uses built-in Windows 10 delivery optimization, although some MDM providers are also providing this functionality through third party solution providers. ConfigMgr and WSUS can use branch cache capability and companion tools such as 1E and Adaptiva to optimize network bandwidth during update deployment. They can also use Windows 10 delivery optimization configured through security policies.

Design Decision 2: Review supporting infrastructure

The second design decision is based on whether you have the infrastructure to support the WaaS process design. Your infrastructure must support the servicing tools requirements approved in the design, with a defined process to keep these tools updated and secured.

With twice-yearly feature updates and monthly cumulative quality updates, the load on the network may increase. Therefore, you must determine what the additional load will be and if the network infrastructure can support it. WaaS delivery optimization tooling can help reduce the network load.

Validation infrastructure should be available to perform the validation activities. This is typically a virtual test environment, but physical test devices can also be used. The capacity of this environment is determined by the amount of validation testing needed and how many business-critical applications need to be tested. Capacity of existing test environments should be assessed to deal with the additional WaaS load.

Analytics will play a key role in determining the readiness of your environment for the next feature release. Therefore, you should enable an analytics solution such as Operations Management Suite (OMS) to provide the data required. Enterprises that cannot enable analytics should determine whether the current tooling will provide the required data or whether an investment in third-party tooling is required.

Reporting on the overall rollout status of new feature updates and compliance of devices during deployment is required. If available, OMS can provide comprehensive reporting for both modern and traditional environments. In the case of a more traditional environment where analytics is not an option, traditional tooling such as ConfigMgr can provide the data needed to create detailed reports.

Design Decision 3: Define validation tasks

With each feature release, you must determine the readiness of your environment to receive the update by performing validation tasks to assess the compatibility level. In this design decision, you must create a well-defined list of tasks to perform for each feature release, in addition to using analytics to refine those tasks.

Application readiness. Large enterprises typically have many applications that need to be managed; the addition of twice-yearly feature updates adds to this complexity. Performing an application compatibility assessment will identify the base set of Windows 10-compatible applications that need ongoing management. As these applications are already compatible, a high level of compatibility is also expected with feature updates. However, this does not mean you don’t have to test applications.

We recommend keeping the deep application testing to a manageable level and instead using a risk-based approach by prioritizing the most critical applications in the enterprise. The application owners should test these thoroughly. Less-critical applications can be tested by business early adopters, and the least critical can be tested by the mainstream users. Analytics should also be used to determine prioritization and to identify troublesome applications up front.

Hardware readiness. Windows 10 is compatible with most hardware, and with original equipment manufacturers (OEMs) now making device drivers available through Windows Update service, high compatibility is expected. However, we recommend using analytics or automated testing to determine the readiness of your hardware.

Security readiness. Windows 10 should be compatible with its own built-in security defenses, such as BitLocker device encryption and Windows Defender. If you are using third-party tooling in this area, work with your vendor for compatibility and include product testing in your validation tasks.

Upgrade process. As most Windows 10 devices in your enterprise will use the Windows in-place upgrade process to install updates, it’s important to test this in the validation tasks to ensure that you maintain any customization in your environment. You should also consider any other areas that are affected by the feature update — for example, security and network.

Security policies. Policies may be introduced, deprecated or updated in a feature release, which may have an impact on your security policy design. Microsoft also releases recommended security baselines for each new release of Windows, and these need to be evaluated and implemented as appropriate.

Security features. Microsoft is always improving Windows 10 security features and may deprecate legacy solutions in favor of a more modern approach. You can see this in the 1709 release, where Windows automatically blocks or removes Enhanced Mitigation Experience Toolkit (EMET) from Windows 10 systems. Instead, the best features from EMET were added directly into the OS via the Windows Defender suite.

Network. Feature releases that have an impact on components related to the network, such as network adapters or drivers, should be reviewed and validated during your testing.

Design Decision 4: Define servicing profiles

Once you define the validation activities, you need to determine the designated testers. There should be at least three main profiles of users (Figure 2): the validation testers, early adopters and mainstream users. Within these, you will see different types of users.

Figure 2. Windows as a Service servicing profiles

Applications validation requires working with the business units to determine the owners for the most critical business applications. You should also define the early adopter testers who will test the less critical applications that need to be validated. The early adopters should be very familiar with the applications but also prepared to perform deep testing and provide feedback on any issues. The least critical applications can be validated during daily usage by mainstream users.

For hardware, enterprise IT can use analytics to determine compatibility. Some service providers also provide automated testing solutions, but if none of those options are available, we recommend that you at least have a full set of hardware models in the early adopter testing rings.

Security readiness should be owned by the enterprise security department, which should work with any third-party vendors to determine readiness for all security components in scope.

The in-place upgrade should be validated by enterprise IT.

Design Decision 5: Create deployment strategy

Your deployment strategy should allow the deployment of Windows 10 feature updates while maintaining compatibility with your environment and staying ahead of Microsoft’s release cadence.

At this point, you should have the validation activities defined and know who will be performing them. Next, determine where and when these will be performed in the overall deployment strategy.

There are three main phases in the deployment of new Windows 10 feature releases (Figure 3).

Figure 3. Windows as  a Service servicing deployment strategy

In this phase you should start evaluating the new feature release as it enters the final stages of the Microsoft Windows development cycle. You should participate in the Windows Insider for Business program to have an early indication of compatibility, but also to explore new features that are available for adoption.

A test environment or devices should be available for enterprise IT and other selected personnel, such as critical application owners, to perform the early testing and provide feedback. We also recommend enrollment in Windows 10 TAP programs.

Windows to Go. But for most enterprises, a fully managed virtual test environment should be available for the validation testers and optionally for the early adopters.

A task-tracking tool is required to manage the validation tasks, assign owners and record the results of the validation activities. This will drive the remediation activities and help shape the broad deployment rings. Ultimately, the results of the validation activities will be used for approval for broad deployment.

If using production devices for the early adopter rings, any break-fix should be rebuilt based on the current live feature update. Procedures should be in place for early adopters to escalate issues with application owners if compatibility issues are found.

Change approval should be planned for the end of this phase to determine readiness for broad deployment.

Broadly deploy

The final phase is to broadly deploy the feature update to the mainstream enterprise users. This happens once approval for rollout of the new feature update is obtained from all stakeholders. The main design considerations are:

Structure of broad deployment rings. Each ring should incrementally increase the number of users with a broad reach across the enterprise based on the criteria that makes the most sense to your organization. Exemption rings can be used to delay the feature updates to those affected by issues identified during validation and while remediation is still ongoing.

Integration with your image management process to ensure the latest update is available for new and break-fix devices. Also consider updating the build on a regular basis to avoid large updates being deployed during the provisioning process.

Support issues related to the new update. During broad rollout, there may be a sharp increase in tickets for your help desk. Preventive measures such as user communication and education are key to reducing the number of service desk calls. For calls that reach the service desk, it’s important to have the correct processes, procedures and escalation paths in place to deal with this.

Regular compliance reporting. This is required to determine the progress of the rollout to the early adopters and mainstream enterprise users.

Design Decision 6: Service management

At this point, you should have a robust WaaS design. You should know what tools and supporting infrastructure need to be in place, what validation tasks need be performed, and who will perform them and when, as well as knowing how to roll out the feature update to the entire estate (Figure 4). Next, you need to know how the process will be managed on an ongoing basis and repeated twice a year.

Figure 4. Windows as a Service servicing process

The WaaS design process should be integrated with your enterprise IT service management (ITSM) model. You should identify the resources that will run and operate WaaS, and put in place the process for validation and deployment of each new release.

1. Start to plan by analyzing the environment’s readiness for the new feature release, evaluate new features and functionality; use this information to define the validation tasks.
2. Prepare the testing infrastructure to support the new feature release, performing any upgrades required.
3. Coordinate and manage the validation tasks; use the validation feedback to drive remediation and approval to commence broad deployment.
4. Finally, manage the broad deployment rollout to mainstream users while providing the required support and incident management.

The operational activities are described in more detail in Operating Windows as a Service.

DXC Windows Servicing helps reduce the complexities

DXC Technology removes complexity from the WaaS release cycle by centrally assessing new features, ensuring that applications are compatible and managing the deployment process. Our Windows 10 Servicing helps you manage the process from ring management to remediation, minimizing the impact of the deployment while maximizing future productivity.

About the authors

Colm Connolly is a Workplace and Mobility offering architect at DXC Technology, responsible for the development of standard offerings for both the traditional and modern workplace, and specializing in the area of Windows 10 servicing.

Kevin Ryan is a Workplace and Mobility offering architect at DXC Technology, focusing on both traditional and modern workplace technologies, and specializing in the area of application readiness.