So, in a previous post, I noted the benefits of using a Linked Deployment Share with MDT. I also pointed out an issue with the way MDT handles CustomSettings.ini and BootStrap.ini when copying the replicated content. As it turns out, this is by design.
I was doing a little more testing with MDT 2013 and was trying to figure out why my MDT database wasn’t filling in the details I needed it to fill in. During this process, I looked in to the properties of the Linked Deployment Share and found a note at the bottom of said properties that states: “To modify the Windows PE settings for a linked deployment share, open the deployment share using the “Open Deployment Share” wizard. Once opened, the settings can be modified through the Properties action.”
So, basically, the Linked Deployment Share will have all the information in needs copied over to the share, but you need to then right click on the Deployment Shares folder, select “Open Deployment Share” and then specify the location of the Linked Deployment Share (ie: \\server\DeploymentShare$). When this second deployment share opens up, all of the data from the original deployment share is copied over, with the exception of the CustomSettings.ini and BootStrap.ini, and your SQL database connection if you’ve configured it. At this point, copy the CustomSettings.ini and BootStrap.ini data from the original share over to the linked share, setup you database connection if you’re using it, then update the new share.
The only reason I can think of off the top of my head for this setup is one that I brought up in the original post: testing versus production. You can test everything on your “desktop” share (aka Test Share), when it’s all working, you can replicate it to a “server” share (aka Production Share). This way you can test your custom settings on the desktop side and replicate the changes to the production side when you know they are working.