Freigeben über

Approving Windows Updates in an MDT 2010 Standalone Environment from a ConfigMgr Software Update Point

  • Artikel

You’ve no doubt read some of the benefits around using the Software Update Point features of ConfigMgr. However, if you are already using MDT standalone as an Image Engineering environment – there is sometimes a duplication in having to manage software updates in both environments. The most common solution is to set up an external standalone WSUS server for your reference machine to pull down updates. However, it would be ideal to have a single place to manage the approval and download of updates for both the deployed machines in ConfigMgr environment and the reference machine during an image capture in the MDT standalone environment.

To create a right click action to approve Update Lists in a standalone WSUS Server:

1. Create your Software Update Lists in ConfigMgr and assign them to a Deployment Package. Download and approve the updates as you would normally in ConfigMgr by creating a Deployment Template.

2. Synchronize your external standalone WSUS server with Microsoft to pull down updates. Note this server should not be a Software Update Point.

3. Download the attached scripts to create a right click action:

a) Copy the a7252c9e-3137-49a4-a8f2-13d17bb8abd0 folder to your ConfigMgr site server  e.g. %ProgramFiles%\Microsoft Configuration Manager\AdminUI\XMLStorage\Extensions\Actions. Substitute the first part of the path with your ConfigMgr path.

b) Copy the ApproveUpdatesToWSUS.ps1 script to a new folder at %ProgramFiles%\OSDLifeCycle\Scripts . Ensure that powershell is installed on your server and that the execution policy is set appropriately.

c) Edit the ApproveUpdatesToWSUS.ps1 file and replace MYUPDATESERVER with the name of you standalone WSUS server.

image

4. Reload your ConfigMgr Console using an account that is the WSUS Administrators local group on the WSUS Server.

5. Right Click on your update list and you should see “Publish these updates in a WSUS Server”. NOTE: This will accept the EULA of any of the updates in the Update List. Ensure you review any EULAs in ConfigMgr before choosing this option.

Publish Right Click action

6. Ensure the updates were approved successfully and close the powershell window.

7. In the customsettings.ini file of your MDT Image Engineering environment set the WSUSServer variable to equal the location of your server (e.g.WSUSServer=https://MyUpdateServer)

8. Update your Deployment Share

This post was contributed by Aly Shivji a consultant with Microsoft Services - U.S. East Region.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .

ApproveUpdatesinWSUS.zip

Comments

  • Anonymous
    January 01, 2003
    I’ve been meaning to blog about this for awhile now, but just haven’t had the time. I got a kick in the

  • Anonymous
    January 01, 2003
    Here is a great post over The Deployment Guys Blog.  A client actually sent this to me today and

  • Anonymous
    January 01, 2003
    Excellent - thank you!

  • Anonymous
    January 01, 2003
    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. Install all updates from Microsoft Update directly This is the easy way, as long as you have good internet bandwidth (all updates are downloaded from the internet) and a direct path to these downloads (as we don’t really support proxy servers in the MDT task sequence), and always want to install all critical updates.  (We skip language packs, drivers, and service packs by default, and you can exclude additional updates, but the exclusion process requires a little work.) To use this method, all you need to do is search your task sequence for the following steps: Windows Update (Pre-Application Installation) Windows Update (Post-Application Installation) Enable both of them, and then build a new image – that’s all there is to it.  (Why are there two steps you ask?  Well, the first might be required in order for the subsequent application installs to complete; the second might be required to patch the applications, e.g. Office, after it’s installed.  If the second step doesn’t need to install any additional patches, it won’t take very long.) Install all updates approved on your WSUS server To give you better control over patched put into your image, you may only want to install approved updates.  If you are using Windows Server Update Services (WSUS), then you already have such an approval mechanism in place, all you need to do is tell the task sequence to talk to WSUS instead of going to the internet.  This is pretty simple too: Enable the same “Windows Update” task sequence steps listed in the previous section (two of them). Add an entry into the [Default] section of CustomSettings.ini that says: W

  • Anonymous
    January 01, 2003
    None that I know of. We use this scenario all the time.

  • Aly

  • Anonymous
    January 01, 2003
    Excellent post.  It just saved my customer an amazing amount of time and hassle standing up multiple new standalone WSUS servers.  There was a lot of politcal tension about how to approve the updates.  This gave them low admin overheaded management of the update approvals using SCCM as their authoritative source. There is one small issue right now though.  Any update that requires the Eula acceptance is not functioning as intended.  Easy fix though! The AcceptLicenseAgreement() method has the word License mispelled, you can see it in the comment above as well. Great post as always guys!

  • Anonymous
    February 03, 2010
    I made a quick edit to the PS script to take a list of updates as a CSV.  This is for folks who can't install right click tools (or powershell) directly on a site server, but would still like the functionality.  Simply export the Update List to CSV and put the path to CSV on the powershell commandline: powershell ApproveUpdatesCSV.ps1 updatelist.csv param($csvlist)

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of

included script samples are subject to the terms specified in the Terms of Use (http://www.microsoft.com/info/cpyright.mspx).

#####################################################################################

main                                                                              #

##################################################################################### [void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") $updateServer = "TestWSUS.adtest.local" $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($updateServer,$false) $tgs = $wsus.GetComputerTargetGroups() foreach ($tg in $tgs)    {    if ($tg.Name -eq "All Computers") { $alltargetgroup = $tg.ID}    } write-host $tg.ID $group = $wsus.GetComputerTargetGroup($alltargetgroup) $action = [Microsoft.UpdateServices.Administration.UpdateApprovalAction]::Install $wsusupdates = $wsus.GetUpdates() $updateslist = Import-Csv $csvlist foreach ($itemID in $updateslist)    {    $articleID = $itemID."Article ID"    write-host $articleID    foreach ($update in $wsusupdates)        {        if ($update.KnowledgebaseArticles -eq $articleID)            {            if ($update.HasLicenseAgreement -eq $true)                {                $update.AcceptLicenceAgreement()                }            $update.Approve($action, $group)                write-host "approving " $update.KnowledgeBaseArticles            }        }    }

  • Anonymous
    April 28, 2010
    any issues with installing WSUS on the same server as MDT 2010

  • Anonymous
    May 03, 2010
    We are using MDT 2010 to deploy Windows 7 Ent x64.  When trying to use the 'Windows Update' step with the parameter configured in our customsettings.ini of WSUSServer=http://SERVER01:8530, the ZTIWindowsUpdate.log reports "[Scan complete, ready to install updates. Count = 0]."  The WSUS server that we are using is an SCCM 2007 SP2 R2 Software Updates point.  Are there configuration changes that we can make to the WSUS to allow SCCM to still utilize it as an update point AND allow MDT to detect and install relevant patches or do we need a seperate WSUS server for use with our MDT process?

  • Anonymous
    August 19, 2015
    Is there an update of this for SCCM 2012?