Once you’re acquainted with the landscape and terminology of Windows 10 security, you can turn your attention to Windows 10 migration: moving your servers and endpoints from Windows XP, 7 and 8.
So far in this series about our webinar Under the Hood with Windows 10 Security, I’ve covered the security aspects of Windows 10 in the enterprise: malware prevention, authentication and data protection. In this post I’ll cover the migration process itself.
Windows 10 migration – Things to consider (54:05 into the on-demand webinar)
- Hardware compatibility – As I mentioned in my post on Device Guard and Secure Boot, much of Windows 10 security depends on new hardware standards and components like UEFI and TPM. The more security you want, the more of that hardware support you need in the next round of devices you procure.
- Driver updates – Hardening the kernel against attacks means a new approach to device drivers, which also work at the kernel level and are a well-known attack vector.
- New update model – Patch Tuesday is giving way to a continuous update process for all Windows 10 devices, including phones.
- File distribution – If you’re using Code Integrity, you’ll need a good way to drop code policies and catalogs onto all endpoints.
- Upgrades – Microsoft has done a lot of work to make the in-place upgrade from Windows 7 and 8 go smoothly. It’s meant to be vastly preferable to the traditional wipe-and-load to which sysadmins are accustomed.
- New runtime configuration tools – These are designed to easily transform devices from their off-the-shelf state into fully configured business devices, without reimaging.
4 Phases to Any Migration (1:01:30)
We think about the migration process in four different phases:
Phase I: Inventory / Content Rationalization
Which components of your hardware will support the migration while meeting the standards of your users?
To find out, you’ll inventory all applications, hardware, users and groups in your organization. You’ll also verify the compatibility of applications and hardware with Windows 10. Next, rationalize your content and prepare yourself to migrate applications based on usage and necessity. Your goal is to migrate only what is needed, based on usage and future support. That includes valid data stored on users’ endpoints.
Phase II: Application Categorization / Remediation
Knowing what you’re going to need, will it all work in the new environment?
The only way to be sure is to test, remediate and repackage your applications, which can take most of the calendar time of your migration project. Many applications will need fixes for compatibility, but fixes now can pay off through a more stable environment down the road.
Phase III: OS Deployment / User State Migration
Can you migrate and keep all your applications happy with a single image? Or do you need more than one?
In this phase you perform the actual migration of user systems and user content. The time it takes you to back up user data, deploy the new system, install updates and copy user data back on determines the amount of lost productivity per system. Doing this manually adds up fast.
Phase IV: Ongoing Management / User Support
How do you know you can care for and feed all your systems in the future?
After migration, you still need to keep systems up to date, secure and tracked. Some industry standards and mandates call for keeping software current with the latest patches and fixes. If you fail an audit, it can lead to fines, suspended certification and unwelcome publicity.
Under the Hood with Windows 10 Security – On-demand Webinar
This series of blog posts has covered the main points in Randy Franklin Smith’s webinar, Under the Hood with Windows 10 Security, for which more than 2,300 sysadmins, IT managers and network administrators registered. You can listen to individual topics (I’ve included the time stamps) or take in the entire on-demand recording, including Q&A from the audience.