Plan Windows 10 Deployments in Microsoft 365

Eray ALTILI

Aug 26, 2020·19 min read

Microsoft 365 is a new offering from Microsoft that combines Windows 10 with Office 365, and Enterprise Mobility and Security (EMS).

To successfully deploy the Windows 10 operating system in your organization, it is important to understand the different ways that it can be deployed, especially now that there are new scenarios to consider. Choosing among these scenarios, and understanding the capabilities and limitations of each, is a key task.

Windows Autopilot
In-place upgrade
Deploying Windows 10 upgrade with Intune
Deploying Windows 10 upgrade with Microsoft Endpoint Configuration Manager
Deploying a computer refresh with Microsoft Endpoint Configuration Manager

Learning Objectives

• Plan for Windows as a Service (WaaS)
• Choosing Windows 10 deployment methods
• Windows 10 AutoPilot Deployments
• Creating AutoPilot deployment profiles
• Enroll Windows 10 Devices
• Analyze Upgrade Readiness for Windows 10
• Windows 10 Enterprise Security features
• Threat Protection
• Deploy Enterprise Security Features

Plan for Windows as a Service (WaaS)

Prior to Windows 10, Microsoft released new versions of Windows every few years. This traditional deployment schedule imposed a training burden on users, because the feature revisions were often significant. That schedule also meant waiting long periods without new features, a scenario that doesn’t work in today’s rapidly changing world, a world in which new security management and deployment capabilities are necessary to address challenges. Windows as a service delivers small feature updates two times per year around March and September to help address these issues. In the past, when Microsoft developed new versions of Windows, it typically released technical previews near the end of the process when Windows was nearly ready to ship. With Windows 10, new features will be delivered to the Windows Insider community as soon as possible. With Windows 10, you will need to change the way you approach deploying updates. Servicing channels are the first way to separate users into deployment groups for feature and quality updates. With the introduction of servicing channels comes the concept of a Deployment Ring, which is simply a way to categorize the combination of a deployment group and a servicing channel to group devices for successive waves of deployment. There are three core servicing channels. The first one is Semi-Annual. Semi-Annual servicing channel feature updates are available as soon as Microsoft releases them. When Microsoft officially releases a feature update for Windows 10, it is made available to any device not configured to defer feature updates so that those devices can immediately install them. Organizations that use Windows Server Update Services, or WSUS, Microsoft System Center Configuration Manager, or Windows Update for Business, however, can defer feature updates to selective devices by withholding their approval and deployment. In this scenario, the content available for the Semi-Annual channel will be available, but not necessarily immediately mandatory, depending on the policy of the management system. Long-Term: Specialized systems, such as devices that control medical equipment, point of sale systems, and ATMs often require a longer servicing option because of their purpose. These devices typically perform a single important task and don’t need feature updates as frequently as other devices in the organization. LTSC, or Long-Term Servicing Channel, model prevents Windows 10 Enterprise LTSB, or Long-Term Servicing Branch, devices from receiving the usual feature updates and provides only quality updates to ensure that device security stays up to date. Quality updates are still immediately available to Windows 10 Enterprise LTSB clients, but organizations can choose to defer them. Insider: Windows 10 feature flighting enables Windows Insiders to consume and deploy pre-production code to their test machines, gaining early visibility into the next build. Microsoft recommend all organizations have a few devices enrolled in the Windows Insider program. Deployment rings in Windows 10 are similar to the deployment groups most organizations constructed for previous major revision upgrades. They are simply a method by which to separate machines into a deployment timeline. With Windows 10, you construct deployment rings a bit differently in each servicing tool, but the concepts remain the same. Each deployment ring should reduce the risk of issues derived from the deployment of the feature updates by gradually deploying the update to entire departments. Defining deployment rings is generally a one-time event or at least infrequent, but IT should revisit these groups to ensure that the sequencing is still correct. Also, there are times in which client computers should move between different deployment rings when necessary. For example, you may use Preview, General, and Critical as the deployment rings. Now we can assign devices to servicing channels. The first deployment ring type is Preview, and this is referred to as the Windows Insider Program and mapped to that service channel. Feature deferral and update deferral are not enabled. The General deployment ring is a Semi-Annual channel and the feature deferral is 120 days until it is forced-installed. Update referral is seven to 14 days. And then, of course, our last one is Critical, and these are devices that are critical and will only receive updates once they’ve been vetted for a period of time by the majority of the organization. So once again, this one sits in the Semi-Annual channel. There’s a 180-day feature deferral and a 30-day update deferral. Now if we look at the servicing channels, we have all three, Semi-Annual, Long-Term Servicing, and Insider. The Semi-Annual channel is the default servicing channel for all Windows 10 devices except those with the LTSB edition installed. So we can see the Semi-Annual servicing channel applies to Professional, Enterprise, Professional Education, Education, and Mobile Enterprise version. Each edition of Windows 10 is available in one or more of the servicing channels. So in the Long-Term servicing channel, it’s only the Enterprise LTSB version, and for the Insider Program, it’s each version of that, but does exclude the LTSB. And that’s an important note to make, is that if you are running the LTSB, so the Long-Term Servicing Branch, it will only sit in the Long-Term servicing channel. Determining the servicing channel for your Windows 10 devices is critical in ensuring that the updates are installed effectively and that you remove some of the critical issues that are found often after updates have been deployed.

Choosing Deployment Methods

Organizations normally deploy a new version of Windows using a wipe-and-load deployment process. As a high level, this process captures existing data and settings from the existing device, deploys a new custom-built Windows image to that device, injects hardware drivers, reinstalls applications, and finally restores the data and settings. With Windows 10, this process is still fully supported and for some deployment scenarios is still necessary. Windows 10, however, also introduces two additional scenarios that organizations should consider. The first is in-place upgrade, which provides a simple automated process that leverages the Windows set-up process to automatically upgrade from an earlier version of Windows. This process automatically migrates existing data, settings, drivers, and applications. The second option is dynamic provisioning, which enables organizations to configure new Windows 10 devices for organization use without having the deploy a new custom organizational image to the device. When choosing the deployment scenario, we first need to understand the type and how and when we should choose them. So our first option is in-place upgrade. You’ll choose this option when you want to keep all, or at least most, of the existing applications. Also, if you do not plan to significantly change the device configuration. So for example, a BIOS change maybe switching to Secure Boot or even an operating system configuration moving from x86 to x64, or even language changes or domain changes. The second option is the traditional wipe-and-load. When you make significant device or operating system changes, or you want to start from clean, or you have significant numbers of applications along with the OS that you wish to retain. Also, if you’re migrating from Windows Vista or other previous operating systems. And then our final choice is dynamic provisioning. For new devices, especially in the choose-your-own-device scenario, when simple configuration, not re-imaging, is all that’s required. You can utilize this in combination with a management tool, for example, a mobile device management service such as Microsoft Intune, that enables self-service installation of user-specific or role-specific applications. Now when we talk about the deployment and the installation process, we are catering for three clear types. One is migration, one is new, and one is update. For migration from previous Windows versions, for existing PCs running Windows 7 or Windows 8.1, in-place upgrade is the recommended method for Windows 10 deployment and should be used whenever possible. Although the wipe-and-load and OS refresh deployments are still fully supported and often necessary, in-place upgrade is simpler and faster and enables a faster Windows 10 deployment overall. For new computers acquired with Windows 10 preinstalled, you can leverage dynamic provisioning scenarios to transform the device from its initial state into a fully configured organization PC. There are two primary dynamic provisioning scenarios you can use. The first is user-driven from the cloud. By joining a device into Azure Active Directory and leveraging the automatic Mobile Device Management, so the MDM provisioning capabilities at the same time, an end user can initiate the full provisioning process themselves. This is done by them entering their Azure Active Directory account and password, often called their work or school account within Windows 10. The Mobile Device Management service can then transform the device into a fully configured organizational PC. The second option is the IT admin-driven using new tools. Using the new Windows Imaging and Configuration Designer or the ICD tool, IT administrators can create provisioning packages that can be applied to a computer to transform it into a fully configured organizational PC. Now, of course, once we have all these machines migrated and built, then we need to focus on updating them. For computers already running Windows 10 on the semiannual channel, new upgrades will periodically be deployed approximately two to three times per year. You can deploy these upgrades by using a variety of methods, Windows Update, Windows Update for Business, for devices where you want to receive updates directly from the internet. You can also utilize Windows Server Update Services, so WSUS, for devices configured to pull updates from internal servers after they are approved. You can also utilize System Center Configuration Manager, utilizing task sequences, or utilizing the next software update capabilities. Now we still have the Deployment Toolkit that can be utilized for deploying updates to devices. The Deployment Toolkit is a unified collection of tools and processes, and guidance for automating desktop and server deployments. It’s built on top of the core deployment tools in the Windows Assessment and Deployment Kit, so the Windows ADK, and has support for zero-touch installation if we’re using System Center Configuration Manager. If you are deploying using System Center, then the operating system deployment with Configuration Manager is part of a normal software distribution infrastructure, but there are additional components that are required. For example, operating system deployment in Configuration Manager may have to utilize the state migration point role, which is not used by normal application deployment in Configuration Manager.

Windows 10 Autopilot Deployments

Windows 10 Autopilot depends on specific capabilities available in Windows 10 and Azure Active Directory. It also requires an MDM service, such as Microsoft Intune. These capabilities can be obtained through various additions and subscription programs. To provide the needed Azure Active Directory and Mobile Device Management functionality, one of the following licenses is required. Microsoft 365 Business subscriptions, Microsoft 365 F1 subscriptions, Microsoft 365 Academic A1, A3 or A5 subscriptions, Microsoft 365 Enterprise E3 or E5, Enterprise Mobility and Security or the EMS E3 or E5, Intune for Education, and Azure Active Directory Premium P1 or P2 with Microsoft Intune subscription. Windows Autopilot enables you to automatically join devices to Azure Active Directory, or Active Directory, Auto-enroll devices into the Mobile Device Management Service, such as Microsoft Intune, Restrict the Administrator account creation, Create and auto-assign devices to configuration groups based on a device profile, and then Customize the Out-of-the-Box-Experience content specific to the organization. And when I mean the Out-of-the-Box-Experience, that’s the installation process that Windows 10 goes through. Now from a scenario perspective, Windows Autopilot includes support for lots and lots of different scenarios, designed to support common organizational needs, which can vary based on the type of organization, and the progress moving to Windows 10 and transitioning to modern management. The first scenario is deploy devices that will be set up by a member of the organization and configured for that person. We can also deploy devices that will be automatically configured for shared use, such as a kiosk, or a digital signage device. Can also redeploy a device in a business-ready state, pre-provision a device with up-to-date applications, policies, and settings. And then of course, deploy Windows 10 on an existing Windows 7 or 8.1 device. Now as far as using Windows 10 Autopilot, these are the following steps. First, create a Base Windows 10 image, and make sure that’s running. This can be done using an existing piece of hardware, or a virtual machine. Capture the Hardware Identifier for that specific device. Reset the Out-Of-Box-Experience, so this is going to reset it back to the default, so it’s ready for building. Verify the Subscription Level within Azure Active Directory, and the licenses. Configure any Company Branding that might need to be assigned to the Out-of-the-Box-Experience, or things such as background or login screens. Configure the Intune Auto-Enrollment process. Register the Windows 10. And then once you’ve done that, you create and assign a Deployment Profile. At that point, you are then ready to deploy Windows 10 devices using the Autopilot process.

Retrieve device details for Autopilot

In order to utilize Windows 10 autopilot, there are a few steps that need to be completed. For this scenario, we’ll utilize a virtual machine and we’ll retrieve some information about the device which we will then upload into the Microsoft Intune portal. To do this, we need to use PowerShell. So I’ve launched Powershell ISE, as an administrator, and my first task is to execute the execution policy command and set that to unrestricted (Set-ExecutionPolicy Unrestricted). This is so that when we install the script from the Microsoft source, which we’ll be using a NuGet package and into where they’re stored, we won’t have any security complications. So I’m going to simply select that, and execute. (Set-ExecutionPolicy Unrestricted) Now what this will do is come back and notify you that you are changing the execution policy and there’s a security risk. For now we can just say yes to all. (Install-Script Get-WindowsAutoPilotInfo) And they’re going to actually install what’s called get windows autopilot info. This is a PowerShell module, that’s provided by Microsoft that will retrieve the information required from the hardware device, in this instance, a virtual machine, so that we can upload that into the Intune portal. Now as a side note, when you execute this, often for the first time, if you’ve never executed any PowerShell commands and never connected to the NuGet packages, it will prompt you for that installation as well. I’ve previously completed that, so it doesn’t prompt me. Now that that’s been installed, I’m going to navigate to that location. So the module itself is installed into program files, Windows, PowerShell, and scripts. I’m going to execute this and you’ll see in the Powershell bottom section, that I’ve now pushed directory, which is the pushd command, to that location. (pushd “c:\Program Files\WindowsPowerShell\Scripts”) I’m then going to execute the actual PowerShell itself and output the results of that to a file which I’ve called HWID.CSV. (.\Get-WindowsAutoPilotInfo.ps1 -OutputFile HWID.CSV) And that’s now completed. Now if I open up my file explorer and navigate here, to my location you can see if I browse to the program files, PowerShell, and scripts, you’ll see that that HWID CSV is now listed. If I right click and choose edit, this will open inside notepad. The most important information here is referred to as the device serial number, the Windows product ID, and the hardware hash. Now of course, we’re not going to be able to decode the hardware hash, but the other information is there for us. Now what we do with this file, is we need to copy this file out and save that, so that we can upload this into the Microsoft Intune portal.

md c:\\HWID Set-Location c:\\HWID Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted Install-Script -Name Get-WindowsAutoPilotInfo Get-WindowsAutoPilotInfo.ps1 -OutputFile AutoPilotHWID.csv

Import Hardware Identification (HWID)

Now that we’ve captured the hardware identification information, we now need to come back to the Microsoft 365 device management and click on devices. We then move down to the device enrollment and click enroll devices. And then from here, you can see we’re going to choose the Windows Enrollment option. We’re not going to utilize any of these options, but scroll towards the bottom where it says, “Devices”. Now when this loads, you’ll see there’s no devices whatsoever, but there is an import option. We’re going to click import and then browse to that file that we copied from that other machine. So HWID file. I’m then going to click import, and this will then kick off a process that will import that information. Now this can take up to 15 minutes. It normally takes a couple of minutes. Sometimes less depending on the number of devices, but this can take some time, so be aware. Microsoft do notify you, this process can take 15 minutes and it shows you the elapsed time. Once that’s completed, the device still will not be listed here. We will then have to perform a sync process. Which will complete once this has executed. So, that device has now been imported. I can close this option here. But notice even if I click refresh, the device gets listed, but nothing’s been associated to that. This is where we would often click the sync option and this will sync this information directly into the rest of Microsoft engine. So, there’s that two-part process. We take that HWID file, import it, it will list the item here.

Sometimes, not all the time, I will be honest with you. And then you click sync to actually make sure that that is then listed as an item. I can click refresh and it’ll now say it’s been synchronized. So, that is how we get the hardware information imported directly into. Now, I can click into this. You can see on the right-hand side, it will give me information about that specific device. But what you’ll notice is there’s no group tags. It’s not been assigned anything, it’s not been enrolled, nothing. This is simply the process to get the device directly into intune, ready for utilizing it.

Create Autopilot Deployment Profile

Now that we have the device registered that we wish to enroll, we now need to configure the device enrollment policy at Microsoft 365 Device Management Console. So I’m going to click devices again, and you can see we’re going to go back to enroll devices, and then from here we’re going to define a deployment profile you’ll see that we have an auto-pilot profile already defined. I’m actually just going to create a new profile for this and give it a name and then we’ll choose next, and then we get to decide the deployment mode and whether or not to join it to Azure AD along with some other options that are available. The first option here is we have User Driven or we have Self Deploying which is in preview mode, for this example we’ll use User Driven, which means that when the user goes to the machine and tries to log in they’ll be asked for a credential and then once the user has done that piece the rest of the deployment process will be handled automatically by this process.

We will choose to actually join to the Azure AD Domain, we can then determine whether to show the Microsoft License Terms, I’m going to leave that as hidden for now. For the privacy sentence I’m going to hide those also I don’t need the end users to read the software license or the privacy, and then have the ability to hide the change account options which I want to do because I don’t want them to modify any of those. I can then choose the type of account that I wish to add as part of this process I’m going to leave it as a standard account. I’m then going to use utilize allow White Glove out of the box experience, what this means is that allows me to make changes to the Out of the box experience which means it automatically defines all the components that I wish to deploy, modify, or change inside that out of the box experience. I can then also apply a device template name, you’ll see Out of the box here it will come up with an example that says my company dash and then some random characters you can define any type of format pattern using specific characters lowercase letters, uppercase letters, or numbers and also there are functions such as rant. I’m going to choose no, I don’t need to define a specific format for this, I’m then going to choose next I then decide who to assign this profile to.

I’m going to say select groups to include and when my groups are listed, I’m going to scroll all the way down to a group I have created here called Windows 10 AutoPilot which just contains a user which is the account that we’ve been utilizing and then I’ll click next. We’re then given a review and create option where we can ensure that everything is set as expected. Now I’ve noticed here that one of the options I need to change which is convert or target devices to AutoPilot, so I can click basics and you’ll notice that we can click backwards and forwards to each of these locations to make changes as needed and I can then click back on review and create and I’ll click create.

This now goes ahead and creates my new policy and you’ll see that a profile has been created and it’s been successfully assigned to that group which contains the user as assigned to that group which contains the individual user.

Now that we have our devices registered and we also have the AutoPilot deployment profile created, we now need to assign the device to the user with which we want to deploy it to so I’m going to click devices, go back to enroll devices. Go back to my list of devices and then select that device, and you’ll see in the top right here, assign user becomes active. I’m going to click assign user and then I can search for my user I’m going to click the user, choose select, click User, choose select, and you’ll see that now it comes up with information and then says user friendly name. It now associates that to the user and I can press save. We’ve now associated a User to the Windows 10 device, and we’ve then added User to a security group which then has the deployment profile associated to it.

Enroll a Windows 10 Device

So we’re back to the Windows 10 device, ready to go through the enrollment process. It’s as simple as typing in the Work account, and then that will register this device directly to Intune, and then pull down all of the profile and the configuration that we defined earlier. So, log in the device as the user and choose Next. This will then ask for password. Remember, this is user’s Azure Active Directory account. Now at this point, this will make a connection to the Azure Active Directory based on the account that we typed in, to your organization. In this instance, it will be your organization. And then go and connect to the entry point that we created in Microsoft Intune and start tying all of these bits and pieces together. So choose Yes for the follow on. Then we get to choose any of the privacy settings. Let’s choose Accept as the default, and then we’re going to go through the Microsoft loading process to let me know that Microsoft Windows is currently executing some configuration. So as you can see, the first things that pops up here is that the organization is requiring Windows Hello as part of the signup process, which was what was configured in the policy. So let’s choose Set Up PIN. This then takes me to Organization login, asking for more information because of the policies that we’ve defined. Choose Next. And it’ll ask for information about the phone or the mobile application. In this instance, we can use a mobile application. At that point, we can say receive notifications for the verification or use the verification as we need. We’ll click Set Up, and then from the mobile device, we can then add a work and school account, as you would normally. This is just to connect the authentication app to Office 365 account, and then allow to generate an ID every time we authenticate. So what will do now is it will check the activation status to make sure it’s been configured. We’ll give that a moment. Click Next. What it’ll then do on the mobile app is prompt to approve so click Approve on device, and this will then go through and confirm that the additional security verification that we required on the device has worked as expected. The second option here is obviously to add in a mobile device as a phone number so that in the event of us losing the phone, we can then add a second factor authentication option, which will send a text message instead of using the mobile app itself. So type phone number, and then choose Done. It’s now going to ask us to set up the PIN for the local device. You’ll notice when we type a lower set of characters, it’s then going to prompt us back because of the complexity requirement that’s in the profile that we created. Now click OK. Here go back on the desktop in full-screen mode. If now click the Start menu and navigate to the account, and if you click Change Account Settings, you can see that information is now connected. Logged in as the user on the domain and we are now successfully connected as a Windows 10 device to the Microsoft cloud. So now that the Windows 10 device has been added, we can click on Devices in the Microsot 365 Device Management home, and we can then click into Windows, and you’ll see that that desktop that was added, which was a virtual machine in my case, has been added as a corporate ownership and is in a compliance mode. You’ll also see that email address, which is the user, that it’s actually been associated to.

In the part 2 we will look at this link.

• Analyze Upgrade Readiness for Windows 10
• Windows 10 Enterprise Security features
• Threat Protection
• Deploy Enterprise Security Features

Originally published at https://github.com.