Business Desktop Deployment 2007 is a vast improvement over previous image deployment tools that Microsoft created. Once you've built the images, you've got to get them deployed. Brien Posey shows us how it works.
Business Desktop Deployment 2007 (BDD 2007) helps speed the deployment of Windows Vista across the network. It's a vast improvement over previous image deployment tools that Microsoft created. Once you've built the images with BDD 2007, you've got to get them deployed. Here's how it works.
For the purposes of this article, I'm only going to be showing you how to deploy images that you've already created. To see how you actually create and customize images, see these articles:
- SolutionBase: Customize a Vista deployment image
- SolutionBase: Using the Deployment Workbench to install Windows Vista
Using the New Deployment Wizard
In order to deploy the builds that we have created, we will have to create a deployment point. To do so, open the BDD 2007 console and navigate to Deploy | Deployment Points. Now, right-click on the Deployment Points container, and select the New command from the resulting shortcut menu. When you do, Windows will launch the New Deployment Point Wizard, as shown in Figure A.
As you can see in Figure A, there are several different options for creating a deployment point. For the purposes of this article, we are going to use the Lab Or Single Server Deployment option. Keep in mind that the wizard also offers you the option of creating removable media-based deployments or SMS-based deployments.
Since we're planning on deploying Vista across a network, choose the Lab Or Single Server Deployment option and press Next to continue. When you do, you will see a screen prompting you to enter a name for the new deployment point. You can call this deployment point anything that you want; but, for the purposes of this article, I am going to use the default name of Lab.
Press Next and you will see the screen shown in Figure B. As you can see, this screen gives you the chance to allow users to select additional applications on upgrade. The screen is basically irrelevant because our goal is to deploy Windows Vista onto new machines. If we were using BDD 2007 to upgrade existing workstations, however, we could use this option to decide whether or not we wanted any new applications that might exist to be deployed during the upgrade.
The next screen will prompt you to specify whether or not you want for Windows to prompt you for image captures. The basic idea is that BDD 2007 can create an image based on a computer that has been configured to match your desired configuration. Since our intention is to perform bare metal restores though, you can deselect this checkbox.
Press Next and you will see a screen asking you if you want to allow the user to set the local administrative password. My personal thoughts on this are that allowing the user to set the administrative password is a really bad idea. In the previous article in this series, I showed you how you could configure your build to use a specific local administrative password, but warned that the password is stored in an XML file. While there are certainly security risks involved in storing a password in an XML file, I tend to think that it is probably better to automate the password then to require the user to enter it manually.
Press Next and you will see a similar screen asking you if you want for the user to be prompted to enter a product key. In the previous article, I showed you how you could automate the process of entering a product key. If you don't happen to have a product key that can be entered for every PC in your organization, then don't worry about it too much. I will soon be writing a separate article that is solely focused on using a key management server to deploy product keys. If you are in a hurry to get up and running though, feel free to select the Ask User For A Product Key checkbox.
The next screen you encounter will ask you to specify the name, share name, and path for the distribution point that you're creating. For the purposes of this article, I'm just going to use the default options shown in Figure C. If you look closely at Figure C, you will notice the dollar sign at the end of the share name, which signifies that the share should be hidden. This will help to prevent users from discovering the share.
Press Next and you'll be prompted to specify the user data defaults. This is another one of those screens that isn't really relevant if you are using BDD 2007 to perform a bare metal install. The basic idea behind this screen is that if the workstations on your network are currently running Windows XP, then there is a good chance that user profile data also exists on the machine. BDD 2007 needs to know what to do with the user profile data after the upgrade.
Dealing with existing user profiles can be a bit tricky, so I will be dedicating an entire article to the subject. For now though, just select the Automatically Determine the Location option, as shown in Figure D. Make sure that the Allow Data and Settings to be Stored locally When Possible checkbox is selected.
Press the Create button and the new distribution point will be created. The new distribution point will be listed in the Deployment Points folder.
Staging the Active Directory
So far in this article series, you've provided quite a bit of information that will help automate the installation process. Conspicuously absent, however, was any information related to joining an Active Directory domain.
As I'm sure you probably know, every computer that is a member of an Active Directory domain requires a computer account within that domain. When Windows is being manually installed, the Setup program gives the administrator a chance to specify which domain the computer should belong to, and to enter a set of administrative credentials. Upon doing so, Setup will create a computer account within the Active Directory.
If your goal is to perform automated Windows installations, then having each machine prompt an administrator to specify a domain and a set of authentication credentials can be disruptive, to say the least. A better approach is to pre-stage the Active Directory by creating computer accounts ahead of time.
To do so, open the Active Directory Users and Computers console. Now, navigate to Your Domain | Computers. Right-click on the Computers container and select the New | Computer commands from the resulting shortcut menus. When you do, Windows will display the New Object — Computer dialog box. Enter the desired workstation name into the Computer Name field, as shown in Figure E.
At this point, you will see the screen that's shown in Figure F. You must select the This Is A Managed Computer checkbox. Upon doing so, you will be forced to enter a GUID for the workstation before you'll be allowed to continue. This is where things get a bit tricky; most administrators think of a GUID as something that is assigned by Windows. In actuality, however, a computer's GUID is assigned at the BIOS level.
There are several different methods for finding a computer's GUID (sometimes called a UUID). With any luck, the GUID will be printed on a sticker on your computer's case. Unfortunately, there is no real standard for documenting a computer's GUID. Some manufacturers document the GUID on a sticker found inside the computer's case, and other manufacturers expose the GUID through the BIOS.
If none of those options work for you, you can use a protocol analyzer to get the machine's GUID. Simply start the packet collection process and then turn the target machine on. The machine should attempt to perform a DHCP Discover. Upon doing so, the computer will reveal its GUID through the captured packets. You can find more information about tracking down a computer's GUID at Microsoft's Web site.
Once you locate a computer's GUID, you should enter it as a 16-byte (or 128-bit) number. Figure F shows this number entered in wire format, but you can enter the GUID in display format (hyphenated), if you prefer.
Press Next and Windows will ask you which remote installation server will be used to support the client computer. Rather than specifying the name of your deployment server, simply choose the Any Available Remote Installation Server option.
Press Next and you should see a summary of the configuration options that you have chosen. Verify that the information on this screen is correct and press Finish to create the computer account. You will now need to create computer accounts for any other workstations to which you'll be deploying Windows.
Verifying share permissions
The last step in the process is to verify the permissions that have been assigned to your distribution share. The steps that I am about to show you assume that the folder is hosted on a machine that's running Windows Server 2003 or Windows XP.
Begin by right-clicking on the shared folder, and selecting the Properties command from the resulting shortcut menu. Upon doing so, Windows will display the folder's properties sheet.
At this point, go to the properties sheet's Security tab and press the Advanced button. Doing so will cause Windows to display the Advanced Security Settings properties sheet. Look at the Permissions tab. If the Allow Inheritable Permissions From The Parent To Propagate To This Object checkbox is selected, then you should clear it.
Press Add; when prompted, enter DOMAIN COMPUTERS into the Object Name to Select text box and press OK. Windows will now display the Permission Entry dialog box. Select the Apply These Permissions to Objects And/Or Containers Within This Container Only checkbox, found at the bottom of the screen, as shown in Figure G.
Select the checkbox in the Allow column for the Create Folders/Append Data permission. Press OK and repeat the process to assign identical permissions to Domain Users.
When you've finished, go back to the folder's main Permissions tab and press Add. When prompted to enter an object name, enter CREATOR OWNER and press OK. You will now see the Permissions Entry list for the folder. Make sure that the Apply Onto drop-down list is set to Subfolders And Files Only. Allow the Full Control permission and press OK. Repeat this process for any other groups that require administrative permissions.
Ready, set, go
You have now performed all necessary configurations and are ready to deploy Windows Vista to the target workstations. The deployment process involves connecting to the deployment point and then following any prompts provided by the Windows Deployment Wizard. There are two different methods that you can use to initiate the Windows Deployment Wizard.
One method is to manually connect to the deployment point's Scripts folder (\\servername\Distribution$\Scripts). After doing so, you would run the following command: CSCRIPT LITETOUCH.VBS.
The other method involves initiating the process through the Windows Deployment Service. Simply start Windows PE and execute the CSCRIPT LITETOUCH.VBS command.