Windows 10 - The Last of the OS Deployments

Windows 10 has been around for a while now, and most organisations are either already running it in production to some degree, or at least have been testing it, with a view to cut over in the very near future. However, there are still places out there or even pockets within your organisation where Windows 7 or Windows 8.1 is still hanging on for dear life. 

Let me explain why Windows 10 will be the last OS you ever deploy, and that is the perfect reason for making the jump to it.

OS Deployments – The Past

In the past deploying an operating system (OS) was a big project. It needed budget, management, consultancy, OS deployment skills, and large amounts of infrastructure and people. The new operating system was a major change from the previous version, causing disruption throughout the business, with a measurable impact to productivity as people readjusted how they worked.

As I write this blog, I’m looking at a Windows 7 detailed design I wrote, and here are just some things that needed consideration when deploying a new OS in the past:

• Hardware/Driver compatibility
• Peripheral device compatibility
• Application compatibility
• Group Policy Settings
• User State Migration
• On-going device & update management
• Deployment scheduling
• User training / handover
• ….and the list goes on

Each one of these bullet points needed planning, discovery, smoke testing, user acceptance testing, etc.   This cycle repeated itself every 4 years or so, and for some organisations, they even skipped operating system versions because it literally went in the “too hard/too disruptive/we only *just* finished the last rollout” basket.

And I’m just talking about deploying the OS.  Once it was deployed, you had to maintain it. This usually involved setting up Windows Software Update Services (WSUS) or System Center Configuration Manager (SCCM), and either approving or creating update packages for deployment.  Some organisations setup automatic deployment rules which worked fine, but very rarely did anybody deploy every patch. Most organisations would deploy all security updates, but then selectivity install some (or none) of the non-security updates. This created gaps in patching which left holes in the operating system.

This inconsistency in patching affected the quality of the operating system, causing issues that were not seen in the Microsoft lab to happen in the real world.

OS Deployments – The Present

Enter Windows 10 – the last OS you’ll deploy. When I say that, I mean it’ll be the last major disruption your organisation will need to endure when shifting to a new operating system.  Windows 10 presents a paradigm shift to thinking about how an OS is deployed, secured and maintained. Security is a whole separate blog post on its own, so I’ll focus on deployment and maintenance for the rest of this article.

When Windows 10 first came out, if you owned a Windows 7 or 8 device at home, chances are you’ll remember being prompted to upgrade to Windows 10. And if you did, you probably had a seamless experience when upgrading. All your applications were still there, most if not all of them still worked without issue, all your data was still there, and you started poking around the new start menu which was a hybrid between the familiar Windows 7 style start menu, and the radical “nobody really liked it” Windows 8 start menu. 

At first you may have needed some time to adjust to the new Windows 10 layout, but there was a familiarity about it. You weren’t completely out of your depth, and you quickly found your way around the desktop interface. 

Since then, you’ve probably gone through a few versions of Windows 10 from the RTM release of “1507” (year/month), to 1511, 1607, 1703 and released in October 2017 – version 1709. These new iterations of the Windows 10 operating system were deployed as in-place upgrades distributed through Windows Update. How many times through those iterations have you felt the need to re-familiarise yourself with the interface? I’m going to guess the answer is none. This is because Windows 10 now runs on a continual improvement cycle with feature updates twice a year. Simply put this means Windows 10 is updated more often, but with smaller incremental changes.

The feature update cadence of Windows 10 serves two purposes.  Firstly, it ensures Windows 10 is continuously evolving, adapting and supporting new technologies. Secondly, it ensures Windows 10 is secured with cumulative updates rolled into each new release.  A by-product of this is far less disruption to productivity. Updating the operating system becomes a change management process, not a project. When something is not a project, you don’t have to worry about all the costs and resource consumption that comes with running a project.

“But Noel, you mentioned all those bullet points above – surely that still applies to Windows 10?!”

I’m not going to lie.  Windows 10 doesn’t make every single OS deployment consideration go away. But it does make it A LOT easier, simplified and streamlined. Here’s why – and it will flip the way you think about deploying an OS.

Application/Hardware Compatibility

Then: Applications and hardware were tested for compatibility with Windows 7 / 8. Application compatibility tools were available but generally the testing was done by the application owner. All applications were blanket tested, and lots of time was spent testing applications that worked perfectly fine.

Now: By leveraging Windows Analytics Upgrade Readiness you can gather intelligence about the hardware, applications and drivers within your organisation. This free service allows you to focus on remediating what matters by offering insights into application and hardware compatibility. Know what you’re dealing with and balance the cost/risk of upgrading to Windows 10. Keep in mind this isn’t just for the jump from Windows 7 / 8 to Windows 10, but Upgrade Readiness can continue to provide insights throughout the different versions of Windows 10 as you move forward.

Rather than proactively test every application (which costs time, money and resources), you can now just react to, and target what needs fixing ahead of time. 

Group Policy Settings

Then: Organisations applied security to Windows 7 / 8 by locking down the environment; locking down user settings and locking down computer settings. This inherently locked down productivity and meant the device was tied to an environment; hardly ideal for an ever-increasing mobile and modern workforce.

Now: People are using multiple (mobile) devices that may be business or personally owned; they’re using cloud managed SaaS applications and users want the ability to self-service while still upholding enterprise security standards.  The mantra of “Work is a thing you do, not a place you go” rings true, and the requirement for restrictive group policy settings is rapidly fading. The thinking around security has now shifted higher in the stack. Not only should the device be secure, but also identity, access, the applications and the data. These are things Group Policy just can’t cover.

Windows 10 is built for this era of modern management. With new capabilities such as multi-factor device authentication (Windows Hello), device level protection (Device Guard & Bitlocker), multi-factor application access (Cloud App Security), information protection (Azure Information Protection), location based conditional access, self-service password reset, separation of personal and enterprise data and remote wipe capabilities; it’s clear that in order to get secure and stay secure, you really need to leverage new security capabilities that are only available in Windows 10 backed by a modern management platform.

User State Migration

Then: Enterprise deployment of an operating system was generally a “wipe and load” function. Naturally this meant user data needed to be backed up before the “wipe” part of that equation kicked in. Using SCCM and the User State Migration Tool (USMT) you had the choice of either keeping that data local on the device and having the new operating system deploy around it; or copying that data to a State Migration Point which added considerable time to the build process.

Now: If you plan to load Windows 10 on hardware that is running a previous operating system, I personally still recommend the wipe and load method; though assuming your applications and hardware is compatible you can just as easily do an in-place upgrade without the need for a user state migration.  That said I should warn you, if you still are running an old operating system the days of doing an upgrade to Windows 10 on that hardware are getting limited (whether that be an in-place upgrade or a wipe and load). For example, the Intel Clover Trail CPU is not compatible with Windows 1709 and 1703. The highest you can go is Windows 10 1607 which hits end of service on April 10 2018, unless it’s an Enterprise or Education version for which you get another 6 months of support. That gives you until October 10 2018.

Once on the Windows 10 train though, all future updates are in-place and the process is highly resilient. This removes the need to configure USMT, or have space allocated for a state migration point. If you need to transfer user data from a Windows 7 / 8 environment to Windows 10, it will be the last time you have to do it.

On-going Device and Update Management

Then: As outlined in Figure 1 maintaining patches on the older operating systems was fragmented. In a corporate environment managing the updates required on-premise infrastructure that itself needed maintenance. The onus was on the IT department to test updates before deployment to the larger user base. This lead to updates taking a considerable time to be deployed, if at all.

Now: Windows 10 is updated as a service, no longer relying on granular security updates and hotfixes to be applied. Monthly updates are cumulative as well as the semi-annual feature updates. On-premise infrastructure can still be used if it suits an organisation, or update workloads can be moved to Intune and provided by the cloud service. This increased update cadence dramatically improves overall OS security closing the gap on vulnerabilities.

This agile approach to update deployment distances itself from previous practices. The recommended approach is to create update rings that allow the monthly cumulative updates through. It is only when a problem is identified that you should pause the update ring to do further investigation and remediation. For the larger semi-annual feature updates I personally recommend an approach like so:

• Pilot Ring – IT staff, developers and test machines. These are IT savvy people who can identify issues and assist in their remediation. This can be considered a closed pilot group. 1-3 months in this ring.
• Semi-Annual Channel (Targeted) – early adopters, volunteers, users who aren’t afraid of change and want new technology. These should be users from a wider spread of the business and hopefully users who cover all business applications.  This can be considered an open pilot group. 1-3 months in this ring.
• Semi Annual Channel – general user population. This is full deployment and involves the entire business. By this stage there has been up to 6 months of testing by Pilot and SAC (Targeted) users. Most, if not all issues have been resolved by this stage. Assuming 3 months of testing in Pilot and SAC (Targeted), by the time this ring starts deploying, the Pilot ring is getting the next build of Windows 10.

Deployment Scheduling

Then: Because deploying an operating system was a big event, users had to be scheduled to be somewhere the machines could be rebuilt. This meant logistical challenges for many organisations, not to mention loss of productivity and inconvenience to the user.

Now: The very first time a user is built to Windows 10 (assuming we are recycling their old hardware), they will once again need to come to a location where that can happen. However, that will be the last time they need to do that. New versions of Windows 10 deploy the same way as standard cumulative updates. This gives control back to the user (within reason) as to when the update can run. It also means users do not need to be in a specific location for this to happen. A user can roll up to the new version of Windows 10 at home or in a coffee shop at a time when it is convenient for them.

By using Windows Analytics Update Compliance, the IT administrators can also keep track of which machines have been updated, and which ones still need to be updated. This telemetry is available across all Windows 10 devices whether they are domain joined, SCCM managed, or neither.

User Training and Handover

Then: Changing the operating system someone uses every day had a real-world impact on productivity and employee sentiment. Of course, every organisation had champions of the new operating system as well as people who despised it. Added to the cost of an OS deployment project was the user training element. Some organisations required more user training than others, but at the time of an OS rollout there would always be an increase in service desk calls, a decline in user productivity, and a bedding in period of acceptance by the users.

Now: If you’re still on Windows 7 or 8, you will probably have to do some user training when you get to Windows 10.  But, it will be the last user training in an OS you’ll have to do. As I’ve already showcased several times throughout this article, there is far less disruption to users with each Windows 10 release. It would be highly unlikely retraining would be required after a semi-annual feature update.

OS Deployments – The Future

Throughout this article we’ve talked about how things were done in the past, and how you can do them today if you move to Windows 10. But what if you didn’t even have to touch the device to provision Windows 10 and on-board a user? Imagine not needing to host and maintain on-premise infrastructure for OS deployment at all. Imagine being able to purchase a new hardware device from your OEM vendor, get it dispatched straight to the user who would then deploy themselves. 

This capability is available right now and is called “Windows Autopilot”. While it is available today, I’ve put this under “the future” because there is a lot more functionality that will develop in this space.  Basically with Windows Autopilot, you won’t need to deploy an operating system ever again.

Here is how it works. 

1. You purchase new hardware from a vendor. This vendor has a list of device ID’s (hardware GUIDs).  The vendor can either supply your IT department with these ID’s, or the vendor can upload the ID’s directly into your Windows Autopilot service on your behalf.
2. Your IT department configures various Autopilot Profiles. These are just applications, security and compliance settings that are defined for a user role. For example a mobile sales consultant will have different applications and security requirements to someone working in payroll. An Autopilot profile is defined for each of these roles with the specific applications and settings required.
3. The hardware gets shipped directly to the employee. All that’s needed by the employee is an internet connection. This can be anywhere; at home, in the office, a café or a hotel room.
4. The employee unboxes the device and turns it on for the first time. The user is prompted for their corporate identity and password, and once entered, the device will recognise it is configured for Autopilot deployment. The device then self-provisions with all the required applications, security and compliance settings. The user (who is the first logged on user and is administrator by default) can even be removed from the administrator role all before hitting the desktop screen.

This is the world of Windows Autopilot, and its capabilities will be extended over the next 18 months to include:

• Redeployment – whereby a device can be reset and refreshed, ready for redeployment or reassignment.
• Plug & Forget – this is a zero touch remote deployment capability. Perfect for remote kiosk machines where a device just needs to be plugged in and powered on.
• Hybrid Azure AD Join – think of this as Windows Autopilot that can also join your remote device to your on-premise domain. Users will be able to just enter their credentials and end up with a domain joined device from the Out of Box Experience. It does this by using a VPN connection that Intune drops onto the machine during the Autopilot process. This is a capability that has never been possible before.

Autopilot is not just restricted to brand new OEM devices either. You can recycle your existing devices to leverage Autopilot right now.

Windows 10 is a departure from the classic IT world and the old school methodology of operating system deployment. With its current capabilities that leverage cloud-based management services, accelerated security and feature update cadence, and the future capabilities that will enable organisations to deploy Windows 10 from the cloud, anytime, anywhere; Windows 10 really is the last OS deployment you'll need to do.

If you would like to know more about Windows 10 and modern management please feel free to contact me.