VMWare View Agent 7.7 installation with Persona management brings the Windows 10 golden image into automatic repair state

During the PoC project of VMWare Horizon View 7.6 for our customer we have noticed quite a weird issue with the View agent. In short, after the installation of View agent 7.7, any Windows 10 golden image gets into automatic repair state and is not able to boot normally. This issue had been reproduced on Windows 10 1803 and Windows 10 1809 LTSC. While this problem arises with Agent 7.7, there are no issues with Agent 7.6. In addition, the main reason is Persona Management component. You will not experience the issue if you are not using Persona Management in your environment.

We have been testing desktop pools with the View Agent 7.6 and Persona Management and all the desktops were working quite good. All the golden images are configured using Local GPOs to define the settings of View Agent software, including the Persona Management component. Unfortunately, we were not able to use Domain GPOs for these VMs and VDI desktops due to some security restrictions of the customer.

My colleague has configured a test VM with some modifications to try different solutions. In addition, he decided to upgrade View Agent to version 7.7. This test VM performed this upgrade successfully showing no errors. That is why we have not been expecting any issues. However, when I tried to install the View Agent on our golden images I've been getting broken golden images every time. I have spent a lot of time trying to find out the reason.

At first, I tried to upgrade the View Agent. I've checked that Agent 7.6 is installed and running correctly.

Also, I checked that Persona Management service is up and running.

Next, I've launched the installer and verified that installation of Persona Management component would be performed during the installation of the View Agent.

Finally, I performed a reboot which is required after the installation. And the golden image came into the automatic repair state. There was no way to revert it, luckily I have made a snapshot of VM before the golden image modification.

Russian text on the image: Preparing automatic repair.

I decided to check the logs of the View Agent using a command line tool available during the automatic repair. You may check the log files located at C:\ProgramData\VMWare\VDM\logs folder. There are multiple files and some of them are not available. However, I tried to open the log of Persona Management and here is a content of this  file:

So, we have got a failing driver after the installation and there was the only option to start over. I have tried to disable Local GPOs for Persona Management and found out that the View Agent is not failing without it. To find out the reason, I decided to perform an upgrade of the View Agent without a following reboot after the installation, so I would be able to check the event viewer. I noticed a weird event in the System event log, stating that a service named «VMWVvpfsd» could not be started due to an error during the digital signature verification.

To find out the difference between two versions of the View Agent I decided to revert the VM to the previous snapshot and to verify the versions of Persona Management files. The file is located at the C:\Program Files\VMWare\VMWare View\Agent\bin\ folder and is named VMWVvpfsd.sys. Below you can see the properties of these files.

You may notice that the View Agent 7.6 uses Persona Management version 7.5 while the Agent 7.7 uses version 7.7 of Persona Management. I tried to replace the file after the upgrade of the View Agent and prior the reboot. It obviously worked but we considered this fix as inapplicable.

Finally, we were able to find out an appropriate solution. To get rid of this ridiculous issue you need to disable Secure boot in the VM options prior the installation of the View Agent 7.7.

VMWare has provided an article about the Persona Management issue which looks quite similar: https://kb.vmware.com/s/article/60454. Here is the cause of the issue from the article: The driver cross-signing has expired and Microsoft enforces every kernel driver to be signed by Microsoft signing server. Note that, this doesn't occur if windows boot is not secure boot.