IT administrators at some point in time have been stumped with the challenge of building machines over a "Direct Access" connection. Many enterprises manage their IT environment with Direct Access and have been looking for a scalable and flexible solution to address this problem.
Sumeeth Evans, VP IT, Pedcor Companies, collaborated with 1E to develop a solution that met his very challenging requirements. Sumeeth and Apurv Gupta (Senior Consultant, 1E) describe their solution and approach to the problem below.
Pedcor consists of 77 remote sites with three to five machines per location. None of these remote sites have connectivity back to ConfigMgr or DCs. Computers in these remote sites are setup on their own DA (Direct Access) connection back to the corporate infrastructure. Each site is setup with public ISPs like ATT DSL., UVERSE, COMCAST etc. to name a few.
1) Poor Bandwidth: Most sites have very poor connectivity (3-5 MB connection links to the internet). Ever tried streaming an 8-10 GB image down to each machine over the WAN without impacting the network?
2) Domain Join: How does one join machines to the domain after they are built? Remote sites have no corporate connectivity.
3) Zero-Touch-Deployments: It is extremely cost prohibitive to send technicians to these remote sites to build or rebuild machines. There was a critical business requirement to provide the ability to re-image machines (including user-data backup and restore) and deploy applications in a completely zero-touch manner.
Sumeeth and Apurv, started working on a design that needed to address all of the challenges above, as well as ensure that it would be easily maintainable and extensible.
Solution to the first problem was the easiest to arrive at: 1E's Nomad! Sumeeth and Apurv went ahead and deployed Nomad in the corporate location and all of the remote sites. Nomad, with its dynamic bandwidth throttling and peer-to-peer distribution capabilities, immediately addressed the low bandwidth issue. Nomad enabled Pedcor to pre-stage all of the required content prior to reimaging the machines.
The second issue turned out to be little more complicated than anticipated. Very quickly, Sumeeth and Apurv realized that they could not reuse or leverage an existing solution, as none existed.
A design assumption was made that if a VPN connection could be established prior to the machines attempting to join the Domain (defined step in the task sequence), they would have been able to achieve their goal. However, after multiple tests they realized that even though VPN settings were available, Windows would not allow the RASDIAL component to run, thus preventing the VPN connection from getting established.
Sumeeth and Apurv then attempted to enable ODJ (offline domain join), a new concept introduced with Windows Server 2008 R2. This approach required that a blob file be created first against a domain controller, followed by importing the blob file into the target machine, in effect making the machine a domain-joined machine. With Windows Server 2012, Microsoft enhanced this functionality to include target group policies and CAs as well. This made it easier to implement the ODJ approach as Pedcor had a Windows Server 2012 Domain Controller deployed in house. After some exhaustive testing, the stability of this approach was proven.
However, a tricky situation needed to be addressed. Execution of the step to create the blob file for the machine that is undergoing a rebuild and importing the blob back (to the machine for the offline domain join process to run).
To address this challenging scenario, Sumeeth and Apurv then added an FTP server and custom scripts at appropriate steps in the Task Sequence to automate the process of creation and importing of the blob file.
1) An FTP location was created with two folders, "Incoming" and "Outgoing" prior to start of the reimaging process.
2) A vbscript was built to create a text file whose filename was the name of machine and copy it to the "Incoming" FTP folder.
3) A VB service was created to monitor the "Incoming" folder. This service was designed to run either on the domain controller or on a client machine (for security purposes) logged on with the domain credentials. When the text file is dropped in the "Incoming" folder, the service executes: Djoin /provision /domain <your domain name> /machine <remote machine name> /policynames DA Client GPO name /rootcacerts /savefile c:\files\provision.txt /reuse command and saves the blob file to the "Outgoing" folder on the FTP location (and deletes the file from the "Incoming" folder).
4) At this point, the vbscript waits (during the Task sequence execution) for the blob file in the "Outgoing" folder with the machine name on which it is running. Once found, the file is copied to the SMSTS folder.
5) The machine is then booted into WinPE and the imaging process on the machine starts.
6) An additional command line task sequence step after the machine is imaged with the following command: Djoin /requestodj /loadfile C:\provision\provision.txt /windowspath %windir% /localos.
7) The step to reboot the client computer is executed. Immediately after the reboot step, the client will be joined to the domain and have connectivity to the corporate network through DirectAccess.
8) The Task sequence then proceeds with deployment of applications, packages and restoring USMT data on the machine.