Hello,
My team and I have begun to deploy an version of Win 10 created using the MDT materials. We have two different target machines in our lab - Dell 3020s and Dell 3010s. Both were in use with Windows 7 prior.
Deployment for the Dell 3020 goes well, and they're brought online in short order. For the Dell 3010s, however, we run into problems. At some point during the OS portion of the install, I see the following error messages:
cscript.exe - Delayed Write Failed
Windows was unable to save all the data for the file \minint\smsosd\osdlogs\bdd.log; the data has been lost. This error may be caused if the device has been removed or the media is write-protected.
If you hit OK (the only option) it will show variations of the same error, just citing different files in the same location - BDD,log, LTIApply.log, variables.dat.lock.
One of the error messages also cites being unable to find the definition file Summary_Definition_ENU.xml
We're using the same deployment for each machine, deployed off a USB HDD. Each 3020 went fine (and a 3020 was used for the deployment buildup) but only one solitary 3010 model made it through setup without any issue. All others have failed at this
portion with the possible exception of a unique case wherein the OS deployed but it would not boot without the USB removable hard drive in place.
I have checked both our removable media and our failed target (using the command line interface they give at the end of a failed install) and found that both have this \minint\ directory and both have copies of these logs (which contain nothing that seems to
help - just a list of deployment steps). These are in the Deployment partition and the root of C: in both instances.
(Related - if it fails early enough in deployment, the partition that houses Windows does not appear to get a drive letter. You can find it using diskpart, even assign a letter to it, but you can't simply jump to C:).
This error appears to only happen during the OS deployment phase, but it happens at variable locations - I've recorded it failing at 11%, 48% and 62%, and one team member reported it failing at or around 99%. Same errors each time.
Hypotheses
I know Delayed Write failures usually have to do with a device losing connection before all of the data is written to it. Based on a few attempts and some data gathering, my hypothesis is that the USB device that holds the deployment is, for whatever
reason, getting a letter re-assigned, and this causes the connection to fail and the deployment to halt. Unfortunately, while I can get to the USB via the CLI after it fails, I can't access it prior to the failure in order to ascertain what the drive
letter would be before it. I noticed in the instance I was able to get Win10 to start (but only with the RHDD attached), there were multiple "disks" detected - Windows was on C:, D: was the Deployment partition of the RHDD, and E:-H: were taken
up by unnamed, unidentified disks (with the on-board CD drive becoming I:).
Permissions - the prompt about write-protecting made me think that somehow permissions were being changed during install so that the files could no longer be accessed (meaning the errors were more a symptom than a cause). Hard-setting NTFS permissions
on the removable to Everyone having full control over the Deployment partition did not help - still failed.
I don't suspect it is a driver issue, as I would believe it would fail consistently in the same location, if it would ever work at all.
Unfortunately there isn't much more to go on, so all of my hypotheses are something of a stretch.
I am mostly bewildered at the inconsistency, and that I was able to get this model of machine to work at all if all the others continue to fail for the same reasons.
Any suggestions would be greatly appreciated.