Determine Bootsettings from WinPE

Got an e-mail from a reader about booting into a buildshare, and part of troubleshooting required us to determine the share the bootimage was trying to phone home to.  I wanted to get a screenshot of how to get that info. It may be useful to you.

A boot image should have one and only one deployroot “share” declared. So different boot images will have different shares that they “phone home to”. From winPE you can determine the configuration from the bootstrap.ini variable from the commandprompt in winpe. Remember, you really only need to “update the share” when you’re messing with the boot settings.

From winPE, you hit F8 and a commandprompt will come up, you do a cd ‘change directory’ to x:\deployscripts and then open bootstrap.ini. This way you can determine where the bootimage is looking for the deployroot variable.


F8 will bring up a commandprompt in WinPE. It’s pretty handy, in this case, we see the boot ini.



Troubleshooting MDT (read your log files)

I was on the TechNet MDT forums the other day and I read somebody claiming that the MDT logfiles were too verbose and too hard to read. This is only kind of true. They certainly are verbose (which is in fact a good thing). These logs will contain lots of information, and while it can seem overwhelming at first, they’re only hard to read when you’re not using CMTrace. This is a free tool you can download from Microsoft. It’s part of the SCCMTooklit downloads available here:


When installing the SCCM2012R2 Toolkit, just select client tools.

Pass on the ServerTools and Select Client Tools

Once that’s installed you may need to set CMTrace as your default viewer for logfiles. That’s easy. Open CMTrace once and it’ll ask to be the default. The hard part is knowing which log files to check.

CMTrace should ask you this right away – Select yes

Yes, sometimes knowing if half the battle, and with MDT that battle is knowing where to look for log files. If the imaging hasn’t started and you’re still in WinPE, look in X:\MININT\SMSOSD\OSDLOGS. If the task sequence has started and that PC has at least imaged, look in C:\MININT\SMSOSD\OSDLOGS. If the task sequence has finished, or at least been wrapped up cleanly, look in %WINDIR%\TEMP\DeploymentLogs. MDT will move everything there at the end.

The core MDT log file is BDD.log. MDT will dump that to the Windows temp folder on the system being imaged. If you don’t have server logging set up in your share, set that up. It’ll save you time down the road. It will let you dump logs back to MDT at the end of the deployment. There’s lots of logs for each script that runs as part of the task sequence and you can even specify to log MSI installs during the deployment as well.

The first place to look when troubleshooting MDT is the BDD.log file in the windows temp.
This is your logfile in notepad. Not pretty. I’d even say this is practically useless
CMTrace allows you easily read MDT log files, it highlights warnings, errors and points out problems for you.

Other log files you may want to look for:

  • ZTIApplications.log – When troubleshooting application installs
  • ZTIDrivers.log – When troubleshooting MDT Driver injection
  • ZTIDomainJoin.log – When troubleshooting joining the domain

Finally, there’s a great guide here that reminds us the most important thing about troubleshooting MDT:

“When you know which log files to research for what failure condition and at what time, issues that were once mysterious and difficult to understand may become clear and understandable.”

For more info on Advanced MDT troubleshooting, check out Keith Garner’s guide on TechNet here:

Installing Adobe Acrobat Reader DC with MDT

Started doing some tests from my Deployment Shares in my home lab when I realized my Reader install was woefully out of date. Figured since I had to update it anyway, might as well make a quick little guide on how to install a customized ReaderDC 2018 with MDT.

First, you’ll need to download the reader executable, I prefer grabbing it from Adobe’s FTP site. Grab the latest DC builds here:

You may also want to look for the latest patch for it as well, they can be a little hit or miss, but it’s worth trying to see if you can get it to work. If you’re locked into a certain version, this can be particularly useful.

If you’re just learning or comfortable with simply installing the standalone executable, that’s easy. You’ll just add it into MDT with the /sAll switch and away you go. No need to unzip the file or create a transform.

However, if you need to install a specific build or customize the install in anyway, you’ll want to extract the executable with 7Zip or WinRAR, as you need both the msi to install from and to be able to generate a transform. This comes in handy when you need to disable upsell and cloud features your users may not want or need in a corporate environment.

If this is the route you’re interested in, you’ll want to first download the Acrobat Customization Tool. This will also let you point to a msi file, configure update settings, EULA stuff and even custom registry keys to disable stuff like the “welcome to reader” first launch stuff for your users, and then save a transform file.

Information on Adobe’s tool is available here:

I don’t recommend disabling the auto update feature, but in some environments, reader is patched from a SMS later after testing. It’s up to you.

Finally, you’ll need to know the unattended command line magic to string along the installer and transform with the update:

msiexec.exe /qb- /l*vx %LogPath%\AcroReadDC.log REBOOT=ReallySuppress UILevel=67 ALLUSERS=2 /i AcroRead.msi PATCH="\\MDT01\Share$\Applications\AdobeReaderDC\AdbeRdrUpd2018.msp" TRANSFORMS="AcroRead.mst"

Note the path requires a FQDN, point it to the server and share.

Quick Walkthrough:

Make Your Customizations to the MSI by opening it with the Adobe Customization Tool.

Unless you’re using the cloud services, you may want to disable them. Pass on ‘upsell’ as well.

Once you’ve saved the mst file, you’ll want to save it with the msi and msp files before uploading them into your share.

The msi, the mst and the msp, Notice the date modified. The newest is the transform file.

Now that you’ve downloaded, extracted, and customized everything, import it into your share as a new application with source files.

Once you’ve unzipped the executable and generated a transform, import as app with source files.
Keep the Version Generic, you may have to update the package later.
Point it to the folder where your updates and transforms are with the msi you extracted from the executable.
You’ll want to point to the MSI, the patch (with the path) and the transform. 
msiexec.exe /qb- /l*vx %LogPath%\AcroRead.log REBOOT=ReallySuppress UILevel=67 ALLUSERS=2 /i AcroRead.msi PATCH=”\\MDT01\Share$\Applications\Adobe Reader DC\AdbeRdrUpd2018.msp” TRANSFORMS=”AcroRead.mst”
Either bundle Adobe into your build prior to capture, or deploy it dynamically.
Win10x64 1709 with AdobeReaderDC fully patched and customized.

Adding a customized install of Reader into your deployment shares takes some time, but with a little bit of trial and error you’ll be installing Reader “automagically” in no time. If you’re having trouble with the install make sure to check the logs in the temp directory.

As Johan says, “Happy Deployments!”


Update Your MDT Install!

Microsoft did quietly release an updated build 6.3.8450 last month to fully support Windows 10 1709 and to fix some known issues. If you haven’t updated, do that sooner rather than later. Remember, there’s no MDT 2012 or 2013 anymore, it’s just MDT plus the build now.

In the release notes you’ll see something interesting:
I’m assuming that’s a fix for Lenovos not identifying as Laptops I identified last year.


And of course, Johan’s already got a guide on upgrading.

When was this computer imaged?

Had a fun question today. “Hey, When was this computer re-imaged?” Wasn’t sure if a co-worker did before he left for the day. Wasn’t sure if it had been reimaged or not.

Good thing MDT dumps that data to the registry during the state restore phase during the Tattoo step.

Look in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Deployment 4\Deployment Timestamp


Yeah, Clonezilla ain’t doing that…

Joining the Domain with MDT

Somebody asked me the other day about joining to the domain with MDT, to which I replied, oh that’s easy.

Let’s take a dive:

The beauty of MDT over other “cloning” tools that I’ll leave nameless is that it’s more than just a disk cloning tool, it’s an entire OS deployment framework. All the scripts are written, you just add variables to an ini file and away you go.

A default standard client task sequence will join a PC to the domain, that’s why by default the LTI Wizard asks for all that information. You can tell the wizard not to ask and just do it “automagically” for you.

To automate your domain joins, there are four variables you’ll need to set in your customsettings.ini file; JoinDomain, DomainAdmin, DomainAdminDomain and DomainAdminPassword.


It’s that easy. By default, the system gets joined to domain immediately and on first boot, it’s joined and ready to rock so it’ll grab group policies almost immediately. If you don’t have stupid group policies, it’s all downhill from here. If you have stupid group policies, you’ll have to modify your XML file and move the domain join to the very end of your task sequence like this.

Now, with that out of the way, what if you want to specify the OU? Well, there’s another customsettings.ini variable for that too, it’s MachineObjectOU.


And finally, if you’re having trouble joining the domain, you’ll be looking for ZTIDomainJoin.log. It’ll be in the %WINDIR%\TEMP\DeploymentLogs. For most of you, that’ll be C:\Windows\Temp\DeploymentLogs or your server side logs location if you have that configured as well, just use Trace32 to read them, because they’re pretty hard to decipher from notepad.

As Johan says, Happy Deployments!

Dynamically Picking Image From MDT

Johan Arwidmark, the MDT Guru extraordinaire posted a neat trick this weekend; Getting MDT to install a different image based on a dynamic variable. In his example, you could have ONE task sequence drop a different image based on location. I didn’t even know you could do this, so this is pretty cool.

I share his sentiments that usually you’d want to have a 1:1 for each TS to image, but in case you ever had a reason to do this, you could. I can already think of a couple of scenarios off hand where this could be pretty useful myself. Now, I haven’t tested this yet, but looking at what he’s showing here, it should work.

Check it out here: