I currently have a 100 user View 4.6 pilot environment that implements very nicely with UniDesk. We are preparing to go production for 1,000 user production environment. The prod env will be View5 and we plan on levearging Persona Management (PM) heavily to provide a "logically" persistant desktop by using Non-persistent VMs. I really hope PM works as advertised. I would love to hear some PM success stories from the community.
With that said, I do have a View DEV environment that is View 5 across the board(View 5 brokers, View 5 Agent on golden image, etc, etc.)
When I try to connect to my new NP desktop to test PM configurations, I get the infamous "The display protocol for the desktop is not available". However, I can connect using RDP just fine. Again, all components are View 5. The golden image has the View 5 Agent, I am using the latest View 5 client, the internal connection broker is View5. I have followed many View community searches/hits to resolve this issue and none have resolved it. I am hoping my VMWare experts chime in here and point me in the right direction...
Thanks in advance...
Scott
Scott, have you consulted the agent logs to see if you can get any info from there? On this golden image did you do an upgrade of the agent to get to the View 5 level or was it a fresh build.
I have been really impressed with the View 5 persona.
Since I can not determine which VM I am hitting I am not sure which agent logs I should review. What is the path to the agent logs?
With regards to the golden image, I actually uninstalled View 4.6 from the image, rebooted, and then installed View 5 Agent.
Also, do you have any KB articles or PM admin guide that talks solely about the many different PM GPO features and their implementation?
Thanks in advance...
Scott
Here is a KB with all of the locations of the log files, http://kb.vmware.com/kb/1027744.
Persona deployment guide, http://www.vmware.com/files/pdf/view/VMware-View-Persona-Management-Deployment-Guide.pdf.
Thanks for the KB articles very Helpful!!!
Since my security & internal brokers are teamed with NLB, is there a VMWare tool or utility that will allow me to determine which particular server an active VDI connection came through?
Thanks in advance...
Have you checked the Volitile Environment Variabled? I bet it just shows the NLB but its worth a shot (as its easy). If you do a netstat -a on the VCS you'll probably find the remote IP of your connected sessions but that's only if you are tunneled.
Gunnar
Gunnar:
Thanks for the feedback...
I am not familiar with the Volitile Envrionment Variable you are talking about. Please elaborate...
I really don't envision having to prompt the "average user" to run NETSTAT -a on their VM, so I would imagine I would run that command from one of the broker servers. I ran that command on 1 of the 2 internal view brokers and I got a list about ~60 VDI VMs with their DNS names listed under the "Foreign Address" column. However, I only have about 11 VDI VMs currently connected. These 60 VMs that are sitting idele are powered on and running, but why would they be listed as a connected session on 1 of the 2 the View broker servers??
Not sure if this would be an ideal tool...
Thoughts?
The Volitile Environment is found under the HKCU registry section of the VDI machine. It contains information passed to it from the connecting computer. The reason you see so many VMs when doing a netstat -a is because the view agents on those machines are checking in with the connection brokers.
Hi,
Check the following information http://www.vmware.com/files/pdf/press-kit/vmw-view-vmworld.pdf
Hope this information helps you.
__________________
Im a nobody.. nobodys perfect.. therefore IM PERFECT!!!
I have reviewed the VMWare logs on the VM that I was attempting to connect to. (Again I can successfully connect to it via RDP)
There were 3 logs files that were modified within a minute or so of my attempted connection.
I have copied the pertinent file information I have gathered from those 3 View files listed below:
Even though I am not exactly sure what verbiage I am looking, I really don't see any glaring issues.
Is there a general rule of thumb to search for possibly a key word for such connection failures?
Thanks in advance...
01/10/2012, 10:35:18.725> LVL:2 RC: 0 MGMT_PCOIP_DATA :Tx thread info: round trip time (ms) = 0, variance = 0, rto = 1000
01/10/2012, 10:35:20.254> LVL:2 RC: 0 MGMT_PCOIP_DATA :Tx thread info: bw limit = 1175, plateau = 1152.0, avg tx = 0.1, avg rx = 0.1 (KBytes/s)
01/10/2012, 10:35:20.254> LVL:1 RC: 0 VGMAC :Stat frms: R=000000/000000/000020 T=000000/000000/000079 (A/I/O) Loss=0.00%/0.00% (R/T)
01/10/2012, 10:35:42.391> LVL:2 RC: 0 SERVER :server mailbox: MBX_SHUTDOWN with agent disconnect reason code (0x5)
01/10/2012, 10:35:42.391> LVL:2 RC: 0 SERVER :server mailbox: Stopping mailbox message loop
01/10/2012, 10:35:42.391> LVL:2 RC: 0 SERVER :server main: got terminate application message
01/10/2012, 10:35:42.391> LVL:2 RC: 0 SERVER :server main: exiting
01/10/2012, 10:35:42.391> LVL:2 RC: 0 SERVER :server cleanup: tearing down pcoip with agent disconnect reason code(5) and waiting
01/10/2012, 10:35:42.391> LVL:1 RC: 0 SERVER :map_agent_to_tera: DISCONNECT_FOR_RECONNECT -> TERA_DISCONNECT_CAUSE_HOST_BROKER_RECONNECT
01/10/2012, 10:35:42.391> LVL:0 RC: 0 MGMT_SESS :Tearing down the session
01/10/2012, 10:35:42.391> LVL:2 RC: 0 MGMT_VCHAN :VChanPluginExit: Closing plugin 'VMware_Server'.
01/10/2012, 10:35:42.422> LVL:2 RC: 0 MGMT_VCHAN :VChanPluginExit: Plugin 'VMware_Server' is closed.
01/10/2012, 10:35:42.422> LVL:1 RC: 0 MGMT_VCHAN :=> Successfully exited all the VChan plugins
01/10/2012, 10:35:42.422> LVL:2 RC: 0 SERVER :server cleanup: detaching inputdevtap
01/10/2012, 10:35:42.422> LVL:0 RC: 0 EXTERN :input_devtap ==> Unable to get the process token for logged on user.
01/10/2012, 10:35:42.422> LVL:2 RC: 0 SERVER :server cleanup: closing mailboxes
01/10/2012, 10:35:42.422> LVL:2 RC: 0 SERVER :server cleanup: freeing argument copy
01/10/2012, 10:35:42.422> LVL:2 RC: 0 SERVER :server cleanup: cleanup complete
01/10/2012, 10:35:42.391> LVL:2 RC: 0 AGENT :pcoip_agent_disconnect_extended
01/10/2012, 10:35:42.391> LVL:2 RC: 0 AGENT :tera_agent_disconnect: agent close code: 2, disconnect reason: 5
01/10/2012, 10:35:42.500> LVL:2 RC: 0 AGENT :tera_agent_disconnect: connection_closed 2
01/10/2012, 10:35:42.500> LVL:2 RC: 38 MAILBOX :tera_util_mailbox_read: Read failed.
01/10/2012, 10:35:42.500> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req
01/10/2012, 10:35:42.500> LVL:2 RC: 0 AGENT :Client address is 0.0.0.0:0 (host order)
01/10/2012, 10:35:42.500> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: For Soft Host: Using Version 1 Tag
01/10/2012, 10:35:42.500> LVL:2 RC: 0 PRI :pcoip_agent_connect_req: Session ID Tag for Soft Host: U6y+PM3iVfbC
01/10/2012, 10:35:42.500> LVL:2 RC: 0 AGENT :server_listen_on_addr is 172.27.134.21:0 (host order)
01/10/2012, 10:35:42.500> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: Session ID = 4
01/10/2012, 10:35:42.500> LVL:2 RC: 0 AGENT :codec = 2.
01/10/2012, 10:35:42.500> LVL:2 RC: 0 AGENT :Launching pcoip_server_win32
01/10/2012, 10:35:42.500> LVL:2 RC: 0 AGENT :Optional log file path specified as "C:\ProgramData\VMware\VDM\logs\"
01/10/2012, 10:35:42.515> LVL:2 RC: 0 AGENT :VMWare's launcher code worked.
01/10/2012, 10:35:43.529> LVL:2 RC: 0 AGENT :Waiting for ready message.
01/10/2012, 10:35:43.639> LVL:2 RC: 0 AGENT :Got ready message.
01/10/2012, 10:35:43.639> LVL:2 RC: 0 AGENT :selected server_addr is 172.27.134.21:4172 (host order)
01/10/2012, 10:35:43.639> LVL:2 RC: 0 AGENT :Connecting to server's mailbox.
01/10/2012, 10:35:43.639> LVL:2 RC: 0 AGENT :Sending session tag
01/10/2012, 10:35:43.639> LVL:2 RC: 0 AGENT :Sending session option #0 key='pcoip.enable_tera2800' value='1'.
01/10/2012, 10:35:43.639> LVL:2 RC: 0 AGENT :Sending session option #1 key='pcoip.priority_level' value='2'.
01/10/2012, 10:35:43.639> LVL:2 RC: 0 AGENT :Adding session to list.
01/10/2012, 10:35:43.639> LVL:2 RC: 0 AGENT :Sending connection response ok.
01/10/2012, 10:35:43.639> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req (end): connection_response, 0
10:35:42,391 WARN <MessageFrameWorkDispatch> [wsnm_desktop] Needed to disconnect existing PCoIP connection during requestConnection {SESSION:727F0E145AD25D957723F6A30C429811;1E5F786E9409B23FC180354D5F658C43}
10:35:42,391 WARN <MessageFrameWorkDispatch> [wsnm_desktop] PCoIP requested disconnect while busy! {SESSION:727F0E145AD25D957723F6A30C429811;1E5F786E9409B23FC180354D5F658C43}
10:35:42,500 WARN <MessageFrameWorkDispatch> [wsnm_desktop] Closed PCoIP connection doesn't match global value {SESSION:727F0E145AD25D957723F6A30C429811;1E5F786E9409B23FC180354D5F658C43}
10:35:42,905 INFO <2248> [pcoip_server_win32] Program 'pcoip_server_win32 - PCoIP Server' started, version=3,8,0,9606:soft_pcoip_rc_3_8, pid=2896, buildtype=release, usethread=0, closeafterwrite=0
10:35:45,433 INFO <MessageFrameWorkDispatch> [MessageFrameWork] Client/agent channel pending wssm to start
10:37:15,101 INFO <MessageFrameWorkDispatch> [MessageFrameWork] Client/agent channel pending wssm to start
10:37:15,585 INFO <2008> [LogonUI] Program 'LogonUI - Windows Logon User Interface Host' started, version=6.1.7601.17514 (win7sp1_rtm.101119-1850), pid=1960, buildtype=release, usethread=0, closeafterwrite=0
10:37:18,081 INFO <Main Thread> [wsnm_desktop] Session RECONNECTED: id=2, user HCBOCC\caryers, client=ITS-PCN0145303D, connectionId=FC0C7111079DE55CCA22FBF6FB498B14, userDn=cn=s-1-5-21-1589207825-987676762-3663815967-13131,cn=foreignsecurityprincipals,dc=vdi,dc=vmware,dc=int
10:37:18,081 INFO <MessageFrameWorkDispatch> [MessageFrameWork] Client/agent channel connected for session = 2
Serach "-500" tends to help that and "disconnect". Also, disconnect issues are easy to find, they are always at the bottom of the log as the log stops and a new log is created after a disconnect.
This log looks like a tare down session. Did it ever connect?
Gunnar
The session never connects using PCoIP. It gives me the infamous black screen for 5 or so seconds and timeout. I have seen this many times before when I first implemented View 4.5, then 4.6 when I did not have the correct Firewall ports added to my VDI rule base. However, from my understanding there are no new ports for View 5 that need to be added to my Firewall VDI rule base. Plus I am trying these connections internal where the traffic does not pass through the firewall.
With that said, I was trying to review the Connection server View log files, but was not able to determine the exact path to our buddy mittim12 provided me yesterday. However, the link below is not coming up for me. Perhaps VMWare's site is having an issue as I have tried from multiple PCs at my location.
http://kb.vmware.com/kb/1027744.
When you say search for disconnect, are your referring to the standard disconnect users do by simply clicking the X on the View tool bar, or an abrupt disconnect like I am having? So all disconnects start a new file?
Thanks Gunnarb!!!
All disconnects start a new file. And the file you sent looks like a session that never established, most likely due to firewall ports being blocked. I know you say you are internal but I've seen this happen internally when Network Admins have ACLs between subnets. Here is my recommendation, remove all hops between you and your View session. This often means putting the View Client on a laptop and plugging it into a switch in your datacenter. Try connecting to the session from there, if it works then you can know without a doubt a port is being blocked somewhere.
Gunnar
I am seeing -500 (and a -504) error message in my View Client that I am trying to connect to, see bolded area below:
So what is this telling me??????
01/10/2012, 10:35:45.136> LVL:2 RC: 0 MGMT_SSIG :Received from peer: BYE disconnect reason cause (0x406)
01/10/2012, 10:35:45.136> LVL:2 RC: 0 MGMT_SSIG :Session closure reason cause (device:internal: SSIG negotiation complete - closing TLS connection)
01/10/2012, 10:35:45.261> LVL:2 RC: 0 MGMT_PCOIP_DATA :pcoip_app_handler: received peer data manager INVITE packet
01/10/2012, 10:35:45.261> LVL:1 RC: 0 VGMAC :Client is NAT'ed!
01/10/2012, 10:35:45.261> LVL:2 RC: 0 MGMT_PCOIP_DATA :mgmt_pcoip_data_set_media_activation: URBoIP is not used
01/10/2012, 10:35:45.261> LVL:2 RC: 0 MGMT_IMG :tera_mgmt_img_open: SACK capability detected. Pseudo Reliable Retransmit Request Feature (Seletive ACK) is ACTIVE.
01/10/2012, 10:35:45.261> LVL:2 RC: 0 MGMT_IMG :Monitor power saving mode is supported.
01/10/2012, 10:35:45.557> LVL:2 RC: 0 MGMT_PCOIP_DATA :pcoip_app_handler: received peer data manager INVITE packet
01/10/2012, 10:35:46.057> LVL:2 RC: 0 MGMT_PCOIP_DATA :pcoip_app_handler: received peer data manager INVITE packet
01/10/2012, 10:35:46.088> LVL:1 RC:-500 COMMON :poll_sockets failed to generate 1 callbacks!
01/10/2012, 10:35:47.055> LVL:2 RC: 0 MGMT_PCOIP_DATA :pcoip_app_handler: received peer data manager INVITE packet
01/10/2012, 10:35:49.052> LVL:2 RC: 0 MGMT_PCOIP_DATA :pcoip_app_handler: received peer data manager INVITE packet
01/10/2012, 10:35:53.061> LVL:2 RC: 0 MGMT_PCOIP_DATA :pcoip_app_handler: received peer data manager INVITE packet
01/10/2012, 10:36:01.064> LVL:2 RC: 0 MGMT_PCOIP_DATA :pcoip_app_handler: received peer data manager INVITE packet
01/10/2012, 10:36:08.817> LVL:2 RC: 0 MGMT_PCOIP_DATA :Tx thread info: round trip time (ms) = 0, variance = 0, rto = 1000
01/10/2012, 10:36:12.951> LVL:2 RC: 0 RTOS :tera_query_performance_frequency(): frequency is 14.313320MHz
01/10/2012, 10:36:15.182> LVL:2 RC: 0 MGMT_PCOIP_DATA :OPEN: Got EVENT_RESET. Transition into BYE, pcoip data handle: 0
01/10/2012, 10:36:17.069> LVL:2 RC: 0 MGMT_PCOIP_DATA :pcoip_app_handler: received peer data manager INVITE packet
01/10/2012, 10:36:19.799> LVL:1 RC:-504 MGMT_PCOIP_DATA :BYE packet not acknowledged, aborting session
01/10/2012, 10:36:19.799> LVL:2 RC: 0 MGMT_PCOIP_DATA :mgmt_pcoip_data_set_media_activation: URBoIP is not used
01/10/2012, 10:36:19.799> LVL:2 RC: 0 MGMT_SSIG :Request to reset session (PRI: 0)
01/10/2012, 10:36:19.815> LVL:1 RC:-500 VGMAC :tera_sock_recv() failed - Socket operation on non-socket (10038)!
01/10/2012, 10:36:19.815> LVL:2 RC: 0 VGMAC :PCoIP UDP RX thread exiting
01/10/2012, 10:36:19.815> LVL:1 RC:-500 MGMT_PCOIP_DATA :INIT: Peer has reset our PCoIP connection. Aborting session ...
01/10/2012, 10:36:34.323> LVL:2 RC: 0 MGMT_PCOIP_DATA :Tx thread info: round trip time (ms) = 0, variance = 0, rto = 1000
01/10/2012, 10:36:48.191> LVL:2 RC: 0 MGMT_PCOIP_DATA :Tx thread info: bw limit = 1175, plateau = 1152.0, avg tx = 0.1, avg rx = 0.1 (KBytes/s)
01/10/2012, 10:36:48.191> LVL:1 RC: 0 VGMAC :Stat frms: R=000000/000000/000020 T=000000/000000/000079 (A/I/O) Loss=0.00%/0.00% (R/T)
01/10/2012, 10:36:59.439> LVL:2 RC: 0 MGMT_PCOIP_DATA :Tx thread info: round trip time (ms) = 0, variance = 0, rto = 1000
01/10/2012, 10:37:17.239> LVL:0 RC: 0 SERVER :==> WindowProc: Detected WM_DISPLAYCHANGE event (640 x 480)
01/10/2012, 10:37:17.239> LVL:2 RC: 0 IMG_FRONTEND :Init: ResolutionSet.dll includes SetDisplayTopologyWithRefreshRate() API.
Is there a View 5 KB article of all the ports that are needed to be open for connectivity? Are they different from 4.6
I have the below FW rules in place now:
FIREWALL FULES
VDI-DMZ1,2, VIP---> Viewman-VDI1,2, VIP on ports tcp 8009, 4001, 4172, 3389
everyone---> VDI-DMZ1,2,VIP on ports tcp 80, 443, 4172
VDI-DMZ1,2,VIP---> VDI vLAN 133,134 on ports tcp 4172, 3389, 32111
Legend
VDI-DMZ1,2, VIP=View Security Servers & the NLB VIP in our DMZ
Viewman-VDI1,2, VIP =Internal View Connection Brokers and the NLB VIP
everyone=Every remote user connection from outside our network
VDI vLAN 133,134=Our internal vLANs that are VDI VMs reside on
Thanks in advance...
Firewall rules and a description of the protocols etc. is in the View 5 documentation - see http://pubs.vmware.com/view-50/topic/com.vmware.ICbase/PDF/view-50-architecture-planning.pdf
Mark.
If a port was being blocked, would the logs indicate what port was problematic either on the Connection server or VM?
Thanks in advance...
The firewall logs would normally log blocked connections.
Mark.
Oh no Mark is responding, there goes my chances of bumping him! Hey Mark.
To answer a question above, unfortunately no the logs will not show if a port is blocked.
Gunnar
Thanks Guys...
To troubleshoot, I tried to TELNET to my two internal connection brokers and VIP and got No Refused connections from a VDI VM client.
(I learned that you can not install the View Client on a VM with the either View Agent installed or the Connection broker service installed.)
Is this TELNET test the best method?
Since my VDI VM vLANs are only used on my ESX servers, I couldn't simply take a latop and plug it in to a port on the switch without having to get the network guys involved...
Thanks in advance...