Lab Ops part 15 - Combining MDT with Windows Update Services
If we are going to deploy VDI to our users we are going to still have some of the same challenges as we would have if we still managed their laptops directly. Perhaps the most important of these is keeping VDI up to date with patches. What I want to do in this post is show who we can integrate Windows Update Services(WSUS) with MDT to achieve this:
- Set up WSUS
- Connect it to MDT
- Approve patches
- recreate the Virtual Desktop Template with the script I created in Part `12 of this series
- Use one line of PowerShell to recreate my pooled VDI collection based on the new VDT.
Some notes before I begin:
- All of this is easier in Configuration Manager but the same principles apply plus I can do a better job of automating an monitoring this process with Orchestrator. I am doing it this way to show the principles.
- I am using my RDS-Ops VM to deploy WSUS on as it’s running Windows Server 2012R2 and I have a separate volume on this VM (E:) with the deduplication feature enabled, which as well being home to my deployment share can also be the place where WSUS can efficiently keep its updates. It’s also quite logical, we normally keep our deployments and updates away from production and then have a change control process to approve and apply updates once we have done our testing.
- RDS-Ops is connected to the internet already as I have configured the Routing and Remote Access (RRAS) role for network address translation (NAT)
Installing & Configuring WSUS
WSUS is now a role inside Windows Server 2012 & later and on my RS-Ops VM I already have a SQL Server installation so I can use that for WSUS as well. The WSUS team have not fully embraced PowerShell (I will tell on them!) so although I I was able to capture the settings I wanted and save those off to an xml file when I added in the Roles and Features I also needed to run something like this after the feature is installed..
.\wsusutil.exe postinstall SQL_INSTANCE_NAME="RDS-Ops\MSSQLServer" CONTENT_DIR=E:\Updates
(the Scripting Guy blog has more on this here)
Now I need to configure WSUS for the updates I want and there isn’t enough out of the box PowerShell for that -I found I could set the synchronization to Microsoft Update with Set-WsusServerSynchronization -SyncFromMU, but there’s no equivalent Get-WsusServerSynchronization command, plus I couldn’t easily see how to set which languages I wanted only products and classification (whether the update is a driver, an update service pack, etc.) so unless you are also a .net expert with time on your hands and I am not you will need to set most everything form the initial wizard and hope for better PowerShell in future. In the meantime rather than pad this post out with Screengrabs I’ll refer you to the WSUS TechNet Documentation on what to configure and explain what I selected..
- Upstream Server Synchronize. Set to Microsoft Update
- Specify Proxy Server. None
- Languages. English
- Products. I decided that all I wanted to do for now was to ensure I had updates for just Windows 8.1 & Windows Server 2-012R2 and SQL Server 2012 (my lab has no old stuff in it). This would mean I would have the updates I needed to patch my lab setup and my Virtual Desktop Template via MDT.
- Classifications. I selected everything but drivers (I am mainly running VMs so the drivers are synthetic and part of the OS)
- Synch Schedule. Set to daily automatic updates
I ran the initial synchronize process to kick things off and then had a look at what sort of PowerShell I could use and I got a bit stuck.
I then looked at creating something like an automatic approval rule as you can see here..
only in PowerShell and came up with this ..
Get-WsusUpdate | where classification -in ("Critical Update", "Security Updates") | Approve-WsusUpdate -Action Install -TargetGroupName "All Computers" # chuck in -whatif to test this
which I could run behind my schedules update. Anyway I have now set some updates as approved so I can now turn my attention to MDT and see how to get those updates into my Deployment once they have actually downloaded onto my RDS-Ops Server. BTW I got a message to download the Microsoft Report Viewer 2008 sp1 Redistributable package on the way.
Top Tip: If the MDT stuff below doesn’t work check that WSUS is working by updating group policy on a VM to point to it. Open GPEdit.msc expand Computer Configuration -> Administrative Templates -> Windows Components -> Windows Updates and set the Specify Intranet Microsoft update service location to https://<WSUS server>:8530 in my case https://RDS-Ops:8530
If I now go into the MDT Deployment Workbench on my RDS-Ops VM I can edit my Task Sequence and as with with my last post on installing applications it’s in State Restore node that my Updates get referenced..
Note there are two places where updates can be applied bot pre and post an application install and both of these are disabled by default. The post application install would be good if you had updates in WSUS that applied to applications not just the OS as I have just set up. The application updates could then be added on top of the base application install. This is a nice touch but how does MDT “know” where to get the updates from? We can’t really set anything in WSUS itself or apply any group policy because the machines aren’t built yet. The answer is to add one more setting into the rule for the Deployment Share aka CustomSettings.ini WSUSServer=https://<WSUS Server>:8530 as I left the default port as is when I setup WSUS ..
[Settings]
Priority=Default
Properties=MyCustomProperty
[Default]
DeploymentType=NEWCOMPUTER
OSInstall=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerBackup=YES
SkipBitLocker=YES
EventService=https://RDS-Ops:9800
SkipBDDWelcome=YES
WSUSServer=https://RDS-Ops:8530
SkipTaskSequence=YES
TaskSequenceID=Win81Ref
SkipCapture=YES
DoCapture=SYSPREP
FinishAction=SHUTDOWN
SkipComputerName=YES
SkipDomainMembership=YES
SkipLocaleSelection=YES
KeyboardLocale=en-US
UserLocale=en-US
UILanguage=en-US
SkipPackageDisplay=YES
SkipSummary=YES
SkipFinalSummary=NO
SkipTimeZone=YES
TimeZoneName=Central Standard Time
SkipUserData=Yes
SkipApplications=Yes
Applications001 ={ec8fcd8e-ec1e-45d8-a3d5-613be5770b14}
As I said in my last post you might want to disable skipping the final summary screen ( SkipFinalSummary=No) to check it’s all working (also don’t forget to update the Deployment Share each time you do a test) and if I do that and then go into Windows Update on my Reference Computer I can see my updates..
So to sum up I know have MDT setup to create a new deployment which includes any patches from my Update Server, and a sample application (Foxit Reader). so I can keep my VDI collections up to date by doing the following
- Approve any updates that have come in to WSUS since I last looked at it OR Auto approve those I want by product or classification with PowerShell
- Add in any new applications I want in the Deployment Workbench in MDT.
- Automatically build a VM from this deployment with the script in part 13 of this series which will sysprep and shutdown at the end of the task sequence.
- Either create a new collection with New-RDVirtualDesktopCollection or update an existing collection with Update-RDVirtualDesktopCollection where the VM I just created is the Virtual Desktop Template.
Obviously this would look a little nicer in Configuration Manager 2012R2 and I could use Orchestrator and other parts of System Center to sharpen this up but what this gives us is one approach to maintaining VDI which I hope you’ll have found useful.
Comments
- Anonymous
September 29, 2014
Great article but I think there is a typo :
"This is a nice touch but how does MDT “know” where to get the updates from? We can’t really set anything in WSUS itself or apply any group policy because the machines aren’t built yet. The answer is to add one more setting into the rule for the Deployment Share aka ControlSettings.ini "
You probably mean CustomSettings.ini
m - Anonymous
September 30, 2014
good catch - Anonymous
November 19, 2014
thanks