Autopilot Hybrid Azure AD Join with Customised First Login Status


This is my flavour of deploying a customised HAADJ progress status, building on work by Joymalya Basu Roy's detailed article -
The differences in my version are:
  • Not using Active Setup to run the HAADJ retry process or Splash Screen as I found this didn't work as expected and I didn't want to add a registry item to affect all future logins with a reboot from the HAADJ process.
  • Running the processes under the context of the SYSTEM account, but displaying status to the interactive user.
  • Avoid the HAADJ process running again after the initial success.
This provides a customised first login status which prevents the user from using the devices until Hybrid Azure AD Join from the Autopilot process. It's use is primarily for when the User ESP is configured to be skipped.


This is my version of customised HAADJ which is built on work and guidance in blogs/articles from Michael Niehaus, Steve Prentice and Joymalya Basu Roy. You can use the files in the repository to create an Intune package for deployment as part of a HAADJ Autopilot Build

Things to Prep

How to Build

  • Amend the files as required
  • Run the makeapp.cmd to package files
  • Follow the instructions to in the Intune_Install_Commands.txt on how to configure the Win32 package in Intune/MEM
  • Target the package to be deployed to new device builds (note, I saw a good recommendation in Joy's blog from Tommy Nielsen saying "If you would like to exclude all the devices already deployed do the following. Go to the dynamic Autopilot group. Export members to csv. Create new group called “Autopilot devices until (enter your date)”. Import the members csv file. Then add this group to excluded on the win32 app package.)
  • Configure the app to be required during ESP in your deployment profile
How it Works
  • Deploys the package during device ESP which is essentially running the Deploy-HAADJOOBE.ps1 script which:
    • Copies the source files to the c:\ProgramData\HAADJOOBE\ directory
    • Creates a scheduled task called "Hybrid Azure AD Join Retry" which is set to run WaitForUserDeviceRegistration.ps1 (a modified version of Steve Prentice's script) which will:
      • Displays the Hybrid Azure AD Join Splash Screen by running the script Invoke-AADHybridLockOOBE.ps1 using ServiceUI.exe from MDT (credit to Joymalya Basu Roy on his script here). Using ServiceUI.exe means the process runs under the context of the SYSTEM account, but the splash screen is presented to the logged in user.
    • Keeps retrying the Automatic-Device-Join scheduled task until it's completed
    • Once successful, it deletes it's own scheduled task "Hybrid Azure AD Join Retry" so it doesn't run at every login
    • Determines the interactively logged in user and adds the toast notification to be displayed/run at their next login using the HKCU RunOnce key
    • Reboots the workstation


  1. Hi Ben, thanks for your post. Do you know if this works with the Whiteglove approach? Thanks in advance.

    1. Hi, I haven't tried, but I imagine it will work. Microsoft state the device is re-sealed before the point at which domain controller connectivity is required. From my understanding, that means the HAADJ splash screen and background HAADJ process would occur when the user first connects to the corp network and logs in with their AD credentials.

      Can you please drop a comment with how it works out for you using the pre provisioned route?

      Reference -

      "The device is resealed before the time when connectivity to a domain controller is expected, and the domain network is contacted when the device is unboxed on-prem by the end-user"


Post a Comment