hi all,
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
Hi jefftag,
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?
i have not tried RDP, I will and post back, we don’t use a disclaimer, but I will check for the registry settings anyway. I will let you know.
Hi,
Try to reinstall the View Agent. You also can verify that the View desktop is using the correct video driver.
Best Regards
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.
which driver you actually use for the video card?
Hi,
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.
Kind regards,
Elcio
For the driver, it was the newest one available, they are onboard intel video cards on an HP dc8000
I will check on that screen saver and turn off monitor setting too.
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
Also, as far as poweing off and on the vm's that has been done many times, as i have recomposed them a few time since they have been built
nice feature
is the firewall disabled on the VDI?
could you send the view client log you find them under: "C:\Users\%username%\AppData\Local\VMware\VDM\Logs\"
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
logs below
2012-10-05 14:52:37.932 ## Starting MKSVchan Server logging.
2012-10-05 14:52:37.932 wWinMain: Loading pcoip_vchan.dll.
2012-10-05 14:52:37.932 wWinMain: Finished loading pcoip_vchan.dll.
2012-10-05 14:52:37.932 wWinMain: Calling pcoip_vchan_plugin_app_init.
2012-10-05 14:52:38.041 wWinMain: pcoip_vchan_plugin_app_init finished.
2012-10-05 14:52:38.041 MKSVchanWin32_ReadRegistryDWORD: Registry key HKLM\Software\Policies\Teradici\PCoIP\pcoip_admin not found.
2012-10-05 14:52:38.041 MKSVchanWin32_ReadRegistryDWORD: Registry key HKLM\Software\Policies\Teradici\PCoIP\pcoip_admin_defaults not found.
2012-10-05 14:52:38.041 MKSVchanWin32_ReadRegistryDWORD: Registry key HKLM\Software\Policies\Teradici\PCoIP\pcoip_admin not found.
2012-10-05 14:52:38.041 MKSVchanWin32_ReadRegistryDWORD: Registry key HKLM\Software\Policies\Teradici\PCoIP\pcoip_admin_defaults not found.
2012-10-05 14:52:38.057 Registering connect callback function
2012-10-05 14:52:38.057 We are already connected, so check the channel state now.
2012-10-05 14:52:38.057 mksvchanplugin CONNECTED.
2012-10-05 14:52:38.057 MKSVchanPluginHandleConnect: Opening new channel with capability 0x04000001.
2012-10-05 14:52:38.057 pcoip_vchan_open succeeded.
2012-10-05 14:52:38.057 MKSVchanPluginHandleConnect: Legacy virtual channel state is 1 and capabilities are 0x00000000.
2012-10-05 14:52:38.057 MKSVchanPluginHandleConnect: Other side has legacy virtual channel open. Opening now.
2012-10-05 14:52:38.057 pcoip_vchan_open succeeded.
2012-10-05 14:52:38.057 FindProcess: Successfully opened process handle.
2012-10-05 14:52:38.057 MKSVchanWin32_ReadRegistryString: Registry key Software\VMware, Inc.\VMware VDM not found.
2012-10-05 14:52:38.057 MKSVchanPluginHandleOpened: Legacy channel opened with capability 0x00000000.
2012-10-05 14:52:38.057 MKSVchanPluginHandleOpened: MKSVchanPlugin is active. Negotiated capability is 0x00000000
2012-10-05 14:52:38.057 MKSVchanPluginHandleOpened: New channel opened with capability 0x04000001.
2012-10-05 14:52:38.057 MKSVchanPluginHandleOpened: MKSVchanPlugin is active. Negotiated capability is 0x04000001
2012-10-05 14:52:38.057 MKSVchanPluginHandleOpened: Queueing vchan RECV_RDY that we may have missed.
2012-10-05 14:52:38.072 HelperWndProc: Queueing deferred RECV_RDY.
2012-10-05 14:52:38.072 MKSVchanPluginEventCb: Received PCOIP_VCHAN_EVENT_CLOSE_PENDING for legacy vchan.
2012-10-05 14:52:38.072 MKSVchanPluginHandleClose: Inactive channel was closed. This is normal.
2012-10-05 14:52:38.104 MKSVchanPluginEventCb: Received PCOIP_VCHAN_EVENT_CLOSED for legacy vchan.
2012-10-05 14:52:38.104 MKSVchanPluginHandleClose: Inactive channel was closed. This is normal.
2012-10-05 14:52:38.166 MKSVchanPlugin_HandleRecvRdy: Allocating 34106 bytes for the clipboard payload
2012-10-05 14:52:38.166 MKSVchanPlugin_HandleRecvRdy: Retrieving 34105-byte payload took 0 seconds
2012-10-05 14:52:38.244 MKSVchan_SetClipboard: Rtf data size 33858.
2012-10-05 14:52:38.244 MKSVchan_SetClipboard: Text data size 207.
2012-10-05 14:52:38.244 MKSVchanPlugin_HandleRecvRdy: Setting clipboard took 0 seconds
ok which version is your eviroment?
Vsphere 4.1/5/5.1
View 5 or 5.1
View client?
View Agent?
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
which version of the agent do you have installed in the masterimage?
maybe you try to reinstall the vmware view agent in the masterimage and recompose the image?
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.
Good luck.
-gogogo5
Thanks Gogogo, I have been having excact same issues. Upgrading to 5.1.1 over the weekend and a client has been having these problems. Think ill set them to RDP.