(Haven’t posted in a while, been busy with my day job(s), travel, scripting, sleep :^).
Some of you have recently noticed that MDT 2013 Update 1 has changed the way it sets the permissions on the network shares when it creates them for the first time.
When you create a new deployment share in MDT, it will ask you what the network share should be, and the wizard will automatically create the necessary bindings for the share and your local path, including setting up the permissions. Super!
The old permissions used to be “Everyone” has full access, it’s now set to “CREATOR OWNER”. I was somewhat confused by this change, and seemed a bit arbitrary to me. I suspect that someone filed a bug against MDT thinking that locking down the deployment share in the most restrictive way possible would somehow be better, because you know… Security! Think of the security breaches at Home Depot, and Target. PKI. Oh the humanity.
Well, MDT deployment shares don’t really store sensitive information, if you *DO* store any sensitive information on a MDT deployment share, then you are doing it wrong.
But anyways, someone made the decision to lock down the share, although “CREATOR OWNER”, this is kind of confusing to me, only one user? Why not use local “Administrators” group, local administrators already have full access to the files. “CREATOR OWNER” might only give access to one of several local “Administrators”.
Additionally, “Everyone” isn’t really that bad, access files over the network, you are still limited to the “File” level permissions on each file, which are better IMHO, I can create a Logging directory with Create/Write permissions, and set everything else to “Everyone” Read, with “Administrators” “Full R/W”
Anyways, this new permissions change for MDT 2013 Update 1 hasn’t caused much of a problem, as most users can easily work around the issue by adding extra approved users to the share afterwards.
Got a question today about a missing DeployRoot varaiable in BootStrap.ini.
MDT uses BootStrap.ini in WinPE to remember where to find the DeploymentShare to do the heavy lifting.
Normally, when creating a new DeploymentShare, MDT will automatically update the DeployRoot variable in BootStrap.ini, however several users were observing that this was no longer getting updated.
I used my trusty ILSpy to disassemble “C:\Program Files\Microsoft Deployment Toolkit\Bin\Microsoft.BDD.PSSnapIn.dll” and look at the “Provider class”, what I observed is this code segment:
IniManager iniManager = new IniManager(deploymentPointSettings["UNCPath"] + "\\Control\\Bootstrap.ini"); iniManager.Write("Default", "DeployRoot", deploymentPointSettings["UNCPath"]); asdfsdf
You can see here that MDT is attempting to open the Bootstrap.ini file and write the Path to the DeployRoot Value.
Note that MDT is trying to load the Bootstrap.ini file using the same “UNCPath”? I suspected that MDT was failing to open the file due to the restrictive “Creator Owner” permissions, Sure enough, I tried opening the file over the network and it failed. Found!
After creating a new deployment share in MDT, be sure to go back and fix some of the defaults:
- Change the permissions, Something more permissive like local “Adminsitrators”
- Change the \\server\deploymentshare$\control\bootstrap.ini to include
- <More to follow I as do more testing>
MDT Bug: 451130 (known issue)