Windows 10 Servicing
There are two key areas that are driving organisations away from the big bang approach to Windows as-a-Service (“WaaS”). One is cost and the other is risk. Businesses have historically found their bottom line was being impacted every six or seven years by the cost and disruption of upgrading IT infrastructure. Many companies tried to get by or delay these costs leading to operational risk and in some cases competitive disadvantage as they struggled to keep up.
This graph shows how organisations have typically managed their operating system upgrades (2000 - 2015) and how they are moving to a more sustainable Evergreen approach (2016 onwards). The effort on the y-axis shows just how much more sustainable the Evergreen model is from a management point of view and how much easier it is to explain to shareholders from a financial perspective.
Big Bang Migration
Every six or seven years organisations have been expected to go through a major transformation to upgrade their operational infrastructure. In terms of scope, this impacted every person, desktop, laptop, application, business unit and geographical location at the same time. This has proven to be incredibly intensive in terms of cost, risk and impact.
Windows-as-a-Service (“Evergreen IT“)
Evergreen IT refers to running services comprised of components that are always up to date. This is not just at the user level, but also all the underlying infrastructure, whether managed in-house or outsourced.
With the introduction to the concept of Evergreen IT there are a few key ideas to understand.
· New functionality is added to Windows 10 twice a year through Feature Updates.
· Security and non-security fixes are released monthly through Quality Updates.
From an Enterprise perspective, it is incredibly risky to update all devices at the same time. Microsoft have therefore introduced the concept of Deployment Rings as part of the WaaS rollout strategy. This is a simple concept that can be managed with the use of a small number of deployment phases.
Typical Deployment Lifecycle
An example of a typical deployment lifecycle would be to create the following deployment rings and rollout new versions of Windows 10 in a staged manner:
Preview: A small number of machines would receive early builds for evaluation to establish how new functionality can be utilised within the organisation.
Targeted: After a short preview period, a few members of each business unit receive a new major release to evaluate how it impacts their business processes, test application compatibility and sign off end-user acceptance. Any issues prior to broad release can be dealt with efficiently without impacting the whole organisation.
Broad: Once the build has been signed-off for general usage in each business area, it is set for broad release across the organisation. This is generally four months after a targeted release.
Critical: After an embedding period of around six months, it's time to start rolling out to critical infrastructure. All the initial issues and concerns from the targeted build should have been ironed out by this time and a rollout to the most sensitive areas of the business can be completed.
Microsoft Analytics Upgrade Readiness (previously referred to as “Upgrade Analytics”) provides insights into potential issues between the applications and the OS build. It will therefore only be a case of testing your business-critical applications before the targeted pilot phase. This amounts to a significant cost and time saving.
Impact on Organisational Governance
Unlike big bang transformations, the Evergreen IT approach leads to a much less risky or disruptive change cycle. This takes the focus away from the CEO and CFO as the rollout can be much more evenly managed, scheduled and budgeted from an annual cost perspective. From a CIO perspective they can start to release the reigns a little and allow business as usual teams to gain control and treat the transformation as they would any other business change environment.
Developing a strategy for Windows-as-a-Service with MigrationStudio
While there are several tools capable of managing the actual deployment of the new operating system, it's very difficult to understand how the logistics of this can be achieved. It's easy to say there should be a Preview ring that lasts four weeks before a seamless transition into Targeted then Broad deployment. But how do you manage the testing cycle, communicate with your test users and collate all of the information, track test results, remediate issues and then make a decision on whether to move from Targeted into Broad deployment?
These are the high-level steps involved in a WaaS update:
- Create the new Build
- Review Application Suitability
- Configure Deployment Rings
- Recruit volunteers
- Test the new Build
- Remediate applications
- Move to the next Deployment Ring
Step 1: Create the new Build
The first step is to Preview the new Operating System build. Work out which features should be removed and what features could benefit the overall business strategy. At this point the core build should be created as you would expect to release it to the whole business. This would include all your core applications, fonts, language packs etc.
Here the new Windows 10 build has been created in MigrationStudio:
Adding core apps to that operating system is just a matter of adding dependencies:
All of the applications, font packs, languages etc can now be tracked against the latest operating system build.
Step 2: Review Application Suitability
Microsoft Upgrade Readiness provides insights into the likelihood of running into application issues when the new build is deployed. MigrationStudio is developing a connector for Upgrade Readiness to allow this data to be extracted from Upgrade Readiness and layered onto the applications in MigrationStudio. This will provide a fast and easy way to preview the likely impact of the updated operating system on the applications.
Depending on the outcome of this analysis, you may choose to progress to the next step, or investigate the applications which have been flagged as potentially having issues.
Step 3: Create Deployment Rings
MigrationStudio uses Blueprints to manage Deployment Rings. A blueprint is a collection of resources. For example, the Finance blueprint may consist of users, applications and machines from the Finance department. With that in mind, it's easy to build a Blueprint for Deployment Rings. It's possible to break the rings down into smaller collections so I can look at either the whole of the Preview Ring or just the Finance department involvement in the Preview Ring:
Step 4: Recruit Volunteers
The next step is to recruit volunteers and formalise who will be responsible for testing the business applications that will be installed for each business unit. Once again, this is as simple as adding users to these specific blueprints:
In the screenshot above, we are adding Russell Robertson and Robert Wood to the "IT Projects Review Board" of the Preview Ring. In this way, we can set up all our rings and define who will receive and operating system refresh and within which deployment ring. By utilising the API it’s possible to automatically add these users to an AD group of SCCM collection so that they receive the build for that deployment ring.
Step 5: Test the Build
The amount of testing required during the Preview and Targeted rings will vary depending on several factors such as the size of the organisation, the number of applications deemed business-critical, the number of applications flagged in Upgrade Readiness as requiring investigation, and the urgency of deploying the Windows update.
MigrationStudio provides centralised management of this testing process, reducing cost and risk:
The screenshot above shows how to create “Preview Deployment Tests". This action will:
· Setup a new test case for every member of the Preview ring
· Send an email with a calendar file and optionally an RDP link to a test machine (if it's not their own desktop)
· Provide a link to each user’s test case so that they can sign-off the build for their own business unit
Once the Preview Deployment Ring testing has been completed it's easy to view the results and decide on whether to release the build to the next Deployment Ring, or remediate the build/applications:
The screenshot above shows test results coming in for each Deployment Ring; who ran the test, when they tested and what the status is; all with one click of a button.
Step 6: Remediate Applications
If/when business-critical applications fail deployment testing, it's easy to raise defects, remediate the application and push back through the testing environment. This can be done on an individual application level or a complete OS re deployment, depending upon the severity of the issue.
Step 7: Move to the Next Deployment Ring
Once all testing has completed successfully the build can be promoted to "Targeted Release" and the testing process can start again. Then we can move to “Broad Release” and finally “Critical Release”.
Microsoft's Evergreen IT view of OS deployment makes a lot of commercial sense. From a risk perspective, having a thorough communication and test strategy is imperative to a streamlined process. With the understanding that most existing applications in a Windows 10 portfolio will work on newer releases, it makes life much easier to transition the whole process from Project Management into BAU (Business as Usual).
Microsoft have created a very simple concept for OS deployment. Behind that concept is a logistical challenge. Tracking, remediation, scheduling, testing and making decisions on a companywide operating system release is complex. It would be extremely difficult to do this using Excel and Outlook. With the functionality of MigrationStudio combined with a toolset such as SCCM, this becomes a simple process.