Are you the publisher? Claim or contact us about this channel

Embed this content in your HTML


Report adult content:

click to rate:

Account: (login)

More Channels

Channel Catalog

Channel Description:

Most recent forum messages

older | 1 | .... | 883 | 884 | (Page 885) | 886 | 887 | .... | 904 | newer

    0 0
    0 0

    Minor update:


    We tried creating a brand new Global Entitlement, assigning it to the same desktop pool, as well as the same Active Directory user groups that the previous GE had. I guess the long shot hope was that somehow/someway, the GE was corrupted (even though this only affected 1 user out of hundreds). Alas, it did nothing, the same results.


    I've provided broker and client logs to support, waiting on their analysis. One step we may try this week, is flip the Horizon environment to out OTHER data center. Our current prod is running in our DC2 environment. The GE is stretched across both DCs, but, we're usually only live on one side at a given time. I feel very confidently that when we enable the DC1 pool, and disable the DC2 pool, this user is going to connect fine once again.


    We shall see.

    0 0

    I have a Win10 PC and a Win10 laptop that I use VMware Horizon Client (v4.8) to connect work's VDI server over the past year. Today, on my PC the VMware client is reporting a SSL error when I click to connect to the VDI server (error happens before any auth prompts). However, my laptop doesn't have the issue and is able to connect through ok. Both PC and laptop are on the same home network.


    I've had a look at the logs but I don't understand most of it so hoping someone can point out what could be wrong.



    Things I have tried on my PC:

    • Change SSL confguration to "Do not verify server identity certificates"
    • Uninstalled VMware Horizon Client - reboot - reinstall with latest v4.8 installer from - reboot


    This is the extract from vmware-horizon-viewclient-2018-06-25-160039.txt attached (server name and IP replaced).


    I tested connecting to any valid domain name not running vmware infrastructure and appears to get the same SSL error so it just appears the SSL error just a general error if there is no SSL handshake? I can confirm my work's VDI server is working though because as I mentioned I can connect to it from my Win10 laptop fine.


    What else can I do?

    0 0

    Hi netw1z,

    It looks like TLS cipher suite mismatch between client and server. Please check if the client host customized Configures SSL protocols and cryptographic algorithmsSecurity Settings for Client GPOs, you can use wireshark to investigate the ssl handshake traffic or enable view client trace log level to assist debug this, thanks.

    0 0

    Evaluating the VMware-rdpvcbridge-sdk-3.2.0 we found that the 32 bit client dll built using this SDK will not work on the 64 bit client box with installed VMware Horizon View Client 4.8.0.

    This was verified with sample application that is included in the sdk.

    Does anybody is able to run 32 bit client dll on the 64 bit client with success?

    If yes then what should be done to accomplish that?

    0 0

    Note1: We use Instant clone. Horizon View 7.4 & vCenter 6.5


    Note2: We had something similar a few weeks ago. During a firewall upgrade, both vCenters of our 2 VDI environment had a network downtime and put the VDI infra in a weird state. We had to reboot all the connection servers and vCenter servers to bring it back to normal.


    Now, after a network wobble over the weekend, our monitoring picked up a downtime of around 5 minutes on the vCenter of our VDI environment, in a normal environment you would see host disconnect/reconnect, nothing too bad. I expected Horizon View to be resilient enough to survive such a small issue.

    I remembered what happened the last time so I went to check and there it is, same issue as last time ...

    The issue is rather weird, there is connectivity between the CS and vCenter but it seems "some" things don't work.


    • Users will be able to log in as long as there are available desktops.
    • When they log off, the VM is deleting from vCenter but not in Horizon View.
    • The desktop goes in error state with the following status.

    25-Jun-2018 09:09:10 CEST: Failed to delete VM - Caught exception deleting VM XXXXXXX. Timed out waiting for operation to complete. Total time waited 5 mins



    Pairing state:In pairing...

    Configured by:<connection server #1> <connection server #2> ...

    Attempted theft by:



    • After that in the events there is a "Provisioning error occurred for Machine XXXXXX: Unable to remove Machine from inventory" and they are filled with

    Automatic error recovery for Pool YYYYYY: attempting recovery for Machine XXXXXXX


    Which of course does not succeed. I could clean it with viewdbcheck but it won't actually solve anything so it's no use.

    • No new desktop can be created. Meaning it is a slow death as users sign out until there is no more desktop available (until I reboot everything).


    The creation of a new pool also fails.




    As you can imagine having a network wobble break the VDI infra and having to restart everything is not sustainable for production especially as more and more users use it.


    I'm new to Horizon View so any idea will be greatly appreciated.

    0 0

    "downtime of around 5 minute"


    That is along time. Horizon in the back end uses an ldap database that tries to mimic the horizon infrastructure. When you delete a vm its deleted from the ldap database, and also vcenter. When that connection is interrupted the connection servers are no longer synchronized, and the way to fix it is to restart the connection servers. I don't know any applicaiton that can survive a 5 minute network outage. You should read this


    VMware Knowledge Base

    0 0

    Lucky for me Shreyskar replied to an old thread because it was helpful to me!

    0 0
  • 06/25/18--12:30: Re: RDP VC Bridge
  • Hi hrph and All,

    Does it mean that client 4.3 and higher supports only 64 bit version of SDK's sample?

    Because right now I am trying to build 32 bit client sample and it does not work with 4.8.0 VMware Horizon Client.

    Is it restriction that started from 4.3 version or there is a workaround to run 32 bit client DLL on 64 bit machine with Horizon Client 4.3 and higher installed.

    Thank you,


    0 0



    There are a couple of places you could look for a resolution to this.


    In the Horizon Client:

    Start Horizon Client and connect to a server.

    In the desktop and application selector window, right-click the remote desktop or published application and select Settings.

    Select the Allow display scaling checkbox.

    To save your changes, click Apply.

    To close the dialog box, click OK.


    In Registry or GPO DPI Synchronization:

    GPO: Administrative Templates (Computer) -> VMware View Agent Configuration -> Agent Configuration -> DPI Synchronization (Enabled)

    Registry on Master Image: HKLM\Software\Policies\VMware, Inc.\Vmware VDM\Configuration\DPI Sync (Set enabled 1)



    I have had success with both of these options to allow the client to adjust display properly, especially with the new Retina displays.


    Hope this helps.


    0 0

    The process that your dll will be loaded into (vmware-remotemk.exe) can be either 32-bit or 64-bit depending on the option that was chosen in the installer. You should build both 32-bit and 64-bit versions of your dll and register each in the appropriate hive of the registry for 64-bit machines.


    So basically:


    32-bit machines: install only 32-bit dll and put it in the appropriate subkey of HKLM\Software

    64-bit machines: install both dlls, put the 32-bit one in HKLM\Software\Wow6432Node, and put the 64-bit one in HKLM\Software

    0 0

    The client use default ssl GPO setting, so this is not the problem. The wireshark logs show some tcp retransmission issues, look like server side might not receive the packege correctly so that no server hello response in the server side during ssl handshake and dropped the connection. please check if there are firewalls or other devices issues in your env. Using curl/openssl -v severname should be same behavior in this host, can you always repro the issue in this host? how about web access the server? BTW, Suggest to remove the trace logs/wireshark in here and file a ticket with attaching these info in future case, Thanks.

    0 0

    Hi pengwang,


    I'm not sure what client GPO setting I should look at or change here but I've compared my PC's registry keys with my (working) laptop for this registry folder and they are the same:

    \HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMware VDM\Client\Security\

    LogInAsCurrentUser_Default DWORD 0

    LogInAsCurrentUser_Display DWORD 1


    Wireshark capture attached - filtered on destination VDI server IP


    Client trace changed to view traces and I have attached new client log trace.


    Thanks for your help in looking at this.

    0 0

    I've disabled all firewall and antivirus but still get the same issue every time. Direct browser access to server bring up a F5 front page since F5 is used to load balance the backend servers. Curl output below.


    I am not sure how I can log a ticket through here as an end user without service contracts attached to my account.


    curl -v

    * Rebuilt URL to:

    *   Trying

    * TCP_NODELAY set

    * Connected to ( port 80 (#0)

    > GET / HTTP/1.1

    > Host:

    > User-Agent: curl/7.55.1

    > Accept: */*


    * HTTP 1.0, assume close after body

    < HTTP/1.0 302 Found

    < Location:

    < Server: BigIP

    * HTTP/1.0 connection set to keep alive!

    < Connection: Keep-Alive

    < Content-Length: 0


    * Connection #0 to host left intact

    0 0

    Yea, been having the same issue here with the black screen in Mojave.  I have put in a bug report to Apple about it.  Please do the same if you have the ability to do so.

    0 0

    Please try to connect to port xxx:443, and does the client host face to internet or intranet? It might backend network related(Your corp IT admin might know about the network access rule  and should not be horizon client issue) since I can see the login dialog from my side, Thanks.

    0 0

    It works for 64 bit client DLL  but does not work for 32bit client DLL.

    If build the sdk sample application for 32 bit configuration and register client DLL here, as you proposed:


    #define KEY_NAME "Software\\Wow6432Node\\Microsoft\\Terminal Server Client\\Default\\AddIns\\VChanPing"

    #define DLL_NAME "vchan-ping-client.dll"


    • Setting Up vchan-ping on the Client
      • On 32-bit Windows systems:

                   a Copy the file vchan-ping-client.dll to the client.

                   b Register the DLL using the following command:

                        C:\Windows\SysWOW64\regsvr32.exe vchan-ping-client.dll


    • Setting Up vchan-ping on the Agent

              1 Copy the files vchan-ping.exe and vdp_rdpvcbridge.dll to a folder.

              2 Establish a Horizon 7 connection from the client to the agent.

              3 Run vchan-ping.exe on the agent from a command prompt.


    It will produce:

    Error reading virtual channel

    Press ENTER to exit.

    Is it limitation for 64 bit machine or something is missing?

    All above information is taken from:  VMware-rdpvcbridge-sdk-programming-guide-3.2.0.pdf

    0 0

    This desktop PC host having the issue is internet facing. Also, I mentioned before, my other laptop host which is also connected to the same personal home network but is not having any issue using Horizon client connecting to the same VDI server. Therefore I don't doubt this is not a VDI server side issue and must be isolated to my PC host which I cannot figure out what caused it to stop working (was working fine last week).


    I've tried reinstalling VMware Horizon client many times. I've also tried installing the VMware Horizon client app from the Windows 10 store but the Horizon client app also gives the same SSL issue.


    Below is the curl output to port 443 as requested. (I did the same on my work laptop and the output is the same as below)


    curl -v

    * Rebuilt URL to:

    *   Trying

    * TCP_NODELAY set

    * Connected to ( port 443 (#0)

    > GET / HTTP/1.1

    > Host:

    > User-Agent: curl/7.55.1

    > Accept: */*


    * Empty reply from server

    * Connection #0 to host left intact

    curl: (52) Empty reply from server

    0 0

    Try adding the following registry on the client machine:



    [HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ VMware, Inc. \ VMware VDM \ Client \ Security]

    "SSLCipherList" = "SSLv3: TLSv1: TLSv1.1: AES: RC4-SHA:! ANULL: @STRENGTH"




    If that doesn't work, you can try deleting this registry key (after backing it up) to see if it helps:



    0 0

    I have a similar issue to this.  We host VDI desktops with different applications on them for third parties to use.  One of them has a device that needs to connect to the VDI desktop by IP address but they are on completely different networks and domains.  Is there any way to bridge the networks through horizon or is it necessary to have a VPN to manage this?

older | 1 | .... | 883 | 884 | (Page 885) | 886 | 887 | .... | 904 | newer