This is the third in a 6-part series chronicling the Dell enterprise Windows 10 migration. Click here to read the first post, Why Now Is the Time to Begin Your Windows 10 Deployment, and here for the second, Making Speed the New Standard with Windows 10.
The IT conundrum: innovation versus stability and security. How can IT introduce new OS features to the enterprise at a rate to keep up with the faster speed of business without compromising stability and security?
The first two posts in this series outlined why my team and I decided that right now is the time to standardize on Windows 10 across the Dell enterprise as the best way for us to meet the challenge of speed, stability, and security. In this post, I’m going to outline the “how”: the planning and pre-migration work the team completed to launch us toward our goal of 100 percent Windows 10 across Dell by the end of 2017.
Our preparation for the Windows 10 deployment comprised two major components: infrastructure readiness and an application validation process.
Infrastructure Readiness
Forward planning for Windows 10 deployment involved evaluating the deployment infrastructure as a whole. The Dell Client Engineering team, in conjunction with Microsoft, assessed our group policies to streamline policy creation and the testing processes leading to the deployment. The team also determined Windows 10 would be managed separately from other Windows clients 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 prior to migration roll out.
The team used Microsoft Deployment Toolkit with Windows Server Update Services for reference image creation. Within Dell, we base image design on the culture of self-service: the reference image includes only software components required by all employees (i.e. Office, security suites), and team members obtain necessary software from the Dell-approved software library. Reference images are patched during the creation process and updated quarterly.
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 process
In my second post, I noted the new Microsoft patching method will be an all-or-nothing proposition. IT shops will no longer have the opportunity to pick and choose the updates applied to their enterprise environment. This, plus a tight timeline between releases, requires an efficient test and deployment coordination between IT and application owners, who are key to long-term success with Windows 10.
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 geared toward consumer use.
- Current Branch for Business (CBB) – Available approximately four months after Current Branch with an approximate lifecycle of eight months. This branch is timed to allow businesses the opportunity to test feature upgrades prior to deployment. Available for Pro, Education, Enteprise, 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 best suited for environments where little change is required.
We’ve decided to standardize on Current Branch for Business for most deployment scenarios. This requires a short four-month testing period of our internal applications between release of Current Branch and the eight-month deployment window for Current Branch for Business.
To accomplish the compressed testing timetable, the team developed an internal ring structure based on Microsoft’s recommended best practice.
With Windows Insider, Client Engineering will evaluate builds as they are released. Once the latest build is declared Current Branch, applications owners can begin testing compatibility of their applications. At the end of the four-month period, each owner will certify their application before general deployment of the servicing update. In the event an application does not qualify for update at any point during the four months leading to Current Branch for Business, the application owner will notify Client Engineering for engagement with Microsoft to resolve the issue.
We will activate the validation process for every Windows 10 branch released. The faster testing turnaround will obligate application teams to build client compatibility into their baseline development practices.
Third-party security products have represented the biggest obstacle to the testing process. However, we’ve been able to properly vet and resolve the issues during the engineering validation phase. The release is not handed off to test teams until we’re confident our base products are in check.
Next Steps
Our Windows 10 deployment kicked off in April and we’re two-thirds of the way to meeting our 2016 year-end goal of 30 percent standardization across Dell. In my next post, I’ll write about this “rubber-meets-the-road” phase and the multi-prong approach we chose for the migration.
I’ll be chatting more about our Windows 10 enterprise deployment this week at the Dell EMC World session, Windows 10 migration: a CIO Reports from the Front Lines, with Gartner Analyst Annette Jump. If you’ll be at Dell EMC World, stop by and join the discussion.