Updated: October 28, 2024
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.
During OOBE the computer asks the end user:
- What region is the device in?
- What keyboard layout do you prefer?
- Do you need a second keyboard?
- Is this your computer or your company computer?
- What Wifi network do you want to join?
- What Microsoft account will you sign in with?
- What user account do you want to create?
- What’s your super memorable password?
- 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?
- Do you want to use Cortana?
- Do you want to buy Microsoft Office?
- Do you want to store all your data in OneDrive?
- Is your device primarily used for gaming?
The Domain Join portion of OOBE begins at 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. In order to answer the domain question, OOBE should be linked to Microsoft AutoPilot to make this an enterprise friendly onboarding model.
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.
When Microsoft AutoPilot is configured, 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 Azure Active Directory, not Active Directory. Microsoft eventually added support for Hybrid Domain Join, where the computer joins AD then joins Azure AD, but this handicaps the ability to use AutoPilot from anywhere and limits the use of AutoPilot to a computer on a corporate network with line-of-site to a Domain Controller.
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. In order to add application installation to the onboarding experience, OOBE + AutoPilot is linked to an MDM (Intune or Workspace ONE UEM) 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 Azure AD 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.
Let’s begin with DSP Online.
VMware created DSP Online in partnership with Dell prior to the VMware/Dell spinoff. Since that time VMware was acquired by Broadcom, Broadcom sold off the EUC division to KKR who formed Omnissa. As of October 2024 the technology continues to exist and is currently available for anyone to use. The original Dell SKU that could be purchased no longer exists but if you are a very large Dell customer the offering can still be purchased from Dell. The original requirements to purchase this 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
Plans by Dell to extend the offering outside of the US have not materialized. The good news here is that now Omnissa has adjusted this process to work as a global solution that is open for any OEM to embrace so it is possible to use this today without purchasing a SKU from Dell.
Here is a visual of the DSP ONLINE process as implemented DIRECTLY AT DELL
The DSP Online provisioning process starts with Dell manufacturing the computer in their factory where Windows Professional is installed on the device. This install does not include any of Dell’s bloatware that is found in their consumer computer process, it’s a vanilla Windows Professional install. During this install the computer has no access to the Internet. Post OS Install, the computer is rebooted into Microsoft Audit Mode and Dell applies a customer generic (but Workspace ONE UEM specific) .PPKG file and unattend.xml file.
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 computer has access to the Internet which 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 those interested I explain ODJ in-depth in a different 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. User-based application and profile assignments are not possible at this stage.
If you are joining the computer to AD, 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. The assumption is that the user is at home and not on the corporate network when they are receiving the laptop thus the requirement for a VPN client.
All of the applications are coming directly from Workspace ONE UEM. 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 and no PPKG to maintain. Application installation happens using the latest version of the application published in Workspace ONE UEM and because that process happens at the Dell Second Touch facility it doesn’t matter how long it takes – the end user will never see this process.
In Summary, DSP Online does not use Microsoft OOBE or AutoPilot As a result Azure AD 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 the process most customers choose. 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 available as a SKU to be purchased from Dell, HP, or Lenovo as part of new computer orders. DSP Offline can also 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 (created in 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 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: Image (Microsoft SCCM/MDT, Altiris, etc)
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 MDT. While Imaging solutions do not support Azure AD join directly, AD joined computers that are imaged would also follow the same AD GPO process described in the previous two sections.