How to Configure VMware Drop Ship Provisioning ONLINE to join Active Directory

Last Updated 11/16/2022

Once you get past the confusing terminology, using VMware’s Drop Ship Provisioning (DSP) to join a computer to Active Directory (AD) is a six-step process. You just need to know what to ignore in Workspace ONE UEM for it to be successful; which is what this blog will teach you.

Before proceeding you should read the Beginner’s Guide where you will learn more about the various methods to configure Windows devices using Workspace ONE including DSP Online and DSP Offline.

To summarize the configuration steps below:

  1. Configure Active Directory to support Domain Join
  2. Change existing Airwatch Cloud Connector (ACC) configuration to support Domain Join
  3. Configure the Workspace ONE UEM Console to support Drop Ship Provisioning ONLINE
  4. Register Devices
  5. Get a copy of the VMware generic unattend.xml and *.ppkg files
  6. Configure the Windows computer

Special Considerations:

The VMware Workspace ONE UEM Console uses an Organization Group (OG) for device management and configuration. It is a common practice in UEM to have a root OG and then to create multiple lower OGs to build out a hierarchy of configurations. Unlike the rest of the UEM Console feature sets, the Domain Join Configuration feature does not support multiple OGs. It does not support sub-OG’s either. All Domain Join Configuration must be configured at the top-most OG. Further, for Domain Join operations to function, the ACC installation and Directory configuration along with all of the UEM Console User accounts, the UEM Console Device Registration records, and all of the UEM Console domain configurations are required to exist at the root OG. While the device can always been moved to a sub-OG post enrollment and onboarding keep this in mind when trying to use this feature.

Step 1: Configure Active Directory to support Domain Join

The configuration starts in Active Directory.

To complete these steps you need access to Active Directory Users and Computers (ADUC). ADUC is installed by default on all Domain Controllers or the tool can be installed on a Windows desktop using the Microsoft RSAT installation files.

To join a domain on behalf of another device, an AD User Account is needed that has permissions to join computers to the domain using Delegated permissions. Create a new AD User account to use as the Delegated Permissions account as follows:

  1. Launch ADUC
  2. Navigate to > Users
  3. Right-click on Users.
  4. Choose New > User.
  5. Complete the New Object – User wizard. As an example in the screenshot below, I’ve named the account UEMDomainJoin with a complex password that does not expire and prevents the account from changing its own password.
    Note: The AD account does not need any admin roles in AD, a standard user account works for this purpose
  6. When a new computer joins the domain it needs to be placed in an AD OU. By default this would be the “Computers” container; however the Workspace ONE UEM domain join process does not support the use of the “Computers” OU. It will be necessary to choose a different OU for this process, or create a new OU as follows:
    1. Create a new OU within ADUC. For example I use “UEMDomainJoin” as the name of the OU
    2. Within ADUC, navigate to the new OU created in the previous step, right-click on the OU name from the left-hand panel and choose Properties
    3. Choose the tab Attribute Editor
    4. Scroll down to distinguishedName, single-click it, and choose View to bring up the “String Attribute Editor. Copy and Paste the Value into Notepad for use later on. In my example the Value is OU=UEMDomainJoin,DC=lab,DC=aftersixcomputers,DC=com
    5. Close the String Attribute Editor and the Properties dialog box returning to the main ADUC navigation pane
    6. From the left-hand panel of ADUC right-click on the OU name, in my example UEMDomainJoin, and choose Delegate Control to launch the Delegation of Control Wizard
    7. Click Next
    8. Click Add
    9. Type in the name of the account that was created back in Step 5, in my example it’s the AD account named UEMDomainJoin. And yes, I know I named both the account and the OU the same name. Sorry if that confuses you.
    10. Choose Check Names to ensure it resolves.
    11. Choose Ok and the results should be similar to this:
    12. Click Next to reach the Tasks To Delegate menu
    13. From the Tasks to Delegate menu, choose “Create a custom task to delegate” as shown below and click Next
    14. Select “Only the following objects in the folder:”, select “Computer objects” and check the box for “Create selected objects in this folder.” The end result should look like this:
    15. Click Next to bring up the Delegation of Control Wizard Permissions menu
    16. From the Delegation of Control Wizard Permissions menu Show these permissions check the box next to General, and Creation/Deletion of the specific child objects then in the specific permissions check the box next to “Create All Child Objects.” The result should look like this:
    17. Click Next to reach the end of the Delegation of Control Wizard and click Finish
    18. This step is optional and only used if you have more than one AD OU to store computer objects in:
      If you need to use more than one AD OU to store computer objects in AD this is achieved by creating multiple Workspace ONE UEM Domain Configurations matching one OU to one Domain Join configuration. We have not covered the UEM Console portion of this, it’s later on in this blog, but while you are here in ADUC, if you do need to use more than one AD OU go ahead and repeat this process for each OU you need to use.

Step 1a) Adjust AD MachineAccount Quota and AD GPO “Ad Workspaces to Domain”

Microsoft Active Directory is designed to limit each AD user account to only being capable of 10 unique computer domain joins. Microsoft named this limit the “Machine Account Quota.” To work around the Machine Account Quota an IT Administrator could add the AD user account to be a member of the Domain Administrators Group but doing so introduces additional security risks and is not recommended. The configuration challenge with the “Machine Account Quota” is that this is set at the domain level for all accounts, it can not be raised or lowered for a specific user account. Unless you have less than 10 machines in your environment, the “Machine Account Quota” must be changed from the default value of “10” to the new value of “0” which means unlimited.

Let me repeat myself: Before making this change understand that making this change means ALL, I repeat ALL Active Directory User accounts that are not members of the Domain Administrators Group will now have unlimited domain joins available.

To prevent this undesirable security configuration, this means it is necessary to implement an additional AD GPO to limit the scope of this change. The AD GPO is named “Add Workspaces to Domain” which will change the default behavior of allowing every AD account to join a domain an unlimited amount of times and instead only allow specific accounts to be able to join the domain an unlimited amount of times.

Many organizations likely already have the “Add Workspaces to Domain” Group Policy enabled, but if you do not, this policy is found in the AD GPO Management console under:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment

Here is what the GPO looks like:

Microsoft’s Best Practice for AD is to create an AD Security Group then assign the “Add workstations to domain” GPO to the Security Group. In this way any users that get added to the Security Group will then be able to create computer objects in the domain. Readers may observe I do not follow this advice in the screenshot attached, but I do still recommend it.

The next step is to make the change to the MachineAccount Quota as follows:

  1. Comfortable with Powershell?

    Change the MachineAccount Quota with:

    Set-ADDomain -Identity ((Get-ADDomain).distinguishedname) -Replace @{"ms-DS-MachineAccountQuota"="0"}

    To validate that the command was successful:

    Get-ADDomain | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'
  2. Not comfortable with Powershell?
    From the Windows Administrative Tools section, launch Active Directory Service Interfaces Editor (ADSI Edit)
  3. Right-Click on the left menu named “ADSI Edit” and select Connect To then select OK to accept the default naming context. A new object will appear on the left hand menu with the name “Default naming context [name of your domain].”
  4. Expand the arrow to the left of the Default naming context to display a folder structure listing your domain and the LDAP structure beneath it.
  5. Right-click on the first folder which should read something like “DC=your,DC=domain,DC=com” and select Properties. It should look like this but with your domain information displayed:
  6. From the Attribute Editor scroll down to ms-DS-MachineAccountQuota, choose Edit and change the value to 0.
  7. Save the changes and close ADSI Edit

Step 2: Change ACC to support Domain Join operations

This step involves all of the configuration changes to the Airwatch Cloud Connector (ACC) configuration. Let’s dig in:

  1. From your primary computer launch the Workspace ONE UEM Admin Console
  2. Validate the version of the UEM Console is 21XX or higher which is the first branch of the UEM console that added support for domain join operations.
    At the time of this writing UEM Console is the lowest recommended version of UEM Console to use with this process.
  3. Navigate to Groups & Settings > All Settings > System > Enterprise Integration > Cloud Connector
  4. Scroll down and choose Test Connection.
  5. In the Test Connection Results, ensure the version of ACC is version or higher.
  6. Domain Join operations are not captured by the ACC logs unless Verbose Logging is enabled so the next step is to connect to the ACC Server and enable Verbose logging.
    1. On ACC Server right-click on the Start menu and choose Run.
    2. Type in services.msc and press Enter
    3. Find AirWatch Cloud Connector and stop the service
    4. Open Windows File Explorer
    5. Enable “File name extensions” by choosing the View tab and checking the box named “File name extensions”
    6. Navigate to C:\vmware\airwatch\cloud connector\bank1\
    7. Find the file CloudConnector.exe.config
      • If you do not see the file in the bank1 folder, change to the bank2 folder
    8. For the next step Notepad.exe needs to be running as a local administrator so it has permissions to save the changes you are about to make.
    9. Open CloudConnector.exe.config using Notepad.exe and find the following line:<loggingConfiguration filePath="..\..\Logs\CloudConnector\CloudConnector.log" logFileRollSize="10240" maxArchivedFiles="20" tracingEnabled="false" level="Information" />
    10. Replace tracingEnabled=”false” with “true”
    11. Replace the word “Information” with “Verbose”
    12. Save the file and close Notepad.exe
    13. In Windows File Explorer make sure the file saved as CloudConnector.exe.config
    14. Back in the Windows Services MMC, start the AirWatch Cloud Connector service. Wait a few seconds to make sure the service starts and remains running.
    15. If the ACC service does not remain running it means there is a typo in the configuration file or the file is now saved with the wrong name. Recheck your work and correct the typo.
    16. To confirm the verbose logging changes worked, open C:\VMware\AirWatch\Logs\CloudConnector\CloudConnector.log
    17. Scroll to the bottom of the file and in the fifth column you should now start to see the word “Debug” and/or “Trace” appear.
    18. Verbose Logging is now enabled.
  7. There are 3 more changes to make on the ACC in order to enable the Domain Join:
    1. Add the account UEMDomainJoin to the local Administrators Group:
      1. Right-click on the Windows Start Menu
      2. Choose Computer Management
      3. Expand System Tools > Local Users and Groups > Groups > Administrators
      4. Click Add
      5. Type in yourdomain\UEMDomainJoin
      6. Choose Check Names
      7. Click OK
    2. Adjust the NTFS permissions for the ACC folder
      1. Open Windows File Explorer
      2. Navigate to C:\VMware\AirWatch\CloudConnector
      3. Right-click on the folder and choose Properties > Security tab,
      4. Choose Advanced
      5. Choose Change Permissions
      6. Choose Add
      7. Select a Principal:
      8. Choose UEMDomainJoin
      9. Under Basic Permissions check the box next to WRITE as indicated in the screenshot below:

        Note: Further testing with customers have shown that in some AD environments this account also needs the Modify permission. Try it without and if things fail adding Modify might be a good troubleshooting step
      10. Apply the changes and close Windows Explorer
    3. When ACC is installed, it runs as the Local System Account but the local system account does not have rights to create computer objects in AD so the ACC service must run as the user account that was created at the beginning of this blog which has been delegated access to create computer objects. In my example the account is UEMDomainJoin
      1. From the Windows Services.MSC right-click on the Airwatch Cloud Connector Service Name
      2. Choose Properties
      3. Choose the Log On tab
      4. Choose “This Account,” choose Browse, add the account UEMDomainJoin
      5. Supply the password for the account
      6. Choose OK.
      7. If everything worked the following message will popup:
  8. Start the ACC Service
  9. Open C:\VMware\AirWatch\Logs\CloudConnector\CloudConnector.log and check for any errors on launch
  10. This concludes the configuration changes necessary to the ACC for domain join operations to succeed.
  11. Launch the Workspace ONE UEM Console and navigate to Groups & Settings > All Settings > System > Enterprise Integration > Directory Services
  12. Below the Bind Authentication Type setting on this page is the Domain and Server field as seen in the photo below:

    Take a look at the value in the Domain field. The value listed here is the name that will be used by the ODJ process join the domain.

Step 3: Configure UEM Console to support Drop Ship Provisioning ONLINE

The next step is to setup the Workspace ONE UEM Console to support DSP Online by adjusting a number of settings within the Workspace ONE UEM Component Configurations.

  1. Login to VMware Workspace ONE Unified Endpoint Management Console (UEM).
    1. Navigate to Groups & Settings > All Settings > Devices & Users > Windows > Windows Desktop > Staging & Provisioning
      1. Scroll down and enable “Workspace ONE Drop Ship Provisioning”
    2. Navigate to Groups & Settings > All Settings > Devices & Users > Windows > Windows Desktop > Intelligent Hub Application
      1. Enable “Publish Workspace ONE Intelligent Hub”
      2. In the “Device Ownership Type” row make sure “Unknown or has not been set” is enabled
  2. The next step is to create a new UEM Device Tag that will be used in conjunction with a Smart Group that will ultimately link new computers to the Domain Join Configuration. To create the tag:
    1. Navigate to Groups & Settings > All Settings > Devices & Users > Advanced > Tags
    2. Choose Create Tag and give the Tag a name.
      In my example I named the tag ODJ
  3. Next create a Smart Group based on the tag
    1. Navigate to Groups & Settings > Groups > Assignment Groups
    2. Choose Add Smart Group
  4. Choose a Name that indicates this Assignment group will be used for Domain Join Operations
    1. For the Type, use Criteria and under Tags, add the Tag created in Step 9. In my example the tag is ODJ
  5. Now it’s time to configure the UEM Console Domain Join Configuration as follows:
    1. Navigate to Groups & Settings > Configurations
    2. Search for “Domain Join” and select it from the results
    3. Choose Add
      1. Name: This will be the NetBIOS name of the domain defined from the Directory Services Setting
      2. Domain Join Type: Currently limited to On-Premises Active Directory
      3. Domain Name: Pre-populated from the ACC configuration
      4. Domain Friendly Name: Pre-populated from the ACC configuration
      5. Machine Name Format: hover on the information circle to see what options you have for naming the computer. As an example I use AS%RAND:8%
  6. Pro Tip: Virtual Machines often use special characters when generating Windows serial numbers. If you define Serial Number for the machine name, and your VM has a special character in the serial number, the domain join will fail with the error that the DNS name contains invalid characters.
  7. The end result should look similar to this:
  8. Choose Save And Assign
    1. Similar to the previous dialog, complete the following:
      1. Name: pre-populated
      2. Domain Join Type: pre-populated
      3. Assignment Name: Type in a name that makes sense to you. In my example I use “Drop Ship”
      4. Organization Units: In this blog back in Step 1.6.4 you copied the DN name from ADSI of the OU where the computers will join the domain. Copy and paste it here.
        Note: In the latest edition of the UEM Console this field has been enhanced to allow searching for a common name which will then resolve to the full DN.
      5. Assignment Groups: Type in the name of the SmartGroup created in Step 10.

        The end result should look similar to this:
  9. Choose Save

Step 4 – Device Registration

In order for UEM to understand that a Windows computer is using DSP Online (and trigger the Domain Join configuration to occur) a device registration record must be created in the UEM Console. Let’s walk through that step using the manual method and then we will discuss how this is done automatically on your behalf. Remember: this step is required for POC/Testing but is done automatically in production.

  1. Launch the UEM Console and navigate to Devices > Lifecycle > Enrollment Status
    1. Choose Add > Register Device
    2. All devices must have a user assigned.
      1. Type in the name of the end user that will receive the new computer and choose Search User.
      2. When the results are displayed, under the Action Column for the user choose “Select” and UEM will populate the required User fields
    3. Scroll down to the Device section > Platform > Change the default “Any” to “Windows Desktop and then choose “Show advanced device information options”
      1. You must provide the Serial Number for the new computer
    4. Scroll down to the Messaging section and for “Message Type” choose NONE
    5. Scroll all the way back up to the top and choose the TAGS column
      1. Choose Add
      2. Select “Drop Ship Provisioning Online”
    6. Choose Save to complete the process

When purchasing DSP Online from Dell, the device registration record is created automatically by a Provisioning Service that is hosted in the cloud. If you look back at the Enrollment Status page in UEM you’ll see an option “Sync Devices” which is the manual trigger button to tell UEM to reach out to the Provisioning Service and import any devices that Dell has added. Keep in mind the sync process runs on its own schedule so you do not need to push this button, but it’s provided here for troubleshooting and testing purposes during the initial setup of this service.

In order to perform the Device Registration at the Factory Dell requires customers to complete a form on the Dell Tech Direct website when the computers are ordered which provides Dell with the customer-specific UEM tenant that will be used along with which Tag in UEM the device will be assigned to.

Now that a device registration record exists, you are ready for a Windows device to run through this process. Or are you?

Step 5 – Request files from VMware

How does a new Windows computer know to communicate with the UEM server? It doesn’t without the help of a couple of configuration files. Microsoft allows the Windows setup process to be modified through the use of an unattend.xml file and/or a *.ppkg file and VMware has created a generic unattend.xml and *.ppkg file that IS REQUIRED to be installed on the Windows device. VMware provides the files to Dell and Dell installs them on the windows computer at the factory in order to start the DSP Online process. In order to test DSP Online you need to request a copy of the unattend.xml and *.ppkg file directly from VMware as it is currently not published on any of the standard download locations.

If you work with a VMware TAM/TAS/TSM/AE/SE ask them for the two files. If you do not have one of those resources log a support ticket with VMware. I recommend writing in your request:
“I would like to test Drop Ship Provisioning ONLINE and need a copy of VMware’s generic unattend.xml and *.ppkg file to use with this process.”

What am I suppose to ignore in UEM?

At the beginning of this blog I shared that you have to know what to ignore in Workspace ONE UEM. This trips up so many people who typically start with DSP OFFLINE and want to try out ONLINE. What you need to ignore in UEM is the Windows staging files. If you have used DSP OFFLINE you are aware that UEM includes a method to generate a customer specific unattend.xml and *.ppkg file. DO NOT, I repeat… DO NOT go into the UEM console > Devices > Lifecycle > Staging > Windows > and create a PPKG and unattend.xml and expect those to work with DSP Online. They will not work. They do not work. Files created using Windows Staging are ONLY for DSP OFFLINE!

Step 6 – Configure the Windows Computer

Now that you have the generic unattend.xml and *.ppkg file how do you use them?

  1. Copy the package received from VMware to a USB key. It should have the generic unattend.xml and *.ppkg file along with the Workspace ONE Setup Assistant tool and a .bat file to trigger the whole experience.
  2. Head over to your computer where you have a freshly formatted hard drive and Install Windows 10/11 using whatever method you prefer. I love using Brook’s Peppin’s method found here
  3. When OOBE launches for the first time and asks for regional settings, reboot the device into Windows Audit Mode by pressing CTRL+SHIFT+F3
  4. When Audit-mode loads, close the Sysprep dialog box, update the devices timezone, and copy the VMware provided files to C:\temp
  5. Launch a command prompt, navigate to c:\temp and run the .bat file. This will trigger the installation of the unattend.xml and the *.ppkg file and when the process is complete the computer will power off
  6. You are not done yet. The computer is ready for the next factory provisioning step. It is NOT in a state to ship to the end user.

What happens next?

At the end of the Provisioning Process the computer has been staged, but it is NOT ready to ship to the end user. At the Dell factory, this is the point where Dell puts the computer in a box, ships it to a Dell 2nd touch facility, and then another technician completes the next set of configuration tasks. When the computer arrives at the 2nd touch facility an ethernet cable and a power cable are connected and the computer is turned on. You should do the same. Do not do this over Wifi.

The computer will now boot into Audit mode and the Workspace ONE Provisioning tool will launch. This is the point where a serial number lookup is performed against the online provisioning service to match the hardware to the UEM tenant. MDM Enrollment will be triggered and the domain join process will trigger leveraging the ACC. Next Workspace ONE UEM will download and install device profiles and applications. When the process is completed a full-screen GREEN box will appear letting you know that the process is complete.

At this point in the process the computer is enrolled in MDM and has installed all of the device specific profiles and applications that have been assigned to it in the UEM console. This is the point where the computer is now ready to be shipped to the end user. Or if you are testing this process, power off the device, then power it back on.

Ok, but did it join the domain?

This is VERY IMPORTANT! Pay attention CLOSELY!

The ACC provided the computer with a Microsoft Offline Domain Join blob file which tells the Windows setup process that the computer is part of a domain. The Domain Controller will have received a computer object for the computer. However, the device won’t sync back to the domain until the end user powers on the computer the next time. This entire process was designed with the expectation that the end user is on a corporate network in an office therefore when the computer arrives, line-of-site to a Domain Controller is present. If you just shipped the computer to someone’s house, you just broke the process because without line-of-site to a domain controller the user will never be able to login.

If you intend to ship computers to a user that is not on your corporate network you need to ensure that you have configured a pre-login VPN solution that is installed on the device via Workspace ONE UEM so that the domain join process will complete, and most importantly so that the end user will be able to authenticate against the DC the first time they turn on their computer.

I have another guide published here that details how VMware Tunnel can be used for this purpose.

If everything worked as intended you’ll end up at the Windows login screen where you will login as the END USER. This will convert the MDM enrollment from the staging account to the end user and if Post Enrollment Onboarding is configured, it will launch to educate the end user on what is left to be configured and with that you have completed the process

Author: bgarmon

Leave a Reply

Your email address will not be published. Required fields are marked *