How to view MDT Logs (or what to do if you get a pink window)

(imported topic written by JackCoates91)

If MDT goes sideways after booting to Windows PE during a refresh or migration, you may need to review its log files to find out more. This is all done at the target, not in BigFix.

  1. If you click on the Finish button in the pink error message window, MDT will erase its log files and reboot.

  2. To get a terminal prompt in Windows PE, press the F8 key on the target’s keyboard.

  3. Use the “net use” command to see whether there are any SMB shares mounted.

  4. The MDT logs are in C:\MININT\SMSOSD\OSDLOGS\ – BDD.log and ZTIDrivers.log are useful places to start.

  5. There should be a C:\drivers folder created with the drivers file that are identical to the one in the folder that you specified.

Log files are in XML format and are tough to read with notepad.exe (the only text editor available in Windows PE). You may want to use trace32.exe from a thumb drive instead, see here for instructions: http://tompopov.blogspot.com/2010/07/trace32exe-download.html

The most likely issue is a lack of storage or network drivers, which can be corrected if you use the PE Drivers field in the capture or reimage dashboard.

(imported comment written by DTan)

Optionally you can make trace32.exe part of the MDT bundle so that you can use it in WinPE. To do that, you can simply copy trace32.exe to the “deploy$OEM$” folder of MDT bundle folder before uploading the bundle to BES Server through OS Deployment Dashboard in Console.

See instructions on how to create MDTBundle in the Preparation section in page 7: http://support.bigfix.com/product/documents/OSD/OSD_Users_Guide.pdf

(imported comment written by SystemAdmin)

What does it mean if there is nothing on the C: drive while the image is being captured and the wim file is being generated?

(imported comment written by JackCoates91)

We looked into this with Vincent and found that the hidden recovery partition was mounting as C in Windows PE. The system partition was accurately captured, but reboot at the end of the process didn’t work. We’re looking further into the issue.