Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
programming4us
Windows 7

MDT's Client Wizard : Customizing the Deployment Share

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
1/28/2015 8:40:24 PM

A deployment share is a shared folder that target machines connect to during the deployment process. From the deployment share, files that are needed for the deployment process such as scripts are copied to the target machine. We created a deployment share on a Windows 2008 R2 Server named DeploySrv, the deployment share name was MDT Lab, and it had a local path of F:\MDTLab. The shared folder name was MDTLab$, which is a hidden share name. The network path (UNC) was \\DeploySrv\MDTLab$.

We'll start by opening the properties of the deployment share. You can do that by right-clicking the deployment share and choosing Properties. You don't need to customize the installation; you could just go ahead and deploy, but every company is slightly different. Every user would have to spend 30-40 minutes the first time they fired up their new computer, but you could instead configure most settings according to your company standard, and save a lot of money.

The properties dialog box of a deployment share contains six tabs: General, Rules, Windows PE x86 Settings, Windows PE x86 Components, Windows PE x64 Settings, and Windows PE x64 Components. The General tab, shown in Figure 1, displays fields for the description, comments, network (UNC) path, and local path of the deployment share. The platforms supported by default are x86 (32-bit) and x64 (64-bit). This explains why when you updated the deployment share for the first time, a 32-bit and 64-bit custom WinPE containing the MDT scripts LiteTouchPE_x86.wim and LiteTouchPE_x64.wim were created in the F:\MDTLab\Boot folder. Along with the WIM files, ISO files were created named LiteTouchPE_x86.iso and LiteTouchPE_x64.iso (which you could easily burn to a CD that you could use to boot the target machine).

If you select x86 only as your supported platform by de-selecting the x64 check box on the properties page of the deployment share, then only the LiteTouchPE_x86.wim and LiteTouchPE_x86.iso will be created. And if you choose only x64 as a supported platform, the LiteTouchPE_x64.wim and LiteTouchPE_x64.iso alone are created.

Using the properties dialog box, you can customize WinPE by configuring the corresponding tabs. If you chose x86 as a supported platform, you use the tabs Windows PE x86 Settings and Windows PE x86 Components. The configuration parameters for the x64 WinPE are on the Windows PE x64 Settings and the Windows PE x64 Components tabs.

Figure 1. The General tab, deployment share properties

We'll get back to these tabs in just a second, but first let's look at the last setting on the General tab: "Enable multicast for this deployment share (requires Windows Server 2008 Windows Deployment Services)." By default this setting is deselected, and there is good reason for that. MDT doesn't know if you have a Windows Deployment Services (WDS) server. As you can see from the name of this setting, MDT requires a WDS server. Normally (with this setting deselected), MDT distributes images using unicast (using the SMB 2.0 protocol if using Windows Server 2008 or higher as the deployment server, otherwise SMB 1.0) packets on the network. For an image to be deployed to a target machine, the image files (usually between 2 GB and 5 GB in size) need to be sent to each computer. Now, if you deploy a small number of machines at the same time, things will most likely work nicely, but when the number of machines deployed at the same time increases, you will load up the network and your switches and routers will look like a Christmas tree.

There is one other big difference between unicast and multicast: When using multicast, the image is first copied down to the computer before being installed. The great thing about that is that if you have networking issues, this method will be more resilient. A multicast transfer will try to reconnect for a much longer period of time than a unicast session will. For example, with multicast you can unplug the cable during the multicast phase (do not try this in real deployment scenarios) and then plug it in again and the image will still be deployed; with unicast, you will most likely be forced to redeploy the machine. With multicast you will have a lower number of packets passing through switches and routers since it will be basically one stream of packets, and that will also lessen the burden on the deployment server. The problem is that MDT 2010 alone cannot provide multicasting—only WDS can. When you select "Enable multicast for this deployment share," you'll need to set up a WDS on the server that will host the deployment share. We recommend you use multicast, if possible. For now, you can leave it unchecked but when everything is working the way you want it to, please go back and check Enable Multicast and re-generate new boot images to start using multicast.

From that point forward, when you deploy an image from the MDT server the image will be handled by WDS, which can distribute it via the multicast protocol.

Before we move onto the Rules tab, let's go back to the supported platforms and look at your configuration options. The Windows PE x86 Settings and Components tabs have settings identical to those on the Windows PE x86 Settings and Components tabs. It's just that the x86 settings and components determine the settings for the x86 WinPE (LiteTouchPE_x86.wim) and the x64 settings and components determine the settings for the x64 WinPE (LiteTouchPE_x64.wim). For this reason we'll cover only the options from one set of these tabs, the Windows PE x86 Settings and Components tabs.

On the Windows PE x86 Settings tab, shown in Figure 2, in the Lite Touch Boot Image Settings pane, the Generate A Lite Touch Windows PE WIM File is selected and you can't deselect this option. It wouldn't make a lot of sense to choose to support x86 clients and then not create a LiteTouchPE_x86.wim, right? What you can change is the image description and whether or not the LiteTouchPE_x86.iso is created. If you are adding your LiteTouchPE_x86.wim file to a WDS server, there may be no need to create the LiteTouchPE_x86.iso, which would result in the update of the deployment share finishing more quickly. You can also edit the ISO filename if you have selected Generate A Lite Touch Bootable ISO Image.

In the Generic Boot Image Settings pane, you can choose to create a generic Windows PE WIM file and ISO image. Choosing the generic boot image creates a WinPE file named Generic_x86.wim or Generic_x64.wim along with the accompanying ISO files (you would find these in the F:\MDTLab\Boot folder) that do not contain the MDT scripts. The WIM and ISO files created from the Lite Touch Boot Image Settings create the WinPE image that contain the scripts needed for the MDT client wizard.

The Windows PE Customizations pane allows you to change the background bitmap that is displayed when you boot a WinPE image, add an extra directory to the WinPE image, and set your scratch space size. First let's change the default custom background bitmap file. The default background is displayed in Figure 3.

Figure 2. The Windows PE x86 Settings tab, deployment share properties

Figure 3. Default background for the MDT client wizard

In the Custom Background Bitmap File box, browse to the bitmap file you would like for your new background. The new file will be copied into the new LiteTouch_x86.wim file in the Windows\System32 folder when you select Update Deployment share (that is the process that will create the WinPE.wim files) and rename to Winpe.bmp. A new background is shown in Figure 4.

Figure 4. Custom background

Why Customize the Background

It might seem inefficient to spend time modifying the background image, but there are some real-world reasons. We have seen deployment issues regarding different boot images where the IT department updates new versions of the boot images when they put in new drivers for new models and/or change rules in boot strap.ini. Other technicians might not be aware of the fact that the boot images have been updated to reflect the new environment changes and they might still try to use the old boot images. That will almost certainly result in error messages and a blocking issue; for example, the installation will not continue. One way to avoid this issue is to update the image every time you create new boot images; that way it will be very easy to see what version they are using as boot images and if there is a problem during a deployment, you can eliminate a number of problems by just asking what version they are using to boot from and they would easily see that directly on the screen.


The Extra Directory To Add field allows you to add folders and files to LiteTouchPE_xXX .wim. At first glance you might think, "I'll just browse to a folder that contains tools I like to have handy in my WIM file and the folder will appear at the root of my WIM file (X:)." But that's not what happens. The folder itself does not get added; only the files within the folder are added to the root of the WIM file. Well, that's fine if you just have one tool to add but a bit messy if you have a few tools you'd like to keep handy in the WIM file. If you add a folder with a subfolder that contains the tools, then the second folder does get added to the WIM file. That is, if you browse to C:\Tools to add it as an extra folder, only the contents of the folder are added. But when you browse to C:\Extra\Tools (where the Tools folder contains the additional tools), the Tools folder is added to the root of the WIM file.

The Scratch Space Size box provides an area in RAM that acts as a temporary storage location for files. During the deployment process, tasks are performed that require hard disk space. There isn't any hard disk space until DiskPart.exe creates and formats a volume. Until there is hard disk space, the scratch space is used. MDT uses the scratch space for logging and configuration files. It also uses the scratch space to inject drivers when deploying Windows Vista and above. As you probably know, drivers tend to be a bit larger than 32 MB which is the default scratch space size. So on a production deployment share, you must change the scratch space to 128 MB to be able to inject some of the drivers.

The Windows PE x86 Components tab is shown in Figure 5. Here you'll find options related to driver injection, feature packs, and optional fonts to be included in LiteTouch_x86.wim.

Figure 5. The Windows PE x86 Components tab, deployment share properties

In the Driver Injection pane, you can choose a selection profile from the drop-down list. Selection profiles must be created before you can use them here. In WinPE you only need drivers to be able to access the deployment share, so follow these steps:

  1. Create two folders under Out-Of-Box Drivers using the Deployment Workbench by browsing to the Out-Of-Box Drivers folder, right-click, and select New Folder. Call one of the new folders WinPEx86 and the other WinPEx64.

  2. Browse to Advanced Configuration\Selection Profiles and create two selection profiles, one called WinPEx86 Drivers (which only includes Out-Of-Box Drivers\WinPEx86) and the other called WinPEx64 Drivers (which only includes Out-Of-Box Drivers\WinPEx64).

  3. Return to the Windows PEx86 Components tab and select the "WinPEx86 Drivers Selection" profile and then do the same for Windows PE x64 Components tab. This way, you will only include the drivers that are needed for booting WinPE. Doing so will make the WinPE image smaller, more stable, and faster to load. Otherwise, the image would include all network drivers and storage drivers you have in the Out-Of-Box Driver folder. It would also mean that regenerating the boot image would take a long time every time you added or removed a driver.

In the Feature Packs pane notice that ADO is selected by default. ADO stands for ActiveX Data Objects, which is a COM object that provides communications to data sources such as the MDT database.

The Optional Fonts options are pretty self-explanatory; the listed fonts can be added to LiteTouchPE_xXX.wim by simply putting a check mark in the accompanying box and regenerating LiteTouchPE_xXX.wim.

There is one more reason to select only the platform that you will be deploying to. If you are only going to be deploying, say, 32-bit images, you can speed things up by deselecting x64 as a supported platform. That way, when you update your deployment share only one set of WinPE WIM and ISO files is generated. Let's get back to the Rules tab now in the deployment share's properties dialog box.

The Rules tab, shown in Figure 6, displays a list of settings that determine the behavior of the MDT client wizard. The Rules tab displays the settings that are stored in the CustomSettings.ini file in MDTLab/Control. These settings are a combination of the CustomSettings.ini template found in CustomSettings.ini in C:\Program Files\Microsoft Deployment Toolkit\Templates and the answers you provided when running the New Deployment Share Wizard.

Figure 6. The Rules tab, deployment share properties

When you compare the CustomSettings.ini template with your deployment share's CustomSettings.ini displayed in the Rules tab, you can see that the template settings have been modified: SkipCapture=YES is now set to NO and the SkipAdminPassword=NO is set to YES. What do these settings mean and what can they be set to? The following list describes each setting and explains where the setting originated from and how it can change the behavior of the MDT client wizard:


[Settings]
, Priority=Default, and [Default]

The first section, [Settings], points to which section the MDT client wizard should begin reading during the deployment process. Under the [Settings] section, the Priority=Default setting points to the [Default] section heading, so this is where the MDT client wizard will begin reading the settings during the deployment process.


OSInstall=Y

This setting allows the target machine to receive an operating system. If this setting is not listed, then deployment of an OS is allowed to any target machines. If this setting is set to N, then no OS will be deployed. There are built-in task sequence (TS) templates that do not deploy OSs but that perform other functions like the Sysprep And Capture TS and the Post OS Installation TS.


SkipAppsOnUpgrade=YES

This setting is from the CustomSettings.ini template. During the deployment of an OS, the MDT client wizard presents the Select One Or More Applications To Install page, which lists applications you've added to the MDT Deployment Workbench. When technicians are performing the installation, they can select applications to be installed after the OS is installed successfully. Setting this to YES will prevent the page from being displayed. Setting it to NO presents this page during deployment. Please note that the SkipAppsOnUpgrade property applies to upgrades only and therefore is not commonly used. For normal deployments (bare-metal, refresh, or replace scenarios), the property for the Select One Or More Applications To Install page is SkipApplications=YES/NO.


SkipCapture=NO

If set to YES, this setting will tell the MDT client wizard to not ask if you would like to create a reference image (Sysprep & Capture). The reason you'd select Prepare is that for some reason you don't want the wizard to do the Sysprep step for you; instead you would like to perform that step manually.


SkipAdminPassword=YES

During the creation of the deployment share you saw the option Ask User To Set The local Administrator Password. You accepted the default setting to not ask the user to set the local administrator password, which resulted in SkipAdminPassword=YES. This setting causes the MDT client wizard to skip this page during the deployment process. If you would like this page to be displayed during deployment, set SkipAdminPassword to NO.


SkipProductKey=YES

Enterprise clients do not need to worry about entering a product key but all non-Enterprise clients will need to do so. Upon creation of the deployment share, you saw the option Ask User For A Product Key. You accepted the default to not ask the user to enter a product key, which resulted in SkipProductKey=YES. If you prefer this page to be displayed during deployment (so someone can type in a product key), SkipProductKey=NO will do just that.

At this point you may be thinking, "Okay, I understand where these settings came from and how they were modified when the deployment share was created, but what happens when you leave the settings as SkipAdminPassword=YES and SkipProductKey=YES? How does the local Administrator account get a password? And where does the product key come from?" Well, you could supply them in the Rules tab; the entries would look like this:

[Settings]
Priority=Default

[Default]
OSInstall=Y
SkipAppsOnUpgrade=YES
SkipCapture=NO
SkipAdminPassword=YES
AdminPassword=P@ssw0rd
SkipProductKey=YES
OverrideProductKey=11111-22222-33333-44444-55555

Before we move on, we'll talk a bit about the password for the local Administrator account. If you leave SkipAdminPassword=YES and you do not supply a local administrator password in the properties of the deployment share Rules tab, then whatever password you supplied in the task sequence you created will be used. You'll learn more when we get to the properties of the task sequences.

Before we leave the Rules tab, let's look at the Edit Bootstrap.ini button in the bottom-right corner. Clicking this button displays the following:

[Settings]
Priority=Default

[Default]
DeployRoot=\\DeploySrv\MDTLab$

The settings from the Bootstrap.ini file were generated just like the CustomSettings.ini file. The template Bootstrap.ini found in the C:\Program Files\Microsoft Deployment Toolkit\Templates folder was copied to the deployment share and then modified when you created your deployment share to include the network path (UNC) of your deployment share. This file is read by the MDT client wizard to locate the root of the deployment share. When you click the Edit Bootstrap.ini button, you are actually looking at the contents of your Bootstrap.ini file in F:\MDTLab\Control.

Other -----------------
 
 
25 Inspiring Game of Thrones Quotes
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
 
programming4us
Natural Miscarriage
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Game Trailer