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

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

   October 10, 2022  Leave a Comment on How to Configure VMware Drop Ship Provisioning ONLINE to join Active Directory  Posted in Workspace ONE 0 Likes 2260 Views

Last Updated 11/22/2023

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

Step 1: Configure Active Directory to support Domain Join

The configuration starts in the Microsoft Active Directory Users and Computers MMC.

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 the ADUC MMC from your workstation or directly on a Domain Controller
  2. By default the ADUC MMC does not include the Advanced Features tab. To enable this, from the MMC Window select the View Menu and choose Advanced Features
    Advanced Features
  3. From the left hand navigation pane to yourDomainName.com > Users
  4. Right-click on Users.
  5. Choose New > User.
  6. 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
  7. 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 22.6.0.7 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 22.6.0.3 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. I recommend disabling verbose logging once you have completed your initial testing and configuration.
    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.
    Special Note: UEM ACC auto upgrades can break this configuration. See my blog for additional details by clicking here.
  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. Over the last year since this blog was initially published the steps have changed slightly. The instructions below reference UEM Console 23.6.0.6 (2306).

  1. Login to VMware Workspace ONE Unified Endpoint Management Console (UEM).
    1. Navigate to Groups & Settings > Configurations > Type in “Drop Ship Provisioning” and select the Drop Ship Provisioning link to open up the initial configuration page.
      1. Toggle the “Enable Workspace ONE Drop Ship Provisioning” to On.
    2. Navigate to Devices > Lifecycle > Drop Ship Provisioning
      1. Select “Create Tags”
        • Create a new Tag that will be used later in the process. In this example I used the name ODJ.
      2. Once the tag has been saved navigate back to Devices > Lifecycle > Drop Ship Provisioning and choose “Create Smart Groups”
        • The Smart Groups will be used to assign applications and profiles to the devices that use DSP Online. Choose “Add Smart Group” and name the Smart Group with something like “DSP Online” so you can easily identity its purpose later. The criteria used to populate the smart group can be whatever you choose, for testing purposes I initially create the group with manual device membership then select a test machine to save the group. Later on in the process I go back to the smart group and add devices to it.
        • With the Smart Group created, navigate back to Devices > Lifecycle > Drop Ship Provisioning
    1. 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. 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%
  3. 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.
  4. The end result should look similar to this:
  5. 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:
  6. 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 and assigned a UEM Tag.

If you are beta testing Drop Ship Provisioning Online via Dell, in the UEM Console navigate to Devices > Lifecycle > Drop Ship Provisioning and click the Sync button. All devices that you have ordered from Dell will be synchronized from the Provisioning Service into your UEM tenant.

As of October 2023 Dell is not offering this service, so for the rest of us we need to manually register the device. Device registration for DSP Online has been simplified by a new Wizard available by navigating to Devices > Lifecycle > Drop Ship Provisioning and clicking the “Add Device” button which brings up the following dialog box to be completed:

Step 5 – Request files from VMware

How does a new Windows computer know to communicate with the UEM server? It does not know 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? Well if Dell is doing this on your behalf you don’t do anything – they handle this for you. But if you are testing this for yourself here are the details:

  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 and is able to communicate with a Windows DC. 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