New Active Directory Documents for IT Pros New Djoin.exe utility in Windows Server 2008 R2 - Active Directory Documentation Team - Site Home - TechNet Blogs

Active Directory Documentation Team

Information for IT Professionals who work with Active Directory. All blog posts are provided "AS IS" with no warranties, and confer no rights.

New Djoin.exe utility in Windows Server 2008 R2

New Djoin.exe utility in Windows Server 2008 R2

  • Comments 10
  • Likes

Windows Server 2008 R2 domain controllers include a new feature named Offline Domain Join. A new utility named Djoin.exe lets you join a computer to a domain, without contacting a domain controller while completing the domain join operation, by obtaining a blob from a Windows Server 2008 R2 domain controller at an earlier point in time. The computer is domain-joined when it first starts, so no restart is needed as with a normal domain join. The general steps for using Djoin.exe are:

  1. Run djoin /provision to create the computer account metadata. The output of this command is a .txt file that includes a base-64 encoded blob.
  2. Run djoin /requestODJ to insert the computer account metadata from the .txt file into the Windows directory of the destination computer.
  3. Start the destination computer, and the computer will be joined to the domain.

The computer where you run djoin /provision and the destination computer both need to run Windows Server 2008 R2 or Windows 7. We have a step-by-step guide published at http://technet.microsoft.com/en-us/library/dd392267(WS.10).aspx and appreciate any feedback you have.

This posting is provided "AS IS" with no warranties, and confers no rights.

Comments
  • PingBack from http://windows7live.info/?p=15000

  • The entire process for joining the domain offline seem to work flawlessly, however, once you have joined the domain and restarted you are still stuck in as much as you can't login as you have no cached credentials, and the only way to get thenm is if you have access to a domain controller to process the logon.  This requires you to be physically connected to the domain. Hence, you might as well wait until you are locally network attached to the domain and join in the normal manner.

    If I'm missing something here please let me know.

  • Hi lmundy,

    Thank you for the comment. You are not missing anything. The ODJ does not enable logon without network connectivity to a domain controller. I asked the djoin.exe developer about your comment and he replied that "to collect and apply the additional state to enable logon would require additional feature work, probably in more than just ODJ. There have been discussions on this but currently there isn’t any work planned by our team."

    So the main benefit today is to reduce the time required and streamline the process for the domain join itself, and to frontload the domain join so if there are any problems with it, they might be exposed and resolved before the new domain client is rolled out in production environment.

    We had feedback from some organizations that want to enable scenarios where they are rolling out 1000 VMs in a datacenter and they want to achieve this in an hour. In some cases the domain join itself was adding several minutes to each VM rollout, so cumulatively the domain joins could impede the high-speed, wide-scale rollout.

    I think this is one of the main scenarios that djoin.exe was initially intended to target (as opposed to enabling a broader offline working scenario). I think the intent is that the next generation of System Center products will leverage it also.  

    But it's great to see customers finding it useful for their own scenarios as well, and for their feedback about how it can be improved.

    Sincerely,

    Justin

  • Is it required that the Windows 7/2008 R2 box come online within certain days once the offline domain join is done i.e. by default within 30 days (secure channel password reset cycle duration).

  • Hi Manishju,

    Thanks for your question. The Djoin.exe developers said that the tool itself does not require the offline domain join to be completed within a specific time period. The secure channel password reset is initiated by the client machine so that will not become an issue.

    The domain controller will not expire or cleanup the account by itself.  An administrator would have to intervene, but many organizations run scripts every 30 to 60 days in order to clean up stale or unused computer accounts.

    I will add this to the topic.

    I hope that helps,

    Justin [MSFT]

    Active Directory Documentation Team

  • Appriciate your quick response. MS supporting community Rocks!!!

  • hi

    this might be a noob question but long long will this process take if had to install over a newwork ?

  • Hi

    This util would be great for us to deploy our lab images, only problem being is we have an odd DNS setup! We have a Domain DNS of domain.ad.sortdns.com and a public dns of sortdns.com, is there any way to fool the djoin util so it will insert the sortdns name as the SPN etc in the machine account?

  • Hi Jeffu,

    I forwarded your comment/question to the feature development team. They said offline domain join was tested with disjoint DNS namespaces like you describe, and the SPN reflects the domain DNS name, just as you see. One way you might get this to work is to provision with the DNS name of the domain then rename (via script) after boot to the disjoint DNS suffix.  Netlogon would then fixup the SPNs.

    hope that helps,

    Justin

  • Hi Justin, Thanks for the Blog.

    We are re-imaging Windows XP machines with a fresh Windows 7 install.  We are keeping the XP and Win 7 machines in separate OUs, meaning that somewhere in the provisioning process, the existing account would need to be moved to the Win 7 OU.  We've developed vbscripts to do this with inconsistent results.  Taking care of the domain join process on the "front-end" sounds like a promising way of assuring the process goes more smoothly.

    My hope is that we could use djoin with the /reuse and /machineOU parameters to "prep" the existing account AND relocate it to the new OU using the /machineOU parameter.  Is this scenario feasible?

    Thanks in Advance for your help!

    -Ben

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment