In my last post, I explained how you can provision Active Directory to offline domain join a computer. Doing this for one computer is one thing; deploying a large number of computers which are already domain members when they boot up the first time is another thing.
- Poll: How reliable are ChatGPT and Bing Chat? - Tue, May 23 2023
- Pip install Boto3 - Thu, Mar 24 2022
- Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022
It is possible to offline domain join a computer in an unattended installation. For this, you have to perform the two steps I outlined in my last post, i.e., create the computer accounts in your domain and the blob that contain the meta data. Then, you can add the following section to the unattend.xml:
"Base64Encoded Blob" has to be replaced with the contents of the blob.txt. Please check out the screenshot below to get an idea what such a blob looks like.
Possible uses of offline domain join
My first thought when I've read about the offline domain feature was that this would be a great enhancement for those organizations that buy their PCs with pre-installed Windows 7. You could just send an OS image that has already been domain joined to the PC vendor. Once the new PCs connect to the corporate network, they would be ready for use without the need to join the computer to the corporate Active Directory domain.
However, since you need a different blob for every machine, the OS image alone won't do it. You have to create the blob files first, and then, the PC vendor has to make sure that each PC receives its own blob. The problem is that the blob has to be included in the unattend.xml. Thus, the procedure is a bit more complicated than automatically assigning computer names to multiple machines because you can't just number the PCs consecutively or use their MAC addresses as names.
Instead of this, you need a central store for all blob files and to make sure that each PC receives the correct unanttend.xml during deployment. Therefore, your PC vendor has to be prepared for this kind of procedure—which is very unlikely at the moment.
However, I suppose there will be third-party solutions soon to solve this problem. Of course, you could also script a solution for yourself to offline domain join newly-installed machines before you send them to your branch offices.
Smaller organizations certainly can do this manually. The advantage of offline domain join is that no admin has to be locally present when the new machine is deployed; respectively no netdom script with a clear text password is required.
Another way to make use of the offline domain join feature is to deploy virtual machines automatically. As I mentioned in my last post, you can domain join a VM that is offline by just mounting its virtual disk. This allows you to deploy a large number of VMs using scripts without the requirement of rebooting the VMs during the deployment process.
As useful as this new offline domain feature is, I would have preferred a solution without the need of a special blob for each PC. I don't see a reason why this shouldn't be technically feasible. The computer name could be added during the unattended installation. Moreover, the computer account could be created in Active Directory once the computer boots up the first time. This would make the provisioning step obsolete.
I suppose such a solution would make some major changes necessary in the way new machines are added to Active Directory. Considering that the new imaging technology that was introduced with Vista is pre-destined to allow organization to buy computers with pre-installed Windows and applications, it would have been worth the effort. However, I guess, Microsoft is not in the mood anymore for major technical changes after the Vista-bashing media campaigns.
More information about the offline domain join feature can be found at Microsoft's Technet site.
Want to write for 4sysops? We are looking for new authors.