Hi Team,
We are planning to migrate View Linked clones desktops to New datastore using rebalance feature. The rebalance will migrate all the linked clone desktops, my doubt is, how to migrate parent VM, will this also migrate with rebalance or we need to use vmotion to migrate the parent VM ? because we will unmounting the existing datastore and we will be using only new datastore.
Regards,
Ranjith
just vmotion/move it, VIew doesn't care on what datastore it is.
Thank you Magneet, it worked.
Thus resolved with the latest Horizon Client update.
Is there anything else we can check from the Thinprint side of things? The problem is very sporadic here, and as far as I can tell it's not tied to network or bandwidth utilization. I was starting to look through the Thinprint settings and documentation, but I was hoping there were some general things we could do for optimization, or best practices?? By default it looks like Thinprint has some optimization settings already set.
Thanks.
What OS (and build version) are you running on the golden master image? The only times I've seen this are when we attempt to use a newer version of Windows (10), before VMware officially supports it. Currently, I have this very issue for Windows 10 1709 and am waiting for VMware to release the next version of Horizon to support it.
Why is this enabled by default? It is adding at least 10+ seconds to our logon time. The comments in the Fling state that it should be enabled only for troubleshooting.
do we have to install middleware on parent VM? we are running Windows 10. My understanding is middleware is built into Windows 7.x and above. is it correct understanding.
we would like to use Biometric (FingerPrint) on Windows 10 in post-session. I see you below as troubleshooting step is to check if SSO is enabled. I would like to disable SSO, instead allow Finger print to be used for Windows authentication. Is it possible?
Hello:
We are in the middle of troubleshooting a ThinPrint printing issue with some of our thin clients and I have been watching the thin client traffic more closely trying to identify a slowness issue we are having only with ThinPrint. All of our thin clients are a custom Windows 10 1607 image of ours that run the Horizon Client 4.3. When I look at traffic between the thin clients and our connection servers, I noticed that there is the normal PCoIP traffic which I expect, but there's also a fair amount of HTTPS traffic as well. Each thin client has both PCoIP traffic, and HTTPS traffic, ranging from 400KB to 700MB over a period of 2 days approximately. In our GPO we force PCoIP as the display protocol. But, what would the HTTPS traffic be, then? I thought HTTPS was only used for the initial authentication, and then it would switch over to PCoIP after that. But we are seeing a lot of HTTPS traffic, more than I would expect. I'm not sure if this is related to our Thinprint slowness issue but thought it was odd.
Can anybody tell me what would be using a lot of HTTPS traffic from the Horizon Client software to the Connection Server?? All of our clients have the Horizon Client 4.3, and our connection servers are on 7.0.3 as well as the Horizon Agent being on 7.0.3.
Thanks in advance.
What if you're having this issue when you are NOT using default self-signed certificates?
We are rolling out virtual machines to around 40 users for the purpose of using AutoCAD and Revit.
We have been testing and all seems mostly well, but have been getting quite a lot of lag on some drawings which are absolutely fine on 6 year old desktop workstations. The lag is worst when panning and zooming.
The VM's are using the M60 cards with the 4q profile and have 50GB of RAM and 8vcpus split across two CPU's. Storage is all on a 3PAR
We are using Appvolumes and also have an Apex2800 card.
We have HP T310 thin clients.
I have tried literally everything i can think of, and now at a loss on where to go next. We are half way through the roll out of the project and cannot continue until this has been resolved!
Any help is greatly appreciated.
Have you tried disabling the Apex card? I have one with GRID K2's in our lab and the 3D VM's with the K2's run like crap with the Apex in the loop. I get excellent performance as soon as I disable the Apex.
I second that.
We had bad experience with apex card also.
With Nvidia Grid cards you can leverage blast protocol offloading, which should work much better than pcoip&apex combo.
Thanks so much guys, i have been going crazy trying to work this out!
Disabled the Apex cards and it is working perfectly!!!
"With Nvidia Grid cards you can leverage blast protocol offloading, which should work much better than pcoip&apex combo."
How do i do this?
You can't with your zero clients. You would need to switch to a different thin client that supports the Blast Extreme protocol.
As per now, I found this is working for me
why because, even thou I delete this key "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\SessionDefaultDevices" it was re-creating after 5 sec, I don't know why it is re-creating but if I disable thous services, I am able to fix the problem.
Thank you,
Vkmr.
OK thanks mate.
I take it, it is correct to have PCOIP Hardware Acceleration turned off now we are not using the Apex cards?
If you're enforcing PCoIP, Port 443 is (besides initial handshake & authentication) used for things like Client Drive Redirection and USB Redirection.
We have 7 brokers in our environment that when we reboot them, it takes about 10-13 minutes uptime for the admin page to finally appear. We have kind of just accepted and gotten used to it, but, I always wanted to find out if that was the norm for everyone. It seems long to me. Am I just being impatient? Or are we possibly experiencing a problem all along?
And yeah the services are all running on the box well in advance. These are Horizon 7.3.2 brokers, but, we were seeing it even on 6.2.0.
