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


Embed this content in your HTML

Search

Report adult content:

click to rate:

Account: (login)

More Channels


Channel Catalog


Channel Description:

Most recent forum messages

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

    0 0

    I figured out what the issue is in the end.

     

    My PC host has a Killer brand network card. Last week I had to reinstall its driver due to a Windows issue. When that happened the Killer driver suite has a feature called "Advanced Stream Detect" which was on by default. This is the feature that if left on seems to break the Horizon client connection and when off, Horizon works fine - confirmed now.

     

    I had a sudden realization tonight that the driver was changed recently and so I went turned off the ASD feature and Horizon was happy again.

     

    I wrote to Killer a year ago when I purchased my PC which is when I first found the same problem that if the ASD feature was on it was doing some screwy things to some other apps. I stopped using their driver back then but forgot about it when I had the driver issue recently and it got me again!

     

    Thanks for the help all and sorry for wasting your time.


    0 0

    We're experiencing similar issues since upgrading to Horizon 7.4 from 7.2.0 about a month ago.

     

    We are seeing that if a vCenter goes down (for a maintenance reboot, Windows patching, etc.), View logs that it's unavailable for the duration that it's down, and reconnects when it's back up, but has severe issues until a Connection Server service restart takes place on one or all of the Connection Servers in the pod.

     

    We have power on policies on all of our VM pools (persistent, ful clone VMs), where if a VM is shut down by a user, View tells vSphere to power it back up almost immediately.  This operation stops working once the vSphere unavailability above take place.  We also have provisioning problems (failed customization, "Error", "Missing", etc.).

     

    This has happened at least 3 times over the last 2 weeks, and it's begging to impact production (VMs powered off so users can't access them). We have had to constantly monitor the inventory and manually power them on, sometimes dozens at a time (we have a lot of VMs).

     

    It's been resolved for us each time by recycling the Connection Server services overnight when fewer users are connecting (or by taking them out of the load balancers one by one and recycling the services), but that is getting old and not sustainable.

     

    We're opening a BCS case shortly, but I wanted to add that we're seeing the same lack of resiliency since we upgraded to Horizon 7.4, that we didn't see on previous 7.x releases.

     

    Horizon 7.4

    VCenter Server 6.0.0 Build 7462484


    0 0

    Didn't work for me as well. Gonna report the bug to apple like cashxxx.


    0 0

    We were provided a hotfix for 7.4.0 that has helped with this.

     

    VMware-viewconnectionserver-x86_64-7.4.0-8215536.exe


    0 0

    Thanks both for your input that is very interesting stuff indeed.

    It seems wrong that a mere network interruption breaks the whole thing.

     

    paulmike3 Please let us know how your SR evolves.

     

    I opened one myself, we'll see how it goes. I'll keep you posted.


    0 0
  • 06/29/18--01:07: Windows View Client - Proxy
  • Seem to be having an issue with Windows Clients (4.7 & 4.8) logging into internal desktop pools (2016 RDS Manual) enabling the proxy server in IE. Results in users not being able to access anything on the Web (as you'd expect), until they remove the proxy setting.

     

    Logging in via HTML, or another OS (ThinOS) does not have this same behaviour and I have no proxy settings configured on the RDS side via GPO. There is also no proxy server conigured within IE on the Windows client.

     

    This only happens when Windows clients connect in. Not been able to find any documentation stating a reason for this behaviour so hopefully someone else might be able to give me a quick fix for it.

     

     

    VMWare Horizon 7.4 (7400497)


    0 0

    cannot extended screen while working with horizon clinet(ver 4.8) while localy I can easily work in extended(dual) screen


    0 0

    I had the same issue except it was more frequent and worse. Users would have it happen at least 6 times a day and sometimes last up to a minute. I eventually found a solution however.

     

    It turns out it was due to the fact that we had multipathing enabled in eSXI on our servers when accessing the extremeIO. Once we disabled that things worked fine.


    0 0

    This could be due to the way your Horizon administrator has the pool setup.  Perhaps they only configured it with enough video memory for one screen.  Try starting there?


    0 0

    Hi smith_II,

    You might installed VMware Client IP Transparency feature in the RDSH and your client host doesn't have interent access. This setup option is not selected by default.  You can disable it by VMware Client IP Transparency Policy SettingsGPO  through VMware View Agent Configuration ADMX Template Settings , Thanks.


    0 0

    Hi

     

    Thanks for reply. Video memory screen is two but though not able to extend.


    0 0

    Is anyone familiar with what "null desktop launch timing profile for user xyz" means in the View events log? I can't say for sure this is even linked to an ongoing issue, but, we come across it in the logs while working on another issue, or even through routine log reviews. We do use cloud pod across 2 data centers, and wonder if it's related to a user authenticating in DC1, but getting a pool/desktop from DC2.

     

    I couldn't find much through the Google, so, hoping someone on the forums has a better definition than what I have, which is nothing.

     

    We did enable the timing profiler on all of our brokers a few months ago. If anyone knows the command to verify that, I'd love to have it. I have the comm and to enable/disable, but, would be nice to just check status.

     

    Thanks in advance.


    0 0
  • 07/02/18--06:08: Vmware horizon client login
  • Hello,

     

    I installed Vmware Horizon 7.1 , it's work well ! All users use active directory to Login.

    If user want to connect he need to type user1@domain.local and then the password , i want to know if it's possible to login just with the login without writing @domain.local

     

    If it's possible how can i do it ?

     

    Thank you for help.


    0 0

    Logon to your connection server admin interface and go to View Configuration and then global settings. One of the settings are "Hide Domain List in client user interface", see if that is set to yes. I'm assuming so if your required do the @domain part. Setting this to no will provide a domain pick list, but you can just do the first part in the username field.


    0 0

    Set the above GPO and seems to have done the trick. Will look to check if Client IP Transparency is also installed.

     

    Thanks Pengwang!


    0 0

    Can confirm that the same still happens on MacOS 10.14 Beta 3.

     

    Although who's to say that it's an apple issue, and not the way that VMWare has hooked into the system to display the VDI desktops?

     

    After all - RDP client works OK, and that does pretty much the same thing...


    0 0

    I can also confirm, it has not worked for me on Mojave since using the beta 1, 2 or 3 today.

    Also downgraded to 4.7 just in case, still no go. I am just trying to be patient


    0 0

    I am facing issues to connect the local internet connection on my AOL desktop, I tried to find out some local servers from AOL chat support, then I sorted out the list and got the perfect local connection on my machine.


    0 0

    Just for the record, doesn't work with iOS 12 beta 3 either..

     

    I would suspect that apple have added an extra security layer that Horizon clients were bypassing, and this is what's causing the issue - similar things happened with macOS 10.11 and VMWare eventually updated the client to work - version 3.4.1 was released with the release note.

     

    • When you connected to a remote desktop from a Mac OS X El Capitan (10.11) client system, the entire desktop window was black. This issue has been resolved.

    0 0

    Hi!

     

    Personally, I prefer PCoIP because this protocol comes with support for multiple codecs which deliver great UX and offer optimal bandwidth and CPU load in VDI environments. This expands your options because you can then choose between various codecs for specific tasks. Blast Extreme, on the other hand, is a single-codec protocol.

     

    I would recommend you to narrow down your choices to Wyse, HP and ClearCube. All three vendors offer endpoints that support the Blast Extreme protocol. However, my personal favorite is ClearCube because their customer support team has been very responsive to my needs. I was not familiar with their VDI endpoints but after understanding my business model, they suggested a thin client solution that delivered. 

     

    The CD8841 thin client device might resonate with your particular VDI environment as it did in my case. It comes with support for Linux® operating systems and Cloud Desktop OS and protocols including:

     

    1.        VMware Horizon® View with PCoIP® and Blast Extreme.

    2.       Citrix® XenDesktop®, XenApp®.

    3.       Microsoft® RemoteFX.

     

    You can always configure the system according to your needs. Other than that, keep your options open to further understand what would best suit your use case.

     

     

    Feel free to share your views with me!


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