This question was in the context of our discussion on “Offline Domain Join” (djoin.exe). For those of you not familiar with it, Windows Server 2008 R2 and Windows 7 support the ability to join a machine to a domain, even while there is no network connectivity between the joining machine and a domain controller.
“That’s neat, Kevin. How do I do that?”
The process involves using the DJOIN.EXE command (from an elevated command prompt) two times. The first time you run it on a domain controller (or a Windows 7 or Windows Server 2008 R2 machine as a domain administrator) to create a new computer entry in Active Directory:
djoin /provision /domain <domain to be joined> /machine <name of the destination computer> /savefile blob.txt
Two things result from this:
- The computer entry is created in Active Directory, and
- A file creating domain metadata is created.
Now take that text file and use it on the machine joining the domain by running DJOIN again.. but this time with the /requestODJ parameter:
djoin /requestODJ /loadfile blob.txt /windowspath %SystemRoot% /localos
You might also be interested in using DJOIN for modifying offline virtual machines. This involves using the DJOIN command the second time to change the properties of the operating system right inside the .VHD file by mounting the .VHD file and then pointing to the WINDOWS directory path of the virtual machine’s installation:
djoin /requestODJ /loadfile blob.txt /windowspath <path to Windows directory of the offline image>
A great description of Offline Domain Join can be found HERE. And here is the Offline Domain Join (djoin.exe) Step-by-Step Guide.
So.. back to Amy’s question: Can one use DJOIN to fix that annoying problem of a computer losing its association with the domain to which it was previously joined?
I would say that, yes, it could be used for fixing that. The DJOIN command has an optional /reuse parameter which “Specifies the reuse of any existing computer account. The password for the computer account will be reset.” (from the command syntax section of the Step-by-Step Guide)
Caution: To do that would require you to keep that blob.txt file around and stored somewhere. We don’t recommend that, because you should really treat that file as if it were protected credentials. From the Step-by-Step:
The base64-encoded metadata blob that is created by the provisioning command contains very sensitive data. It should be treated just as securely as a plaintext password. The blob contains the machine account password and other information about the domain, including the domain name, the name of a domain controller, the security ID (SID) of the domain, and so on. If the blob is being transported physically or over the network, care must be taken to transport it securely.
What do you think? Does DJOIN have a place in your toolbelt? Share your experiences with it, or any questions, in the comments.
2 thoughts on “Can DJOIN fix this? (So many questions. So little time. Part 25)”
I see this alot in my environment, I think the real solution is to track down why those machines are losing their association back to the domain to begin with. For us, we have a large number of research computers, those tend to be used as DAC's and so are typically powered on, but offline for an extended period of time, so we see that issue crop up because the computer missed it's reset interval, or whatever.
I see that as well in our teaching labs, and am still puzzled by it. These are machines that are always on, and lose that association.
Do those lab machines also have a consistent view of the domain controller? Is the domain controller virtualized or refreshed in some way that might cause the clients to lose that association?