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: https://deploymentresearch.com/Research/Post/648/Dynamically-select-OS-Image-in-the-MDT-Lite-Touch-Task-Sequencehttps://deploymentresearch.com/Research/Post/648/Dynamically-select-OS-Image-in-the-MDT-Lite-Touch-Task-Sequence

Designing a Hybrid Image

For some time, thin images were all the rage, IT Pros were trying to keep images as thin as possible and let the applications get installed either as part of the next task sequence or from group policy. This was in response to the old school and monolithic images that had become prevalent over the prior decade. In the past, you’d just create one thick image, per model and roll that out with everything, regardless of whether the user needed all these applications or not.

I assert however that like most things in this world, the best solution fits somewhere close to the middle of two extremes. Organizations need a balance of time and of disk space. This solution is colloquially known as a hybrid image. It allows us to keep common applications in the image and then let the supplemental applications come only later to those who need them.

First things first; don’t build your images on physical hardware. I can’t tell you how many times I still get emails from people who do this. If you are building images on physical hardware like it’s 1999, you’re doing it wrong. Always, always, always build your image in a VM and capture it via standard client task sequences. This ensures your image runs on everything, laptops, desktops, tablets. Let MDT install drivers for you. It’s that whole rule of working smarter not harder at hand here.

Next, build a hybrid image. Essentials like Office, Adobe Reader, and Some Core Line of Business Applications should go in your image. Leave Flash and Java and other commonly updated optional apps out of the image. The whole point of imaging is saving time, and while yes you can get MDT to drop a raw windows wim file and do the whole office and patching for you, this is not something you want to do repeatedly. You don’t need five dozen some PCs all pulling six month old office patches across a 40 meg connection across your WAN just because you can.

Fundamentally, it comes down to striking a balance between having a flexible deployment over a fast one, but with some work, you can have both.

There’s lots of ways this can be done. Applications can be installed by form factor. This could include rules your MDT ini that install VPN clients only on your laptops. Applications could also be installed by location, so that only desktops at a certain location get a certain program. This is also done by rules in the ini file based on gateway. Finally, you can also install applications based on the presence of specific hardware. Using some WMIC queries, conditions can be added to task sequences that install applications that are only needed when certain devices are plugged in.

That last example takes some work, you need to know the hardware IDs of the devices, and the devices would have to be standardized, but the point is that after some trial and error, You’re able to set up your imaging system to work for you, so that you can kick off a reimage, tell your user to go to lunch, and when they get back, they’re back to work, and you never get bothered again by them. Its truly a beautiful thing.

MDT can also be configured to detect and reinstall certain software during a refresh. During the gather phase, conditions can be set to create task sequence variables that would detect the install of software like Adobe Acrobat for instance. If MDT detects that Acrobat Pro is installed, the variable gets set and MDT will then install that application only on those PCs. The gotcha on this one is that the install has to usually needs to come from an MSI, but the framework exists, and could be used for any registry key if one wanted to go down that rabbit hole.

Build an image factory. Yes, this possibly one of the coolest things you can do with MDT. Some people don’t know this, but MDT is more than just an imaging system, its an entire automated systems deployment framework and as such it can be utilized to automate the entire image build process. This has allowed me to automate monthly builds of images, and keep our deployment times in the 25-30 min range.

ImageFactory

Setting wallpapers, start menus, and desktop icons can all be scripted, and I’ve blogged extensively on some of these techniques, but the idea here is more of using MDT to build the configuration for you so that you know that the image you create tomorrow is more or less identical to the image you made last quarter just this one is fully patched, and that’s truly working smarter not harder.

Questions? Comments? Reach Out to Me Here!

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.

See:
https://technet.microsoft.com/en-us/library/cc742162(v=ws.11).aspx
https://ss64.com/nt/reg.html

What do you mean “PowerShell is required to use the Deployment Workbench”? Powershell IS installed!

Spent some time setting up a new laptop today and saw this error: PowerShell is required to use the Deployment Workbench. Found that to be weird considering I JUST used powershell to install MDT. Turns out I had forgot to set the execution policy back to RemoteSigned. Today, I learned: Powershell needs to be set to RemoteSigned the first time you run MDT.

Capture

Set-ExecutionPolicy RemoteSigned –Scope CurrentUser

See: https://www.inframon.com/initialisation-error-loading-the-deployment-workbench-in-windows-server-2012-2/

Lenovos Not Identifying As Laptops, Chassis Type 31

Just got a pallet of fresh off the truck Lenovos in today, and of course if they don’t get the shiny new Windows 10 image here quick I won’t hear the end of it. Naturally, the first thing I want to do is image them, but I found it strange when I was prompted for the system type when assigning the hostname from the LTI wizard.

The wizard was showing %ComputerTypeName% and the serial with an error, that hostname was too long it said.

The only explanation was that for some reason these systems were failing to identify as laptops, as my customsettings.ini file is supposed to set hostnames based on a basic FormFactor and Serial Format. To make matters worse, this throws a wrench in all kinds of stuff like what OU and applications they get during deployment, so this was a problem that needed an immediate solution. Some googling led me to the wmic command to determine “chassistype” and I got a chassis type 31. Then I found this…

https://social.technet.microsoft.com/Forums/office/en-US/a38f1593-34d2-4434-a510-fc89c35cb4f8/mdt-chassistype-31?forum=mdt

Chassis type 31 is “convertible” and I wondered, “Isn’t this all in the ZTIGather.wsf?” Sure enough, adding ,”31″ to the end of ZTIGather.wsf solves the issue….

It’s Friday, I’m going home. Its been one of those weeks, and next week is go time…

Update 4/6: Just got an e-mail from Paul at 1E mentioning I should “include a reference to table 17 in this document: http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.1.1.pdf. It lists the official chassis type and thus gives us all confidence that we’re handling the new values correctly.” Thanks Paul!

When in doubt, Run LTICleanup.wsf

Look, I don’t work for Microsoft, I just support their software. I have no idea what the hell -2147024890 or even what 0x80070006 means. It’s computer babble for something bad happened, sorry. I could also look up the hex code and change the hex into something else and check the log files, all of which I did, but nothing jumped out as to why. The task sequence ran fine on everything except this ONE pc in the lab, so What the heck?

When in doubt, run the LTICleanup.wsf file from WinPE. Press F8 and run LTI Cleanup. If you’re doing in place upgrades, you can even just run it from plain old windows. Browse to the \\Servername\Share$\Scripts folder and run LTICleanup.

lticleanup

That fixed it, go figure. Your milage may vary, but sometimes when MDT is being dumb, just run the cleanup and start from scratch.

Testing CustomSettings.ini The Quick And Dirty Way

Had the privilege and honor of studying under both Johan Arwidmark and Mikael “The Deployment Bunny” Nystrom in Redmond WA for a week this last summer. During the session Mr. Nystrom brushed up on using ZTIGather.wsf to debug customsettings.ini verbosely from the command line instead of actually kicking off a deployment and crossing your fingers.

I had known it was possible, and I had done it before, but didn’t need to do it in a long, long time until today and in an attempt to find his again, I stumbled across this…

https://deploymentbunny.com/2011/04/27/quick-and-dirty-testing-customsettings-ini-variables-in-mdt/

In the article, he’s referring to a local install of CMTrace, in this example I am running it from the server. I figure the PC I am testing on may not always have it installed, but the idea is the same, run the gather and run CMTrace and open the log file! Its that easy! My buddy from Questa thinks this is pretty cool! Thanks to Mikael for the good idea!

 

CSTS.png
CMTrace is a beautiful thing, calling it programmatically is even more beautiful…

 

 

cst
This version allows you to call it from any PC at anytime.