Since Windows NT4, clients who wanted to join a domain always needed a direct connection to the domain, either via VPN, dial-in or direct connection. New in Windows 2008R2 is the option for an offline domain join.. how does this work.. ? read on!

A new program is introduced called djoin.exe. We can use this to join a computer to the domain which is not directly connected. What does it do? It creates a text file that can be used by a Windows 7 or Windows 2008R2 client to join the domain.

In most cases a separate machine will be used to “deploy” new machines, so a new account must be created and delegated the rights to add computers to the domain. Change the default domain policy for this one (note that Authenticated Users by default can add computers to the domain to a maximum number of 10 (http://support.microsoft.com/kb/243327/en-us). This number is offcourse changeable by setting the ms-DS-MachineAccountQuota for the domain.

But since the number of machine accounts can exceed the number in the ms-DS-MachineAccountQuota setting, best is to allow the right to add workstations to the domain explicitly by editing the Default Domain Policy.

Computer accounts are created in the Computers OU, however we might not want the new machines to be placed in that OU. Create a new OU and delegate the permissions to the account created earlier. To provision new computers use the following command:  djoin /provision /domain /machine /savefile blob.txt

Optionally you can specify the OU with the /Machineou <OUname> else the default Computers OU is used. If the computer account object is already created, use the /reuse option. And if your domain controller is not yet 2008R2, use the /downlevel command.

The next thing we need to do is copy the created blob file to the new client and run an import command, the blob itself is not really human readable, it’s certainly not in xml format…

The command to use is: djoin /requestODJ /loadfile blob.txt /windowspath %systemroot% /localos

Now the /localOs is a bit scary if you perform this on a domain controller, make sure to only focus to the client when you issue this command. Issuing this on a domain controller will result in a broken Active Directory Domain Controller with the only option left is demote/promote.

Our client machine has a base install and is renamed to CL2 in this case before using the new command:

If you did not start your command prompt with Administrative privileges, the join will fail:

After a (manual) reboot, the computer joined the domain:

The main question if offcourse why would you want this, since the computer is not connected to the domain; users cannot logon with their account, nor make them member of any group. Since the computer is not able to connect to a domain controller it cannot retrieve SYSVOL thus no group policies.

But imagine yourself the following scenario, we have users who have been sent a laptop, they install the computers themselves and a domain controller is connected to the internet, but only allowing Kerberos traffic. Computers who have domain joined in this way, can obtain Kerberos tickets from that Internet facing domain controller. Therefore making Kerberos logons to for example Sharepoint possible. It also can help in securely deploying laptops/computers throughout the enterprise, since the joining does not require any password from the domain on the client itself!

And Microsoft’s reason:

For example, an organization might need to deploy many virtual machines in a datacenter. Offline domain join makes it possible for the virtual machines to be joined to the domain when they initially start after the installation of the operating system. No additional restart is required to complete the domain join. This can significantly reduce the overall time required for wide-scale virtual machine deployments.