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:
Some notes before I begin:
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..
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 http://<WSUS server>:8530 in my case http://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=http://<WSUS Server>:8530 as I left the default port as is when I setup WSUS ..
SkipPackageDisplay=YESSkipSummary=YESSkipFinalSummary=NOSkipTimeZone=YESTimeZoneName=Central Standard Time
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
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.
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