Michael Niehaus has a new post up over on his blog.
I’ve always been a fan of the thinnest image possible. Taking that to an extreme, that means using the original image straight off the Microsoft media. But over time if you did this you’d find that the time required to apply patches to that image becomes unmanageable. (Case in point: I started up a new laptop for the first time with an OEM-installed image that had hooks to require all patches be applied before first logon. It took three hours for that to happen.)
I’ve also been a fan of doing “just in time” patching, which is something that MDT can do too: Instead of patching the image in advance, you can inject updates offline after the image has been applied to the disk but before it boots for the first time. That does often improve the time required, but it doesn’t eliminate it – it adds time when initially injecting the updates offline, and then more time on first boot as the “online actions” for those “offline patches” are completed (you’ll see the messages on the screen during the first boot showing a percentage complete while this is happening).
So reading between the lines, that means I would suggest always creating your own master image containing at least all the current service packs and patches. (Don’t try to install the OS service pack yourself – just download “slipstreamed” media from the Microsoft licensing website, as that’s the ultimate time-saving technique.) So how should you do this? Well, there are a few ways:
- Mount the existing WIM image and just inject the updates offline with DISM. This is certainly doable, but there are three challenges:
- The online actions for these updates will still take some time
- It introduces a “human touch” into the process, unless you go through the effort of automating this to make it a repeatable process.
- It only works for operating system updates.
- Build a new image and install all the updates into that image before sysprepping and capturing the image using a completely automated process. This is my preferred approach, because it’s a consistent process for any other type of update being made to the image.
Not surprisingly, MDT 2010 Lite Touch provides a way to implement my preferred method above – and actually multiple methods that can be used. Let’s go through those methods.
Using ZTIWindowsUpdate.wsf To Install Updates In A System Center Configuration Manager Task Sequence
There are instances were you may want to install updates during a ConfigMgr Task Sequence without using Software Updates in ConfigMgr. Maybe you don’t have it implemented yet, or maybe you are still using WSUS for updates. I’ve seen it asked many times if there is a way to pull updates from WSUS during a ConfigMgr TS, so I just wanted to show you a few ways to handle this situation.
Using ZTIWindowsUpdates.wsf in a ConfigMgr Task Sequence
You can use ZTIWindowsUpdate.wsf in a non-MDT integrated task sequence without very much configuration at all. It basically consists of using the ztiwindowsupdates.wsf script and setting a WSUSServer variable.
In order to use the ztiwindowsupdate.wsf script, we also need to have ZTIUtility.vbs available to the script. So first, lets create a package called “ZTIWindowsUpdate” that contains the ztiwindowsupdate.wsf and ztiutility.vbs script.
Next, we’ll need to add a few steps to our task sequence. First we need to set a value for a variable “WSUSServer”, this tells it what WSUS Server to contact for the updates. This is a Set Task Sequence Variable step.
Next we need to add a step to call the ZTIWindowsUpdate.wsf script. This is a Run Command Line step.
We need to make sure that we reference the package we created earlier containing the ztiwindowsupdates.wsf and ztiutility.vbs scripts.
Using ZTIWindowsUpdates.wsf in a MDT-Integrated Task Sequence
You can also use the script in a MDT integrated Task Sequence. In order to do this, we need to set the variable for WSUSServer and add a Run Command Line step to call the script.
First, you can set the variable in the Task Sequence, OR you can set the variable in your setting package that contains customsettings.ini
Setting the value using customsettings.ini
Setting the value using a Set Task Sequence Variable step
Next we need to add a Run Command Line step to call the script. We don’t have to specify a package for this because the script already exists in the Toolkit Package \scripts directory. (The Use Toolkit Package task sequence step specifies the package that contains the MDT scripts)
Publishing A ConfigMgr Update List to WSUS for use with Microsoft Deployment Toolkit (MDT) Lite-Touch Builds
I’ve been meaning to blog about this for awhile now, but just haven’t had the time. I got a kick in the pants at MMS 2011 this year when Keith Garner mentioned this during one of his sessions (BE32), thanks Keith. I had a client send me the following link from an older post on The Deployment Guys blog.
It basically amounted to, hey this is pretty cool, can you figure out how it works and then blog about it so I can implement it in my environment.
Sure I can…..
First the end result of having this script added to your environment. A new right-click option!
Once it’s all configured and ready to go, you up with a nifty right-click in the ConfigMgr console that lets you take an Update List and publish those specific updates to your stand-alone WSUS server. This allows you then use that WSUS server for your Lite-Touch builds.
By default MDT LTI lets you either pull updates from Microsoft Update or from a local WSUS server. You can do exclusions (WUMU_ExcludeID and WUMU_ExcludeKB), but it’s never been super easy. A major gripe from clients has always been that I’m using ConfigMgr to deploy my images, so why can’t I use the updates I’ve already approved/arranged in ConfigMgr? Well, using this you pretty much can.
I implemented it as described in the original post, but had a few issues. It wasn’t publishing my updates as expected and I kept getting errors. Well it turns out the script was expecting WSUS to be on the standard port (80), however being a ConfigMgr guy, I just have a habit of always setting up WSUS on port 8530, which the script didn’t like since it was looking for it on port 80. I also might have targeted the wrong server a few times, not that I would ever do such a thing. It happens.
I’m not the GodFather, so my PowerShell force is not very strong. So I decided to phone a friend, Keith Garner. His PowerShell force is quite strong, he’s also one of the main developers on MDT. I figured he could help me
What we, err, I mean Keith added was the ability to specify the configured port, then we cleaned up the script a bit so it was easier to modify the values you needed. So there is a section in the script you just need to modify the following section in the script and then you should be good to go. So Keith worked his scripting magic and then I worked my testing magic.
#configure these values
$updateServer = “2008-CONFIGMGR2”
$updatePort = “8530”
#end value configuration
Can I use my ConfigMgr Software Update Point?
The original post says not to use a SUP WSUS server. I’m not sure on the reasoning behind it and I haven’t tested using one. I had another server I could easily configure for the stand-alone WSUS Server. So you are welcome to try it, but it’s recommend that you use a separate server for hosting the WSUS updates.
How do I install the necessary files?
Just download the attached updated script file. I’ve included the paths in the archive (for a 64-bit server) so you just need to extract them out and then reopen your ConfigMgr console and you should see the right-click available to you. If you have a 32-bit server, you will need to move the xml to the appropriate path.
OSD.LifeCycle.PublishToWSUS.xml goes in:
C:\Program Files (x86)\Microsoft Configuration Manager\AdminUI\XmlStorage\Extensions\Actions\a7252c9e-3137-49a4-a8f2-13d17bb8abd0
ApproveUpdatesToWSUS.ps1 goes in:
What do I need to configure in MDT Lite-Touch?
First you need to add the variable WSUSServer=http://servername to your customsettings.ini You will also need to specify the port if not configured on port 80.
In your Task Sequence, you need to enable the Windows Update steps. You can just use one step or both, depending on your preference and what you are all doing in your reference build process.
Was having some trouble getting SCUP to publish updates on my lab today and this TechNet post solved my issue.
I was talking to my buddy Clifton Hughes today and he mentioned an interesting issue that we’ve seen a couple times concerning an error you get when trying to publishing updates to WSUS via System Center Update Publisher. In this particular case, when you try to publish an update you would get the following error in the UpdatesPublisher.log:
Publish: : Exception occurred during publishing: Verification of file signature failed for file: \\<serverName>\UpdateServicesPackages\<AppName_abf10b91-bfa6-44ff-aa54-099e4bf1487d\a7f3d4b2-02b6-4f0c-ab9b-e38c8de9c3f0_1.cab
You may also see this error:
"Exception occurred during publishing: Verification of the signature failed for fil" for each of the updates attempted.
To resolve this one, add the self-signed WSUS certificate to the Trusted Publishers Store and the Trusted Root Certification Authorities store on the Update Publisher machine as follows:
1. Click Start, click Run, type MMC in the text box, and then click OK to open the Microsoft Management Console (MMC).
2. Click File, click Add/Remove Snap-in, click Add, click Certificates, click Add, select Computer account, and then click Next.
3. Select Another computer, type the name of the update server or click Browse to find the update server computer, click Finish, click Close, and then click OK.
4. Expand Certificates (update server name), expand WSUS, and then click Certificates.
5. In the results pane, right-click the desired certificate, click All Tasks, and then click Export.
6. In the Certificate Export Wizard, use the default settings to create an export file with the name and location specified in the wizard. This file must be available to the update server before proceeding to the next step.
7. Right-click Trusted Publishers, click All Tasks, and then click Import. Complete the Certificate Import Wizard using the exported file from step 6.
8. If a self-signed certificate is used, such as WSUS Publishers Self-signed, right-click Trusted Root Certification Authorities, click All Tasks, and then click Import. Complete the Certificate Import Wizard using the exported file from step 6.
9. Right-click Certificates (update server name), click Connect to another computer, enter the computer name for the Updates Publisher computer, and click OK.
10. If Updates Publisher is remote from the update server, repeat steps 7 through 9 to import the certificate to the certificate store on the Updates Publisher computer.
Once you do this you should be good to go.
A special thanks to Clifton Hughes and Vinay Pamnani for doing all the leg work in tracking this down and getting it documented.
Configuration Manager – Installing Windows Server Update Services 3.0 SP2 to support Software Update Services
Download WSUS 3.0 SP2 from here:
Launch the installation. Click “Next”.
Select “Full server installation including Administration Console” and click “Next”.
Click “I accept the terms of the License agreement” and click “Next”.
Select the location to store the WSUS updates and click “Next”.
Select “Use an existing database server on this computer” and click “Next”.
The installation will connect to the database, once it does, click “Next” to continue.
Select “Create a Windows Server Update Services 3.0 SP2 Web Site” and select “Next”.
Click on “Finish” to exit the installation.
When the WSUS Configuration Wizard pops up after installation, simply select “Cancel”.