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.
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.
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.
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.
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.”
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.
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.
Note the path requires a FQDN, point it to the server and share.
Make Your Customizations to the MSI by opening it with the Adobe Customization Tool.
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.
Now that you’ve downloaded, extracted, and customized everything, import it into your share as a new application with source files.
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.
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:
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.
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.