Non-Entra ID joined deployment best practices?

I’m curious how other MSPs are handling their computer deployments for non-EntraID joined computers.
In the Autopilot/Intune world, we can just Autopilot the computer, have Intune deploy ImmyBot, and let ImmyBot take it from there.

However, in the legacy (i.e. ActiveDirectory) world, we don’t have as many Zero-Touch possibilities for computer deployments.

If you utilize the provisioning package installer it’s fairly easy for those deployments. You just need to give your client, or an onsite tech, a USB with the provisioning package and have them plug it in while a new device is in the Out-of-box-experience. Provisioning packages are a Microsoft technology and are built to be used here (in most cases). The OOBE will detect the ppkg automatically and begin setup and the install of the ImmyBot agent, meaning the only thing they had to do was unbox the device, power it on, and plug in the USB. That’s it.

Thanks, @Dakota_Lewis .
I know that’s a possibility (that’s better than nothing), but still involves the manual touch involvement.

My initial thought was to work with our computer vendor/distributors and have them put the ImmyBot agent PPKG as part of the image.

That will work great for new computers, but for reimaging computers, it’s hard to match the convenience of an Autopilot reset.

@David_Stephenson So in that case, yes, use dism to inject the ppkg into an iso and work with your vendors to get new devices sent out with Immy preinstalled. After which, you can add an Immy ppkg into the C:\Recovery\Customizations directory. This directory will automatically deploy ppkg when someone does a standard windows reset. This what you looking for?

1 Like

Ahh. So if we use Immy to drop the immy agent into that directory, We could, in theory, get a psuedo AutoPilot reset functionality.


I think the only other missing piece is the Domain Join functionality.
With Autopiot, it can do the Entra Join (or hybrid join :face_vomiting:) as part of the setup process.

For zero-touch to work in a legacy AD world, we either need line of site or an on-demand VPN that Immy could trigger/connect (similar to the Azure always-on VPN).
I’m struggling thinking of a way around that. There may not be one.

For now though, if we do those two things (have the vendor put our Immy Agent package as part of the image and have Immy deploy the immy agent to C:\Recovery.…), we should be able to drop-ship computers to the client’s office and have anyone plug them in and turn them on. Then, once the setup is finished, we can have the client (or worse case send a tech) go on-site to swap the computer with their current (or new) computer.

Unless someone has another option (I’m hoping there are other options out there :crossed_fingers:), that may be the closest we can get to “Zero Touch Deployment” for legacy AD environments.

I mean, Immy does offline domain joins by running djoin on the dc and copying the blob file over to the client to join it. But if you’re talking about being able to have it update group policies right away as well, then you would definitely need a vpn or line-of-sight access to the DC

1 Like

I appreciate the help.

1 Like