Here are some general guidelines on how to use ConfigMgr 2007 OSD Standalone Media to deploy/upgrade a new OS on remote worker's systems without a help desk call. You will have to identify if your environment (security, remote access, etc.) has the flexibility that is required. Then tailor the steps below to work within your environment.

The objective is to modify your existing task sequence to include the capability for standalone media deployment for remote workers. Please don't create another task sequence just for standalone media.

For this discussion, it is assumed that you have a working Standalone Media build which is completely successful when connected to your corporate network, but fails to join the domain when built offline.

General Overview

Modify your task sequence to:
  1. Identify a remote build scenario
  2. Configure the system for remote build.
  3. Deploy a toolkit to assist the user with establishing a remote connection, domain join, and other tasks.
Create a Toolkit to:
  1. Address any security requirements for remote connectivity (AV updates, etc.)
  2. Establish a remote connection to your network.
  3. Join the system to your domain.
  4. Establish cached credentials or allow for a remote connected first logon.

Task Sequence Modification Details

ConfigMgr OSD is designed to work in a dynamic environment, so there is little need for setting static variables when using Standalone Media. Instead, query WMI for what you are looking for. So let's go for the dynamic approach.

1. At the end of your task sequence create a new group and call it "Remote Build".
2. On the Options tab, create a "None" If Statement. (see screenshot below)
3. Add a WMI query for domain presence similar to "select * from win32_computersystem where domain = "yourdomain"" (without outer quotes) or if you join systems to multiple subdomains "select * from win32_computersystem where domain like "%yourrootdomain"" (without outer quotes)
4. You will add remote build specific steps to this group like a toolkit deployment step, auto-logon configuration step, etc.

The end result is a dynamic task sequence group that will only execute when the normal domain join step in the task sequence failed.

WMI Query for remote build

Remote Toolkit General Tips

Here's some tips to keep in mind while you build your toolkit.
1. Use whatever platform that you are comfortable with (SMS Installer, VBScript, etc.) as you will have to make many update during the trial and error phase.
2. A "user driven" approach (i.e. lots of dialog boxes) works well and is easier to talk a remote user through over the phone. Said another way...
3. Avoid hidden scripts or silent installs as the remote user is your troubleshooting tech when things go wrong.
4. As best as possible, make the toolkit dynamic and robust by using state validation, error checking, and logging.
5. Make the toolkit easily accessible via a desktop shortcut.

Remote Toolkit User Scenario

Hypothetically speaking...At this point your user has a built system which is in a workgroup. The remote user is either auto-logged in as the administrator or you created a local account with admin rights for them to use to complete the remote domain join. Now they see a shortcut on their desktop to the toolkit and they double-click it and...

1. They are instructed on what to expect from this process. Next.
2. There is a check for prerequisites and they are instructed on which prerequisites need to be corrected. (we'll use an AV update) Next.
3. They are notified that the AV update will now run. Next.
4. After the AV update is complete they are instructed that the prerequisites are complete. Next.
5. They are instructed to initiate a remote connection. Next.
6. Remote Connection/VPN is launched and remote connection is established.
7. User is instructed that a domain join is about to be attempted. Next.
8. Domain Join is successful!
9. User is instructed to reboot and logon with Remote Connection/VPN.
10. Remote Build is Complete!

Remote Toolkit Development Scenario

The challenging part of the above User scenario is getting all of the pieces together to work that way. I can't give specifics on each of the steps, but lets look at a few of them and discuss the challenges.

1. Prerequisites could be:
  • AV updates
  • NAP config
  • User input (computer name, etc.)
  • Certificates for remote connections
  • ??
2. Remote Connection/VPN connections will have to be discussed with the team that owns your VPN. Engage them early so that they can own their part of the process. Give them the big picture/end result and let them help find the solution.

3. If you get to this step, then it's all downhill from here. Domain join can be accomplished a number of ways. The old netdom.exe still works and may be needed if you plan to deploy XP or Vista and don't have Powershell.
(usage: netdom.exe JOIN <computername> /D:<domain> /UD:accountthatcanjoindomain /PD:<password>)
Powershell is the obvious choice if you plan to only deploy Windows 7. Use the add-computer cmdlet.

4.Creating a cached profile. The easiest way is to connect to your VPN prior to logon using the Network Logon function in Windows 7 or equivalent interface that your VPN client provides at logon. If that is not available, you may have to attempt to cache the profile prior to rebooting.