ASK MDT Guy: Adding Scripts as Applications to MDT

Just received a great question this morning from Paul who’s asking about adding scripts as applications to MDT shares to be selected as needed at deploy time.

Question:
It is possible to add a really small/simple .bat file I created as a Standard application that users can just click on the checkbox to add the application at deploy time?
The .bat file is really simple: just displays a few lines in the command prompt and does one other thing, and at the end, there is EXIT, where it closes the command prompt.
I right-click Applications in the Deployment Workbench and choose “Application with source files.” The main question I got is, what would I put in the Quiet Install Command?

Answer:

The short answer to this question is yes. You can very easily add batch scripts as applications in a share to allow helpdesk staff to install them “as needed” at deploy time. I would only do one bat per application, nesting them like that may be half the problem right there.

I however, prefer to use VBScripting (vbs) or windows script files (wsf) whenever possible for a number of reasons, the least of which is the numerous limitations of bat files regarding UNC paths and logging.

If you’re in a crunch, and you know your batch script works, go ahead and use cmd.exe /c script.bat as your quiet install command.

The /c tells the command prompt to close when it’s done.

As for importing the applications…

You could do it one of two ways, import it as an application with source files, and point to a folder that has the batch or vbs script in it.

Sometimes, I’ll also import it without source files and use the %SCRIPTROOT% variable and just throw it in the script root directory, which I’m trying to not do anymore, as the advantage of the first method is that if I need to move this application to another share down the road, it’s a simple drag and drop operation.

Where’s the Any Key?

In a perfect world we’d all have WDS servers configured everywhere, just laying around ready to feed us .wim files at a moment or F12’s notice, but that’s not always the case.

Problem: When booting to an MDT boot ISO there’s not always somebody to press any key, and well, sometimes, end users really will look for the ‘any key’. So the question is: How do we disable the press any key to boot prompt on MDT ISO files?

Solution:To disable the press any key prompt in your ISOs you’ll need to rename the file that MDT uses for this ‘feature’. Just be advised this can cause problems with physical boot media and is really only for specific situations, like USB or one time PXE boot actions with third party systems.

Rename the following files accordingly.

32-bit
C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\Media\Boot\bootfix.bin
64-bit
C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\Boot\bootfix.bin

Once you’ve renamed your bootfix.bin files to bootfix.old. Update your share and have MDT regenerate the ISOs.

Now these ISOs will no longer prompt for the any key.

Why would Microsoft make such a simple thing so complicated?

Today I got an e-mail from a reader Blake, who was wondering why Microsoft would make imaging more complicated with MDT as opposed to the “simplicity” of basic disk cloning tools that were ubquitious over a decade ago.

Question: Why would Microsoft make such a simple thing that has been used for so many years so complicated?

Answer: Agreed, the complexity of MDT is quite intimidating, I must admit, the first time I opened MDT I had no idea where to even begin.

I’ve been using MDT for over two years here now and there’s no way I would go back to the nightmare of managing a single image for every single make and model. That wasn’t simple. That was hell. I would never go back to having to run windows updates by hand on a six month old image. That was not easy, that was a pain in the ass. I wouldn’t go back to installing one off applications by hand, that wasn’t simple, that was a chore. The dynamic driver injection, the windows updates, and the dynamic provisioning is really hard to beat. When I worked for Xerox I reduced their image count from over twelve to two, one for 32bit and one for 64 bit, it was beautiful, long gone are the days when you’re maintaining dozens and dozens of images. Again, today I have one 32bit win7 image, and one 64 bit image, that’s beautiful.

Understand, that back in the early days of Windows XP there were no Microsoft tools, there was sysprep, and that’s as far as Microsoft would take you, but that all changed with the release of Vista, which was released with the first version of the AIK. MDT was still called the Business Desktop Deployment Kit (BDD), but by the release of Vista SP1, it was rebranded as MDT.

Now, for the Thick vs. Thin image debate… Fans of thick images say that they’re faster, and fans of thin images say they’re more flexible at the expense of speed. I honestly don’t like either. I’m a big fan of the “hybrid” image.

Seriously, take what’s good about thick images (speed) and what’s good about thin images (flexibility) and you can have your cake and it too. Build the image in a VM with MDT and the cost of maintaining your images is cut exponentially.

Here’s what I recommend to lots of people; Put Office, C++ runtimes, and DotNetFramework in your image, along with the windows and office updates, but keep Java and Flash out (they’re easy to add back in as they get updated which is weekly.)

SEE: http://www.microsoft.com/en-us/download/confirmation.aspx?id=6157

I also suspect that you’re missing the real benefit of using hybrid images with MDT and that is the flexibility. I personally have to support a call center, accounting, marketing, sales, lending, human resources and an accounting department. I don’t have the time to build ten different images for all the departments I support, so I build a pretty generic image that has office, c++ runtimes, silverlight, etc… and then I use MDT’s wizard to let me customize what apps I install at deploy time, and that my friend is what separates a tool like MDT from a toy like clonezilla.

For more questions and answers: See the Ask MDT Guy Page

Creating Custom Variables in MDT

Another excellent post from Mr. Johan Arwidmark at DeploymentResearch.com. Check it out. Make note of the section on property definitions, I get this question from time to time, so alas, if you’re going to create a variable, make sure it’s not one that already exists.

http://www.deploymentresearch.com/Research/tabid/62/EntryId/182/Creating-custom-variables-in-MDT-2013.aspx

How to Copy Folders in MDT Like a Boss (The Easy Way) !

Yeah, This script is hella cool. Ever need to get MDT to copy folders? Course you do: That’s why you’re here. Instead of writing a separate and new script every time you need a folder copied, just use this script I found last week. It really does make this part easy.

SEE: http://blog.coretech.dk/mip/making-file-copy-easy/

Thanks to this glorious, glorious script courtesy Mr. Michael Petersen’s brilliant site: blog.coretech.dk, You Too Can Copy Folders in MDT Like a Boss! (The Easy Way).

So, since half of what makes building images a pain is that half of what you’re doing is nothing more than copying folders; make it easy. Sometimes, these folders don’t already exist (Bummer)

Here’s what you need. The greatest MDT Folder Copy Script Ever Written: http://blog.coretech.dk/download/CopyFiles.zip

Then copy the folder to %SCRIPTROOT%\ and rename the folder to whatever, in this case, I am moving a folder of backgrounds for the UseOEMBackground Feature in a Windows 7 image building task sequence.

Copy it to your folder that needs to be copied on your Deployment Share.

Run it from your task sequence by adding a custom step or just copy any step that calls from scriptroot.

To copy an entire folder…

cscript.exe %ScriptRoot%\Folder\CopyFiles.vbs c:\TEST

Simply change C:\Test to whatever folder you need to create in the deployed system, it’s that easy.

Go get some tacos now that half of your image building process has now been automated.

SEE: 2016 Update: https://mdtguy.wordpress.com/2016/08/03/still-writing-scripts-to-copy-files-yeah-dont-do-that/

ASK MDT Guy: How do I Rename the Default Administrator Account in MDT 2013?

Late last week I was e-mailing with a long time reader about changing admin passwords and he asked me how to change the Default Administrator Account in MDT 2013. I know some people like to use the setup complete .cmd trick, but that’s really for those who aren’t using MDT to build & deploy.

Question:

Is there a prefered method for renaming the administrator account?

I used to do this using the “unattend.xml”. Can I do the same or is there a different method?

Answer:

I add a a customized commandline  wmic step at the very, very end of a task sequence to rename the admin account before the final reboot

wmic useraccount where name='Administrator' call rename name='SysAdmin'

I dunno what you wanna rename it to, I kind of like SysAdmin. It’s your build, just change it to something other than Administrator.

However, I have heard that the GUID for this account is globally available, so this may not be the MOST secure method, but at least it’s a start.

Super hardcore security types will disable the account, that way you need to get at it via boot media to turn it back on, in some environments this is overkill. A simple rename is fine.

Using WMI to rename the admin account is easy.

Adding this final step to MDT is easy, and far more effective than going through the whole hassle of creating another account, setting it up and disabling it via command line.

See Also:

http://social.technet.microsoft.com/Forums/en-US/edc88cb5-f9b0-4862-adf9-bb2b73940ee7/how-to-rename-local-administrator-account-when-deploy-windows-7-image?forum=mdt

ASK MDT Guy: A tale of Two WSUS Servers

Yesterday I received a really good question from a reader Winston.

Question:

I have multiple sites that I have been able to connect together using DFSR. Servers are 2012 R2 using MDT 2013. I have a WSUS server on one server but I would like to be able to have a WSUS server on the second server. The WAN link between the two sites is fairly fast but I would like to have two WSUS servers but having one sync to the other but the second site will get it’s updates from the second WSUS server. I know how to sync the two WSUS servers just not how to have my two MDT servers recognize which one should be used for their respective site.

Answer:

Getting clients deploying at site A to get one WSUS server and clients deploying at site B to get another is actually pretty easy. In fact, we can do lots of fun stuff this way, we could set names based on sites, and even specify which applications get installed.

The solution is brilliant in it’s simplicity. Tweak your customsettings.ini file.

MDT allows us to set different variables based on the default gateway detected at deploy time.

See the Example Below.

Using the Default Gateway, we can configure site specific settings at deployment time.

In this example, we have two sites, Chicago and Atlanta. Devices at each site will detect different Gateways when the NICs initialize, and then will get different names, different WSUS servers, and different application bundles. There is almost no limit of what could be done with these

See Also:

http://deploymentbunny.com/2012/04/21/back-to-basic-customsettings-ini-explained/

http://scriptimus.wordpress.com/2011/06/23/mdt-2010-sample-customsettings-ini-for-fully-automated-deployments/

http://deploymentbunny.com/2014/05/19/back-to-basic-customsettings-ini-sample-3-and-a-bunch-more/

Delaying Domain Join When Legal Notices Break MDT AutoLogin

Sometimes Group Policy Breaks MDT. Policies such as Rename Administrator or a GP Install will break the glorious automation of MDT. Most commonly however, it’s those pesky legal disclaimers that tin foil hat wearers just love. These little warnings will bring your beautiful task sequences to a screeching halt.

See, MDT after imaging will need to login to the default local administrator account to run windows updates, install applications, update those apps, and apply local policies and perform the final cleanup. Often these steps can require several reboots, and having to click okay to some legal disclaimer every reboot kinda defeats the whole purpose of having MDT around in the first place.

There are several documented workarounds for this problem, the simplest of which is to turn off these warnings, because they don’t really do much good, but since they’re usually the idea of management, its not a fight worth having. So the next solution is to disable the domain join until the very end by hacking your unattended.xml file and moving recover to the domain to the very end, which is a little better. I’ve also read about staging OUs and hacks to GP using WMI filters, and all kinds of not so fun stuff, but there’s a pretty simple and easy way to teach MDT to “remember” this information, and join at the end still.

Until today when dealing with this very issue, I forgot about this excellent workaround I found over a year when I was doing IT for a large Business Solutions Provider here in Albuquerque.

Avoiding Legal Disclaimers That Break MDT

The idea here is simple, you’re going to comment out two lines of code from the TZIDomainJoin.wsf file in your MDT Scripts folder, and add logic to your customsettings.ini to store the domain information as a variable, and create a temporary task sequence that you’re going to override with a version that has steps that have logic to deal with this, and then copy those steps to your task sequence, I know it sounds complicated, but it works, and is worth doing.

These and MDT do not play well together.

Find The ZTIDomainJoin.wsf file in your scripts folder.

Comment Out Two Lines, 189 and 190

Create a temporary Task Sequence, and overwrite the xml with the xml provided by the link above.

Copy and Paste the Save Join and Restore Join Steps into your Task Sequence..

Note The save occurs in the Pre-Install Phase just before Configure. Restore Join Domain occurs at the very end of the task sequence, pretty much just before we run Recover From Domain at the very end. This way MDT joins to the domain, and you don’t have to worry about

Click the link below for the complete workaround, and the custom XML to use, but it works like a champ.

See: Avoiding Legal Disclaimers That Break MDT

ASK MDT Guy: Updates in MDT take forever… HELP!

Today’s Question comes from a reader named Walter, and he wants to know about updates in task sequences.

Question: When I deploy Windows 7 from the Media Install files and the task reaches the “State Restore” and begins with the Windows Update pre and post application installation. The deployment process can literally take hours to complete. If I disable the Windows Update pre and post application installation the process then is really completed in less than 10 minutes.

1. Why does it take so long?

2. Does the target machine pulls the updates from MS or does get the updates via the MDT machine?

3. Aside from building a WIM that has all the updates, is there a way to speed up this part of the process?

Answer:

These are all really good questions.

This is typical, an unpatched image can take hours and hours to patch, depending on the starting point and your internet connection speed. Now, I use SP1 media and inject a hotfix rollup from last summer and there’s still over a hundred updates it still needs to run. I can only imagine if you’re missing SP1 and/or the hotfix rollup its going to take even more time, as these patches vary from anywhere to just a few Kb to over ten megs. Some take just a mere second, and some like dotnet framework updates can take several minutes, and when those updates are done, they need updates. Yes, updating your updates, fun I know.
When the State Restore phase starts the windows update, it’s calling to a script called ZTIWindowsUpdate.wsf. Unless you specify in MDT to look for a WSUS server, you’re going to be pulling from Microsoft’s Windows Update servers.
As far as speeding this up, yes, you could inject the post Win7 SP1 hotfix rollup from Microsoft or better yet, get a WSUS server setup. If you don’t have a WSUS server handy, there are a few other steps you could do. But for now, start with adding the hotfix rollup, its like 90 updates out of the way.
Info on the HotFix Rollup:
http://scriptimus.wordpress.com/2013/03/13/hotfix-rollup-released-for-windows-7-sp1-and-windows-server-2008-r2-sp1/
Add a step in the task sequence to install the latest version of IE BEFORE patching starts. This really helps because that way you’re not upgrading to IE 9, patching and then upgrading to 10, patching, and then upgrading to 11, and yes, then doing more patching.
Block updates you don’t need, I don’t think you really need the Bing Toolbar, so block the ones you don’t need in the customsettings.ini file.
See:
https://mdtguy.wordpress.com/2013/07/12/mdt-customsettings-ini-tips-tricks/
I actually use MDT to build my images in a VM. I simply use the standard client task sequence, have it capture, use the LTISuspend.wsf script, and make my customizations then.
Info on Adding IE 11 to your image:
http://www.deploymentresearch.com/Research/tabid/62/EntryId/124/Adding-Internet-Explorer-11-to-your-Windows-7-SP1-reference-image.aspx
For more questions and answers: See the Ask MDT Guy Page

Building the Perfect Hybrid Windows Image

Week before last I was visiting with an old co-worker of mine at the ‘ol University, and one of his students and I started talking about thin images versus thick images, and he was shocked to hear I didn’t like thin images. I told him I preferred hybrid images.

Thick? Thin? Hybrid?

Back when I was just a young padawan grasshoppa, imaging Dell OptiPlex 110s, I was taught we put drivers and applications in an image. We had one image for every make and model. At the time, that was pretty slick, but that was also when people still thought the first generation x-box was cool and still took Eminem seriously. Never the less, that kind of image was a thick image, we had lots of them and it really sucked in hindsight, there was no flexibility, these images were monolithic and pain to maintain.

Now some people take image design to an extreme in the other direction and keep EVERYTHING out of their images, the true diehards will literally pull the install.wim file from the windows ISO and go with that. Now, yes it’s true a real MDT master could then get MDT to install office, and all the updates, this will take hours, and hours, and hours. I cannot in good faith recommend anybody try this at home.

But as a follower of Johan, I build Hybrid images. Johan teaches us to build hybrid images, and I highly recommend you do the same. You get all the benefits of both thin and thick, and with very few of the headaches of either. Its one of those rare instances in the Industry where you really can have your cake and eat it to.

Thick images lack flexibility, and thin images take too darn long to install. Its a question of what to put in an image and keep out.

So, as IT Manager Samuel L. Jackson asks,
“What’s in your Image?”

Basically, you put in an image only the things you are certain, without a doubt:

• Everybody will Need
• Doesn’t get updated Every Week
• Will Survive Sysprep

So, Office is in, Adobe Reader is Out. Dot Net Framework 4.5.1 is in, Java is out. Windows 7 SP1 Cumulative Update 1 is in, Antivirus is out.

Office takes a good amount of time to install and patch. In some environments, I’ve seen deploy times cut down by half an hour by adding office to an image. Adobe reader comes in an MSI and its very easy to just update in an MDT deployment share, keep it of your image, you don’t want to be rebuilding an image everytime a new version of adobe comes out. Dot Net Framework is a pre-requisite for so much stuff and god only knows for what, WSUS will patch it, so it’s in. Update rollups are always good, but Antivirus should NEVER go in an image. They have unique IDs that get generated at install time, so putting them in an image is a big no-no.

Finally, I want to show you how Mikael Nystrom does it here.

Note, this guy’s one of the best of the best, and this is what he puts in his images, Screenshot courtesy MS Virtual Academy.

For more info: Check out the Microsoft Virtual Academy Sessions