MDT 2010 New Feature #5: Support for multiple deployment shares

  • Articolo

With MDT 2008, you could have one distribution share, which corresponded to a lab deployment point.  You could then have additional network deployment points and media deployment points, with each of these receiving a subset of what was on the main lab deployment point.

With MDT 2010, we’ve changed terminology somewhat.  Now, instead of distribution shares and deployment points we just have deployment shares.  And there’s no real differentiation between “lab” and “network” – a deployment share is a deployment share.  You can have as many of those as you want, and you can choose to replicate all content between them or keep them independent.  Each deployment share can be on the local machine or on a different server (accessed via the UNC path); we even support standalone DFS roots.

So let’s talk about a few different scenarios that you might want to consider.

Scenario #1: Simple but reliable

You want to have a single deployment share on a highly-available file server cluster with SAN-attached storage, but you don’t want to install MDT on that server.  That wasn’t possible with MDT 2008, but it’s simple with MDT 2010.  You can install MDT on your workstation (or any other machine) and use it to manage the contents of a deployment share on the file server cluster via the UNC path that you created.

Scenario #2: Private and public

You have a lab environment where you create your reference images.  You import those images into Deployment Workbench and create new task sequences to deploy those.  But you don’t want your end users to ever deploy the reference image task sequences, just the ones that deploy the reference images.  With MDT 2008, you could have done that using a lab deployment point and a network deployment point.

With MDT 2010, you would create two deployment shares, for example \\SERVER1\Lab and \\SERVER1\Production.  You can then replicate only the items you want from lab to production.  This is done using “linked deployment shares”, a new feature that allows you to specify the target deployment share (e.g. \\SERVER1\Production) and the content that should be replicated to it.  Or, you could do this manually as Deployment Workbench could have both deployment shares open at the same time, enabling you to manually copy the needed items from one share to the other.

Scenario #3: Server and desktop

You might have two different teams, one which works on server OSes, images and task sequences, and the other that works on desktop OSes, images, and task sequences.  You can create two deployment shares to support that, and even selectively copy content (e.g. a subset of drivers or applications) between them.

Scenario #4: Cooperative deployment shares

Some companies do not have a completely centralized IT group.  They may have a central team that creates reference images and packages applications, but regional IT groups are responsible for the actual deployment, including figuring out what drivers are needed for the hardware used at that location.  With MDT 2010, you can have a central deployment share, then selectively replicate content to regional deployment shares, e.g. all images and applications, without disturbing the rest of the deployment share content.  The IT administrators at the regional sites can maintain their own task sequences, drivers, etc.

Comments

  • Anonymous
    January 08, 2013
    I wanted to replicate my deployment to other sites, including applications, task sequences custom settings, etc.  I just want them to replace the deploymentroot wherever needed to the correct one. Instead it only copies most files but leaves others untouched even when using "replace" not merge.   Is there a way to replicate everything down except the daployment share path or should I just use robocopy and then use powershell to find all the configuration files and replace it with the server name?