Last Updated: June 17, 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.
The remainder of this blog will break down each one of the four in detail. In practice many customers will leverage more than one of these methods.
Bonus tip – scroll to the end of the this blog for a script that can be used to build an automated USB-key that can be used to configure all of the methods described.
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:
- 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?
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: “What Microsoft Account will you sign in with?” and make the remainder of the decisions on behalf of the end user.
AutoPilot eliminates two OS configuraiton options: the ability to place the computer in a Workgroup and the “Wse a Microsoft Account.” While both of these are traditionally used for a personal computer at someonoe’s house, customers that do not use Microsoft Active Directory or Microsoft EntraID should steer clear of attempting to use AutoPilot for device provisioning.
Unlike OOBE, which is part of the Windows Operating System, AutoPilot is a Microsoft licensed service that is hosted in Microsoft EntraID. Originally AutoPilot was configured from a dedicated web console, but Microsoft retired the dedicated admin console and moved the configuration directly into the Microsoft Intune Administrator Portal. The result of this change is that all customers who wish to use Microsoft AutoPilot must now purchase a single Microsoft Intune device management license in order to gain access to the Intune Administrator Portal in additional to purchasing Azure AD Premium P1, rebranded as Microsoft Entry ID P1 licenses.
When Microsoft AutoPilot is licensed and configured, the OOBE Question 6 “What Microsoft Account will you sign in with?” 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
This method does NOT support Microsoft EntraID join. If your Windows device needs to join Microsoft EntraID this method can NOT be used. Instead consider Microsoft AutoPilot or Omnissa Drop-Ship Provisioning OFFLINE covered in the next section.
The remainder of this section goes into detail on how Dell implemented the solution as part of their OEM offering. The purpose is to show Omnissa Administrators how they can re-create this flow in their own environment.
In the UEM Console this configuration is found by navigating to Devices > LifeCycle > Drop Ship Provisioning.
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.”
In the UEM Console this option is configured from Devices > Staging > Desktop Staging.
A few important details:
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.
The way this works is that DSP Offline provisions a Windows device using an unattend.xml and .PPKG file that is created from the 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 and must be installed on the device in Windows Audit Mode.
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:
The intended workflow for DSP Offline is that 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.
DSP OFFLINE supports EntraID join, AD join, and Workgroup domain models without requiring the purchase of Microsoft AutoPilot licensing. The trade-off is that it requires 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 Imaging tool (Microsoft SCCM, Microsoft Deployment Toolkit (now retired), Symantec, Bigfix, Avocent, RDeploy, 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.
In all of these tools there is some form of automated boot process usually based on PXE. The computer boots into PXE, receives Windows PE, then either launches what amounts to glorified copy-and-paste job, or they download and run through the Windows OS installation process. The end result is usually a duplicate of the source computer where the OS, the apps, and any other configuration items are now replicated to the new device.
The argument for continuing to Image a computer is based on time of completion. It’s faster. Most of the time. To copy-and-paste (over simplified, but true) an entire OS + Apps + configuration is often much faster than downloading an OS, installing the OS, then downloading and installing all the apps, then waiting for app configuration. Speeds and times vary and modern hardware with SSD and/or NVME make this less of a problem today but as a general rule of thumb
Here is a generic visual of the traditional Imaging process. Each vendor will offer their own special flavor of this concept:
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.
How to POC these methods – Automating the OS Installation via USB-Key
With the exception of Imaging, none of the methods discussed above install the OS or prep the OS for what is required to use each method. For testing and demonstration purposes I’ve found using a USB-Key to be the most effective method to try out each method. What follows is the process I follow each time Microsoft release’s a new version of Windows.
To get started grab a USB key with at least 32GB of space available. It will be ERASED as part of this process.
Download the latest ISO from Microsoft for the Windows 11 installation media you plan to use. In all of the scenarios above it is expected that your OS is the Professional Edition. You can upgrade to the Enterprise SKU as part of the provisioning task, but the base OS is always recommended to be Windows Professional Edition.
From a Windows 11 computer, MOUNT the Windows ISO. Insert the USB Key. Run the following Powershell script. The end result will be a bootable USB Key that will silently install the Windows OS to the device.
Here is the script, save it as createmedia.ps1
# Windows 10/11 USB Media Creator Last updated 06/17/2026
# Results:
# - Single FAT32 USB partition
# - Split install.wim into install.swm files
# - Recovery partition increased to 1024 MB
# - InstallTo = Disk <target> Partition 4
$ErrorActionPreference = "Stop"
function Test-IsAdmin {
$identity = [Security.Principal.WindowsIdentity]::GetCurrent()
$principal = [Security.Principal.WindowsPrincipal]::new($identity)
return $principal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
}
function New-AutounattendXml {
param (
[Parameter(Mandatory)]
[string]$OutputPath,
[Parameter(Mandatory)]
[int]$ImageIndex,
[Parameter(Mandatory)]
[int]$TargetDiskId
)
$xmlContent = @"
<?xml version='1.0' encoding='utf-8'?>
<!-- This XML is for EFI partitioning only -->
<unattend xmlns="urn:schemas-microsoft-com:unattend" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
<settings pass="windowsPE">
<component name="Microsoft-Windows-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="amd64">
<UserData>
<AcceptEula>true</AcceptEula>
</UserData>
<DiskConfiguration>
<Disk wcm:action="add">
<DiskID>$TargetDiskId</DiskID>
<WillWipeDisk>true</WillWipeDisk>
<CreatePartitions>
<!-- Recovery partition -->
<CreatePartition wcm:action="add">
<Order>1</Order>
<Type>Primary</Type>
<Size>1024</Size>
</CreatePartition>
<!-- EFI system partition ESP -->
<CreatePartition wcm:action="add">
<Order>2</Order>
<Type>EFI</Type>
<Size>100</Size>
</CreatePartition>
<!-- Microsoft reserved partition MSR -->
<CreatePartition wcm:action="add">
<Order>3</Order>
<Type>MSR</Type>
<Size>128</Size>
</CreatePartition>
<!-- Windows partition -->
<CreatePartition wcm:action="add">
<Order>4</Order>
<Type>Primary</Type>
<Extend>true</Extend>
</CreatePartition>
</CreatePartitions>
<ModifyPartitions>
<!-- Recovery partition -->
<ModifyPartition wcm:action="add">
<Order>1</Order>
<PartitionID>1</PartitionID>
<Label>Recovery</Label>
<Format>NTFS</Format>
<TypeID>de94bba4-06d1-4d40-a16a-bfd50179d6ac</TypeID>
</ModifyPartition>
<!-- EFI system partition ESP -->
<ModifyPartition wcm:action="add">
<Order>2</Order>
<PartitionID>2</PartitionID>
<Label>System</Label>
<Format>FAT32</Format>
</ModifyPartition>
<!-- MSR partition does not need to be modified -->
<!-- Windows partition -->
<ModifyPartition wcm:action="add">
<Order>3</Order>
<PartitionID>4</PartitionID>
<Label>Windows</Label>
<Format>NTFS</Format>
</ModifyPartition>
</ModifyPartitions>
</Disk>
<WillShowUI>OnError</WillShowUI>
</DiskConfiguration>
<ComplianceCheck>
<DisplayReport>OnError</DisplayReport>
</ComplianceCheck>
<ImageInstall>
<OSImage>
<InstallFrom>
<MetaData wcm:action="add">
<Key>/IMAGE/INDEX</Key>
<Value>$ImageIndex</Value>
</MetaData>
</InstallFrom>
<InstallTo>
<DiskID>$TargetDiskId</DiskID>
<PartitionID>4</PartitionID>
</InstallTo>
<WillShowUI>OnError</WillShowUI>
<InstallToAvailablePartition>false</InstallToAvailablePartition>
</OSImage>
</ImageInstall>
</component>
<component name="Microsoft-Windows-International-Core-WinPE" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="amd64">
<InputLocale>en-us</InputLocale>
<SystemLocale>en-us</SystemLocale>
<UILanguage>en-us</UILanguage>
<UserLocale>en-us</UserLocale>
</component>
</settings>
</unattend>
"@
Set-Content -Path $OutputPath -Value $xmlContent -Encoding UTF8 -Force
}
if (-not (Test-IsAdmin)) {
$psExe = (Get-Process -Id $PID).Path
Start-Process -FilePath $psExe -ArgumentList "-ExecutionPolicy Bypass -File `"$PSCommandPath`"" -Verb RunAs
exit
}
Write-Host "================================================================================="
Write-Host "======================= Windows 10/11 USB Media Creator ========================="
Write-Host "============= Single FAT32 / Split WIM / VMware XML Structure ==================="
Write-Host "=================================================================================`n"
Pause
Write-Host "Scanning for mounted ISO..." -ForegroundColor Yellow
$ISO = Get-Volume |
Where-Object { $_.DriveType -eq "CD-ROM" -and $_.OperationalStatus -eq "OK" -and $_.Size -gt 0 } |
Select-Object -First 1
if ($ISO) {
$isoletter = "$($ISO.DriveLetter):"
Write-Host "Mounted ISO found."
Write-Host "Drive letter: $isoletter"
Write-Host "Friendly Name: $($ISO.FileSystemLabel)"
Write-Host "Is this correct? (y/n)" -ForegroundColor Yellow
$confirmation = Read-Host
if ($confirmation -ne 'y') { exit }
}
else {
Write-Host "Mounted ISO not found. Enter the mounted ISO drive letter. Example: G:" -ForegroundColor Yellow
$manualIso = Read-Host
$manualIso = $manualIso.TrimEnd('\')
if ($manualIso -notmatch '^[A-Za-z]:$') {
throw "Invalid ISO drive format. Use a format like G:"
}
$isoletter = $manualIso
}
$sourcesPath = Join-Path $isoletter "sources"
$sourceInstallWim = Join-Path $sourcesPath "install.wim"
$sourceInstallEsd = Join-Path $sourcesPath "install.esd"
if (Test-Path $sourceInstallWim) {
$installImagePath = $sourceInstallWim
$installImageType = "WIM"
}
elseif (Test-Path $sourceInstallEsd) {
$installImagePath = $sourceInstallEsd
$installImageType = "ESD"
}
else {
throw "Could not find install.wim or install.esd in $sourcesPath"
}
Write-Host "Detected Windows image: $installImagePath" -ForegroundColor Yellow
Write-Host "Detecting USB drives..." -ForegroundColor Yellow
Get-Disk |
Where-Object { $_.BusType -eq 'USB' } |
Select-Object Number, FriendlyName, Model, PartitionStyle, @{ Name = "TotalSizeGB"; Expression = { "{0:N2}" -f ($_.Size / 1GB) } } |
Out-Host
Write-Host "Enter the USB drive number to format. Example: 2" -ForegroundColor Yellow
$drivenumber = Read-Host
while ($drivenumber -eq "0") {
Write-Host "You selected drive 0, which is generally the internal disk. Select a USB drive." -ForegroundColor Red
$drivenumber = Read-Host
}
$selectedDisk = Get-Disk -Number $drivenumber -ErrorAction Stop
if ($selectedDisk.BusType -ne 'USB') {
throw "Selected disk $drivenumber is not detected as USB. Aborting."
}
Write-Host "You selected the following USB drive to format:"
Write-Host "This drive will be completely erased." -ForegroundColor Red
$selectedDisk |
Select-Object Number, FriendlyName, Model, PartitionStyle, @{ Name = "TotalSizeGB"; Expression = { "{0:N2}" -f ($_.Size / 1GB) } } |
Out-Host
Write-Host "Is this correct? (y/n)" -ForegroundColor Yellow
$confirmation = Read-Host
if ($confirmation -ne 'y') { exit }
Write-Host "Would you like to generate autounattend.xml for zero-touch install? (y/n)" -ForegroundColor Yellow
$addAutounattend = Read-Host
$targetInstallDiskNumber = 0
if ($addAutounattend -eq 'y') {
Write-Host ""
Write-Host "Enter the TARGET INSTALL disk number Windows Setup should wipe and install to." -ForegroundColor Yellow
Write-Host "Most physical machines use Disk 0, but verify this on multi-disk systems." -ForegroundColor Red
Write-Host "Press Enter to use 0." -ForegroundColor Yellow
$targetInstallDiskNumber = Read-Host
if ([string]::IsNullOrWhiteSpace($targetInstallDiskNumber)) {
$targetInstallDiskNumber = 0
}
if ($targetInstallDiskNumber -notmatch '^\d+$') {
throw "Invalid target install disk number."
}
}
Write-Host "Formatting USB drive as single FAT32 partition..." -ForegroundColor Yellow
Clear-Disk -Number $drivenumber -RemoveData -RemoveOEM -Confirm:$false
Start-Sleep -Seconds 2
$disk = Get-Disk -Number $drivenumber -ErrorAction Stop
if ($disk.PartitionStyle -eq 'RAW') {
Initialize-Disk -Number $drivenumber -PartitionStyle MBR
}
$partition = New-Partition `
-DiskNumber $drivenumber `
-Size 32GB `
-IsActive `
-AssignDriveLetter
Format-Volume `
-Partition $partition `
-FileSystem FAT32 `
-NewFileSystemLabel "WINSETUP" `
-Confirm:$false `
-Force
Start-Sleep -Seconds 3
$partition = Get-Partition `
-DiskNumber $drivenumber `
-PartitionNumber $partition.PartitionNumber
if (-not $partition.DriveLetter) {
$availableLetter = ([char[]](68..90) | Where-Object {
-not (Get-Volume -DriveLetter $_ -ErrorAction SilentlyContinue)
} | Select-Object -First 1)
if (-not $availableLetter) {
throw "No available drive letter could be assigned to the USB partition."
}
Set-Partition `
-DiskNumber $drivenumber `
-PartitionNumber $partition.PartitionNumber `
-NewDriveLetter $availableLetter
Start-Sleep -Seconds 2
$partition = Get-Partition `
-DiskNumber $drivenumber `
-PartitionNumber $partition.PartitionNumber
}
$USB_Boot = "$($partition.DriveLetter):"
if (-not (Test-Path $USB_Boot)) {
throw "Could not access USB partition at $USB_Boot after formatting."
}
Write-Host "USB partition detected at $USB_Boot" -ForegroundColor Green
Write-Host "Copying Windows setup files to USB..." -ForegroundColor Yellow
robocopy $isoletter $USB_Boot /mir /xf install.wim install.esd /xd "System Volume Information" '$Recycle.Bin' /njh /njs
$usbSources = Join-Path $USB_Boot "sources"
if (-not (Test-Path $usbSources)) {
throw "USB sources folder was not created."
}
if ($installImageType -eq "WIM") {
Write-Host "Splitting install.wim into local temp folder..." -ForegroundColor Yellow
$splitTemp = Join-Path $env:TEMP "WinSetupSplitWim"
if (Test-Path $splitTemp) {
Remove-Item $splitTemp -Recurse -Force
}
New-Item -Path $splitTemp -ItemType Directory -Force | Out-Null
$tempSwmPath = Join-Path $splitTemp "install.swm"
$dismArgs = @(
"/Split-Image",
"/ImageFile:$sourceInstallWim",
"/SWMFile:$tempSwmPath",
"/FileSize:3800",
"/CheckIntegrity"
)
$process = Start-Process `
-FilePath dism.exe `
-ArgumentList $dismArgs `
-Wait `
-PassThru `
-NoNewWindow
if ($process.ExitCode -ne 0) {
throw "DISM failed to split install.wim. Exit code: $($process.ExitCode)"
}
Write-Host "Copying split install.swm files to USB..." -ForegroundColor Yellow
Copy-Item `
-Path (Join-Path $splitTemp "install*.swm") `
-Destination $usbSources `
-Force
if (-not (Test-Path (Join-Path $usbSources "install.swm"))) {
throw "install.wim split failed. install.swm was not copied to USB."
}
Remove-Item $splitTemp -Recurse -Force
Write-Host "install.wim split and copied successfully." -ForegroundColor Green
}
elseif ($installImageType -eq "ESD") {
$esdInfo = Get-Item $sourceInstallEsd
if ($esdInfo.Length -gt 3.8GB) {
throw "install.esd is larger than FAT32 can safely support. Use media with install.wim or convert the ESD first."
}
Write-Host "Copying install.esd..." -ForegroundColor Yellow
Copy-Item `
-Path $sourceInstallEsd `
-Destination (Join-Path $usbSources "install.esd") `
-Force
}
$eiCfgPath = Join-Path $usbSources "ei.cfg"
Remove-Item $eiCfgPath -Force -ErrorAction SilentlyContinue
Set-Content -Path $eiCfgPath -Value "[CHANNEL]`r`nRetail" -Force
if ($addAutounattend -eq 'y') {
Write-Host "Getting Windows image information..." -ForegroundColor Yellow
$ISO_Image = Get-WindowsImage -ImagePath $installImagePath
$ISO_Image | Out-Host
Write-Host "Enter the image index number of the Windows edition to install." -ForegroundColor Yellow
[string]$index = Read-Host
$selectedImage = $ISO_Image | Where-Object { $_.ImageIndex -eq [int]$index }
if (-not $selectedImage) {
throw "Invalid image index selected: $index"
}
$autounattendPath = Join-Path $USB_Boot "autounattend.xml"
New-AutounattendXml `
-OutputPath $autounattendPath `
-ImageIndex ([int]$index) `
-TargetDiskId ([int]$targetInstallDiskNumber)
Write-Host "Generated autounattend.xml at $autounattendPath" -ForegroundColor Yellow
Write-Host "OS Image Index set to $index - $($selectedImage.ImageName)" -ForegroundColor Yellow
Write-Host "Target install disk set to Disk $targetInstallDiskNumber" -ForegroundColor Yellow
}
Write-Host ""
Write-Host "USB media creation complete." -ForegroundColor Green
Pause
The next step is to boot the target computer from the USB-Key where the Windows OS will silently install.
Let the Windows OS setup complete the initial round of installation tasks including several reboots.
When OOBE launches, indicated with the question:
“Is this the right country or region?”
unplug the Ethernet Cable and/or disconnect the device from Wifi. This is because the DSP Online and Offline process will fail if the device has internet connectivity. Leave it connected if you are going to register the device with Microsoft AutoPilot.
Press Ctrl_Shift_F3 to reboot the device in Windows audit-mode. The machine will auto login to Audit Mode as the built-in administrator account.
What happens next is hardware dependent.
Right-click on the Windows Start menu and launch Device Manager.
If there are any missing drivers install those drivers before continuing. If you are using Dell hardware, checkout my blog on how to grab the drivers https://aftersixcomputers.com/using-dell-driver-packs-with-workspace-one-factory-provisioning/ – at a minium you want to ensure chipset, wifi, and or NIC drivers are installed.
The OS is now ready to do AutoPilot registration, or DSP Online, or DSP Offline.
1 thought on “A Beginner’s Guide to Windows Domain Join using Workspace ONE UEM”