Windows 7 / Getting Started

Creating a Linked Deployment Share

By using several linked deployment shares, you can create a scalable deployment solution by placing these linked deployment shares in the neighborhood of the clients you are going to deploy.

Understanding Linked Deployment Shares

By using linked deployment shares, you can synchronize content from a source deployment share to a target deployment share. Using selection profiles allows you to create deployment shares servicing certain scenarios. You can, for example, create a deployment share only suitable for installing servers within your organization and place that deployment share in your server VLAN.

By using Distributed File System Replication (DFS-R), you can replicate the contents of equally configured linked deployment shares automatically. If you also replicate the contents of the MDT database, you are able to build a highly scalable deployment solution.

The target deployment share server doesn't need to have the WAIK and MDT installed. It will just host a file share containing the necessary files. WDS is needed, though, if you want this server to perform PXE boot services to its clients.

  1. On the server where you want to create the target deployment share, create a folder and share it with the share name you prefer. Also make sure that the share is accessible by the source deployment server by providing correct share and NTFS permissions.
  2. Start the Deployment Workbench and browse to Deployment Shares → <your deployment share name> → Advanced Configuration → Linked Deployment Shares.
  3. Select New Linked Deployment Share from the Actions pane on the right; the New Linked Deployment Share wizard will start.
  4. On the General page, provide the UNC path to the share you just created on the target server. You can optionally provide comments explaining the purpose of the linked deployment share you are about to create.
  5. By default, the Everything selection profile is selected, but you can modify this when necessary so that only a subset of the source deployment share is copied to the target deployment share.
  6. Specify whether you want the New Linked Deployment Share wizard to either merge or replace the selected content into the target deployment share. Click Next.
  7. On the Summary page, review the settings and click Next to create the relationship.
  8. Verify on the Confirmation page that the process completed successfully.
  9. Click Finish to end the New Linked Deployment Share wizard, and verify that the new linked replication share is listed in the workbench.

You also have the ability to save the status presented on the screen to a log file by selecting Save Output and providing a name to save the output to. Also notice that you can view the PowerShell script that was used to create the linked deployment share by selecting View Script. You can later use this script as a basis to create linked deployment shares automatically.

Using Linked Deployment Shares to Distinguish between Test and Production

Linked deployment shares in combination with selection profiles can help you distinguish between your MDT test environment and the MDT environment that you want to make available for mass deployment. If you receive a new hardware device, you can test the driver installation in your MDT test environment and later include the drivers and applications in your MDT production selection profile. You can use this selection profile to fill the linked deployment share that you use for production deployment.

Maintaining Linked Deployment Shares

Linked deployment shares can be synchronized again after you have modified the settings or content on your master deployment share. To synchronize the linked deployment share, follow these steps:

  1. Open the Deployment Workbench connected to your master deployment server and navigate to Deployment Shares. Then select the master deployment share-in this example, the MDT Deployment Share, which resides locally (D:\DeploymentShare)-and navigate to Advanced Configuration ? Linked Deployment Shares.
  2. Select the linked deployment share that you want to synchronize, and select Replicate Content from the Actions pane.
  3. The Replicate To Linked Deployment Share wizard launches and displays its progress on the Progress page.
    Just like in the previous series of steps, you also have the ability to save the status presented on the screen to a log file by selecting Save Output and providing a filename to save the output to. Also notice that you can view the PowerShell script that was used to create the linked deployment share by selecting View Script. You can later use this script as a basis to replicate linked deployment shares automatically.

Here is the view script information after updating the linked replication share, which you can execute directly in a PowerShell command prompt or save to a PowerShell script file (PS1).

Add-PSSnapIn Microsoft.BDD.PSSnapIn
New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "D:\DeploymentShare"
Update-MDTLinkedOS -path "DS001:\Linked Deployment Shares\LINKED001" -Verbose

While you could use PowerShell in combination with Task Scheduler to create a replication schedule, using DFS-R will make your deployment solution more robust.

Using DFS-R as a Replica tion Mechanism

DFS-R is the replacement for File Replication Services (FRS) and has been available within Windows Server since 2003 R2. DFS-R features a replication engine that is capable of keeping folders synchronized between servers across connections with limited bandwidth. DFS-R uses Remote Differential Compression (RDC) as a compression algorithm so that only changed file blocks are replicated instead of the entire file.

Follow these steps to set up DFS Replication on Windows Server 2008 R2:

  1. Open the DFS management node from Server Manager.
  2. Select Replication and, from the Actions pane, select New Replication Group.
  3. Make sure that Multipurpose Replication Group is selected on the Replication Group Type page and click Next.
  4. Provide a name and optionally a description for the replication group. If you have a multiple-domain environment, select the domain in which you are going to create your replication group. Click Next.
  5. On the Replication Group Members page, indicate which servers should become members of the replication group. Make sure you select your MDT server here, and at least one server to which you want to replicate your content. Click Next.
  6. If you selected only one server besides your MDT server on the Replication Group Members page, specify Full Mesh as the topology. If you selected two or more servers besides your MDT server, choose Hub And Spoke. Click Next.
  7. On the Replication Group Schedule And Bandwidth page, indicate whether you want to replicate constantly or only during specified hours. You can also specify how much bandwidth should be used for replication, ranging from 16 Kbps to 256 Mbps, or you can choose the Full Bandwidth setting. If you plan to replicate on specified days and times, you can create a detailed schedule that specifies when you want to replicate using what bandwidth. Click Next when finished.
  8. On the Primary Member page, select your MDT server, which contains the source of the to-be replicated content. Click Next.
  9. On the Folders To Replicate page, click Add to add the folders that you want to synchronize. On the Add Folder To Replicate page, select the D:\DeploymentShare folder. Select the option Use Custom Name to provide a custom name for that folder. Or you can choose the Use Name Based On Path option if you want to use the name of the folder which you want to use. To modify the NTFS permissions, click Permissions. To replicate the boot images as well, add the \RemoteInstall\Boot folder. Click Next.
  10. On the Local Path Of Deployment Share Or Other Members page, specify the local path on the receiving server where the content you just selected should be replicated to. Choose another name for the folder so that you can distinguish between the source and the destination. You have to provide the local path separately on every destination server in order to enable the membership. Click Next.
  11. On the Review Settings And Create Replication Group page, check over the settings displayed and click Create to create the new replication group.
  12. Click Close on the Confirmation page to finish the wizard. The replication group you just created should now appear under the Replication icon in the DFS management node.

Removing Hard References to the Deployment Share

When using DFS-R as a replication mechanism, there is one challenge that you need to address. Because the exact content of the master deployment share is replicated, you must use a variable instead of a hard reference to the WDS server. This variable will be used in the CustomSettings.ini file. The WDS server you are using when booting an MDT-generated boot image will be available in the %WDSServer% variable. You should therefore change the DeployRoot value in your Bootstrap.ini file to %WDSServer%. Also check if you made any references in your CustomSettings.ini that you want to replace with this %WDSServer% variable. Make sure that you update your deployment share so that these changes are integrated into the boot image and replicated to the DFS-R receiving members.

Because refresh and replace scenarios do not leverage the WDS server, the %WDSServer% variable will not work. When you need to support these scenarios as well, you should use the DefaultGateway definition in your bootstrap.ini. An example is provided in Listing below, where for each gateway another deployment server is defined.

Sample bootstrap.ini using the DefaultGateway variable to determine the MDT server


When you don't use WDS as a mechanism to boot your MDT boot images, you can still have multiple replicated MDT shares. In this scenario you should not provide a DeployRoot property in your bootstrap.ini. Having no DeployRoot property in your bootstrap.ini will be detected by the MDT scripts which will prompt the user to provide the details for the server to connect to. You can also use a LocationServer.xml file, which you should include as an extra file in your boot image (which will be included during boot image creation, ending up in the \Deploy\ Control folder). This XML file specifies the available MDT shares within your organization. MDT will then provide the user with a selection screen.

Adding Extra Files to Your Boot Image

You can add extra files and folders to your boot image by specifying a custom folder to include when boot image creation takes place. You can specify this folder for the x86 and x64 Windows PE images when you request the properties of the deployment share. On the Windows PE x86 Settings or the Windows PE x64 Settings tab, you will find the Extra Directory To Add option in the Windows PE Customizations section. Point this setting to a folder that contains a structure that will be applied to the root of the Windows PE image. If you want to have files added to the Control folder as mentioned earlier, you should create the \Deploy\Control folder structure in your directory which you provide at the "to add folder" option.

The following example shows a LocationServer.xml configuration where you can choose between booting from the deployment share in NewYork HQ or in Amersfoort. The weight value determines how often the server is used compared to the total use, or weight, specified. In this case, the SRV-MDT1 server is selected two out of six times and the SRV-MDT2 server is selected four out of six times.

<?xml version="1.0" encoding="utf-8" ?>
     New York HQ, the America
    <Server weight="2">\\SRV-MDT1\DeploymentShare$</Server>
    <Server weight="4">\\SRV-MDT2\DeploymentShare$</Server>
     Amersfoort, the America

Securing Linked Deployment Shares

You can connect to a deployment share in one of two ways. The first method is to specify a user ID, password, and domain in the bootstrap.ini file. These credentials are then used in Windows PE to make a connection to the deployment share and from that point a deployment can be started. Keep in mind that if you use this method, you should use an account with least privilege rights. Also keep in mind that when using MDT in a refresh scenario, the contents of bootstrap.ini are sent over the network in clear text, making it easy for someone with a network sniffer to record the settings in that file. When you are using an MDT database, you should also give the specified account the db_datareader rights within that database.

The second option is to not specify these settings in the bootstrap.ini file and allow the MDT wizard to prompt the user who booted into Windows PE for a username and password. Based on the NTFS and Share Security settings that you specified on the deployment share, access is granted to the user who wants to perform the installation.

[Contents] [Next]