Skill 1.2: Plan and implement Windows 10 by using Windows Autopilot

Within a domain-based environment, deploying new devices to users has become increasingly complex. There are many “moving” parts and components, and each one needs to work precisely to ensure devices are compliant, secure, and usable. This is partly due to the granular nature of the tooling used to ensure that devices comply with strict organizational security requirements. Windows Autopilot is a solution that radically changes this approach while allowing IT administrators to deploy secure and compliant devices.

You must understand how to plan and implement Windows 10 within an organization using Windows Autopilot. This skill explores the planning, example scenarios, and installation requirements for the application of Windows Autopilot.

This skill covers how to:

• Choose method based on requirements
• Create, validate, and assign deployment profiles
• Extract device hardware information
• Import device hardware information to a cloud service
• Deploy Windows 10
• Troubleshoot deployment

Choose method based on requirements

Windows Autopilot offers a new method of provisioning Windows 10 within an enterprise. Of course, it is not the only deployment choice, and indeed, there will be scenarios in which using Autopilot would be folly.

You must explore each of the available deployment options. These options include technology such as MDT or Configuration Manager that may be currently used within your organization. Other methods, such as using Windows Autopilot or Microsoft Intune, may be worth employing to achieve your Windows 10 deployment goals.

Listed in Table 1-9 are many different methods that you can use to deploy and configure Windows 10. You need to understand when to use each deployment method.

TABLE 1-9 Methods for deploying and configuring Windows 10

Configure Windows Hello and Windows Hello for Business

Windows Hello is a two-factor biometric authentication mechanism built into Windows 10. The personal biometric data created and used by Windows Hello is unique to the device on which it is set up, and it is not synced with other devices. Windows Hello allows users to unlock their devices by using facial recognition, fingerprint scanning, or a PIN.

Windows Hello for Business is the enterprise implementation of Windows Hello; it allows users to authenticate to Active Directory or Azure AD, and it enables users to access network resources. Administrators can configure Windows Hello for Business using Group Policy or by using mobile device management policy; it uses asymmetric (public/private key) or certificate-based authentication.

Windows Hello provides the following benefits:

• Strong passwords can be difficult to remember, and users often reuse passwords on multiple sites, which reduces security. Windows Hello allows them to authenticate using their biometric data.
• Passwords are vulnerable to replay attacks, and server breaches can expose password-based credentials.
• Passwords offer less security because users can inadvertently expose their passwords because of phishing attacks.
• Windows Hello helps protect against credential theft. Because a malicious person must have both the device and the biometric information or PIN, it becomes more difficult to hack the authentication process.
• Windows Hello can be used in cloud-only and hybrid-cloud deployment scenarios.
• Windows Hello logs you into your devices three times faster than by using a password.

To implement Windows Hello, your devices must be equipped with the appropriate hardware. For example, facial recognition requires that you use special cameras that see in infrared (IR) light. These can be external cameras or cameras incorporated into the device. The cameras can reliably tell the difference between a photograph or scan, and a living person. For fingerprint recognition, your devices must be equipped with fingerprint readers, which can be external or integrated into laptops or USB keyboards.

If you have previously experienced poor reliability from legacy fingerprint readers, you should review the current generation of sensors, which offer significantly better reliability and are less error prone.

After you have installed the necessary hardware devices, use these directions to set up Windows Hello:

1. Open the Settings app and select Accounts.
2. On the Sign-in options page, under Manage how you sign in to your device, review the options for face or fingerprint. (If you do not have Windows Hello-supported hardware, the Windows Hello section does not appear on the Sign-in Options page.)

To configure Windows Hello, follow these steps:

1. Under the Windows Hello section, select Windows Hello Face, and then select Set up.
2. On the Welcome to Windows Hello page, select Get started.
3. When prompted, enter your PIN or password to confirm your identity.
4. Allow Windows Hello to capture your facial features, as shown in Figure 1-19.

Figure 1-19 Configuring Windows Hello

5. Once complete, you are presented with an All Set! message that you can close.

Users can use Windows Hello for a convenient and secure sign-in method, which is tied to the device on which it is set up.

For enterprises who want to enable Windows Hello, they can configure and manage Windows Hello for Business. Windows Hello for Business uses key-based or certificate-based authentication for users by using Group Policy or by using a modern management approach, such as Microsoft Intune.

To manage Windows Hello for Business with Group Policy, you should review the two Windows Hello for Business GPO settings, which can be found in this node: User Configuration > Administrative Templates > Windows Components > Windows Hello for Business.

One setting is used to enable Windows Hello for Business, and the other setting is used to configure the use of certificates for on-premises authentication.

You also have additional Windows Hello for Business GPO settings available to manage your Windows Hello for Business deployment. These policies can be found in this node: Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business.

There are ten settings that allow you to configure hardware security devices, such as TPM. These settings also allow you to configure smart cards, biometrics settings, and more.

Need More Review? Windows Hello Biometrics in the Enterprise

To review further details about using Windows Hello in the enterprise, refer to the Microsoft website at https://docs.microsoft.com/windows/access-protection/hello-for-business/hello-biometrics-in-enterprise.

Configure Dynamic Lock

Users with smartphones can take advantage of a feature introduced with the Creators Update for Windows 10 Version 1703, which allows users to automatically lock their devices whenever they’re not using them. (At the time of this writing, iPhone devices do not support this feature.)

This feature relies on a Bluetooth link between your PC and paired smartphone.

To configure Windows 10 Dynamic Lock, use the following steps:

1. Open the Settings app and select Accounts.
2. Select Sign-in options and scroll to Dynamic lock.
3. Select the Allow Windows to lock your device automatically when you’re away check box.
4. Select the Bluetooth & other devices link.
5. Add your smartphone using Bluetooth and pair it.
6. Return to the Dynamic lock page, and you should see your connected phone.
7. Your device will be automatically locked whenever Windows detects that your connected smartphone has moved away from your desk for 30 seconds.

You can configure Dynamic Lock functionality for your devices using the Configure Dynamic Lock Factors GPO setting. You can locate the policy setting at Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business.

Configure VPN client

In Windows 10, you can create a VPN that enables data to be transferred through a virtual private network using a secured connection (known as a tunnel) over a public network, like the internet, as displayed in Figure 1-21.

Figure 1-21 Using a VPN to connect locations securely over the internet

VPN protocols

Windows 10 supports four commonly used VPN protocols. Each protocol offers different characteristics:

• Point-to-Point Tunneling Protocol (PPTP) The oldest and what is considered one of the least secure of all supported VPN protocols. However, it can be used successfully in low-security scenarios because it is very easy to set up and still offers more protection than using PPP over the internet. PPTP creates the tunnel and then can use several authentication methods, including the Microsoft Challenge Handshake Authentication Protocol versions 1 and 2 (MS-CHAP v1 and MS-CHAP v2), Extensible Authentication Protocol (EAP), and Protected Extensible Authentication Protocol (PEAP). If EAP is used, certificates can be used with PPTP; otherwise, they are not necessary.
• Layer 2 Tunneling Protocol (L2TP) This protocol uses the IP security extensions (IPsec) for encryption and encapsulation. L2TP encapsulates the messages with IPsec, and then encrypts the contents using the Data Encryption Standard (DES) or Triple DES (3DES) algorithm. The encryption keys are provided by IPsec using Internet Key Exchange (IKE). L2TP/IPsec can use pre-shared keys or certificates for authentication. Using a pre-shared key is useful during testing and evaluation, but should be replaced with a certificate in a production environment.
• Secure Socket Tunneling Protocol (SSTP) This protocol encapsulates PPP traffic using the Secure Sockets Layer (SSL) protocol, which is widely supported on the internet and passes through TCP port 443, which is the same as SSL. Using the Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) authentication protocol together with certificates makes SSTP a very versatile and widely used protocol.
• Internet Key Exchange, Version 2 (IKEv2) IKEv2 is most useful for mobile users and is the default protocol for Windows 10 when trying to connect to remote access servers. This protocol supports IPv6 traffic and the IKEv2 Mobility and Multi-homing (MOBIKE) protocol through the Windows VPN Reconnect feature, which allows automatic reconnection if a VPN connection is lost. Authentication is provided by using EAP, PEAP, EAP-MSCHAPv2, and smart cards. IKEv2 will not support older authentication methods, such as Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP), which offer low protection.

Authenticating remote users

Windows users authenticate using Kerberos when accessing the local network, but for remote authentication, this is not suitable; a separate protocol, which protects against network intrusion, must be used. During the initial negotiation sequence (using PPP), when a client connects to the remote computer, each party must agree on a shared authentication protocol to use. By default, Windows 10 will use the strongest protocol that both parties have in common.

In the Add A VPN Connection Wizard, Windows 10 offers three sign-in options when configuring a VPN, such as:

• Username and password
• Smart card
• One-time password

In addition to these options, you can also configure Windows 10 to use the common authentication protocols:

• EAP-MS-CHAPv2 This is a protocol that uses Extensible Authentication Protocol (EAP), which offers the default and most flexible authentication option for Windows 10 clients. It offers the strongest password-based mechanism for the client side, with certificates being used on the server side. Authentication can be negotiated based on certificates or smart cards, and EAP-MS-CHAPv2 is likely to be further extended and developed as technology advances. Windows 10 aims to use this method for authentication connections where possible. IKEv2 connections must use EAP-MS-CHAPv2 or a certificate.
• MS-CHAP v2 Stronger than the CHAP protocol, with significantly improved security when partnered with EAP to enable encryption of the password.
• CHAP Used for down-level client compatibility and has been surpassed by MS-CHAP v2. This protocol uses a pre-shared key between the client and server to enable encryption to take place.
• PAP This is the least secure protocol as it uses plaintext passwords. It is not considered secure and should only be used whenever other authentication methods cannot be negotiated.

Creating a VPN connection in Network and Sharing Center

To create a VPN in Windows 10, from the Network and Sharing Center, under Change your network settings, select Set up a new connection or network and then select Connect to a workplace.

To configure your VPN connection, in the Connect to a Workplace wizard, provide the following information:

• How do you want to connect? You can connect by using an existing internet connection or by dialing directly to your workplace.
• Internet address This is the name or IP address of the computer that you connect to at your workplace, as shown in Figure 1-22. Typically, this is an FQDN, such as remote.adatum.com.

Figure 1-22 The Connect to a Workplace wizard

• Destination name This is the name of this VPN connection.

After you have created the VPN connection, from the Network And Sharing Center, select Change adapter settings, right-click your VPN connection, and select Properties. As shown in Figure 1-23, you can then configure additional options as required by your organization’s network infrastructure.

Figure 1-23 The Security tab of a VPN connection

These settings must match the remote access device that your device connects to, and includes the following options:

• Type of VPN Point-to-Point Tunneling Protocol (PPTP), Layer Two Tunneling Protocol with IPsec (L2TP/IPsec), Secure Socket Tunneling Protocol (SSTP), or Internet Key Exchange version 2 (IKEv2).
• Data encryption None, Optional, Required, or Maximum Strength.

In the Authentication section, you choose either Use Extensible Authentication Protocol (EAP) or Allow These Protocols. If you choose to use EAP, you then configure one of the following:

• Microsoft: EAP-AKA (Encryption Enabled)
• Microsoft: EAP-SIM (Encryption Enabled)
• Microsoft: EAP-TTLS (Encryption Enabled)
• Microsoft: Protected EAP (PEAP) (Encryption Enabled)
• Microsoft: Secured Password (EAP-MSCHAP v2) (Encryption Enabled)
• Microsoft: Smart Card Or Other Certificate (Encryption Enabled)

If you choose Allow These Protocols, you then configure the following options:

• Unencrypted Password (PAP)
• Challenge Handshake Authentication Protocol (CHAP)
• Microsoft CHAP Version 2 (MS-CHAP v2)
• Automatically Use My Windows Log-on Name And Password (And Domain, If Any)

Windows Autopilot requirements

There are several requirements and prerequisites that you need to put in place before you can use Windows Autopilot with your Windows 10 devices. If your organization already has a Microsoft 365 subscription, then you will already meet the licensing requirements:

Licensing Requirements

The following licensing requirements must be met:

• Devices must be pre-installed with Windows 10 Pro, Pro Education, Pro for Workstations, Enterprise, or Education.
• Azure AD Premium P1 or P2.
• Microsoft Intune or another MDM solution to manage your devices.

Exam Tip

You can use the Microsoft Store for Business to manage Windows Autopilot profile deployments.

Networking Configuration

The following network configuration requirements must be met:

• Devices must have access to the internet.
• Devices must be able to access cloud services used by Windows Autopilot:
  • Using DNS name resolution.
  • Firewall access through port 80 (for HTTP), port 443 (for HTTPS), and port 123 (for UDP and NTP).
• The following URLs must be accessible:
  • https://go.microsoft.com
  • https://login.microsoftonline.com
  • https://login.live.com
  • https://account.live.com
  • https://signup.live.com
  • https://licensing.mp.microsoft.com
  • https://licensing.md.mp.microsoft.com
  • https://ztd.dds.microsoft.com
  • https://cs.dds.microsoft.com
  • ctldl.windowsupdate.com
  • download.windowsupdate.com

Azure AD Configuration Prerequisites

The following Azure AD configuration prerequisites must be met:

• Azure AD company branding must be configured.
• Azure AD automatic enrollment must be configured.
• A device must be registered with Azure AD.
• Users must have permissions to join devices into Azure AD.

Windows Autopilot Configuration

The following Windows Autopilot configuration prerequisites must be met:

• Devices must have their device hardware IDs known by Windows Autopilot.
• Devices must have a Windows Autopilot deployment profile assigned.

Implement pilot deployment

Windows Autopilot is not complex to configure and use, although there are several services that need to work together for your users to see a seamless OOBE. After completing the prerequisites needed for Windows Autopilot, you may want to practice using Windows Autopilot to provision Windows 10 in your test lab using virtual machines.

Once you have the basic functionality working, you can explore the additional features that are available; these features can be used to streamline the deployment process or personalize the experience for the user. These enhancements currently include the following:

• Device Groups Creating device groups with Azure AD allows you to separate devices into logical groupings.
• Dynamic Groups You can use Azure AD Dynamic Groups to simplify device group management. Devices are automatically added to the dynamic group if they meet the group membership criteria outlined in the rules. Dynamic groups are an Azure AD premium feature.
• Deployment Profiles You can create a single default deployment profile for your whole organization, or you can create additional deployment profiles and assign them to device groups.
• Personalization Windows Autopilot allows you to assign a username and a friendly name to a specific device. During OOBE, the friendly name is then shown to the user.
• Enrollment Status Page During device enrollment into Microsoft Intune, users can be shown a progress status page. This is configurable.

After you have configured your Windows Autopilot processes and successfully provisioned devices in your test lab, you are ready to deploy Windows Autopilot in your production environment. You should follow best practices for any new technology deployment, and you should first pilot the processes to a small group of new devices and their users.

The pilot phase of the Windows Autopilot rollout should be closely monitored, and feedback should be sought from all stakeholders. Any problems with the pilot deployment should be thoroughly resolved before proceeding to a larger scale rollout.

Note Windows Autopilot Roadmap

Windows Autopilot is a comparatively new technology and is likely to have additional functionality added frequently. To ensure that you are up to date with the most recent Windows Autopilot features, you should review the reference information on the Microsoft website at https://docs.microsoft.com/mem/autopilot/windows-autopilot.

Import device hardware information to cloud service

With the hardware ID for each device, you need to import the information into one of the cloud-based administration centers and then synchronize this information to the Windows Autopilot deployment service.

Devices must be known to Azure AD and registered to your tenant before you can provision the devices using Autopilot.

There are a number of administrative portals that you can use to import the hardware device IDs. However, generally, you’ll use one of the following:

• Microsoft Endpoint Manager Admin Center
• Microsoft Store for Business

Use the following procedure to add Windows Autopilot devices to a Microsoft 365 tenant by importing a CSV file with its information:

1. Open the Microsoft Endpoint Manager admin center and sign in as a global admin.
2. Select Devices, select Enroll devices, and then select the Devices tile.
3. On the Windows Autopilot devices page, select Import.
4. On the Add Windows Autopilot devices blade, browse to a .csv file containing the hardware IDs of the devices you want to add, and select Open.
5. If the imported file displays as correctly formatted, select Import. It can take up to 15 minutes to import and process the file contents. On the Windows Autopilot Devices page, the banner should indicate that the import is in progress and show the elapsed time.
6. When the import process has completed, select Sync on the menu bar. A banner should indicate that the synchronization is in progress. The process might take a few minutes to complete, depending on how many devices are being synchronized.
7. Once the sync process has been completed, you will see a notification indicating whether the sync was successful and whether some devices have not been imported. Select Refresh to see the new devices that have been added.
8. After you’ve imported the relevant device IDs, you can optionally assign specific devices to particular users. On the Windows Autopilot devices page, select the device check box, and then select Assign user on the toolbar.
9. On the Select user blade, choose the appropriate user, and then click Select.
10. On the device ID blade, select Save.

Troubleshoot deployment

Before you can resolve an issue with Windows Autopilot, you need to identify in which part of the overall process the problem is occurring. The Windows Autopilot process can be broken down into logical stages:

• Network connectivity Establish an internet connection and connect to the Windows Autopilot service.
• Deployment profile and OOBE A deployment profile will be delivered to the device to manage the OOBE. The OOBE will complete using the settings within the deployment profile.
• Azure AD Has Azure AD been configured correctly? For user-driven deployments, users need to enter their Azure AD credentials to join the device to Azure AD.
• MDM enrollment issues After being auto-enrolled into the MDM service, any policies, settings, and apps will be delivered to the device.

The whole process should result in the device being set up, configured, and ready for the user to be productive.

For a summary of possible troubleshooting areas within these stages, review Table 1-13.

TABLE 1-13 Windows Autopilot process flow

Note Time

If you have ensured that the configuration is correct, then wait. Maybe go grab a coffee. Nearly all issues that I have experienced, such as the new device not being recognized by the Autopilot service, can be resolved by waiting 15 minutes and rebooting the device. Remember that Autopilot uses the cloud, and Azure AD group membership propagation or device ID synchronization can sometimes take a little longer to update.

Error codes

Whenever a major issue occurs when using Windows Autopilot, an error code will be generated. Some error codes can be viewed on the device whenever a problem occurs during setup. Also, error codes can be viewed using the Event Trace for Windows tool.

Some common error codes relating to Windows Autopilot are shown in Table 1-14.

TABLE 1-14 Windows Autopilot error codes

When troubleshooting, other sources of information include looking in the Event Viewer for issues relating to the deployment profile settings and the OOBE. The relevant logs are located here:

Click here to view code image

Application and Services Logs –> Microsoft –> Windows –> Provisioning-Diagnostics-
Provider –> AutoPilot.

An example log entry might read, “Autopilot policy name not found.”

Need More Review? Reviewing Event Log Entries

If you want to know more about the event log entries related to troubleshooting Autopilot profile settings and OOBE flow, visit the Microsoft website at https://docs.microsoft.com/windows/deployment/windows-autopilot/troubleshooting.

You can also look in the registry to find evidence of Windows Autopilot failures. The Auto-pilot deployment service will record information in the registry at this location:

Click here to view code image

HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\AutoPilot

An example of a problem recorded in the registry would read, “The device has not been registered with Autopilot.”

For more advanced troubleshooting, administrators can use the Event Tracing for Windows (ETW) tool to capture detailed information from Autopilot. This will generate trace files, which you can view by using the Windows Performance Analyzer.

Note Support Case for Windows Autopilot

If you have an issue that you cannot resolve, you can obtain help by contacting Microsoft Support and opening a support case for Windows Autopilot at https://docs.microsoft.com/windows/deployment/windows-autopilot/autopilot-support.

Create and manage images

Before you can do anything else. You’ll need to create your images. The starting point is a reference image. The reference image is the standard operating system that you’ll deliver to your users. You’ll have to consider what you want to add to the image; for example, adding drivers, apps, or specific configurations.

Create a reference image

After you’ve determined what will be included in the image, you’ll need to create it. Use the following procedure:

1. On a reference computer, install Windows 10.
2. Apply any Windows updates.
3. Add any drivers, apps, or other required software.
4. Apply any app updates.
5. Configure any installed apps or software as needed.
6. Generalize the image.

Exam Tip

You use the Sysprep.exe program to generalize your image. It’s located in the C:\Windows\System32\Sysprep\ folder.

7. Capture the generalized image.

8. Store the captured image in a location accessible to MDT.

In addition to your operating system image, you’ll also need a boot image. Typically, you’ll use the boot image provided on the Windows 10 product DVD or ISO.

Need More Review? Create a Windows 10 Reference Image

To review further details about reference image creation, refer to the Microsoft website at https://docs.microsoft.com/windows/deployment/deploy-windows-mdt/create-a-windows-10-reference-image.

Add the images to MDT

After you’ve created any required images, the next step is to add the images to MDT. Before you can add images, you’ll need to create a deployment share. Use the following procedure:

1. Open the Deployment Workbench.
2. Select the Deployment Shares folder.
3. Right-click Deployment Shares and then select New Deployment Share.
4. Complete the New Deployment Share Wizard by providing the following:

• A local path on the MDT server for the share.
  • A share name, such as Deployment Share$.
  • A description.
  • Options that control the deployment experience when images are applied:
    • Ask if a computer backup should be performed.
    • Ask for a product key.
    • Ask to set the local Administrator password.
    • Ask if an image should be captured.
    • Ask if BitLocker should be enabled.

When you’ve created the deployment share, you can add your images to it.

To add an operating system image, use the following procedure:

1. Expand your deployment share and select Operating Systems.
2. Right-click Operating Systems and then select Import Operating System.
3. Complete the Import Operating System Wizard, displayed in Figure 1-12, by entering the following information:

Figure 1-12 Choosing the operating system image type

• Choose between Full set of source files, Custom image file, and Windows Deployment Services image.
  • The source location for your image.
  • A WDS server name, if you’re using a Windows Deployment Services image.
  • A destination directory name.