Jun 01 2020 05:40 PM
Jun 01 2020 05:40 PM
We are testing deploying a host pool using the new ARM-based deployment and I'm running into an error when deploying new versions.
Source VM is running in Azure (server 2016 datacenter, if it matters)
-Azure Backup taken
-Azure Backup restored as new VM in new VNET
-VM is modified (removing unneeded apps/roles, setting up FSLogix, Sophos sysprep script)
-VM is sysprep'd, OOBE, generalized, and shut down
-Image captured from VM, added to Shared Image Gallery
-New host pool deployed using SIG image, 2 VMs provisioned successfully.
Now, based on guides I've found regarding deploying Spring 2020 WVD, the thought is I should be able to update the "golden image" by:
-Provision a new VM from the SIG image
-Modify VM as required (app updates or whatever else)
-Capture new image
-Add image to SIG as new version
-Deploy new VMs to host pool using SIG latest
However, after the 2nd sysprep, the image created is un-bootable. Fails with this error (below) very quickly, every single time. I have a case created with Microsoft support, but the first info I got from them was "we don't usually see people taking images of images, going to have to research", so I'm not hopeful. But I have seen at least two different guides explain this same process for updating the master image, so I am not sure what I am missing here. I appreciate any help provided!
"message": "The resource operation completed with terminal provisioning state 'Failed'.",
"message": "OS provisioning for VM 'WVDTEST' failed. Error details: This installation of Windows is undeployable. Make sure the image has been properly prepared (generalized).\r\nInstructions for Windows: https://azure.microsoft.com/documentation/articles/virtual-machines-windows-upload-image/ "
Jun 02 2020 11:00 AMSolution
@fgottman hi, this issue seems related to preparing the master image and not WVD. It is Azure compute that reports that the VM cannot be build based on the image provided. Path to for troubleshooting will be to try building a stand alone vm based on the image that has been selected. Once a single VM can be successfully provisioned then that image can be used in the with WVD.
Technically an image from an image should work but if support states its not supported I cannot argue the point.
We have also seen situations where certain applications break sysprep.
Jun 02 2020 01:37 PM
Support hasn't said anything yet. I was hoping the community here might have run into a similar issue given the use case, as I can't find information about this anywhere else. I am going to have a need soon to do the same process with a Windows 10 image for a VDI deployment. I agree that the issue isn't directly related to WVD, but I can't find any other community that is attempting to use images in this way.
The same error occurs when deploying a VM straight from the image (no WVD). Sysprep process completes successfully, and I don't believe it is a conflict with an application, as this would have caused the first sysprep to fail as well.
Or am I just fundamentally misunderstanding the point of using images for WVD? Is everyone just building out new host pools and session hosts any time they need to apply software updates to a hosted application? Do they not maintain a "golden image", even for a desktop-VDI use case? Perhaps I will attempt all of this with a vanilla marketplace image instead of a cloned server, to see if that makes any difference
Jun 03 2020 12:28 AM
@fgottman the process being used in this case is not exactly what we have recommended as best practice (https://docs.microsoft.com/en-us/azure/virtual-desktop/set-up-customize-master-image) and also seems very unique to your context.
When it comes to images in WVD there isn't one answer that fits all organizations out there. From what organizations have shared with me I am not aware of anyone doing the below. (Most have scripts to automate and with fewer steps)
Jun 17 2020 10:59 AM
Jul 09 2020 07:47 AM
That is not possible when a hostpool has been created using a shared image gallery.
You would have to recreate the hostpool.
I don't think the shared image gallery itself is the problem, we have deployed hosts before using image versions from the gallery.
I am now getting the same problem. My colleague had this too. We notice that when we run sysprep with the shutdown option, the VM is nevertheless rebooted. When that happens the image is not generalized anymore.
Jul 09 2020 04:36 PM
Aug 06 2020 11:13 PM
@Startkabels did you ever find a fix for this? Have been using WVD for few weeks now and yesterday trying to update our master image we now get this error when deploying new servers into the host pool.
Any help would be great.
Aug 13 2020 03:43 AM
No we did not.
We actually asked an external consultant for help but he could get this fixed either.
We decided not to look any further because we have decided to move away from WvD for the scenario we were testing it for.
I guess I would just not install the feature update since installing cumulative updates is not a problem.
Investigating this would take some time. You could prepare a new hostpool with a WvD host based on the standard Windows 10 1909 multiuser image from the gallery, then update to 2004 and see if the problem is reproducible with gallery images that were not customized.
Though I cannot tell if you are having the issue with the same feature update...
Aug 13 2020 03:51 AM
@Startkabels, many thanks for the reply. I found out what was causing our issue.
It was our Anti-Virus - Sophos - it has tamperproof feature and this seems to throw out the image when trying to redeploy.
As such we now deploy that after adding new VMs into the host pool