This could be a few things, most likely that port 4172 UDP/TCP is not opened in the firewall.
As priously 4172 TCp are opend. and now i open both UDP/TCP.
Not configured the PCoIP Tunnel correctly, have a look at the config options for the connection broker.
I am directly connection to connection server i dont’ have install «Security Server» so i don’t enable «PCoIp Secure Gateway»option .
Further ,
I would strongly recommend not to use IP:s, use proper FQDN:s instead, you will never be able to secure it or loadbalance properly if using IP:s.
Still for testing we use Ips, for production we may use FQDN.
As i clear priviously , Many of time i connected to Pool as.
Vmware view Error is
«User»,»Severity»,»Time»,»Module»,»Message»,»Objects»
«compnaymy.name»,»Audit success»,»3/4/2013 2:11 PM»,»Connection Server»,»User compnaymy.name has logged out»,
«compnaymy.name»,»Info»,»3/4/2013 2:10 PM»,»Connection Server»,»User compnaymy.name requested Pool View7Regional02, allocated machine vm-view7r2001″,»POOL:View7Regional02 DESKTOP:vm-view7r2001 «
«compnaymy.name»,»Info»,»3/4/2013 2:10 PM»,»Connection Server»,»User compnaymy.name requested Pool View7Regional02″,»POOL:View7Regional02 «
«compnaymy.name»,»Info»,»3/4/2013 2:10 PM»,»Agent»,»The agent running on machine VM-VIEW7R2001 has accepted an allocated session for user compnaymy.name»,»POOL:view7regional02 DESKTOP:VM-VIEW7R2001 «
«compnaymy.name»,»Audit success»,»3/4/2013 2:10 PM»,»Connection Server»,»User compnaymy.name has logged in»,
«compnaymy.name»,»Warn»,»3/4/2013 1:07 PM»,»Agent»,»The pending session on machine VM-VIEW7R2001 for user compnaymy.name has expired»,»POOL:view7regional02 DESKTOP:VM-VIEW7R2001 «
Some of the time i encounter error
Recently I found myself looking at an error which I’ve seen many times before with different customers View environments in which they are unable to connect to desktops getting the following error..
«The connection to the remote computer ended»
In 99% of cases this is usually due to missing firewall rules between the View Client (thick/thin client) and the View Agent (virtual desktop).
The following VMware KB details this error and how to troubleshoot.
http://kb.vmware.com/kb/2013003
However it only affected my test Windows 8 clients which were previously working.
The only thing that has changed was I had been applying and testing the CIS benemarks for Windows 8 in some new GPOs I had created, it had to be those what had broken it, so I set out trying to find which setting.
Unlinking the new CIS GPOs I found I could now connect to my View desktop succesfully so it definatley a setting in the CIS GPOs. The tough job was going through each setting and testing it to find which (initial guess work was not sucessful).
In the end I found the cause to be the following setting:
“System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing Enabled”
This setting being configured to enabled, caused a conflict with the View 4.5 connection server settings in the environment which resulted in connections to the View agent from a View client with this policy setting to be rejected.
I recently ran into an interesting issue where I went through a series of troubleshooting steps that eventually led me to reinstalling the VMware Horizon View Agent on a master image but quickly realized I wasn’t able to. The error messages I was presented wasn’t too helpful so I thought writing this blog post may help others who may encounter the same problem.
The whole process started off with an administrator asking me to look at why a user wasn’t able to connect to their virtual desktops after we recompose their VDI with the latest snapshot that recently had 2GB of Windows updates installed. The user would attempt to log onto the View environment as such:
The Connection Server is preparing the desktop…
They would see a black screen as such:
They would see a black screen as such:
Then they would get cut off and displayed the following error message:
VMware Horizon Client
The connection to the remote computer ended.
Suspecting the PCoIP logs would assist with the troubleshooting, I browsed over to the desktop’s VDMlogs folder:
VDI-001c$ProgramDataVMwareVDMlogs
… then opened one of the pcoip_agent logs to review the entries. Some of the entries I noticed were:
Server died.
… and:
disconnect reason: 0
The follow log entries are as follows:
11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Adding session to list.
11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Total number of active sessions = 1
11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Sending connection response ok.
11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] connection_response (end), 0
11/17/2015, 14:02:36.562> LVL:2 RC: 0 AGENT :monitor_soft_hosts: {s_tag:0x9bd8fbc8ee73a36a} Server died.
11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect [soft host]: agent close code: 6, disconnect reason: 0
11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect: {s_tag:0x9bd8fbc8ee73a36a} disconnect is ** NOT ** pending (hndl: 5, pid: 924, process handle: 0000060c)
11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect: {s_tag:0x9bd8fbc8ee73a36a} Server process already exited (hndl: 5, pid: 924, process handle: 0000060c)
11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_finish_disconnect_thread: connection_closed 6
11/17/2015, 14:02:36.703> LVL:2 RC: 0 AGENT :sSERVER_SESSION::~sSERVER_SESSION: {s_tag:0x9bd8fbc8ee73a36a} Closing pcoip server process handle 000000000000060C
Suspecting the PCoIP logs would assist with the troubleshooting, I browsed over to the desktop’s VDMlogs folder:
VDI-001c$ProgramDataVMwareVDMlogs
… then opened one of the pcoip_agent logs to review the entries. Some of the entries I noticed were:
Server died.
… and:
disconnect reason: 0
The follow log entries are as follows:
11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Adding session to list.
11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Total number of active sessions = 1
11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Sending connection response ok.
11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] connection_response (end), 0
11/17/2015, 14:02:36.562> LVL:2 RC: 0 AGENT :monitor_soft_hosts: {s_tag:0x9bd8fbc8ee73a36a} Server died.
11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect [soft host]: agent close code: 6, disconnect reason: 0
11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect: {s_tag:0x9bd8fbc8ee73a36a} disconnect is ** NOT ** pending (hndl: 5, pid: 924, process handle: 0000060c)
11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect: {s_tag:0x9bd8fbc8ee73a36a} Server process already exited (hndl: 5, pid: 924, process handle: 0000060c)
11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_finish_disconnect_thread: connection_closed 6
11/17/2015, 14:02:36.703> LVL:2 RC: 0 AGENT :sSERVER_SESSION::~sSERVER_SESSION: {s_tag:0x9bd8fbc8ee73a36a} Closing pcoip server process handle 000000000000060C
Reviewing the View Connection server’s logs from the folder:
C:ProgramDataVMwareVDMlogs
… reveal the entry:
2015-11-17T14:17:10.024-04:00 DEBUG (0C70-094C) <e1f29aa5-68ed-437b-ad9f-cc1759d63d8b> [DesktopTracker] onEvent: PENDING_EXPIRED — UserName:a-tluk;DomainName:CONTOSO;UserDn:cn=s-1-5-21-206374890-975330658-925700815-10626,cn=foreignsecurityprincipals,dc=vdi,dc=vmware,dc=int;UserSid:null;GroupSids:null;BrokerUserSid:S-1-5-21-206374890-975330658-925700815-10626;ConnectionId:fcca_***_1220;Protocol:null;ClientName:null;ClientAddress:null;ServerDn:cn=a34734d6-4e78-4d07-83c4-5ce3d1ce31cd,ou=servers,dc=vdi,dc=vmware,dc=int;ServerPoolDn:cn=standard_CON_desktop,ou=server groups,dc=vdi,dc=vmware,dc=int;ServerDnsName:CONFSTAWKST-158.tokiomillennium.com;DynamicIpAddress:10.23.0.92;ManagedObjectId:null;Id:e1f29aa5-68ed-437b-ad9f-cc1759d63d8b;State:PENDING_EXPIRED;SessionGuid:c80b-***-2d5b;PreviousSessionGuid:null;LoggedInAsDomain:CONTOSO;LoggedInAsUser:a-tluk;SessionType:DESKTOP;RemotableContent:null
Reviewing the Events database in the View Administrator console reveals the following:
The pending session on machine <VDIname> for user contosoa-tluk has expired.
Reviewing the Events database in the View Administrator console reveals the following:
The pending session on machine <VDIname> for user contosoa-tluk has expired.
What I’ve done in the past for troubleshooting black screen disconnection issues was to reinstall the VMware Horizon View agent but what I noticed was that attempting to install the View Agent on the master image after uninstalling it would briefly show the splash screen, disappear and nothing would happen. From there, I proceeded to uninstall VMware Tools and reinstall it but quickly noticed that the install would fail with the message:
VMware Product Installation
This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package.
Attempting to copy the installer onto the desktop and run the install would generate the following error message:
Setup failed to extract the files necessary to install VMware Tools.
Attempting to copy the installer onto the desktop and run the install would generate the following error message:
Setup failed to extract the files necessary to install VMware Tools.
From here on, what ended up being the cause of all these issues was actually because there was no space in the %temp% directory to extract the installation files. The reason why this was the case was because the environment I was working in had SanDisk’s ioVDI solution deployed and the %temp% folder was redirected to a disposable disk that also stored the page file which had already filled up the disk. This was why the installer for VMware Tools and the Horizon View Agent would fail and it was also why the user had connection issues.
The whole ordeal concluded in a way that I did not expect so I hope the error messages I outlined here would be able to help anyone who happens to come across a similar issue with the same cause.
Recently I had to troubleshoot a VMware View Client connection problem. In a new VMware View environment the customer has installed a VMware Horizon View Security Server for the external connections. When a external View Client tried to connect through the Security Server using the PCoIP protocol to the View desktop the following appeared:
The connection to the remote computer ended
When the users connects to the View Desktop using the LAN (without the Security Server) everything worked fine. I suspected that a PCoIP port (4172 TCP and UDP) is blocked between the Security Server and desktop pool or vice versa.
To troubleshoot this problem I used the tool “Netcat”. With Netcat TCP and UDP ports can be checked (Telnet can only check TCP ports). So I used Netcat to check the TCP and UDP ports between the Security server and View Desktop (1) and the View Desktop to the Security Server(2).
Here is an example how to use Netcat:
On the View desktop run Netcat to listen to UDP port 4172:
nc –l –u –p 4172
On the security server run Netcat to connect to the View Desktop on UDP port 4172:
nc –u ipaddress 4172
You can type some text and press enter. The text typed in the screen must be displayed on both sides, If not the port is blocked.
So I discovered that the 4172 UDP protocol from the View desktop pool to the Security server was blocked by a firewall. After opening this port in the firewalls the problem was solved.
More information: Netcat for Windows can be downloaded here.
9. Создание пула Linked Clone.
Создадим пул машин с ОС Windows 7.
Идем в Inventory – щелкаем пулы и Add:
Выбираем автоматический:
Выбираем Dedicated (но галку автоназначения здесь не ставим – сами назначим пользователей – благо их всего 4):
Далее указываем, что будем использовать Linked Clones:
Обзываем пул:
А здесь уже жестко прописываем протокол PCoIP и 3D (память 256MB) и ставим галочку HTML Access:
Здесь указываем имя и число машин в пуле:
Здесь сколько GB на какие диски:
Не трогаем:
Тут указываем шаблон-снапшот-папка-хост итп:
Не трогаем:
Здесь лишь указываем наш OU HorizonPC:
И жмем финиш:
И далее назначим пользователей на машины.
Получим пул с двумя машинами Windows 7:
Также создадим пул с Windows 8:
10. Проверка работоспособности.
Запускаем View Client и логинимся-проверяем:
С iPhone:
Все работает.
Немного о подключении: пользователи могут подключаться к View Connection-серверу, используя SSL-подключение. В простейшем случае (наш) используется самоподписанный сертификат. В продуктивной среде необходимо использовать сертификаты, получаемые централизованно от сервера CA. Как это сделать, описано здесь: http://pubs.vmware.com/view-51/index.jsp?topic=%2Fcom.vmware.view.installation.doc%2FGUID-80CC770D-327E-4A21-B382-786621B23C44.html, здесь: http://derek858.blogspot.com/2012/05/vmware-view-51-installation-part-1-view.html и здесь в целом для vSphere: http://www.wooditwork.com/2011/11/30/vsphere-5-certificates-1-installing-a-root-certificate-authority-3/.
А теперь прикрутим HTML Access к нашим виртуальным десктопам.
11. Что нужно для HTML Access?
Для доступа к виртуальным десктопам с использованием HTML, необходимо установить VMware View Feature Pack. Состоит он из агента, устанавливаемого на шаблон десктопа, и серверной части, устанавливаемой на сервер VMware View Connection Server:
12. Установка агента VMware View Feature Pack.
Запускаем наш шаблон и включаем родной MS-брандмауэр (если был выключен).
Затем установка, снова ipconfig /release, выключение шаблона и снапшот:
Тоже самое проделываем со всеми шаблонами, нуждающимися в доступе с использованием HTML.
Затем пересобираем пул:
Выбираем новый снапшот:
Не меняем:
И ждем окончания процесса:
Далее установим серверную часть VMware View Feature Pack.
13. Установка серверной части VMware View Feature Pack.
Все просто до безобразия:
И теперь можно проверить новые фишки.
14. Проверка работоспособности HTML Access.
Идем по http-адресу нашего сервера view-mgr.horizon.local и попадаем на интересную страничку:
Выбираем HTML Access, вводим логин-пароль:
Выбираем наш пул:
И попадаем на машину (в которой работает даже тестовое видео!):
Также для 8ки:
БОНУС:
Наконец, в View 5.2 появилась функция Unity Touch, как это работает, показано здесь:
http://www.youtube.com/watch?v=eHZoUiDFeVE.
У меня же это работает так:
Конец 
Recently I found myself looking at an error which I’ve seen many times before with different customers View environments in which they are unable to connect to desktops getting the following error..
«The connection to the remote computer ended»
In 99% of cases this is usually due to missing firewall rules between the View Client (thick/thin client) and the View Agent (virtual desktop).
The following VMware KB details this error and how to troubleshoot.
http://kb.vmware.com/kb/2013003
However it only affected my test Windows 8 clients which were previously working.
The only thing that has changed was I had been applying and testing the CIS benemarks for Windows 8 in some new GPOs I had created, it had to be those what had broken it, so I set out trying to find which setting.
Unlinking the new CIS GPOs I found I could now connect to my View desktop succesfully so it definatley a setting in the CIS GPOs. The tough job was going through each setting and testing it to find which (initial guess work was not sucessful).
In the end I found the cause to be the following setting:
“System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing Enabled”
This setting being configured to enabled, caused a conflict with the View 4.5 connection server settings in the environment which resulted in connections to the View agent from a View client with this policy setting to be rejected.
Hi,
I have simple VDI infrastructure with ~100 linked clone Windows 10 VDIs and VMware Horizon 7.12. Thin clients Dell Wyse 5070 (Windows 10) managed by Wyse Easy Setup. Thin clients connect to VDI by Blast protocol and use VMware Horizon Client. 98 setups works fine but 2 of them have time to time an error: «the connection to the remote computer ended». Error appear when user has a brake. All of thin clients and VDI have the same energy settings, same GPO policies, same hardware (keyboard, mouse, monitor). I changed thin client for an user, change network location on a switch.
What elese should I check?
I recently ran into an interesting issue where I went through a series of troubleshooting steps that eventually led me to reinstalling the VMware Horizon View Agent on a master image but quickly realized I wasn’t able to. The error messages I was presented wasn’t too helpful so I thought writing this blog post may help others who may encounter the same problem.
The whole process started off with an administrator asking me to look at why a user wasn’t able to connect to their virtual desktops after we recompose their VDI with the latest snapshot that recently had 2GB of Windows updates installed. The user would attempt to log onto the View environment as such:
The Connection Server is preparing the desktop…
They would see a black screen as such:
Then they would get cut off and displayed the following error message:
VMware Horizon Client
The connection to the remote computer ended.
Suspecting the PCoIP logs would assist with the troubleshooting, I browsed over to the desktop’s VDMlogs folder:
\VDI-001c$ProgramDataVMwareVDMlogs
… then opened one of the pcoip_agent logs to review the entries. Some of the entries I noticed were:
Server died.
… and:
disconnect reason: 0
The follow log entries are as follows:
11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Adding session to list.
11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Total number of active sessions = 1
11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Sending connection response ok.
11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] connection_response (end), 0
11/17/2015, 14:02:36.562> LVL:2 RC: 0 AGENT :monitor_soft_hosts: {s_tag:0x9bd8fbc8ee73a36a} Server died.
11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect [soft host]: agent close code: 6, disconnect reason: 0
11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect: {s_tag:0x9bd8fbc8ee73a36a} disconnect is ** NOT ** pending (hndl: 5, pid: 924, process handle: 0000060c)
11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect: {s_tag:0x9bd8fbc8ee73a36a} Server process already exited (hndl: 5, pid: 924, process handle: 0000060c)
11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_finish_disconnect_thread: connection_closed 6
11/17/2015, 14:02:36.703> LVL:2 RC: 0 AGENT :sSERVER_SESSION::~sSERVER_SESSION: {s_tag:0x9bd8fbc8ee73a36a} Closing pcoip server process handle 000000000000060C
Reviewing the View Connection server’s logs from the folder:
C:ProgramDataVMwareVDMlogs
… reveal the entry:
2015-11-17T14:17:10.024-04:00 DEBUG (0C70-094C) <e1f29aa5-68ed-437b-ad9f-cc1759d63d8b> [DesktopTracker] onEvent: PENDING_EXPIRED — UserName:a-tluk;DomainName:CONTOSO;UserDn:cn=s-1-5-21-206374890-975330658-925700815-10626,cn=foreignsecurityprincipals,dc=vdi,dc=vmware,dc=int;UserSid:null;GroupSids:null;BrokerUserSid:S-1-5-21-206374890-975330658-925700815-10626;ConnectionId:fcca_***_1220;Protocol:null;ClientName:null;ClientAddress:null;ServerDn:cn=a34734d6-4e78-4d07-83c4-5ce3d1ce31cd,ou=servers,dc=vdi,dc=vmware,dc=int;ServerPoolDn:cn=standard_CON_desktop,ou=server groups,dc=vdi,dc=vmware,dc=int;ServerDnsName:CONFSTAWKST-158.tokiomillennium.com;DynamicIpAddress:10.23.0.92;ManagedObjectId:null;Id:e1f29aa5-68ed-437b-ad9f-cc1759d63d8b;State:PENDING_EXPIRED;SessionGuid:c80b-***-2d5b;PreviousSessionGuid:null;LoggedInAsDomain:CONTOSO;LoggedInAsUser:a-tluk;SessionType:DESKTOP;RemotableContent:null
Reviewing the Events database in the View Administrator console reveals the following:
The pending session on machine <VDIname> for user contosoa-tluk has expired.
What I’ve done in the past for troubleshooting black screen disconnection issues was to reinstall the VMware Horizon View agent but what I noticed was that attempting to install the View Agent on the master image after uninstalling it would briefly show the splash screen, disappear and nothing would happen. From there, I proceeded to uninstall VMware Tools and reinstall it but quickly noticed that the install would fail with the message:
VMware Product Installation
This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package.
Attempting to copy the installer onto the desktop and run the install would generate the following error message:
Setup failed to extract the files necessary to install VMware Tools.
From here on, what ended up being the cause of all these issues was actually because there was no space in the %temp% directory to extract the installation files. The reason why this was the case was because the environment I was working in had SanDisk’s ioVDI solution deployed and the %temp% folder was redirected to a disposable disk that also stored the page file which had already filled up the disk. This was why the installer for VMware Tools and the Horizon View Agent would fail and it was also why the user had connection issues.
The whole ordeal concluded in a way that I did not expect so I hope the error messages I outlined here would be able to help anyone who happens to come across a similar issue with the same cause.
Про View
Интересные заметки про VMware View:
1) Интересная особенность работы PCoIP в VMware View.
В ходе тестирования работы VMware View 4.6 с платформой виртуализации vSphere 5 (в составе vCenter 5 + ESXi 5) мы с моим коллегой Mikhalych обнаружили интересную особенность — при работе пользователя в сессии VMware View по протоколу PCoIP, администратор платформы виртуализации может подключиться к консоли виртуальной рабочей станции пользователя, но при этом он увидит лишь черный экран.
Однако если попытаться переключить фокус в черную область консоли, то нажатия на кнопки и движения мыши будут переданы в сессию пользователя VMware View.
2) Подготовка Windows 7 для Linked Clone в VMware View/VMware View + ZeroClient (Pano 4.5).
3) Настройка серверов View в NLB-конфигурации.