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.

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

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/

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

Download Slides From ‘Deployment Made Simple’

I’ve received numerous requests over the last week for my PowerPoint presentation entitled ‘Deployment Made Simple’, from my talk last week at the HDI Rio Grande Chapter meeting.

It can be downloaded here.

ASK MDT Guy: Why should I integrate MDT with SCCM?

This week’s question comes from Andrea.

Question: Why should I integrate MDT with SCCM?

Answer: Integrating MDT with SCCM really expands the capabilities of SCCM with over 200 some features. Lots of IT pros will use MDT to build the images, and then use SCCM integrated with MDT to push the image. If you’re learning, you can always just start with MDT, see if it works well and add SCCM into the mix later, it’s what I’d recommend. Learn to walk before you run, right?

The advantages of using MDT+SCCM are pretty big. SCCM by itself is pretty crude, MDT allows you to do things with much more finesse. For example, MDT allows you to leverage the LTISsuspend.wsf script to pause the image creation, customize the image, and capture the image. The copy profile setting will also let you copy tweaks made to the admin profile to the default profile for end users who will be using the image.

Regardless of what you do, make sure you build the image in MDT on a VM, it’ll save you lots and lots of trouble down the road.

MDT in and of itself is great for getting images out, SCCM is a much better tool for managing them down the road.

Again, if you’re just learning I’d really suggest starting with MDT first, and when you’re ready to move up your management, integrate the two. It’s hard to beat imaging systems without even having to touch them.

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

Troubleshooting Windows Deployments

I get lots of e-mails regarding the basics of troubleshooting MDT. Turns out Michael Niehaus pretty much already wrote the closest thing to a book on the subject. Good Reverence. I highly recommend it.

http://blogs.technet.com/b/mniehaus/archive/2012/09/06/troubleshooting-windows-deployments.aspx

Who you calling a WSUS?

Somebody asked me today about pointing MDT to a WSUS server (which is best practice really). Do you really want 50+ machines all pulling updates from the outside at the same time? Yeah, I didn’t think so.

Turns out doing so is a very simple tweak in the customsettings.ini file.

WSUSServer=http://MDT01

Replace MDT01 with the name of your WSUS server. You could use IP, but you’d have to update MDT if that ever changed. Save yourself the hassle and just use hostname.

I’ve also seen it where you need the port of the WSUS server in the ini file. But depending on your WSUS server, you prolly wont need that, just a heads up.

ASK MDT Guy: Do I need WDS?

This question comes from Canadian Luke.

Question: At my day job, I would like to use MDT. Do I need WDS to deploy via PXE booting machines? We use Linux servers, and the company I work for cannot afford (read: does not want to pay for) Windows Servers in the environment.

Answer: It’s important to understand that WDS is just a server role, MDT is the scripts and GUI, and ADK is just the tools. So, no you don’t need WDS, its cool to have, but not a deal breaker.

The ONLY thing you need WDS for is for is PXE boot and Multicasting. Which most people don’t need unless they’re running hundreds of machines (like I used to do when I worked for a large multinational conglomorate) Instead, just use the ISO that MDT spits out and burn it to CD or configure a USB drive to boot with that ISO.

So, the answer is No, you don’t need WDS. In fact, you can run it off a Windows 7 box. Better yet, use a Windows 7 VM on a server. I’ve done this in a pinch, and it works just fine. Now, it wont be a good idea to image 25+ some boxes at a time from a desktop system, but you’d be surprise how well it works for a few PCs here and there.

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