New Active Directory Documents for IT Pros
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:
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.
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.
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.
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).
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,
Active Directory Documentation Team
Appriciate your quick response. MS supporting community Rocks!!!
this might be a noob question but long long will this process take if had to install over a newwork ?
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?
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,
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!
I thought this djoin had a real world purpose for me, as I wanted to create a mechanism where staff in rural parts of the world could re-connect to a corporate domain without having to travel 8+ hours to get into an office (so that they would pass our VPN authentication
checks), I am now stuck where the rest of the people in this thread seem to be, where you get 99% of the way through just to get "no logon servers available" when trying to connect whilst off the network. Is there any extra switch that could be used to get
around this, or any future plans to make this tool so much more powerful?
You are correct that the offline domain-join process _by itself_ does nothing to either setup or ensure network connectivity to your corporate domain's domain controllers. The good news is that djoin.exe was extended to work in conjunction with Microsoft Direct
Access; this makes it possible to automatically install the minimal set of group policies and certificates necessary to bootstrap not only the domain-join state, but the network connectivity to a DA server. Once the machine is bootstrapped, normal Group Policy
behaviors and DA procedures take over.
Please see https://technet.microsoft.com/en-us/library/jj574150.aspx for more info.
Additionally: a bing search on "djoin.exe direct access" should yield several reports of this scenario working for actual customers.
I hope this helps,
Thanks for the quick and valuable response Jay,
I will look into this, it sounds like it could be exactly what I am after.