Linked Deployment Shares in MDT 2010/2012/2013

MDT versions from 2010 to 2013 have an option under Advanced Configuration called "Linked Deployment Shares" that I'd like to touch on for just a moment, and also an issue all these versions seem to have. Basically, creating a Linked Deployment Share allows you to copy the Deployment Share to one or more other locations. One of the benefits of this is that you can install the MDT on a technician machine instead of a server so that all the testing can be done on the tech machine. The benefit this provides is that you can test your MDT deployment in a controlled environment before pushing everything to the server. That way, you can keep your server deployment share as your production and your tech machine deployment share as your test bed. Anytime you need to make a change, do it on the tech machine, then use the ISO in the Boot folder, or create a full ISO will all the info on it, then load it on a test machine and see how it works. If all is fine, copy it to the Linked Deployment Share and use that share on the server in WDS.

Creating a Linked Deployment Share is a relatively straightforward and easy process. All you need to do is expand the Advanced Configuration Option, then right click on Linked Deployment Share and select “New Linked Deployment Share”. The dialog box pops up and asks for the UNC path. Type in the path you want to use. This can be a folder on another workstation, or a folder on a server. The important part to remember is that you must have modification rights to the folder you are using as the share so that you can update it. You can add comments about the share in the box below that, and then you have two options: “Merge…” or “Replace…”. The Merge option allows you to only copy the files that have been updated instead of the whole deployment share. The Replace option completely replaces all of the files, which con take a considerable amount of time. I use the Merge option unless something isn’t updating properly, then I use the Replace option. These options can be modified by right-clicking the linked share after it’s been created and selecting “Properties”. Then just click next until the folder is created.

This step only creates the Linked Share, but does not copy the information over. In order to copy all the data from the local deployment share to the linked deployment share, you must right-click on the name of the linked deployment share and select “Replicate Content”.

There is also an additional option when you create your linked deployment share that I didn’t mention above: Selection Profile. This allows you to copy the content based on criteria you set up, or copy everything. This gives you more control as you only have to push out the information you need. For example, say your company has two offices. One office requires a certain list of applications, the office needs a different list of applications. You create your local deployment share with all of the applications in it, but create Selection Profiles for each company. You can create a Linked Deployment Share to a server in each office, and select the correct Selection Profiles for the Linked Deployment Share and only that information will be sent to each share. Each office location then only gets the applications it needs.

This is only one example. You could have selection profiles that distinguish between multiple factors (drivers, applications, OS, etc), and the only information that gets copied over, is the information that is needed for that particular Linked Deployment Share. Another example is if you have Linked Deployment Shares to 2008 servers for your Windows 7 deployments. Your organization rolls out new 2012 servers and Windows 8. You could update your current local deployment share with the Windows 8 deployment information (while still having the Windows 7 deployment information there), create Selection Profiles for the Windows 8 information, then replicate that information out the just the 2012 servers. Once the server 2008 servers are decommissioned or re-purposed, your environment now only has it’s current Windows 8 deployment information, BUT, your local deployment share still has all of the Windows 7 information on hand in case it ever needed to be pushed back out, this time on new shares on the 2012 servers.

There is, however, a downside. In my testing, there seems to be an issue with CustomSettings.ini and Bootstrap.ini. In both MDT 2012 and MDT 2013, these settings don’t work when loading through WDS.

In MDT 2012, the solution, from my testing and information I gathered from other sources, seems to be that if you delete all of the stuff in the “Boot” folder on the Tech machine, then use the “Completely regenerate the boot images” when you update the deployment share. Just using the forced regeneration didn’t work until I deleted the Boot folder contents. Then, on the Linked Deployment Share, right click it and go to Properties and make sure that the “Replace the contents…” option is selected, then you can click on the Linked Share and replicate the folder again. You could also delete all the contents from the server share location and either the Merge or Replace options will work. Use the new boot image in WDS and you should be good to go.

In MDT 2013, it’s a little easier. I tried the above approach and it still didn’t work. However, all I did was made sure both INI’s were correct, then updated the tech machine Deployment Share, then I copied the Deployment Share folder over to the server. I then used the boot image from the copied folder  with WDS and all good. I haven’t tested whether this option would work with 2012 yet. The downside here is that your Selection Profiles aren’t doing what you want them to.

In both versions, once I had done the modifications to the INI and updated the local deployment share, I could see the updated INI’s in the control folder. However, when I replicated the content, everything except the two INI’s got updated. If anyone has any questions or comments, feel free to let me know, or let BJ know and he and I can try and figure it all out. It’s all about the learns!!!!

Using the Linked Deployment Share is a good way to keep from accidentally making mistakes to your production environment, but remember to change the value in the BootStrap.ini for DeploymentShare. In your testing, make sure the BootStrap is pointing to your test machine, and once you’ve finished your testing, modify the BootStrap with the Deployment Share on the server, update the local share, then copy the content to the server.