A Beginner’s Guide to Windows Domain Join using Workspace ONE UEM

Last Updated: February 9, 2026

I miss the days when a Windows computer never left the office. Back then joining a computer to a Microsoft Active Directory (AD) domain was simple. But humans had to go screw that up by inventing the laptop, the Cloud, and Microsoft Azure (now EntraID).

Now joining a domain is a complicated mess that is made more difficult by Microsoft, Dell, HP, Lenovo, and Omnissa using different names to describe the domain join process. Today’s blog is an attempt to clear up the confusion. Let’s start with a visual aide:

The four boxes at the top of the illustration summarize four unique device provisioning methods. Each of the four methods can be used to get the computer to join a domain; however each of the four methods uses different technology and has different requirements for how the domain join occurs. Let’s break down each one of the four.

Update: The original images used in this blog were created in Miro and the more complex ones don’t convert well to HTML. I recommend downloading the PDF I created which has a higher quality version of each graphic. You can download the PDF from here then follow along using the downloaded visuals.

Method 1: Microsoft Out of Box Experience (OOBE) and Microsoft AutoPilot

The Microsoft Windows Operating System contains an installation/setup phase (multiple actually) and a configuration phase. The OEM/IT Administrator is responsible for the installation/setup phase.

OOBE is what happens after the installation/setup phase is complete.

OOBE is intended to be seen by the person who receives the computer (aka the end user) and is intended primarily for consumer PCs. Think of OOBE as the final interview process before the computer can be used.

With Windows 10 during OOBE the computer asks the end user 13 questions. That’s 13 mouse clicks before Windows ever makes it to a login screen. Originally they were as follows:

1. What region is the device in?
2. What keyboard layout do you prefer?
3. Do you need a second keyboard?
4. Is this your computer or your company computer?
5. What Wifi network do you want to join?
6. What Microsoft account will you sign in with?
7. What user account do you want to create?
8. What’s your super memorable password?
9. What three questions do you want me to ask you when you forget your super memorable password? What are the answers to the three questions?
10. Do you want to use Cortana?
11. Do you want to buy Microsoft Office?
12. Do you want to store all your data in OneDrive?
13. Is your device primarily used for gaming?

With Windows 11, more questions have been added. This is mostly Microsoft attempting to up-sell licensing for more OneDrive storage, buying licenses for Microsoft Office or optimizing your PC for tasks like Entertainment or Gaming. Worth noting, OEM’s like Dell have the ability to introduce additional OOBE questions, all of which is something most IT Administrators want to eliminate from the setup experience.

The Domain Join portion of OOBE begins at what was originally Question 6: What Microsoft Account will you sign in with? The options at this point are for the end user to choose a Microsoft Account, login with a Microsoft Azure Account, or join the computer to a Windows Workgroup, or a Windows AD Domain. In an Enterprise this is not a question that you should be asking your end users, it’s an administrative decision that should be made on their behalf. Microsoft only allows this decision to be made for the end user if the organization buys a license for a configuration option named Microsoft AutoPilot.

Microsoft AutoPilot gives IT Administrators the ability to interrupt the OOBE process at Question 6 and make the remainder of the decisions on behalf of the end user.

One trade-off is that AutoPilot eliminates the ability to place the computer in a Workgroup or a Microsoft Account join, which for Enterprise Deployments is a great thing (unless you do not use Active Directory and need your computers to be in a Workgroup).

Unlike OOBE, which is part of the Operating System, AutoPilot is a service that is hosted in Microsoft EntraID, thus using it requires a license from Microsoft. The license is bundled in multiple product SKUs, the most common being Azure AD Premium P1, rebranded as Microsoft Entry ID P1.

There is now an additional licensing requirement for Microsoft AutoPilot: I.T. Administrators must purchase a single license for Microsoft Intune. This is because the configuration menus that were available from a dedicated URL (then added to the Office 365 Admin page) have all been moved into the Microsoft Intune Administrator Console.

When Microsoft AutoPilot is licensed and configured, OOBE Question 6 is replaced with a Your-Company-Logo branded question that asks the user to login using their corporate email address. From there the process is mostly automated. If all goes to plan the next screen the user sees will be the Windows login prompt at the end of the experience.

Here is a visual of the Microsoft AutoPilot Workflow:

One of the biggest advantages of using OOBE and AutoPilot is that it works on any version of Windows 10/11 from any hardware manufacturer.

The biggest disadvantage is that AutoPilot won’t function until the device has been registered with Microsoft. The registration process is something that is done by the OEM at the factory, or by the IT Administrator BEFORE the device is shipped to the end user but this registration requires coordination and sometimes an additional fee from the OEM.

Another disadvantage to Autopilot is that it is designed to place computer objects in Microsoft Entra ID, not Active Directory.

Microsoft eventually added support for Hybrid Domain Join, where the computer joins AD then joins EntraID, but at the technical tradeoff of only working if the computer has direct line of site to a domain controller. The use of a VPN product is not supported for this scenario, thus eliminating one of the selling points of AutoPilot – which originally was the ability to configure/restore a computer from anywhere with an internet connection.

A final disadvantage of AutoPilot is that AutoPilot does not include a method to install Applications as part of the onboarding process. AutoPilot is designed solely to configure the Windows Operating System and optionally to enroll the device into an MDM.

In order to add application installation to the onboarding experience, OOBE + AutoPilot can be is linked to an MDM and the MDM is able to install applications to the device prior to the end user logging onto the device.

For organizations that require pre-installation of large Windows applications (think multi-gigabit), OOBE + AutoPilot + MDM can be a challenge for users that do not have fast internet connectivity.

In summary, Microsoft OOBE + Microsoft AutoPilot + MDM is a great fit for organizations who have licenses available for it and are ready to fully embrace Microsoft EntraID and do not require local AD domain join.

For more information on how to configure Microsoft Autopilot and Workspace ONE UEM the Omnissa Techzone website offers a great tutorial here.

If you are insist on placing computers in AD and doing so through Hybrid Domain Join with AutoPilot, I detail how to configure Workspace ONE to implement OOBE + AutoPilot + MDM + Hybrid Domain Join in a different blog found here:

Method 2: Workspace ONE UEM Drop-Ship Provisioning ONLINE

Workspace ONE UEM Drop-Ship Provisioning (DSP) comes in two versions: Online and Offline though as of the year 2026 Omnissa is doing everything that can to hide/discontinue that Offline still exists.

Airwatch created DSP Online in partnership with Dell prior to the sale of Airwatch to VMware. The original intent of this offering was that customers purchased a SKU from the OEM they used, then the OEM handled everything else. PCs purchased were no longer shipped to IT departments for provisioning, instead they are shipped directly to end users who power them on, get to skip OOBE and have their applications preinstalled and ready to go. It’s the Utopia of Windows OS Provisioning.

Since the original release, Airwatch was acquired by VMware, VMware was acquired by Broadcom, Broadcom sold off the EUC division to KKR who formed Omnissa. What got lost in all this corporate shuffle is the ability to license DSP Online from an OEM. As of 2026, there’s no general SKU available for purchase from any of the OEMs for this technology.

If you previously purchased the SKU while Dell made it available, or if you are buying and deploying hundreds of PCs a week and would like your OEM to implement this on your behalf, contact Omnissa directly and they will work through this problem. But for all practical purposes what started as a behind the scense-you-never-need-to-care about this process, how now become something the I.T. Admin must configure on their own and implement.

The original requirements to purchase this SKU/service from Dell were as follows:

• Only available for brand new computers
• Only available when ordered from Dell Direct (no 3rd party hardware purchases)
• Only available through Dell’s Tech Direct Portal
• Only available in the USA

As of 2026, plans by Dell to extend the offering outside of the US have not materialized, plans to extend this offering to HP or Lenovo have not happened and overall this is very much a “do-it-yourself” approach to systems deployment.

Here is a visual of the DSP ONLINE process as originally implemented DIRECTLY AT DELL

The main reason to understand this process is because it’s the one recommended for anyone to consume. 

The generic Omnissa unattend.xml and .PPKG file include a set of scripts that install the Workspace ONE UEM Intelligent Hub app on the computer and includes the information required for the Windows computer to reach out to the Omnissa Device Provisioning Service the next time the computer has access to the Internet. The unattend.xml does NOT include any information to join the computer to the domain. Sysprep is run and the computer is powered off.

Dell puts the computer in a box and ships the computer to what they call a Second Touch Facility. At this point the computer is NOT enrolled into MDM and no customer specific information is on the device.

Note that Dell reserves a 7-day window to get the computer from the Factory to the Second Touch Facility

The Second Touch Facility is different from the Factory in that the computer is plugged into a rack that has access to the Internet, This opens the computer up to over-the-air configuration options.

When the computer arrives at the Second Touch Facility a Dell Technician boots the computer with Internet Access and the computer is now able to communicate with the Omnissa Provisioning Service.

The Omnissa Provisioning Service is responsible for linking the computer to the customer specific Workspace ONE UEM Console in order to complete the MDM enrollment.

With MDM Enrollment completed as a generic staging user, the UEM Console uses a Workspace ONE UEM Device Tag to trigger the Workspace ONE UEM Domain Join process. The Workspace ONE UEM Domain Join process uses Microsoft Offline Domain Join (ODJ) (djoin.exe) to complete an offline domain join. For a detailed explanation of ODJ check-out my other blog found here.

After the ODJ completes, the computer will download and install all of the applications assigned to the computer by Workspace ONE UEM. Note that User-based application and profile assignments are not possible at this stage.

If you are joining the computer to AD, in order to gain line-of-site to a Domain Controller, it is expected that one of the applications that must be included in this workflow is a VPN client that supports pre-login VPN. The reason a VPN client is required is because while the device is joined to AD via ODJ, when Windows boots to the first login screen, there is no cached credential for login, so Windows needs network line-of-site to a DC in order to authenticate the user account to allow the user to sign in to Windows. Remember that the end user is going to receive this computer and originally the end user was expected to be working from home, not from a corporate office. Post covid and with 2026 Return to office mandates you may find you no longer need a VPN for this process as your employees might be coming back into an office.

With this process, all of the applications are coming directly from Workspace ONE UEM over the Internet. The process waits until all of the applications have downloaded and completed the installation as defined in the UEM Console. Then the computer is powered off. Dell boxes the computer and ships the device directly to the end-user.

When the end-user receives the device and powers it on for the first time, the VPN client loads as the Windows Operating System is booting enabling the device the line-of-site to the domain controller which allows two things to happen: the end user is able to login to the Operating System using their AD credentials AND Workspace ONE UEM is able to switch the device registration from the generic staging user account to the end user’s account which allows user-based app and profile assignments to be triggered.

The biggest advantage to DSP Online is that there is no OS image to maintain (it’s up to the OEM to install the OS) and there is no PPKG to create then send to the OEM. This is also more secure because it ensures that the latest versions of an application are deployed, instead of hoping the image was updated and then replicated to the OEM. A final advantage is that because the app installs happen at the Dell 2nd touch facility, the end user is spared the time required to download and install the apps making them more productive form the time they receive the computer.

In Summary, DSP Online does not use Microsoft OOBE or AutoPilot. As a result EnterID join is not supported using this method.

While Hybrid Mode is not directly supported at the Factory, it is possible to achieve Hybrid mode if Microsoft AD GPO is configured to do so post onboarding. I document how to configure the AD GPO to achieve this in my blog found here.

For a complete step-by-step guide on how to configure DSP Online it can be found here.

Method 3: Workspace ONE UEM Drop-Ship Provisioning OFFLINE

Workspace ONE UEM Drop-Ship Provisioning (DSP) Offline is another option to consider. A brief history lesson: this method went to market under the name “Dell Factory Provisioning” and was then renamed to “Factory Provisioning” before settling on its current name “DSP Offline.”

DSP Offline is not available as a SKU to be purchased from Dell, HP, or Lenovo as part of new computer orders.

DSP Offline can be implemented by any 3rd party integration partner, or used directly by an I.T. Administrator.

What you can NOT do is ship the computer directly to an end user that is off the network. DSP Offline, when used for AD domain join, is designed to be completed on the corporate network by the IT Administrator.

DSP Offline provisions a Windows device using a customer created unattend.xml and .PPKG file. This is done using the Workspace ONE UEM Console. The unattend.xml includes the domain model to be used and the .PPKG contains all of the applications that need to be installed on the device. These two files are sent to whatever entity is responsible for provisioning the device.

When the computer is manufactured, Windows 10/11 Professional is installed, the computer is booted into Microsoft Audit Mode then the manufacturer uses the Omnissa Factory Provisioning Tool to apply the customer provided unattend.xml and .PPKG file. Part of the .PPKG file is the Workspace ONE UEM Intelligent Hub application. Sysprep is run to return the device to the OOBE experience and the computer is then shipped to the corporate office.

A key detail about the .PPKG is that it is a point-in-time snapshot of the applications. There is no method to update the applications except to generate a new .PPKG. Compare the use of the .PPKG to the DSP ONLINE workflow (where applications are installed directly from the UEM Console and no .PPKG is involved) and it starts to make sense why the process is named DSP OFFLINE.

Here is a visual of the DSP OFFLINE process:

When the computer arrives at the corporate office, the computer is booted on a network with line-of-site to a Domain Controller and Windows joins the computer to the domain. After a reboot the computer completes MDM enrollment as a staging user account. When the end user logs into Windows the staging user is replaced with the end user and the Intelligent Hub agent is launched with a status screen informing the user that Workspace ONE UEM is installing any user specific applications and applying user specific profiles.

In summary, DSP OFFLINE is different from ONLINE in that it uses a customer specific .PPKG (with the customer’s application stack included) along with a customer specific unattend.xml that tells the Windows OS what domain model to join. As a result this method supports Azure, AD, and Workgroup domain models without requiring the purchase of Microsoft AutoPilot licensing at the trade-off of requiring computers to be provisioned on the corporate network. Hybrid Domain join can also be achieved with DSP OFFLINE by leveraging the AD GPO process as described in the blog found here.

Bonus: While I started this section saying it’s not supported to use this method off-network, there is a method that allows this to work though it’s not supported by Omnissa Tech Support. Check it out here.

Method 4: Traditional Image (Microsoft SCCM, Symantec, Bigfix, Avocent)

I include Imaging because despite what you may have heard, modern management does not support Bare-metal OS Deployment.

Break-fix scenarios do still occur and Imaging is a valid solution to break-fix. Imaging is also heavily leveraged by Virtual Desktop solutions like Omnissa Horizon so it’s a technology that is not likely to go away anytime soon.

Here is a generic visual of the Imaging process:

The advantage to imaging is that the computer will be joined to AD or a workgroup as part of the image creation process, or through the task sequencing if using a tool like Microsoft SCCM or the now defunct MDT. While Imaging solutions do not support EntraID join directly, AD joined computers that are imaged would also follow the same AD GPO process described in the previous two sections to achieve hybrid configuration.

As Imaging is not a solution provided by Workspace ONE UEM no further details about this method will be discussed as part of this blog.