We have a relatively small VDI environment. Fifty users are entitled to use the system, however the max concurrent sessions never exceed 30. We average 20 - 25 sessions on any given day.
Once in a while users report a black screen after they enter their credentials and system starts to load. We use persona management and every time we investigate the logs at the time of the black screen report it is always pointing to VMWVvpsvc.exe. We made sure VMWVvpsvc is excluded from the antivirus scan and minimized the content of the user folders getting synced by persona management. User folders average 500MB, and we constantly monitor the share to make sure nobody goes over 1GB or 1000 files.
VDI Agent 7.3.2 was installed on the parent after vmware tools and we don't think the video driver is the root cause of the black screens we are getting.
Additionally we verified that none of the GPO scrips require a user input.
What's left to question is the storage and networking.
Below are cpu / ram / hdd graphs from the user log on at 7:40AM and getting a black screen. We also increased the VCenter log level for VMs to get a deeper look at the additional stats on the next black screen.
Besides enabling login tracing on the parent does anyone have any other ideas what could be causing the black screens in out environment?
Custom reports: Past 4 hours
This happened in my environment - and we found to be the Blast protocol -
We changed it to PCoIP and that seemed to work for the users facing this issue.
I did not troubleshoot further as why Blast Protocol was causing it - however when i read a couple of articles - It was mentioned that if using a Multi monitor setup - PCoIP is a better protocol.
We actually see this occasionally with PCoIP. Typically a black screen is a result of a connection issue (If the desktop eventually present itself I would look for high latency and/or dropped packets) between the Horizon Client and Horizon Agent
We have seen this as well. A brief black screen will be seen during login once creds are input as the client switches the connection protocol from TCP to UDP. If this "handshake" doesn't occur the user can be left with a black screen and will not get connected. In one case where this was occurring we found out there was a port mismatch (speed and duplex) between the end point and the switch. Setting to AUTO/AUTO resolved this.
"users report a black screen after they enter their credentials and system starts to load" - if you referring to horizon client login...
I think i might remember this issue a while ago with linked clones and dhcp, anyway check IP assigned to virtual desktop with blank screen and compare to dns record, i think i changed dhcp to register and manage dns records to remedy this in VDI subnet.
Some of the linked clones remain powered off after refresh, few days later another linked clone gets powered and gets same IP that previous had.
So ends up with few same IP's going to different host name.
But i'm not 100% sure because it works now with no issues.and have not deal with it for over a year
I do see this scenario as a potential black screen, but don't think we are running in to this, however I certainly will double check our DHCP scope and DNS scavenging.
As we dig more in to our black screen problem we are leaning towards networking or storage. If we log in to the VM with a black screen after the black screen has occurred we see a user profile half-merged (not entire content is copied to the vm from the server share)
So the other suggestion to verify the port settings on the switch is a good place to restart our investigation and perhaps dig in to the storage logs to see if there are any resets on the storage controller.
In our case, the black screens began out of the blue with no known changes made. These users were connecting fine for several months prior and were tolerating the port mismatch condition. Correcting speed and duplex did resolve it but we never got to root cause as to why it started up in the first place.
We still have this issue on View 7.4.
I would say out of the 300-350 users we get about 20-30 a day that get stuck on the welcome screen for Window 10 normally if they have been logged in and locked their machine, the only way to get the machine responsive again is to kill the VMWVvpsvc.exe process. This is removed from real time scanning etc...
We've had to include the ability for users to reset their VM from the pool settings so they that non-persistent linked clone can be destroyed and ability given to the user to log into a new machine.