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.



Editing The Registry With MDT

I was helping somebody understand how to edit the registry with MDT, which isn’t very intuitive or obvious to some, and I ended up diagramming the entire commandline syntax of an example, and I figured it might help somebody else, so we’ll walk through it step by step on the blog today. First, you need to know what registry key you’re trying to set: In this example, we’re setting the lock screensaver option. This can easily be done via the command prompt like so:

reg.exe add "HKCU\Control Panel\Desktop" /v ScreenSaverIsSecure /t REG_DWORD /d 1 /f

What’s going on here? Look below.

Part of the beauty of task sequences is anything that can be done via commandline can be done via a task sequence. Simply Add it as a command line in your task sequence.

This is especially helpful when building an image. By using a combination of this and a few other tricks, I have fully automated by windows 7 image build so the hardest thing I have to do is run a task sequence which in turn builds and captures an image for me.


Decomissioning PCs with MDT

Now, I’ve known for a while there’s a way you can use MDT to wipe systems after you’re done with them. I know this isn’t some kind of KGB/CIA proof standard of wiping things, but it does the trick since I have PCs we were evaluating and I just need to send them back to the reseller. In this case, I’m dealing with systems that simply won’t boot to USB thanks to our wonderful secure boot technology, bargain bin USB flash drives so I need a task sequence based solution.

A while back I found this…

Googling the issue, I found this…

So, it really is pretty straight forward, just use the replace task sequence, and create a task sequence that’ll reboot into WinPE and wipe the disk. At first it didn’t work, buy

Create a Standard Client Replace TS
Note that by default there are conditions to running these steps. I added WipeDisk=True
Now, just browse to your share and run your shortcut to the wizard. Don’t run MDT from UNC? You’re doing it wrong.
Yeah, We got a task sequence for that!
WinPE is downloading! Reboot is Next!
Really I just wanted an excuse to show my WinPE wallpaper…

Okay, I know this wouldn’t fly at the DoD and all you tinfoil hat wearing mouth breathers are yelling “BUT THE GUBMENT CAN STILL GET MY DATA!” Okay, Okay, If three wipes of zeros don’t assure the Fox Mulder in the back of your head. We need to look into some serious data sanitation napalm. This is where sDelete comes in handy.

For you security types: check that out, it’s a SCCM task sequence, but it’s the same idea, no reason why it wouldn’t work with MDT. If you’re still that opposed to writing zeros or using sDelete and insist on using a DoD certified solution by hand, look into DaRT, Microsoft’s free¹ USB repair utility for Software Assurance Users.

¹ Free as in your employer pays lots and lots of money for a Volume Licensing Service Agreement or are a bad person that downloads software from bad places.

MDT FUNdamentals: Adding Office 2016 to MDT 2013

This one’s been something I’ve meaning to post for a while now, and it’s going to hopefully be part of a fun little series I want to call MDT FUNdamentals. In this article I will outline how to add a basic Office install to your deployment share.

One of my absolute favorite things about the Microsoft Deployment Toolkit is the relative ease in which we can get it to install, configure and patch just about any version of MS Office for us. If you really wanted to, you could use this to install Office at deploy time, but for 99% of us out there, we’ll do this during the image build prior to Sysprep and capture.

This guide assumes a few things:
MDT 2013 Update 2 is installed.
ADK 10 is installed.

Now, what I won’t assume is that you have Office 2016 imported into your share. If you have an ISO, mount it, if you can’t mount it, extract it. Once that’s complete, this guide will show you how to add it.

First if you don’t already, you’ll need a share, an image, and a task sequence, don’t worry if you don’t have a custom image yet, you can use the wim in the iso. If you don’t have a share, you’ll need to create one. Remember, this is how I put Office in my image, I have MDT install it before I have MDT capture the image for me.

For this example, I’m going to add Microsoft Office Pro Plus 2016 to a share I use to build windows 10 images.

From the applications folder in your deployment share, right click and select new application. Point it to the mounted ISO or extracted ISO.

Office is easily added to MDT by importing the contents of the ISO. See below for the syntax. Once Office is imported, we’ll run the office customization tool. Create a new file, make your tweaks and save to the updates folder in the share.

Since we’re installing Pro setup.exe will need to be pointed to the proplus XML like above.

The MDT/Office integration is pretty solid. The most basic configs can be done here. Right click it once imported and select properties.

The Office Customization Tool is a powerful way to automate office install and tweak it for your needs.

The wizard also allows you to pick and choose which components. Skype? Who needs that? Not me.

The wizard’s prolly the safest way to add Office keys, well next to KMS that is.

Final trick: Use this setting to disable that first run wizard that NOBODY wants to see. Set this and thank me later.

SEE ALSO: Johan’s Guide, This and This Initials Prompt Trick

Reinstalling apps in MDT 2013 the easy way

Haven’t been this excited about finding a new trick in MDT for a while, so bear with me, this is going to be a long post. I really like this as it adds a whole new level of automation to a strictly MDT lite touch environment that’s minus Config Manager, which is perfect since this is after all, an MDT blog.

MDT is great in bare metal scenarios. That is to say, “Here’s an order of 500 brand new computers, get them ready!” MDT can do that easily. Now, what most deployment pros also know is that where MDT really shines is in refresh scenarios. That is to say, “Here’s an entire organization that needs to be moved to a new version of windows” or even just standardized to a newer image. MDT can detect and reinstall apps dynamically as well.

So, in this hypothetical refresh scenario everyone’s getting an image with windows, office, the core line of business apps, and that’s all in the image, but only half of the users use Adobe Acrobat Pro and there’s a mix of users who use other one-off applications. Now, one could go about using the lite touch option to select these additional supplemental applications in the lite touch menus prior to deployment, but do you want to inventory every device?

Now, I’ve known for a while that in theory one could go about using complicated scripts, bundles or the MDT database, but yesterday I stumbled across this gem and a lightbulb went off. While I had looked into this before in the past, it involved manually creating GUID lists or writing queries and the amount of work needed didn’t look like it would be worth the hassle, but this method is really the easiest as long as we’re talking about an MSI, because while you could in theory also use a WMIC query, who’s got time for that?

So, here’s the quick rundown:

  • Some (not all) users have an application like Adobe Acrobat Pro installed
  • You’ll need to have the MSI that’s installed on the user’s PCs to show MDT
  • Create a step in the State Capture phase that sets a TS variable called AcrobatInstalled to true
  • Use a this to only set if it detects the GUID for the MSI that’s used to install Acrobat
  • During the State Restore, if the task sequence variable is set to true it will run the install for Acrobat.

Of course, this may not work during ‘offline’ migrations from PXE, or USB, so I’ll have to most likely go over refresh scenarios where we’re running from within windows.

Lots of people use MDT almost exclusively from PXE or ISO, but you really almost never need to do it that way, MDT can be run from the UNC path from within windows itself. (PXE is criminally over-rated and really only necessary when you’re imaging bare metal or a crashed PC that wont boot)

Browsing to the \\MDTSERVERNAME\ShareName$\Scripts folder, you’ll see litetouch.vbs, kick that off and you’ll get the wizard to run. This is how I kick off 99% of my refreshes. You can even pass switches to this vbs via shortcuts to include or exclude prompts in the wizard. More on that in a later post.

STEP BY STEP: How to get MDT to detect an app and reinstall it during a refresh:

Step One:
Add a step to the task sequence that detects for product in the Capture State
Step Two:
This step creates a task sequence variable and sets it to true if application is detected
Step Three:
Add a step to the task sequence that installs product in the State Restore
Step Four:
This step runs only if it detects the variable as set as true

This could be used to call not just one app, but a bundle if you wanted, however you wouldn’t want to do this for every single app, as this trick is best for something that’s on 20-45% range of your user base (like acrobat pro). This wouldn’t replace Desktop or Laptop bundles either, but it will however allow you to bring a whole new level of automation to the supplemental applications installed in your environment.

Questions? Comments? Hit me up in the Contact Me page.

Installing Cisco AnyConnect 4.1 with MDT 2013

This one’s eluded me for quite sometime, so I am posting this in a hope that somebody else sees this and it saves them the blood and sweat and tears that me and other readers lost beating on this one.

I’ve had no less than two separate readers e-mail me over the last few years asking about Cisco’s AnyConnec MSI creating the “Dirty Environment Found” error when using the standard command line syntax that works on just about every other MSI. In the past, I’d use a 3.x exe and it wasn’t a problem, however, newer versions come in an MSI that disconnects and reconnects the NIC and pisses MDT off something awful. Basically, disabling and enabling the NIC (which AnyConnect does during install) while the task sequence is running is akin to an unexpected reboot, and causes the LTI Dirty screen to come up.

Well, like everything Application related in MDT, its just a matter of googling long enough and spending the time playing the game of trial and error. Last week I found this, and finally spent the time to look through it.


Page 2-27 has the following:

Turns out the /passive switch does the trick. This somehow must be related to the fact that I can now install AnyConnect and not get the “Dirty Environment Found” error. Wish I had known that like two years ago, but hey, better late than never! So in conclusion, here’s what I am using to do my CiscoAnyConnect 4.1 install in MDT 2013:

msiexec.exe /qb- /l*vx %LogPath%CiscoAnyConnect.log REBOOT=ReallySuppress UILevel=67 ALLUSERS=2 /package anyconnect-win-4.2.02075-pre-deploy-k9.msi /norestart /passive

Now I know, and so do you! And Knowing Is Half The Battle.

Questions? Comments? Hit me Up on the Contact Me Page!

Restore Office 2010 and 2013 User initials prompt in Your Hybrid Image

This one’s driven me a bit nuts for a good while now, sorry I haven’t been posting much, been keeping hella busy with a security project at the new job, I do however want to document this for you guys as it’s an embarrassment as to how long it took me to figure this one out.

PROBLEM: You’re installing Office in your image prior to sysprep and capture because you’re smart and use a hybrid image that’s got Office in it, because not putting Office in your image can easily add hours to your deploy. However since you’re also setting copyprofile=true in your unattended.xml, the userinfo is getting set in your default profile and users that are doing tracking changes and/or collaborating via a file share get these errors:


This error sucks for numerous reasons, most importantly though, it’s pulling the username used to install Office and not prompting the users when they first start office.

THE FIX: Add this to your build task sequence after Office gets installed and before it gets sysprepped.

reg.exe delete "HKEY_CURRENT_USER\Software\Microsoft\Office\Common\UserInfo" /f


So there you have it, the one single reghack that makes that problem go away, now Office will prompt users on first use of Office.