im a bit new to this but here is where i stand ... i have vmware view 5 i have 30 computers running inside the network, no firewalls between the servers and the end points, no windows firewalls on the servers or the end points
when the students attempt to login sometimes it works, sometimes they just get a black screen, with the virtual desktop minimize/close bar at the top, and they have to close and reopen the view client 2-4 times before it works,
in the end it ends up working, so i know the credentials are good,
we have gig through and through from end point to the server, so it shouldnt be a bandwidth issue
im at a loss and the teachers are starting to get annoyed. this is a beta and i hope to go live everywhere, but if i cant get over this obstical, i wont be able to go full scale.
i dont have any win XP so i am not sure if this is isolated to just windows 7 or not.
any help would be much appricated
1. this only happens with PCoIP or with RDP too.
2. which video driver do you use in the VDI?
3. maybe there is a problem with the screen resolution?
maybe this kb will help you http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=102833...
Do you use a Transfer Server or a Security Server?
So no “black screen of death” with RDP, now going to turn on PCoIP and remove the disclaimer registry entry, even though we don’t have a disclaimer, figure it could be worth a shot..
Updated drivers require .net for some reason I am not sure of. We are running windows embedded so .net wont install.
Try to power off and power on the VMs. It's a "must" be done after install View Agent.
Also make sure you have the setting "Turn off the display" = never and Screen Saver disabled.
Sorry my question wasn't clear. I mean the driver in the VDI is there the Standard VGA Display driver or the VMware SVGA 3D.
Click in the virtual Desktop Device Manager ==> Display ==> "which driver is installed there?" maybe a screenshot could help
OK so i removed the disclaimer registry keys even though we dont have a disclaimer, Still no luck. I will check the firewall settings ( i cant believe it would have forgotten that, but anything is possible) as well as post the logs later today
firewall is off
Check that port 4172 UDP and TCP are open bi-directionally in your firewall and are not being blocked on your network at all. Also check your local firewalls and AV for the same ports. I've seen some AV's (McAffee for example) where you have to explicitly allow those ports or you'll get this symption.
No firewall in-between, all local traffic, 1GB links
No windows firewall
My trend AV is strictly AV, no firewalling
VMware view administrator 5.1.0
Vsphere client 5.0.0
VMware vcenter 5.0.0
VMware view client 5.1.1
Hi jefftag - you are not alone in this "black screen" anomaly. In fact, I have been working on a new View 5.1 deployment over the last 3 weeks, fresh install of everything including vSphere 5.0 U1 and have run into a few issues including the "black screen" feature at login. We've done our due diligence with the Windows 7 build, implemented the optimisation recommendations, set screen savers, disclaimers, power settings, AV config etc etc on and on and still found inconsistent results with this black screen issue. One day you go to connect and everything is fine, the next day the black screen appears and you have to disconnect and reconnect to fix this.
Another issue we found is that the pcoip_server_win32.exe process consumes 20-30% CPU after login with no mouse and keyboard activity It just hovers around this CPU usage then when you go to use the mouse/keyboard and try to start an application the CPU heads up to 80%+ and the whole desktop becomes unusable.
I hate to say this but we found our fix for everything- RDP! All of our issues have been fixed, no black login screen, no pcoip_server_win32.exe CPU usage issue, fluid window dragging between multimonitors (yes, we did test max.poll.headlessRates settting but this caused the pcoip_server_win32.exe issue described above). And with RDP v7 we get to use multimonitors in "proper" extended mode rather than spanned mode.
Fortunately the issues we have experienced have come out from our internal and initial pilot testing phase. Fact is when this solution goes live it just has to work, period. Issues like the above stop us from using PCoIP as the default protocol as users will complain and the value of the upgrade diminished rapidly.