LockDown Diary – How I used DJOIN to Build Test Machines over VPN

It’s been a few months since I’ve sat down to put write something. I’ve been taking a break trying to pick up some woodworking skills and spend a bit more time with the family during this COVID-19 lockdown. On March 5, I left work to take a week off for Spring Break and never returned to the office. Today is May 5. I wasn’t prepared for being at home and since I don’t regularly work from home, I don’t have any hardware here other than a normal desk setup. At the office, we have a build lab and I have access to numerous hardware models that I can test with. At home, I just have my company-issued laptop and a VPN connection, which is generally fine for the few days per month that I’m actually working from home. We have a VMWare build farm as well where I generally do most of my image builds and testing unless I need to test drivers or other device specific things. One thing that our VMWare farm doesn’t have is direct internet access - we only have a business network VLAN, which makes it impossible to test VPN-related things (split-tunneling, Cloud Management Gateway, internet-only clients, etc.).

More on Split-Tunneling and Microsoft Updates from ConfigMgr here from @RobDotYork and @MikeTerrill

The Problem

So here I am, stuck at home, with a mandate from management to get split-tunneling working to reduce VPN bandwidth for Microsoft Updates, with no way to test other than my primary device - which is never fun to do. So I started thinking. I had just spun up Hyper-V to build a new ConfigMgr lab for some Intune testing so I decided to see if I could somehow use build a new VM to our standards that I could test VPN on. The semi-obvious answer would be to use AutoPilot, except I would need line-of-sight to the domain controller for hybrid-join to work and we are just beginning to get Intune configured in production (see note about lab build above…).

Our VPN client requires user domain credentials and a valid computer certificate issued from our CA in order to connect. The domain credentials are easy, the client certificate, not so much. So I started playing around with DJOIN and had a breakthrough. I’ve never needed to use DJOIN so this was a cool learning experience for me. So if you want to see what I was able to do, keep reading.

The Plan

Here are the steps I’ll be going through:

  • Use DJOIN on Domain Joined device to create offline join blob
  • Use DJOIN to ‘install’ the offline blob on a new clean VM
  • Install the company VPN client
  • Install the ConfigMgr client
  • Run our standard OSD Task Sequence in Apps-Only mode to standardize the VM



If you’ve ever looked at logs during OSD, you’ve likely seen references to DJOIN - that’s pretty much where my experience with DJOIN ends.

SetupAct.Log from the Panther folder
SetupAct.Log from the Panther folder

As I started playing with it I discovered that it is a very powerful tool capable of not only creating an offline domain joined object, but you can specify the OU, certificate template and more. It was like finding a Swiss Army Knife while on a desert island. You can read more about DJOIN here https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/ff793312(v=ws.11)

NOTE: DJOIN /PROVISION must be run from a domain joined device connected to the domain (over VPN works) since it has to talk to AD to create the new device.

You can look up the parameter info on the link above, but essentially this command line will do the following:

  • /PROVISION /DOMAIN - Join the domain
  • /MACHINE - Specify the device name
  • /MACHINEOU - Put the device in a specific OU,
  • /SAVEFILE - Save to a file
  • /CERTTEMPLATE - Generate a computer auth cert using our domain computer template
  • /REUSE - Reuse the device name if it exists
DJOIN /PROVISION /DOMAIN "asd.net" /MACHINE "ASD-MyVM1" /MACHINEOU "CN=Computers,DC=asd,DC=net" /SAVEFILE "C:\Temp\ASD-MyVM1_ODJ.txt" /CERTTEMPLATE "ASD-DomainComputerTemplate" /REUSE

A Square Dozen Image

Once you run this command, you can check Active Directory and you should see your new computer in the OU that you specified and you’ll have a text file in the /SAVEFILE location.

NOTE: During this process I discovered that you can rename a computer AND get a new domain computer cert using DJOIN. In the past, if we renamed a computer, Cisco ISE would block the device since it didn’t have a valid computer auth cert. This would be an easy way to deal with that.


STOP! Ensure that you have a local Admin account on the target device at this stage. If you don’t, you won’t be able to use admin rights after this step. Also, you could choose to install your VPN client before this step, but I’m doing it afterwards. Doesn’t make a huge difference.

As mentioned, you’ll need a new, clean device. I used Hyper-V but this will work with a VM or physical device. You can do this by using DISM to mount a WIM and running the commands (exclude /LOCALOS) or spin up the device the run the command from the new device (Include /LOCALOS). Simply copy your Offline Domain Join (ODJ) text file to the new device and run the following:

  • /REQUESTODJ - Tells the device to request an offline domain join on the next restart
  • /LOADFILE - specifies the ODJ blob file that you generated with /PROVISION
  • /WINDOWSPATH - the path to Windows for an offline image or if used with /LOCALOS the windows directory of the device you are running the command on.
  • /LOCALOS - targets the local OS


A Square Dozen Image

Once you run the command, reboot the device and you’ll be prompted to log in with your domain credentials. Since you won’t be on the domain yet, log back in with your local admin credentials.

To verify that this all worked, you can check Computer Management to see that you’re on the domain and check your Local Computer personal certificate store and see that you have a domain CA cert issued to the device name that you specified and the root and intermediate certs should be there as well.

A Square Dozen Image
A Square Dozen Image


This is the part that may be a show stopper for you, depending on the type of VPN you use and the auth requirements for it. I got lucky with the device cert and user domain creds. At this point, you simply want to install your company VPN client and configure it properly. Since everyone will have something different, I’m not going to go into details.

In my case, once the client was installed from an MSI, I was able to connect to the VPN portal and sign in with my domain credentials, using the device certificate in the background as well. Once I establish the tunnel successfully the first time, the VPN client is ready to go. I can reboot the machine, then log in with my domain credentials and I’m on!

That’s pretty much it

From here, what you do is up to you. You should have a computer that’s domain joined and on VPN. For me, I wanted to test using a device that matched our standard build. If you don’t need to do this, then you can pretty much stop here.

Standardizing the Image

If you want to complete your build, you will need to manually install the ConfigMgr client using the command lines appropriate to your site. From a domain connected device, copy the client installation media to the new device. Once installed, drop the machine into a collection that has your ‘Apps-Only’ Task Sequence (keep reading) advertised to it and run it once it shows up. If you’ve read any of my Task Sequence blogs, you may have come across my ‘Building a Smarter Task Sequence’ post. In it, I detail how to build a OS Deployment Task Sequence that is able to be re-run on failed devices without reinstalling the whole OS. You may also be able to just break out everything after the Setup Windows and ConfigMgr step in your Task Sequence and create a new ‘Apps-Only’ sequence that will finish installing all of the bits that make up your company’s standard build. This would be equivalent the Task Sequence you’d want to build if you use the new PROVISIONTS commandline option in ConfigMgr 2002 to auto launch a Task Sequence right after the ConfigMgr client is installed via AutoPilot. Ultimately, if you have Windows on the box, everything else SHOULD just be apps and policies. Now, if you are offline servicing and doing a bunch of tweaking to your image or even using a reference image, you may not end up quite standard. We don’t do any of that, so this process is perfect. I just need to install a few standard apps and add a registry key to tag this as a standard build and my device should match anything we’ve built from bare metal.

NOTE: My Task Sequence reboots several times. Each time, I had to log back in to reconnect VPN or else it would fail. Something may not be configured properly with the machine channel of our VPN client because this was unexpected behavior.

Give It A Spin

Once you’ve built your new machine, you should have a device that looks like any other standard device. I was able to spin up several Hyper-V VMs using this process and successfully tested several VPN scenarios to validate our split-tunnel configuration, which made all of the effort worth it. I’m sure there is more to learn about DJOIN but this is what I’ve learned so far. Hope you find some inspiration in this.


I’ve been saying this to anyone who will listen for the past few years and I have been fighting to make this a reality in my production environment as well - the less you bake into your image and the less you customize your builds, the easier it will be to move to AutoPilot or an Apps-Only TS model that allows you to take advantage of the OS already being on the box. There are MANY reasons why this is an unattainable goal for many orgs, but you I challenge you to keep chipping away at your customizations to deliver a vanilla image that could easily be replicated by installing some apps and applying some policies. It’s a worthwhile endeavor and I’m very glad that we are on a journey to zero (or as close as we can get to zero) customizations.