Autopilot Hybrid Azure AD Join with Customised First Login Status
Introduction
This is my flavour of deploying a customised HAADJ progress status, building on work by Joymalya Basu Roy's detailed article - https://joymalya.com/autopilot-hybrid-azure-ad-join-reworked-with-joy/.
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.
Files
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
Files
You can download the files from here - https://github.com/benjaminjamesowens/AutopilotHAADJCustomUI
Things to Prep
- Amend the file Deploy-HAADJOOBE.ps1 to include your tenant name and tenant ID if you're planning to use controlled validation using client side registry settings intead of deploying your SCP record in Active Directory (https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-control#configure-client-side-registry-setting-for-scp). If you're not using controlled validation, comment out the lines for your tenant name and ID
- Change the PNG image for the toast notification if required by amending .\bin\toastimage.png
- Ensure you're deploying UserESP to be skipped as part of your HAADJ Autopilot setup
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
Hi Ben, thanks for your post. Do you know if this works with the Whiteglove approach? Thanks in advance.
ReplyDeleteHi, 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.
DeleteCan you please drop a comment with how it works out for you using the pre provisioned route?
Reference - https://docs.microsoft.com/en-us/mem/autopilot/pre-provision#prerequisites
"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"
Windows 10 this works perfect, for Windows 11 it installs, the "pause" screen does not load, but the device reboots, and the toast notification triggers as expected. Have you seen this? Windows 11 21H2 is on my test device
ReplyDeleteYes, I have come across the same issue, but haven't spent time looking into it yet. I'm not sure what is happening there. May be a case of outputting a log file to see and what point is failing, and also trying to trigger the pause screen to see if it functions properly on Windows 11 anyway.
DeleteI cam accross this and in my case the reason was as follows:
DeleteServiceUI.exe is looking for explorer.exe to inject into that session (i.e. the session that is hosting explorer.exe). In my case when the script runs from the TaskScheduler at user logon explorer.exe did not exist and was delayed most likely by the 1st sigin in animation that runs. I simply added retry/wait logic to the script that launches ServiceUI.exe to wait for explorer.
Interesting. So the modification resolve the issue for you. Would you mind sharing the modification you made? Thanks for your comment.
DeleteI came accross this blog and it excited me. I'm getting mixed results though on Windows 10 21 and 22H2. The issue seems to be on some of my systems MahApps.Metro.dll will not load. Is this some dependancy that's missing? I have .NET framework 4.6.2 installed:
ReplyDeleteC:\ProgramData\HAADJOOBE\bin> Add-Type -Path .\MahApps.Metro.dll
Add-Type : Could not load file or assembly
'file:///C:\ProgramData\HAADJOOBE\bin\MahApps.Metro.dll' or one of its dependencies. Operation is
not supported. (Exception from HRESULT: 0x80131515)
At line:1 char:1
Add-Type -Path .\MahApps.Metro.dll
+ CategoryInfo : NotSpecified: (:) [Add-Type], FileLoadException
+ FullyQualifiedErrorId : System.IO.FileLoadException,Microsoft.PowerShell.Commands.AddTypeCo
Interested to know more.
DeleteYou mention mixed results. Does it work on some Windows 10 21 and 22H2 but not others?
Have you had it working in any? If so, which winver?
So I have Windows [21|22] H2 [PRO|Ent] and some work fine and some throw that error. Pretty standard builds with .NET 4.6.2 on them. Can't figure out what's causing it.
DeletePS: This is great work. It's a shame MS would not take this idea and run with it and back in a cusotm OMA-URI capbilty to configure it