Copying, moving and replicating the MDT 2010 deployment share

During our recent Windows 7 and Office 2010 rollout we decided to set up MDT 2010 on each of our branch Windows Server 2008 servers to automate the client upgrades. We had previously been using MDT 2010 at our central site to install and commision new computers, or rebuild existing computers, but to get Windows 7 rolled out quickly we needed this functionality in each of our branch offices. Having finalised our new task sequence for Windows 7 SP1, we started looking at options for copying the deployment share from our central MDT server to the branch offices and came up with several methods.

Method 1: Simple Copy

In the first instance it is simple enough to take a copy of the deployment share to a USB drive, and then copy this on to the branch server and add then add it to the Deployment Workbench on the branch server. The only significant change you need to make using this method is to edit the DeployRoot setting in the bootstrap.ini file found in the ‘Control’ folder of your deployment share. This setting should be edited to reflect the UNC path to the distribution share on the new server.

e.g.  DeployRoot=\\NewServerName\DeploymentShare$

You can also update the deployment share properties to reflect the new path if required:

Deployment Share Properties

The only other thing you need to be careful of is any hard coded references to the UNC path of the old server deployment share that you may have in any custom scripts that you are using to install applications or make customisations.

Finally, update the deployment share by right clicking on it in the Deployment Workbench and choose ‘Update Deployment Share’.

Method 2: Using Linked Deployment Shares

Whilst the method above is a quick and dirty fix to get your existing deploment share up and running on a new server, it has several shortcomings. One of the main problems is that when you make changes to the deployment share on your central MDT server, the changes will not be updated on your branch server. You would need to manually copy your deployment share, or some of its subfolders to your branch server in order to update it.

New in MDT 2010 is the ability to create Linked Deployment Shares. This allows you to replicate your central deployment share or certain selected parts of your deployment share to other servers. You could for example set up a link which replicates the drivers folder from your central MDT server to your branch server. To set up a link to your branch server for replication you need to look in ‘Advanced Configuration’, under your deployment share in Deployment Workbench.

Deployment Share Advanced Configuration

There are a couple of areas to look out for here. Firstly, you have ‘Selection Profiles’ which define what content you are going to replicate to your branch server. There are a number of predefined selection profiles, but you can also create your own if you wish, by right clicking the ‘Selection Profiles’ container and choosing ‘New Selection Profile’. Here you can choose which content you want to add to your selection profile for replication, as shown below:

Selecting which content to add to your selection profile

Once you have your selection profile set up, or alternatively if the predefined selection profiles meet your needs, you can proceed with creating your linked deployment share. To create a new link right click on the ‘Linked Deployment Share’ container, and choose ‘New Linked Deployment Share’.

Creating a new link

As you can see on the screen shown above, you need to specify the UNC path to the target deployment share, choose a selection profile, and also decide whether you want to merge, or replace content with the target deployment share on your branch server. Click next through the wizard to finish creating the Link. Once your link is created you can replicate the chosen content to your branch server by right clicking the newly created link, and choosing ‘Replicate Now’. Replicating in this way is a manual process. If you you want to replicate automatically to a schedule, you can write a powershell script to replicate the content over the link, and set it up as a scheduled task.

You can see that it is possible to set up multiple links to branch servers to replicate content, but depending on how many branch servers you have, this will involve setting up lots of links, and scheduled tasks if you want to replicate automatically. Another disadvantage of setting up linked deployment shares in this way, is that the performance over slow WAN links is not great. Linked Deployment Shares use a mix of SMB and robocopy to sync content which can be slow if bandwidth between sites is limited, especially on the initial copy.

Method 3: DFS Replication

The final method we looked at was using DFS Replication to replicate the deployment share to branch offices. This seemed like a good idea as content would easily be kept in sync, and replication could be throttled back during business hours. Another advantage over linked deployment shares was the fact that DFS Replication is able to compress the traffic as it passes over the slow links, minimising the amount of bandwidth required to update the branch copies of the deployment share.

Reading around the subject suggested that replicating an MDT deployment share, needed to be set up as a standalone DFS root, rather than domain based. We set up a replication group in a hub and spoke topology, where the central server acted as the hub and the remote branches were the spokes. This would also be easily scalable if further branch deployment shares needed to be added in the future.

The only problem with this method is the fact that there are hard coded references to the central deployment share in the bootstrap.ini file, which need to be changed in some way to be compatible with all the branch servers. We found 2 solutions to deal with this problem.

The first was very simple and just involved making a simple change to the DeployRoot setting in the bootstrap.ini file. By changing this setting to use the variable %wdsserver% rather than the actual MDT/WDS server name the bootstrap.ini file will work with any wds server, providing the deployment share name is the same.

To use this method simply edit the bootstrap.ini file to so that the ‘DeployRoot’ setting is something like this this:

DeployRoot=\\%wdsserver%\YOUR_DEPLOYMENT_SHARE_NAME$

The second method, is much more thorough, and uses the ‘DefaultGateway’ setting in the bootstrap.ini file, which enables you to specify the wds server name and deployment share location for each site. In this method when you PXE boot the client computer that you want to commission on to the network, the default gateway it is assigned by DHCP is used to determine its physical location. It is then pointed to the correct deployment share.

An example using the ‘DefaultGateway’ method showing the bits you need to add/modify is shown below:

[Settings]
Priority=DefaultGateway, Default

[Default]
OSInstall=Y
SkipBDDWelcome=Yes

[DefaultGateway]
10.0.1.254=Branch1
10.0.2.254=Branch2
10.0.3.254=Branch3

[Branch1]
Deployroot=\\Branch1Server\DFSRoot\DeploymentShare$

[Branch2]
Deployroot=\\Branch2Server\DFSRoot\DeploymentShare$

[Branch3]
Deployroot=\\Branch3Server\DFSRoot\DeploymentShare$

So in conclusion, we opted for the use of a standalone DFS root to replicate the deployment share out to remote sites, in order to ensure that all content was always up to date at our branch sites. We then customised the bootstrap.ini file using the DefaultGateway setting, allowing us to set deployment share paths for each of our physical locations. Once the deployment share was available at the branch offices we installed MDT 2010 and the Windows Deployment Services role on each of the local servers, and then added the newly replicated deployment share in the deployment workbench on each of the local servers.

About these ads

11 Responses to Copying, moving and replicating the MDT 2010 deployment share

  1. Jeff says:

    Wonderful article! Can you share your exact “task sequence” (hide any proprietary info with genericinfo). We are attempting to do similar win 7 deployment, with:
    1) Task sequence (or portion of task sequence) that boots a workstation and does IMAGEX and grabs a copy of the XP system
    2) It then removes itself (unjoins – netdom something force, I think?) into a workgroup
    3) Then, if the initial task sequence IMAGEX copy was successful,
    4) Ideally, deploy win7 to the system.
    There are a lot of ‘cryptic’ things in task sequences and, when testing, it’s not always easy to get a task sequence to RE-run after it faiils. We have SCCM so we have to do the ‘sccm prep step’ in the task squence, but I need to see steps from someone who has done it already.

    We are not, so far, using any MDT, just basically WDS & branch DPs and PXE booting to those branch DP’s for manual installs of Win7 but, due to “corporate policy” we need to BACKUP the existing WIN7 systems as an ‘image’ (thus “imagex”) so that, if things go bad, we can lay back down the ‘image’ in a matter of less than an hour (in general), and we are back and functioning on XP. (not that we ever would “roll back” but you get the idea: ‘backup’ FIRST! Then deploy.

    Any thoughts or ideas and detailed steps of your Task Sequences would be greatly appreciated!
    Thanks.

    • oasysadmin says:

      Hi Jeff,

      Do you have to have a full image of the target system or just the user data. If not you could try the user state migration tool to copy off files and settings before the deployment process.

    • T3chn0manc3r says:

      ImageX is not meant as a backup tool. Using it as such may cause problems and is not supported by Microsoft. I would suggest using Windows Backup or similar and then instigating an MDT task sequence from within the client Windows. It might even be possible to script the backup into the task sequence so you could have a shortcut on a network drive or USB stick and launch it from the client PC, sit back and watch it all go. Rolling back using Windows Backup images is pretty easy too should that be necessary.

  2. bizie says:

    Great article.

    Just one question, although you’ve written it already, but to be sure, the “DefaultGateway” method is this applied to the bootstrap.ini or the customsettings.ini

  3. bizie says:

    Please ignore my previous post. I now have this working :-) Great Stuff

  4. Phylum says:

    I’ve got a dedicated DeploymentShare and a dedicated CaptureShare. Both, ultimately, will use the same OS’ and drivers, but not necessarily the same packages, tasks and so on. Is there a way I can add the OS’ and drivers from my DeploymentShare to the CaptureShare *without* duplicating data? Using any of the methods I’ve seen (drag & drop from one DpeloymentShare to another; linking DeploymentShares, etc.) means I’m essentially duplicating the data.

    I realize this is a bit ‘hackish’, but I was thinking of maybe leveraging hard links/junctions:
    Create DeploymentShare at \\server\DS$ (D:\DS on local server)
    Add OS’s etc
    Create CaptureShare at \\server\CS$ (D:\CS on local server)
    Delete OS & drivers folders (from D:\CS on local server)
    Create link (mklink /D D:\CS\OS D:\DS\OS && mklink /D D:\CS\Drivers D:\DS\Drivers)
    Will the CaptureShare ‘see’ the updated data when added to the DeploymentShare?

  5. rippieuk says:

    Great article, I have a few questions i would like to ask you. I used something similar to this, but not used any standalone DFS Root share. set up replication group and what I see is that when i make a change on either one of my 3 MDT 2012 servers and update the deployment share it will start injecting new drivers and everything back in to it. Do you have same problem?

    • oasysadmin says:

      Hi rippieuk, DFS only replicates the content of the share to the other servers. You will need to update the deployment share manually on each server to reflect any new changes I seem to remember. So if I understand your question correctly, I think that this is the normal behaviour.

  6. mbrownnyc says:

    I went ahead with DFS-R without doing much research, then tried to dig myself out of the hole. Not bad. Modified task sequences’ unattend.xml, and modified the root Network Path of the MDT Deployment Share in the console. This didn’t modify bootstrap.ini, but likely modified the value in the ESE DB (?). However, the clients at the site where DHCP option 66 was directing to the site server (allowing the clients to grab the boot image off TFTPd), were reading the WIM from the source site (yikes!). The reasoning must be the bootstrap.ini was not configed.

    Regardless, I’ve scrapped the receiving directories and started over and will make the change to bootstrap.ini. Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: