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!”

Quick Trick: Configure Adobe Flash AutoUpdate

In a perfect world, Adobe Flash would have died a long time ago. In this hypothetical perfect world, we’d also have everybody on Windows 10, but we don’t live in a perfect world, and so consequently, in 2016 we’re still installing Flash ActiveX in 32bit Windows 7 installs. I don’t like it anymore than you do, but at least we can make sure that the copy of flash we’re installing is updating, and doing so silently; automagically and checking EVERY time it starts.

This is simply done by using a MMS.cfg file. Two settings will need to be set, SilentAutoUpdateEnable to 1 and AutoUpdateInterval to 0 (Everytime, No Interval). To be OCD, I also explicitly set AutoUpdateDisable to 0 from the start. This file then needs to be in the System32\Macromedia\Flash folder for 32-bit systems. 64bit will need it copied to SysWOW64\Macromed\Flash (thanks Sean!). To do this we need a script that we can bundle with the Adobe Flash install.

MMS

Back in the day anytime I needed to copy a file from server to client during a deployment, I was creating a new script from scratch. Eventually, I just started using a basic template. This was all of course, before I found the CoreTech file copy script.

Once you have created this MMS.cfg file, create a folder with the Flash folder, place the cfg file inside, and copy the coretech folder inside like below.

Flash

Import this into the share as an application. Use The syntax below and bundle with Adobe Flash installer.

CopyFIles

SEE ALSO: http://www.adobe.com/devnet/flashplayer/articles/flash_player_admin_guide.html

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.

Office01
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.

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

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

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

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

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

Office07
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

Overriding Customsettings.ini in MDT 2013 Update 2

This is an old trick that I still have to show people once in a while because this is something I wish I knew years ago. It’s pretty neat if you ask me. This is basically how you can have your cake and eat it too with your standalone MDT lite touch infrastructure.

Forget PXE and USB. MDT just runs even better from UNC. Using the core .vbs that kicks off the wizard from the \\SERVER\Share$\Scripts folder, you really can just make shortcuts to the wizard with switches that call conditions that override the settings in your global CS.ini file. This allows you to add an additional layer of control without needing to mess with your CustomSettings.ini file.

These conditions can include but are not limited to:

  • Task Sequence (specify TS, bypass prompt in wizard)
  • Apps (Include, or Exclude Bundles)
  • Hostname (Prompt & Override defaults called in Customsettings.ini)
  • State Restore (Wipe & Load vs. Refresh)

So, even if you’re running LTI without SCCM, you can call out to the LTI engine and use switches to the specify what TS you’re running and what prompts you do or do not run from the wizard.

For example you could create shortcuts that kick off a refresh with specific conditions that override the rules in your CustomSettings.ini

  • Build Image TS (Set Capture)
  • Call 32bit TS Win7 no prompts
  • Call 64bit TS Win7 no prompts
  • Call Windows 10×64 w/ prompts
  • Call Windows 10×64 w/o prompts
  • Call all prompts (Task Sequence, Domain, Name, Applications ala cart)

 

Shortcuts

Create Shortcuts and point them to the Litetouch.vbs

Shortcuts2

Use switches to explicitly call a task sequence, or enable prompts you usually disable.

EXAMPLES:

Override Tasksequence called in customsettings.ini

\\SERVERNAME\SHARE$\scripts\litetouch.vbs /skiptasksequence:yes /tasksequenceid:win7SP1-32bit

Override Skip Prompt in customsettings.ini

\\SERVERNAME\SHARE$\scripts\litetouch.vbs /skiptasksequence:no /SkipApplications:no

Override Applications and/or Locale called in customsettings.ini

\\SERVERNAME\SHARE$\scripts\litetouch.vbs /SkipApplications:no /SkipLocaleSelection:no

Override Domain Settings and/or timezone called in customsettings.ini

\\SERVERNAME\SHARE$\scripts\litetouch.vbs /SkipDomainMembership:yes /skiptimezone:yes

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:
1
Add a step to the task sequence that detects for product in the Capture State
Step Two:
2
This step creates a task sequence variable and sets it to true if application is detected
Step Three:
3
Add a step to the task sequence that installs product in the State Restore
Step Four:
4
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.

MDT 2013 Update 1 Is Out!

After much waiting, Microsoft Released MDT 2013 Update 1 (version 6.3) yesterday. It will support windows 7,8 and 10. (No Vista). The lack of Vista support is nothing new, and hardly a tragedy. Just pick up the Windows 10 ADK, and a Win10 ISO and

MDT2013

http://www.microsoft.com/en-us/download/details.aspx?id=48595

Johan’s already got a pretty excellent upgrade guide here: http://deploymentresearch.com/Research/Post/504/A-Geeks-Guide-for-upgrading-MDT-2013-to-MDT-2013-Update-1

ASK MDTGuy! Redundant Windows Updates?

Got a great question from a long time reader today:

I’ve googled this and cannot seem to find a good explanation.  What are the differences between the following with regards to windows updates:

  1. Task Sequence, Windows Update (Pre-application)
  2. Task Sequence, Windows Update (Post application)

The updates are taking an obscene amount of time to apply (2 hours).  And I just updated the image with updates on 7/1.  So, I’m just trying to find anything I really don’t need to be doing (redundant steps).

Both are simply steps in the task sequence that will pull windows updates from either Microsoft’s public windowsupdate.com site or if you have MDT configured to do so; pull from a WSUS server. I use WSUS at work, and it runs like a champ. There’s two separate steps in the default task sequence (pre-apps and post apps) incase you’re installing office or some other MS apps, its going to run updates for those again, post application install. This is particularly helpful when you’re building images, or you’re installing Visio for instance as part of a bundle as part of a state restore for a limited amount of users.

WinUpdate

As an image gets older and older, the updates will take longer and longer to apply. Fun story, I once had an image that took 28minutes to run as a task sequence, over the course of a year and a major office service pack later, take almost two hours to run. Its not that the network was getting slower, it was the windows updates steps that were pulling from a public site (we had no WSUS at that location) and then patch, and then patch again, and those were taking longer and longer to run as the image got older.

Best advise is to get a WSUS box up ASAP, and make sure you have a build lab that you use for building images.

My build lab is a separate deployment share separate from my production share that’s fully automated and optimized for building images once a month after patch Tuesday, I call that day image thurdsay. We reimage a lot where I work, so having a freshly patched image keeps our image times down to a minimum.