Onboard Windows Devices with Workspace ONE UEM and Microsoft Autopilot

Introduction

In today’s modern IT landscape, many organizations have adopted Entra ID (formerly known as Azure Active Directory), transitioning from traditional on-premises Active Directory (AD) to a more flexible and scalable identity management system. This transition has introduced the concept of Hybrid Domain Join (HDJ) for corporate Windows devices. With HDJ, a Windows device first joins on-premises AD and then Entra ID, allowing the device to consume configurations and policies from both on-premises AD and Entra ID.

Alongside this, the corporate Windows device must also be onboarded to an endpoint management solution. Omnissa (formerly VMware) Workspace ONE UEM (WS1 UEM) offers a wide range of methods to enroll Windows devices. One prevalent method is to integrate WS1 UEM with Entra ID. This integration automates the enrollment of Windows devices into WS1 UEM, facilitates Offline Domain Join (ODJ), and leverages Microsoft Autopilot to dictate the out-of-the-box experience (OOBE) for end-users during the onboarding process. This integration fosters robust WS1 onboarding workflows tailored specifically for corporate Windows laptops, empowering organizations to harness the benefits of the zero-touch onboarding framework for end-users using corporate-issued Windows devices (i.e. managed endpoints).

Objectives and Architecture Overview

Before diving into the integration of Workspace ONE with Entra ID, it is essential to grasp a few key aspects of the end-user infrastructure in which Workspace ONE acts as the endpoint management solution, while Entra ID serves as an identity and access management (IAM) solution. It is important to consider the necessary integration steps and potential organizational considerations for managing corporate Windows devices, as this sets the stage for the use case discussed in this blog and will guide us through the integration process.

Organizations implement this solution to achieve the following core objectives:

• To streamline the end-user onboarding process, the organization requires that corporate Windows devices be onboarded into WS1 UEM with minimal end-user interaction. Essentially, the organization aims to implement a “zero-touch” onboarding framework for Windows devices.
• Although all corporate Windows devices are onboarded with WS1 UEM, the organization still has some core device management that will continue to be managed via AD by deploying Group Policy Objects (GPO) to the endpoints for an interim period. Hence, the organization mandates that corporate Windows devices must also join the on-premises AD domain as part of the onboarding workflow.
• Additionally, the organization requires corporate Windows devices to join Entra ID as part of the onboarding workflow. This is part of a future roadmap to leverage Entra ID’s conditional access, ensuring resources are only accessible on Windows devices marked as compliant by Entra ID.

To accomplish the above objectives, the organization must implement the below prerequisite architecture using WS1 UEM to manage corporate Windows devices.

• WS1 UEM and Workspace ONE Access (WS1 Access) have been configured to synchronize end-users’ AD accounts to the WS1 consoles via the AirWatch Cloud Connector (ACC) and the WS1 Access Connector, respectively.
• The organization has adopted Entra ID as the primary identity provider (IdP) and has a Microsoft Entra ID Premium P1 or greater license (or any Microsoft bundle that includes this license). All end-user accounts have been synchronized from on-premises AD to the Entra ID tenant via Microsoft Entra ID Connect and the sourceAnchor used is ms-DS-ConsistencyGuid. In addition, core conditional access has been implemented successfully.
• For device enrollment into WS1 UEM, WS1 UEM is federated with WS1 Access as the IdP. The organization has further integrated Entra ID as a third-party IdP within WS1 Access. Thus, WS1 Access is configured to use Entra ID for WS1 UEM device enrollment via SAML integration, such that end-users are redirected to Entra ID for authentication and must meet the configured conditional access requirements before their device can be successfully enrolled into WS1 UEM.
• User identities and attributes are the same across all components (Entra ID and Workspace ONE). These components use on-premises AD as the source to synchronize the end-user’s accounts into the respective admin console.

With the above information, let’s map the required implementations to specific integrations we must accomplish.

Integrating Workspace ONE with Entra ID is a powerful approach that combines the strengths of both platforms; however, this process can be complex due to the multiple components involved. To simplify the integration and validation, it is crucial to organize into manageable steps, testing each component individually before bringing everything together. This strategy makes the integration process more efficient and also helps administrators quickly achieve a fully functional solution.

Integration Summary

In Section 4, we will dive into the specifics of each integration step. But first, let’s outline the sequence of integrations and the high-level objectives we will be achieving along the way:

1.Configure WS1 UEM’s Offline Domain Join via the AirWatch Cloud Connector.

Before a user can leverage their AD credentials to sign in to the laptop, the device must first join the on-premises domain. As well, the device must already exist in AD before it can be synced to Entra ID as Entra ID hybrid joined. For Windows devices to join the on-premises AD domain, WS1 UEM’s domain join configuration must use the AirWatch Cloud Connector (ACC) service, which resides within the organization’s network and is used to add computer objects in the organization’s on-premises AD via a service account that has the permission to do so in AD.

2. Enable Entra ID for Identity Services within WS1 UEM.

This configuration is a prerequisite before we can integrate Microsoft Autopilot workflows. Its main purpose is to enable automatic enrollment of the Windows device into WS1 UEM. Automatic enrollment occurs when the end-user authenticates at the OOBE screen using their organization’s Entra ID account.

3. Enroll Windows Devices using Microsoft Autopilot.

Microsoft Autopilot is a device provisioning solution similar to Apple iOS Device Enrollment Program (DEP); however, unlike Apple iOS DEP that operates via the Apple Business Manager (ABM) portal, Microsoft Autopilot uses a configuration profile deployed to Windows devices via the Microsoft Intune Admin Center. Thus, organizations must have a Microsoft license that includes access to the Intune Admin Center to create and deploy the Microsoft Autopilot profile to target Windows endpoints.

Microsoft Intune’s Autopilot profile for Windows devices provides additional capability that allows administrators to customize the OOBE screens, which translates to a better and more secure onboarding experience for end-users. As soon as a Windows device is powered on, connects to the Internet, and downloads the Autopilot profile, it displays a custom-branded Entra ID login screen during OOBE that prompts the end-user to submit their Entra ID credentials. Once authenticated, WS1 UEM enrollment occurs automatically.

With every Autopilot deployment, devices conduct the following by default (deployment profiles can be created to customize additional options):

• Skip OneDrive and OEM registration setup pages.
• Automatically set up for work or school.
• Get a customized sign-in experience with the company or school branding.

For comparison, an iOS DEP device is assigned a MDM server on Apple’s ABM portal and a Samsung Android device is managed on Samsung KME; i.e. these devices must first be DEP-enabled or KME-enabled, respectively. Likewise, for a Windows device to be Autopilot-enabled, their serial number and hardware hash must be pre-registered with the Microsoft Intune Admin Center, then we can assign an Autopilot profile to an Autopilot-enabled Windows device.

To do so, the easiest method is to purchase the device from a participating OEM (Dell, Lenovo, HP) and work with the OEM to upload the device to the organization’s Microsoft Intune Admin Center. If the device is not from a participating OEM or was purchased before the implementation of Autopilot, an administrator can still perform the manual upload of the device’s serial number and hardware hash to the Intune Admin Center or register devices directly.

With this basic understanding, you are ready to proceed. If you prefer to jump straight into the integration process, feel free to click here or click on each integration step in the list above. If you would like a deeper understanding of the architecture and workflows behind each integration, continue reading for a detailed exploration.

Architecture Models

OOBE/Autopilot Workflows

Once Azure Identity Services are configured within the WS1 UEM tenant, the integration facilitates two key actions: the Windows device will automatically join Entra ID directly and will be auto-enrolled into WS1 UEM. These processes are triggered when the user signs in with their organization’s Entra ID account at the Microsoft Account sign-in prompt via the Out-of-the-box Experience (OOBE) screens.

However, in this OOBE onboarding workflow method, the Windows device itself is not fully locked down to the organization. In case of a lost/stolen device scenario, the Windows device is open to accept any Microsoft account sign-in at the OOBE screen. If the Entra ID account used to sign in does not belong to the organization, WS1 UEM auto-enrollment would never occur. This is where the integration of Microsoft Autopilot is used to lock down the device to the organization’s Entra ID sign-in page and customize the OOBE process for the end-user. The WS1 and Entra ID administrator can perform further work on integrating the Autopilot onboarding option, which we shall discuss later.

The screenshot below provides a high-level overview of the OOBE/Autopilot workflows from an infrastructure perspective using Entra ID and Workspace ONE UEM.

The following steps describe the workflow illustrated in the diagram above.

1. Users receive their device, power it on, and conduct one of the onboarding options: the actual OOBE screens or the customized OOBE screens (Autopilot). At the “Microsoft Account Sign In” screen, users enter their email/UPN > Entra ID to identify and authenticate the user with conditional access.
2. Once authenticated, Entra ID sends the JSON Web Token (JWT) token along with WS1 UEM’s Terms of Use and Enrollment URLs (https://ds####.awmdm.com/DeviceManagement/Enrollment) to the device. This step starts WS1 UEM web-based enrollment.
3. The device redirects to WS1 UEM and it checks enrollment restrictions, if enabled. Workspace ONE UEM parses the JWT token to obtain the Entra ID directory ID (TID), Object ID (OID), and the UPN for the user that it has within the UEM console. WS1 UEM uses these attributes to query Entra ID for the user’s attributes, including the Immutable ID if present.
4. After successfully verifying the user attributes, WS1 UEM prompts for any optional enrollment items or terms of use (if configured).
5. Azure AD sends an access token to the device, which is forwarded to WS1 UEM, which parses the token and saves the device into the database, keeping track of the Azure AD Device ID.
6. WS1 UEM checks for any additional enrollment restrictions. If any of these enrollment restrictions are triggered, the device is wiped; if not, the device has successfully joined Entra ID and enrolled into WS1 UEM. Windows profiles and resources start deploying on the device.Note: since there is a possibility of the device to be wiped, the user should backup any personal data (e.g. contacts, notes, etc.) before beginning this process (this is not necessary if the user began this process immediately after receiving and powering on their device for the first time).
7. The on-premises AD synchronizes the device into the organization’s Entra ID tenant via the Microsoft Entra Connect service.

In the Workspace ONE architecture outlined above, one critical missing component is the integration of WS1 Access and Entra ID as IdP for WS1 UEM device enrollment. Including these elements in this workflow is essential for effective troubleshooting if/when issues arise. Specifically, their role as IdP should be incorporated between steps #2 and #3 wherein WS1 UEM would redirect to the IdP for end-user authentication before completing the automated enrollment process.

For simplicity, we will not explore the detailed involvement of the IdP in this discussion; however, it is important for organizations using a third-party IdP (such as Okta or Ping Identity) integrated with WS1 UEM to consider a critical attribute used by Entra ID to identify users: ImmutableID. This attribute must be synchronized and be consistent across all components, including WS1 UEM, WS1 Access, and the third-party IdP. If the ImmutableID values do not match, Entra ID will fail to recognize the user, and the automated enrollment workflow via OOBE will not succeed.

For example, if an admin configures the Microsoft Entra ID Connect to use the ObjectGUID attribute as the sourceAnchor/Immutable ID to sync on-premises users to Entra ID, this attribute must also be mapped to WS1 UEM, WS1 Access, and the third-party IdP. While ObjectGUID is the most used attribute by default, some organizations may choose to use mS-DS-ConsistencyGuid instead. For more information about sourceAnchor attributes, refer to Entra ID Connect: Design Concepts.

The following process diagram illustrates the OOBE/Autopilot workflows from both an end-user and WS1 administrator perspective. This process flow is instrumental during implementation and validation, helping to pinpoint any failures and facilitate troubleshooting.

Hybrid Domain Join for Windows Devices

When an organization adopts Entra ID, administrators can configure the device settings on the Entra ID admin console to allow devices to join Entra ID. But what is the purpose of joining a device to Entra ID? The primary goal is for the organization to leverage conditional access policies, ensuring that only devices recognized by Entra ID can access organizational apps and resources. Devices joined to Entra ID are considered “managed” according to Microsoft, enabling a higher level of security and control.

Specifically for Windows devices, joining directly to Entra ID enables users to sign in with their Microsoft Entra ID accounts. For Entra ID hybrid joined Windows devices, users must instead sign in using their AD account.

There are three device joined statuses on Entra ID:

Hence, the term “Hybrid Domain Join” identifies the Windows device’s join status on Entra ID. Entra ID labeled the Windows devices as hybrid domain joined when the Windows device first joined on-premises AD and was then synchronized to Entra ID via Microsoft Entra Connect. As the use case of this blog stated (and as Microsoft documentation advises), the join status we want to achieve is hybrid domain join and must be accommodated into the OOBE/Autopilot workflow.

Hybrid Domain Join and Onboarding Deployment Scenarios

The HDJ process via Microsoft OOBE/Autopilot involves a Windows device starting the OOBE process. The user then authenticates using their organization Entra ID account when prompted at the Microsoft account page, and subsequently the automated enrollment into WS1 UEM occurs. Once enrolled, the Windows device is redirected by Autopilot to perform on-premises AD domain join using the Offline Domain Join (ODJ) configuration deployed by WS1 UEM. In turn, the AirWatch Cloud Connector component of WS1 UEM executes the ODJ for the machine and lets the machine join the AD domain.

When ODJ completes on the device, Autopilot triggers a device reboot to enable the AD domain availability on the device and to finish the process. Autopilot then continues registering the device with Entra ID by leveraging the Microsoft Entra Connect on-premises component. The device is synchronized from on-premises AD to Entra ID with HDJ status labeled on Entra ID tenant. Subsequently, the user will need to sign in to the laptop for the first time using their AD domain credentials. The diagram below illustrates the HDJ workflow described, highlighting the key interactions between Microsoft OOBE/Autopilot, WS1 UEM, and on-premises AD.

Before committing to Hybrid Domain Join (HDJ), administrators must understand that this onboarding workflow is unable to be leveraged by default if the Windows device lacks “line-of-sight” to the AD domain. Without this, the end-user will not be able to sign in to the device for the first time using their AD domain credentials, and GPOs will not apply to the device. For this reason, it is important to decide whether to distribute the Windows device directly to the end-user’s home (remote) or to the office where the user would go through the Autopilot onboarding workflows.

This blog focuses on the scenario of distributing devices to the office and assumes the Windows device is on a corporate LAN with line-of-sight to an AD domain controller throughout the process of Microsoft OOBE/Autopilot workflows. This blog does not cover similar workflow for the scenario of distributing devices to the home (remote).

Implementation, Configuration, and Validation

As Section 3 indicates, in the sequence of integration the first step is to implement the ability of WS1 UEM to join the Windows device to on-premises AD via the ACC.

Setup WS1 UEM ODJ Configuration via ACC

Configuration

1. Create and configure a service account with permission to add a computer object in AD. If there is already an existing service account that can add devices to AD, skip this step and use the existing service account for the configuration in step 2.

• In ADUC (AD Users and Computers), create a user account.
• Right-click the container or folder in which to add devices and select Delegate Control. This selection displays the Delegation of Control Wizard.
• Select Next in the Delegation of Control Wizard.
• On the Users or Groups window, input the created user from the step above with Windows Server delegated permissions from the list, and select Add > Next. If this user account is not a member of the Domain Administrators group, increase the computer account creation limit (ms-ds-machine-account-quota) from the default value of 10 to prevent failures after joining 10 devices to the domain.
• On the Tasks to Delegate window, select Create a custom task to delegate > Next.

• On the Active Directory Object Type window, select Only the following objects in the folder > Computer Objects > Create selected objects in this folder menu items > Next.

• On the Permissions window, select General and Creation/deletion of specific child objects > Write, and Create All Child Objects > Next.

2. Configure the ACC service to run with the service account.

This is an important step to perform on all ACC servers in an organization’s WS1 UEM environment. Overlooking any of them could lead to occasional offline domain join failures during testing, validation, and production deployment.

• Access an ACC server > Launch Computer Management > Add the service account from step #1 to the local admin group with privileges so this service account can successfully start the service.

• Launch Services and locate the AirWatch Cloud Connector Service > right-click and choose Properties > choose Log On tab > choose This account > input the service account and password > click Okay and ensure AirWatch Cloud Connector service is in running status. Restart the service if needed.
  • Note: If you input incorrect credentials, an error will be displayed and will not let you click Okay.

Additional Notes: Ensure the password of this service account is secure and has a scheduled expiration (we recommend setting it to expire annually) to maintain security standards without causing frequent disruptions. Moreover, when WS1 admins manually upgrade the ACC in the environment, the AirWatch Cloud Connector service is reverted to using a local system account that can no longer perform the domain join. Ensure the Log-on As field for the service is always updated whenever performing a manual ACC update and after changing the password.

• In the ACC Advanced Security Settings area, give the user Write permissions for the ACC folder at <Drive>:\VMWare\AirWatch\CloudConnector.

3. In ADUC, create a new Organization Unit (OU) in which the enrolled Autopilot Windows device can be created.

Moving to the third step, we establish a dedicated OU in AD specifically designated for Autopilot Windows devices to reside. We named the OU “Workspace ONE”. If you already have an existing OU to which you want to add the devices, you can use this OU and provide the OU name to WS1 UEM’s domain join configuration in a subsequent step.

4. In WS1 UEM, create and assign a domain join configuration.

The initial three steps above involve configuring the ACC to utilize a service account capable of generating machines in AD and where to create them. Despite this setup, the ACC requires an ‘MDM command’ initiated by its master, WS1 UEM, to execute the assigned task. This MDM command is crucial, specifying the location in AD where the device should be created and the desired format for the machine name as preferred by the administrator.

• Access the WS1 UEM admin console at the top org > Groups & Settings > Configurations > Search for Domain Join in the search field > click Domain Join > Add.

• We specified the below for our domain join configuration > Save.

Name – enter a meaningful friendly entry in the Name field so a WS1 admin can recognize the domain join (e.g. “Offline Domain Join”).

Domain Join Type – choose the On-Premises Active Directory.

Domain Name – once you choose On-Premises Active Directory, you can only view this Domain Name field as it is auto-populated with the server you configured for the organization’s directory services with our WS1 UEM tenant.

Domain Friendly Name – same as the domain name field, it is auto-populated with the domain configured for the directory services with the organization’s WS1 UEM tenant.

Machine Name Format – specify the identification record for the machine once it is created in AD under the Workspace ONE OU. We specify %SERIAL% to see the machine’s serial number once it joins the domain. Other WS1 lookup values are not supported here, only %SERIAL% and %RAND:[#]%

• Before assigning the domain join configuration, set up an Assignment Group.

As soon as the device is enrolled via the OOBE/Autopilot Workflows, WS1 UEM deploys the domain join configuration and seamlessly guides the machine through the domain joining process. It is a crucial step in ensuring a smooth and efficient Autopilot hybrid domain join onboarding experience into the WS1 UEM ecosystem.

For testing, create an Assignment Group with a collection of the devices or test users that will go through OOBE/Autopilot. This collection of devices or users should match the assignment of Autopilot profiles on the Intune console. The condition of this Assignment group can be a combination of using WS1 UEM’s TAGS and device registration records within the WS1 UEM console.

Once testing is completed, the WS1 administrator can customize the Assignment Group’s assignment criteria to target all corporate Windows devices that will go through OOBE/Autopilot.

• Assign the domain join configuration.

Now that the assignment group has been created, navigate to Groups & Settings > Configurations > Search for Domain Join and click it > select (enable) the name of the domain join configuration created in the step above > click the Assign button.

Under the Assignments page, click New > Provide an assignment name > under Organization Units, input the name of the OU created in step #3 (“Workspace One OU” in our example) > choose the OU.

Note 1: when you input the name of the OU, WS1 UEM will perform a dynamic search within the organization’s AD and return the full distinguished name of the OU. Ensure selection of the proper OU by validating its distinguished name in AD.

Note 2: with a previous version of WS1 UEM, we experienced an issue wherein the OU field did not perform a dynamic search for the OU, which caused a failure in domain join assignment. We had to work with VMware R&D to fix it, and changes were made to the cloud tenant. If you encounter the same issue, please submit a ticket to Omnissa WS1 Support.

Under Assignment Groups, input the assignment group created above in step #4 > Create.

The configuration of WS1 UEM Offline Domain Join via AirWatch Cloud Connector is now complete!

Testing and Validation

Before conducting the complete OOBE/Autopilot workflow involving the Hybrid Domain Join process, we need to test “Offline Domain Join” using the ACC independently, as these are core components in the workflows, and nothing else matters if the machine fails to join the domain. To guarantee the accuracy of our configuration, let’s explore the testing phase and see the offline domain join functionality in action.

• For an organization with multiple ACC servers deployed, it is advisable to temporarily halt the ACC service on one of the ACC servers to leave just one ACC server running. This ensures that only one ACC service executes the Offline Domain Join operation and makes it much easier to monitor the process.
• By default, the log level for the ACC is set to Information, but the Domain Join actions are only captured in the ACC’s Debug log Hence, on the ACC server targeted for testing, enable the AirWatch Cloud Connector service’s debug log by navigating to <Installation Drive”:\VMWare\AirWatch\CloudConnector\Bank#.
• Compare the two “Bank” folders to ensure you are editing the one with the most recently modified dates.

Then locate and open the file called CloudConnector.exe > Open with Notepad++.

Locate the line (<loggingConfiguration ….level=”Information”).

Change “Information” to “Verbose” and save. Allow a few minutes for the service to pick up the change.

Open the latest Cloud Connector log by navigating to <Installation Folder>:\VMWare\AirWatch\Logs\CloudConnector.

Confirm “Debug” is shown on a few latest log lines.

• Enroll a Windows device directly with WS1 UEM using the test user account that belongs to the Assignment Group used for Offline Domain Join deployment from step #4.
• Once enrolled, open the CloudConnector log on the target test ACC server. The WS1 admin should be able to see the ODJ executed successfully within the latest debug log lines. In addition, the WS1 admin or AD admin can also view AD to confirm the serial number of the test Windows device that landed in the Workspace ONE OU.
• On the Windows device, despite the ACC successfully executing the domain join, the device will need a manual reboot to have the domain available for sign-in.

Repeat all the testing and validation steps above for the rest of the ACC servers deployed in the environment. If all tests are successful, ensure the log level on all ACC servers is reset to Information and that the ACC service is running on all ACC servers.

Enroll using Entra ID OOBE

Configuration

1. Enable Entra ID for Identity Services in WS1 UEM and gather WS1 UEM’s Enrollment and Terms of Use URLs.

•  Log into the WS1 UEM admin console and navigate to the top OG where Directory Services is configured > Groups & Settings > All Settings > Enterprise Integration > Directory Services.

• Scroll down and locate Azure AD integration > click Enabled > when the Use Azure AD for Identity Services setting appears, click Enabled.

• Locate and copy the following URLs to a text file if needed.

2. Integrate AirWatch by providing WS1 UEM’s Enrollment and Terms of Use URLs to Entra ID under Mobility (MDM and MAM)

• Log into the Entra ID admin console by using an account with at least an Application Administrator role (or Global Administrator role) > Navigate to Azure Active Directory > Mobility (MDM and MAM) > Add Application.

• On the Add Application screen, search for “AirWatch by VMware” > click Add

• Once “AirWatch” is added, select this application under the Mobility (MDM and MAM) section to start the configuration > Provide the WS1 UEM’s URLs from step #1 above.

For MDM user scope setting, select Some and input the Entra ID accounts you want to test first. Ensure the selected Entra ID accounts match the WS1 Assignment Group constructed in step #4 under the configuration section for Offline Domain Join, as the OOBE onboarding options will only apply to these selected Entra ID accounts. Once testing is successful, the admin can switch to an Entra ID group that represents all users in the organization. Click Save to apply the changes.

3. Provide Entra ID Tenant Properties to WS1 UEM.

• Within Entra ID admin console, click Properties > locate the Tenant ID and Tenant Name > copy to a text file if needed.

• Navigate to WS1 UEM admin console > Groups & Settings > All Settings > Systems > Enterprise Integration > Directory Services > scroll to section Azure AD integration > paste the Tenant ID and Tenant Name into the respective fields as depicted in the screenshot below.

• Scroll down to Immutable ID Mapping Attribute field > input the ms-DS-ConsistencyGuid value > save the configuration in WS1 UEM.

Note: We use ms-DS-ConsistencyGuid because the organization in this blog specified this AD attribute as the Source Anchor in Microsoft Entra Connect to sync users from AD to Entra ID. Please refer to Understanding OOBE/Autopilot Onboarding Workflows for more details.

The configuration of Enrolling using Entra ID Out-of-the-Box Experience (OOBE) is now complete!

Testing and Validation

The purpose of this testing is to confirm the WS1 UEM automatic enrollment of the Windows device will occur via OOBE.

• On a fresh Windows device or a fresh virtual machine, power on the device and start the OOBE
• On the Sign in with Microsoft page, input the test Entra ID account > perform authentication with Entra ID.

• You will then be guided through several ensuing OOBE screens, and after a few minutes the Windows device will be enrolled into WS1 UEM under the same test AD account on the WS1 UEM admin console. WS1 administrators can check the WS1 UEM console to validate the enrollment status of the Windows device.
• The Windows device should also be joined to the on-premises AD domain as per deployment of the Offline Domain Joined process above. Perform a device reboot.
• At the sign in screen on the Windows device, the AD domain should be available. Sign in to the Window device using AD credentials.
• On the desktop screen, the Windows desktop will be visible and the Intelligent Hub app catalog as shown.

• If you do not see the Hub on the test device, ensure you have configured WS1 UEM to publish the Hub. This can be enabled by selecting Groups and Settings > All Settings > Devices & Users > Windows > Windows Desktop > Intelligent Hub Application, then enable Publish Workspace ONE Intelligent Hub.

This concludes the testing to confirm the WS1 UEM automatic enrollment of the Windows device occurs via OOBE. Note that the automatic enrollment of a Windows device into WS1 UEM using Entra ID OOBE still requires the user to go through each OOBE screen manually. In addition, this method does not fully lock down the Windows device to the organization’s Entra ID. In the next configuration section, we will conduct enrollment using Entra ID Autopilot.

Enroll using Entra ID Autopilot

Configuration – Enable Windows Device to Autopilot

1. Manually upload the Windows device to the Intune Admin Center method via .CSV file.

• Use the following commands from an elevated Windows Command Prompt to obtain the device hardware hash:

powershell.exe
Set-ExecutionPolicy Unrestricted
Install-Script -Name Get-WindowsAutopilotInfo
Get-WindowsAutopilotInfo -OutputFile C:\HWID\AutopilotHWID.csv

• This will create a file called AutopilotHWID.csv in the C:\HWID folder, which will contain the device’s serial number and hardware hash.

Note: when using the Install-Script command, an internet connection is required to download the script from Microsoft.

To capture multiple device serial numbers and hardware hashes in the same .CSV file for the purpose of bulk upload, an administrator can include up to 500 rows in the file’s list of devices. The header and line format must look like this: <serialNumber>,<ProductID>,<hardwareHash>

There are a few constraints to be considered:

• • It is not possible to use extra columns.
  • It is not possible to use quotation marks.
  • Use only ANSI-format text files (not Unicode).
  • Headers are case-sensitive.
  • For best results, use a plain-text editor such as Notepad or Notepad++ with this .CSV file (avoid using Microsoft Excel).

• Create the file in Notepad/Notepad++, add the header, the device serial numbers, product IDs, and the hardware hash, or if adding just one device, an administrator can just use the AutopilotHWID.csv file.

• In the Microsoft Intune admin portal, select Devices > Windows > Enrollment (under Device Onboarding) > Devices (under Windows Autopilot Deployment Program) > Import.

2. Directly add a device to the Intune portal via OOBE.

• Boot the Windows device into OOBE and launch Command Prompt.
• Enter the following commands:

Powershell.exe
Install-Script -name Get-WindowsAutopilotInfo -Force
Set-ExecutionPolicy Unrestricted
Get-WindowsAutoPilotInfo -Online

• At this point you will be prompted to sign in. Sign in with an account with the Intune Administrator role, accept the permissions as shown, and the device hash will then be uploaded automatically to Microsoft Intune Admin Portal as a Windows Autopilot-enabled device.

• Confirm the Windows device is Autopilot-enabled by opening Microsoft Intune Admin console, and navigate to Devices > Windows > Enrollment (under Device Onboarding) > Devices (under Windows Autopilot Deployment Program) > Confirm your device serial number as registered. The device is now Autopilot-enabled!

Configuration – Create Device Group for Autopilot Profile Assignment

A device group is required to assign a Windows Autopilot deployment profile to the devices. For initial testing, create a device group by setting membership type to Assigned (instead of Dynamic). For production deployment, it is recommended to create dynamic device groups using Autopilot attributes.

• Access Intune admin portal > select Groups > click New Group.

• • Group Type: select Security
  • Group name and Group description: enter a name and description for the group.
  • Microsoft Entra roles can be assigned to the group: select No as the Microsoft Entra roles are not assigned to this group.
  • Membership type:
  • For initial testing purposes, choose “Assigned” and pick a test device that was enabled for Autopilot from the prerequisite section above.
  • For production deployments, choose Dynamic Device > under the field Dynamic Device members > select Add dynamic query > Add expression. The Microsoft KB here explains the details of using expressions that work in conjunction with the Windows device procurement process with the OEM.
  • Owners: select users that own the group. Owners can also delete this group. It is recommended that owners are the personnel who will oversee Apple’s ABM and/or Samsung KME portal since Autopilot deployment is the same concept for Windows devices.

• Create the Device Group.

Configuration – Create, Configure, and Assign Autopilot Profile

At this point, there is a device group on Intune Portal that contains the test AutoPilot-enabled device. This step is to create, configure, and assign the AutoPilot profile to this device group.

• In Microsoft Intune admin portal > Devices > Windows > Enrollment (under Device Onboarding).
• Under Windows Autopilot section > Deployment Profiles > click Create profile.
  

• Name the Autopilot Profile accordingly and configure the OOBE settings regarding what to skip and not skip > Create. Select User-Driven deployment mode and pick hybrid domain join as “Join to Azure AD As”.

• Assign the Autopilot Profile to the device group from the section above by clicking the name of the AutoPilot profile > Assign. We are now ready to test a full Autopilot onboarding workflow!

Testing and Validation

Please refer to the process diagram in the sections above illustrating the complete OOBE/Autopilot workflows from both the end-user and WS1 administrator perspectives as a reference to conduct the test. The test Autopilot-enabled Windows device will perform these exact steps. If/when encountering any issues, an administrator can use the following recommendations to identify possible root cause and to troubleshoot accordingly:

• Omnissa KB on Autopilot Hybrid Join Best Practices
• If the Windows device fails to complete the Autopilot workflows and triggers an error, an administrator can enter Shift + F10 on the error screen on the device itself to launch Command Prompt and execute the command below to view a diagnostic output:

Powershell.exe
Set-ExecutionPolicy bypass
Install-Script Get-AutopilotDiagnostics -force
Get-AutopilotDiagnostics.ps1

A successful AutoPilot Hybrid Domain Join should generate a diagnostic output containing the full workflow.