We are using Horizon 7.13.0 and publishing Instant Clone pools. One pool that we have been using has users sometimes logging in and getting "The User Profile Service service failed the sign-in. User Profile cannot be loaded." with an OK button that closes the session when the user hits it. Any user that tries to login to this VM gets this error. Other machines that are cloned from the same CP-parent machine will work correctly.
After some investigation, i found that the C:\users folder is empty on the machine that gives this error. If I copy a Default folder from C:\users on a working VM users can then login to the machine with no issues.
Any ideas what could cause this?
We are having the same issue all of a sudden. It doesn't happen to all the desktops but roughly 1/3 of them are missing the default user profile. This is also happening for us on multiple pools. We have pushed known good images from another pod and even built new images and problem remains.
Did you ever find a solution to this?
The folder is there on the parent image.
If I follow the cloning process back for a machine with this issue, there are other machines created off the parent that do not have any issues.
No we did not find a solution. VMware support suggested that it was the appvolume process that was causing the issue but following the instructions given from them did not correct the issue.
My company even had outside VMware/Horizon consultants that we work with do a dive into the occurrences and they could not come up with any suggestions either.
What we have been doing is have a script that monitors VM's that do not have that folder and resetting them when found.
So it appears for us the solution was to change the storage controller. We were running Horizon 7.13 on vSphere 6.7 using the NVMe controller and everything was fine. We started having this issue when we upgraded to vSphere 7. We worked with VMware for a week or so and they couldn't find any answer for us and the issue would occur not matter what was tried. New images, existing images with and without agents, varying compatibility modes and vmtools versions, etc. Then internally we moved to testing the virtual hardware and found that when we changed the storage controller from NVMe to SCSI the issue stopped and all VMs were building successfully again. Not sure why or what issue occurs between vSphere 7 and the NVMe controller that causes this but changing back to SCSI seems to have fixed the issue for us.
Hopefully this info might be of some use in fixing your issue.