Dec 16 2019 07:00 AM
Dec 16 2019 07:00 AM
Would be grateful if someone from MS could advise on the best method for patch management on WVD. From the following document it is advised to disable automatic updates
My questions, are therefore as follows
- Is there currently a best practise from MS for keeping the WVD Windows 10 VM's secure from a security patch perspective. I can't see any documentation on this?
- If automatic updates are disabled what is the method by which VM's should be updated. Can this be done via Azure Update Management?
- If automatic updates are disabled how does this impact Windows Defender updates.
I am hoping that the solution to this is to constantly keep the 'master image' updated and then re-deploy to the host pool? The architecture of my WVD tenant is a multi-host pool 'pooled desktop' configuration.
Dec 16 2019 07:40 AM - edited Dec 16 2019 07:42 AM
Best practice is to take your snapshot before the sysprep, patch it, snapshot it again, sysprep and redeploy the WVD pool. You can deploy to the same pool of servers, just make sure to enter the correct total of servers you want to obtain.
Deletion of the old servers can take place after deployment.
For Defender updates, you can create a scheduled task to execute the following:
Dec 16 2019 07:53 AM - edited Dec 16 2019 07:56 AM
Thanks for the reply knowlite. I think that is probably the best option for pooled desktops, but for dedicated personal desktops where users will have local admin rights I'm note sure that is going to be the best solution? In the scenario I am looking at, there will likely be deviation on the personal desktops away from the initial 'master image' with respect to applications installed etc.
Dec 16 2019 04:28 PM
You can use this ARM Template for updating WVD.
Dec 17 2019 12:45 AM
Thanks for the link. I've see this and believe this along with applying security & feature updates to the 'master image' is the best method for pooled desktops. If you are using personal desktops that users are modifying (deploying software etc) you cannot remove their persistent vdi's and give them a brand new one every time the OS needs patched. Its not feasible. I think until app attach is in GA its not a straight forward process for applying updates to personal desktops
Dec 17 2019 04:28 AM
Dec 17 2019 05:14 AM
I probably didn't explain it well enough. We would want to give a group of users, possibly up to 20 a personal desktop with admin rights. They could be using a significant number of different applications (probably too many to have in a master image ). Also these applications could vary quite frequently for different development staff. In short ' image management' becomes too intensive from an app perspective. I do take the point that app attach is not necessarily a silver bullet but it does help with the separation of the apps from the OS and also keeping the updating of the apps and the OS segregated.
Effectively I was trying to find out if there was any reason why I couldn't just allow the personal desktops to autoupdate using windows update. I understand the inherent risk associated of adopting this method with respect of an update causing an issue on the desktop.
Apr 22 2020 08:20 AM
We use SCCM to patch WVD - Personal Desktop on monthly basis. We consider it no different than regular corporate desktop. This way, there is no new process/project/standards created for handling WVD - Personal Desktop. Works very well with existing patching operations. End-users are already familiar with how patching works on corporate desktop, so they don't have any issues with WVD - Personal Desktop patching process.
May 12 2020 11:22 AM
FYI, Based on extensive testing, I found WVD persistent VMs created based on "Microsoft Windows 10 + Office 365 ProPlus" image from Azure Marketplace is not working. SCCM CB 1906 version or CB 2002 version is unable to patch these VMs using the regular SCCM patching process SUM - (Software Update Management). And feedback or solution will be helpful.
Jun 05 2020 07:57 AM
with MECM CB 1910 and above, it's possibile to update Windows Virtual Desktop Session Host. It's necessary to select "Windows Server, version 1903 and later" from Products section in Software Updates Point Component Properties.
Jun 05 2020 08:16 AM
On ConfigMgr CB 2002 version, each WVD - Shared Desktops or Persistent Desktops are reported as "Windows Server" Operating System on ConfigMgr. Don't know why?
So, to manage WVDs with ConfigMgr, we made appropriate changes on ConfigMgr Collection's Limiting Collection and set to - "All Systems".
Jun 05 2020 08:33 AM
As Christiaan Brinkhoff says (https://twitter.com/brinkhoff_c/status/1244557292214915072), Windows 10 Enterprise Multi-session has a different OperatingSystemSKU (175) and it's not a client-sku.
Apr 14 2021 02:34 AM
Apr 14 2021 03:47 AM
as indicated in my previous post, in order to update the WVD Session Hosts through Microsoft Endpoint Configuration Manager it is necessary to select "Windows Server, version 1903 and later" from Products section in Software Updates Point Component Properties.