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

Ask MDTGuy: Adding Applications to MDT as .exe

Got an e-mail from a reader today about getting MDT to install a file as an exe.

In a perfect world, we’d all have MSI files to install software from because there is largely almost no guess work other than what paramaters to set if we need to. Sadly though, it is often the case with stand-alone exe files there is no documentation, and we’re playing the guess and check game.

Finding the magic switch to install software can be a real pain. The best thing to do is to try it on a PC first until you get it then add it to MDT. I like to copy the file to the desktop of a VM, snapshot it, and open a command prompt from within the folder. This is done easily by typing CMD into the address bar of the folder from explorer. This way you can nail it down first, then add it to MDT.

I usually start with the most obvious switches, /s, /q, -s or -q.

Sometimes however, you need to ask nicely and use /?, -?, /h or -h to get it to tell you what to do. This works more often than you think. It’s a way to ask the executable for help and in some cases it works, the package creator spent a few minutes leaving this behind for us sysadmins. For all the developers out there who do this, we salute you!

Microsoft installers are USUALLY pretty good about using /passive /norestart on stuff like dotNetFramework and other stuff, if all else fails, there is the googles. Usually putting in the name of the product or installer file name followed by silent or unattended will do the trick.

As Johan says, “Happy Deployments”!

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!

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…
https://scriptimus.wordpress.com/2011/06/08/mdt-2010-wiping-disks/

Googling the issue, I found this…
https://social.technet.microsoft.com/Forums/en-US/f066e0b5-013a-4baa-9566-7eef8a50e177/wiping-a-disk-with-mdt-task-sequence

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

crts3
Create a Standard Client Replace TS
crts2
Note that by default there are conditions to running these steps. I added WipeDisk=True
crts
Now, just browse to your share and run your shortcut to the wizard. Don’t run MDT from UNC? You’re doing it wrong.
crts4
Yeah, We got a task sequence for that!
crts5
WinPE is downloading! Reboot is Next!
crts6
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.

http://syswow.blogspot.com/2012/05/secure-dod-drive-wiping-with-sccm.html

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.

A connection to the deployment share (\\Servername\Share$) could not be made. DHCP lease was not obtained. Retry works just fine.

I hadn’t seen this one for a good minute, and I remember why. There are several reasons you can get this error. Sometimes you just need the driver. However the error screen will almost always tell you that you’re missing a driver, and no amount of clicking retry will fix that. Other times you’re genuinely seeing some kind of delay with the assignment of a DHCP address and fancy new hardware boots quicker than the network can get the systems IPs.

I know in the past I was able to add some kind of delay to get MDT to wait and then try to resume the task sequence, but I couldn’t remember what or where, so off to the googles I went…

I found this:
https://4sysops.com/archives/resolving-a-connection-to-the-deployment-share-could-not-be-madeerrors-in-mdt/

Then I remembered, yes, there is a delay we can add to the main heart and soul of MDT, the script of all scripts, the holiest of holies, the LiteTouch.wsf I hate doing this, I hate the idea of editing the scripts provided by Microsoft, because you never remember what you modified and where after an upgrade or after building a new share. But then again, you know what they say, “When in Rome Do as The Vandals!” Also, I’m tired of having to walk over to computers in our training room and clicking retry, so there’s that too.

Anyway, like Kyle describes in the abovementioned article, if it is a genuine delay in the DHCP assignment of an IP, we’ll need to add a delay in the LiteTouch.wsf script.

dhcpdelayfix

Look around line 1268. In this case, I’m adding a whole 10 seconds because I don’t want to come back and do this again if 5 seconds doesn’t cut it so I add wscript.sleep 10000 at line 1270. Lines 1269 and 1271 are optional snark that in theory will help me find it if I ever need to again.

Your Milage May Vary and as Johan says, “Happy Deployments!”

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.