I'm currently using an VMware View v4.5 infrastructure which now out of the blue keeps on giving me a hard time in sense of connecting to several Windows XP and 7 based VM's. The 'Thin Client' and 'VMware View client' keeps on giving me the error message 'the display protocol for this desktop is currently not available' once I try to choose one of the proposed available VM's using PCoIP.
I really hope that somebody can help me out with this one 'cause I'm currently performing a small POC with 30 clients.....
Additionally I already tried this thread 'http://communities.vmware.com/thread/259692', but got an negative result....
Thanks for the help...
A Desperate Admin.
Can you check if agent services are started in those failed VMs? What does admin UI show as desktop status for those VMs?
( Checking the View Agent installation and status http://kb.vmware.com/kb/1006780 )
Please would you include a bit more information, i.e. logs? The error message itself could be due to a few reasons, and the logs from the connection server (and agent on the relevant VM) will contain the answers, e.g. there are a few specific error codes passed back from the agent which will result in the same error text given to the user but more detailed information in the server logs.
The versions of the VMware View Agent and Connection server are the same = v22.214.171.1243049
The VMware View Agent is started.
If I have a look at the VM using the vCenter -> Virtual Machine Console, then everything is ok and the OS is waiting on an ctrl-alt-del.
This is the bundle from the client which only has the simple result that the server returns to the user, the most recent failures are because the VM is still starting up (STARTUP_IN_PROGRESS) but there are a few errors that are PROTOCOL_ERR_BUSY (latest at 2011-02-28 11:26:47,743). You should look at the logs from the desktop VM to see why this response was returned.
please follow the procedure given here http://kb.vmware.com/kb/1017939
To obtain diagnostic information from the View Agent:
Sorry for not giving you a link to the support tool gathering process, sometimes I forget other people have no idea what this is. Anyway, down to the analysis...
In the agent logs you can see the session request come in:
2011-03-02 06:50:14,604 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] DesktopManager got a StartSession message
2011-03-02 06:50:14,604 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] commandhandler::startSession: Received windows credentials for SSO
2011-03-02 06:50:14,604 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] Starting protocol PCOIP...
2011-03-02 06:50:14,604 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] Launch PCoIP server.
This in turn launches the pcoip_server process:
03/02/2011, 06:50:14.745> LVL:2 RC: 0 AGENT :Launching pcoip_server_win32
03/02/2011, 06:50:14.745> LVL:2 RC: 0 AGENT :Optional log file path specified as "D:\Documents and Settings\All Users\Application Data\VMware\VDM\logs\"
03/02/2011, 06:50:14.854> LVL:2 RC: 0 AGENT :VMWare's launcher code worked.
03/02/2011, 06:50:15.854> LVL:2 RC: 0 AGENT :Waiting for ready message.
03/02/2011, 06:51:14.933> LVL:2 RC: 0 AGENT :Server has timed out or server has quit in wait loop.
03/02/2011, 06:51:14.933> LVL:0 RC: 0 AGENT :Server has timed out or server has quit.
Note that we're waiting for a minute before timing out. This is blocking the retry requests also, which is where the busy error comes from:
2011-03-02 06:50:24,526 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] commandhandler::startSession: Received windows credentials for SSO
2011-03-02 06:50:24,526 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] Starting protocol PCOIP...
2011-03-02 06:50:24,542 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] Requested protocol for session is not available, user XXX
2011-03-02 06:50:24,542 DEBUG <Thread-1403> [ComponentResponse] Reponse directed to:ID:/127.0.0.1/-6534047654062958589/429034/0
2011-03-02 06:50:24,542 DEBUG <Thread-1403> [ComponentResponse] Message is ...<ERROR-CODE>PROTOCOL_ERR_BUSY</ERROR-CODE>...
Here are the pcoip_server logs from the launch:
03/02/2011, 06:50:15.745> LVL:2 RC: 0 COMMON :-- pcoip_server begins.
03/02/2011, 06:50:16.042> LVL:1 RC: 0 SCNET :tera_cert_load_root_certificate (root): err=-500
03/02/2011, 06:50:16.042> LVL:0 RC:-500 ASSERT :init_managers at line number 118.
03/02/2011, 06:50:16.151> LVL:0 RC:-500 COMMON :Critical Exception/Reset Detected!! Saving a minidump file...
03/02/2011, 06:50:16.292> LVL:0 RC:-500 COMMON :Minidump File saved as D:\Documents and Settings\All Users\Application Data\VMware\VDM\logs\pcoip_server_2011_03_02_000010c0.dmp
So the pcoip_server process is crashing on an assert. There are a lot of these. I don't know why, I've not seen this before - you'll need to raise a support request and include this agent bundle (it has also collected the dump files for analysis).
Hi, VMware support noticed a couple of things (logs) which resulted in disabling (test purpose) the Symantec Endpoint Protection agent (AV + FW) and Ta Daaaa everything worked. Now what they noticed was the status 'Disconnected' in the 'Inventory' tab of my desktop pool, eventhoug the VM is online. I already knew that SEP can and will give you a hard time, but this is a new one... and of course no log's within the SEP agent shows me something I can use... Has someone an idee on this one.....