Gear up for an ultimate upgrade with Windows 10 – article three of six
By Scott Pittman, Dell CIO
It’s the age-old IT dilemma: You want advanced innovation and usability, but not if it comes at the cost of your system’s stability and security. So how can IT introduce new OS features without slowing down the pace of your business?
We’ve already explained in our first and second articles why we think now is the best time to employ Windows 10 across your enterprise. Here at Dell, we’ve set a goal to be using Windows 10 on 100% of our systems by the end of 2017 in order to meet future speed, stability and security challenges. In this post, we’ll explain how we plan to do it.
Our preparation for a full Windows 10 deployment is comprised of two major components: infrastructure readiness and an application validation process.
Preparing your infrastructure
Planning for a Windows 10 deployment involves evaluating the infrastructure as a whole. Our Dell Client Engineering team, in partnership with Microsoft, assessed group strategies to streamline policy creation and the testing processes leading to the deployment. They also decided to manage Windows 10 separately from other Windows client to avoid policy conflicts. Using the Microsoft Baseline Security Configuration as a starting point, Client Engineering established Windows 10 client baselines and delivered them to Dell Security for approval.
The team uses Microsoft Deployment Toolkit with Windows Server Update Services for reference image creation. At Dell, we base image design on a culture of self-service: the reference image includes only software components required by all employees and team members obtain software only from the Dell-approved library. Reference images are pathed during the creation process and updated every quarter.
We followed Microsoft guidelines for Configuration Manager versions in support of Windows-as-a-Service (WaaS), beginning with System Center Configuration Manager Build 1511. We also developed processes by which clients are updated on a more frequent basis to ensure high availability through migration and servicing processes.
Application validation and testing
In a previous post, we discussed that the new Microsoft patching method is an all-or-nothing proposition. IT shops are no longer able to pick and choose updates applied to their enterprise environment. This, plus a tight timeline between releases, requires Windows 10 is developed along three branches:
- Current Branch (CB) – First available version with an approximate four-month lifecycle. Supported on Home, Pro, Education, Enterprise, and IoT editions. Current Branch is generally geared towards consumer use.
- Current Branch for Business (CBB) – Available approximately four months after Current Branch with a lifecycle of approximately eight months. This branch is timed to give businesses the opportunity to test upgrades prior to deployment. Available for Pro, Education, Enterprise and IoT editions.
- Long-Term Servicing Branch (LTSB) – Available on Enterprise editions only with a lifecycle of ten years immediately after publication by Microsoft. This edition is ideal for environments where little change is required.
We decided our best approach was to use Current Branch for Business on most deployment scenarios. This requires a short, but helpful, four-month testing period between the release of Current Branch and eight-month deployment window for CBB.
Using Windows Insider, our Client Engineering department will evaluate builds as they’re released. Once the latest build is declared Current Branch, applications owners can begin testing compatibility of their applications. After four months, each owner will certify their application before general deployment. If an application doesn’t qualify for an update at any point of the process leading to CBB, the owner will notify Client Engineering – who then contacts Microsoft – in order to resolve the issue.
We will activate the vetting process for every Windows 10 branch released. However, the faster testing turnaround will require application teams to build client compatibility into their baseline development practices.
Overall, third-party security products have been the biggest obstacle during our testing process. However, we’ve been able to vet and resolve all issues during our rigorous engineering validation phase. We never hand off releases to test teams until we’re confident our base products are in check.