figured it out.
the default resolution of the pro 4s was to high, the pro 3s are not the high so it worked on my test but not on the client's tablet.
dropped the resolution down a notch and it was fine.
also the MS store version works well i found out.
We just recently upgraded our View Environment to 7.4.0-7400497 including composer service 7.4.0-7312595 and new agent etc, not long after the installation we had a number of pools go offiine with the message "error" missings and waiting for agent". The error was effecting non persistent stateless pools and on demand provisioning pools, our persona pools seems to be fine...weird.
Over night we have reverted back the composer service to 7.3.2 including our two connection servers to 7.3.2. So far things are working fine again.
Our Hosts are running on VMware ESXi, 6.5.0, 7388607 with vCenter Windows Version 6.5.0.10000 Build 597332.
I am just wondering if anyone has expereinced any issues after upgrading to View 7.4,
Cheers
David.
Hi
I am having problems with Bast connections through my UAG, I am just finishing off a deployment so its not yet work
When i try to connect through the UAG
In the client i don't get an error , it just spins for 10 seconds and then goes back to the pool selection screen
in the admin console on the connection server it allocates me a vdi in the events log
Is there a way to trouble shoot bast connectivity through the chain ?
it works fine over vpn or internally so in my mind it must be either firewall , the uAG tunnel or SSL error
to add my internal dns is different to my external , i am using a wildcard for the external dns all the way through to my connection server and it looks ok
PCOIP is working fine also
Thanks
Hi marlont_1. What are the exact vmware dll exemptions you added to your anti-virus?
Sorry, there isn’t any way I know of to do this. We used to have the View “openclient” project to allow this but it is not available anymore.
Make sure your Blast settings on the UAG have the external IP address and port like this. It uses port 443.
Since your PCOIP is working fine I'm guessing DNS resolution on the UAG is fine.
I have similar issue on my desktop pools with Windows 10 LTSB 2016 and View Agent 7.4
When I looked to the event Viewr, I saw this error:
I can confirm this error on two different infrastructures. When I switched back to Agent 7.3.1, everything works.
Any idea?
I think, it is time for support.
Hey
Do i not have to put https;//externaldns.com:443 ?
ive tried both and neither seem to work still
i get the error the display protocol for this desktop is currently unavailable
on the VM i get this in the blast worker service logs
2018-01-16 20:01:50.416Z [INFO ] 0x3914 ServerAsyncSocket::Listen: SSL Ctx is 0000000002D126E0
2018-01-16 20:01:50.416Z [INFO ] 0x3914 ServerAsyncSocket::Listen: Listen for FEC Async connection, port: 22443, numPorts: -1.
2018-01-16 20:01:50.416Z [INFO ] 0x3914 bora::Log: faSSL: SSL listen requested
2018-01-16 20:01:50.416Z [WARN ] 0x3914 bora::Warning: could not bind
2018-01-16 20:01:50.416Z [ERROR] 0x3914 ServerAsyncSocket::Listen: Error: 1 listening on Client Facing Port: 22443
2018-01-16 20:01:50.422Z [INFO ] 0x3914 ServerAsyncSocket::~ServerAsyncSocket: Destroy Server.
My firewall guy has confirmed the ports are correct from the firewall outside to the dmz interface on the uag , but as the 2nd nic sits on the inside management network its assumed all ports are open , is this correct ?
2018-01-16 20:01:50.422Z [INFO ] 0x3914 ServerAsyncSocket::~ServerAsyncSocket: Destroy Server.
As I mentioned we have removed all 7.4 Horizon view components and reinstalled 7.3.2, all our pools have been working fine since going back and with no issues experienced at all. My feeling is the issue is within the connection servers (Brokers), possibly the Adam database. At this stage we will be staying with 7.3.2. Also I do agree totally with you, the next step will be a support ticket.
Cheers
David.
Linked and Instant Clones worked like a charm after update 7.2.0 -> 7.4.0.
Just had trouble with a manual clone that got updated with Agent 7.4.0. VM was in state "waiting for agent". Workaround was:
1.) Remove UEM Agent, App Volumes Agent and Horizon Agent
2.) install the Horizon Agent again. Then UEM and AV agents.
3.) Afterwards I had to remove the VM from the pool.
4.) Power off the VM.
5.) Re-add VM to the pool.
6.) Power on the VM.
VM then was available again.
In case anyone wants to know the a/v exclusions that finally worked for me.
Hello:
We are expanding our use of VDI here and recently came across an issue specific to printing. Remote users were complaining about slow printing and after some investigation we are finding that print jobs are somewhat slow at transferring from the VM's printer queue to the Thin Client's printer queue. All of our printers are installed directly on our Thin Clients (Windows 10 LTSB), and print direct to the associated printer on their local network via TCP/IP. The local printing fro the Thin Client to the printer appears to be fast as expected. Users are printing to the printers in their VMs that use the ThinPrint output gateway, which then gets sent down over the WAN to the local Thin Client's printer, which is connected to its local network.
When we print some test documents, we see the jobs queue up instantly in the VM to their printers (that use the ThinPrint output gateway). But, after that there is a lag as the jobs take anywhere from several seconds to up to a minute at times to appear in the queue of the printers on the actual Thin Client itself. To my knowledge we do not have any bandwidth issues at this location. Latency is around 30 ms. The print jobs are around 150KB each in size (relatively small). This is a new location so we don't have a benchmark on speed, but I would think it should be really fast for small print jobs like this.
What's the best way to go about troubleshooting this further, and are there any settings we can try? Any help would be appreciated.
Thanks.
What version of Agent and Client are you running? Try comparing printing performance over PCoIP and Blast on the same client.
What version of Agent and Client are you running? Try comparing printing performance over PCoIP and Blast on the same client.
Sorry for leaving out that detail. We are on the Horizon 7.0.3 agent and 4.3 client. We have not upgraded either side because the environment has been very stable. However we do have a project to upgrade it in the near future.
Also, we cannot switch to Blast in production for a permanent solution, as our tests were suboptimal with screen artifacts and such that we stuck with PCoIP and we force this across for all of our clients. I thought ThinPrint worked outside of Blast and PCoIP anyway, as its own service. Does it sit within the display protocols?
Thanks for your help.
We are in the middle of an upgrade from 6.2.0 to 7.3.2. With VMware's assistance, we leapfrogged first to 6.2.5, tested fine, and then went to 7.3.2. Our environment prior to this was a dual data center VDI environment with CPA/Global Entitlements set across both. We are using F5 as our load balancer, with all clients hitting a GTM, that has 1 LTM from each of our data centers behind it. Those LTMs have 5 brokers from each side behind them.
We marked down the LTM in DC1 so no new clients would go there, and proceeded with the upgrade there. Composer servers first, then brokers, then security servers. No blips no errors, went pretty well. Upon everything being on 7.3.2, we started testing from our thin client, Wyse thinOS terminals. That's when we started to see issues.
We would specify a specific DC1 broker or the DC1 LTM itself (DC was the 7.3.2 side), authenticate, be presented with out DC1 Globally Entitled pool, and we would get an error connecting. Either desktop unavailable, even though there were available desktops, or we would get unable to launch desktop due to a communications failure.
What was odd was 2 things: if we instead picked a pool that was globally entitled over on DC2 (still at 6.2), even though we were coming in through DC1, it worked. The other thing was when using a Horizon windows or Mac client, we couldn't get this issue to happen. I did try 2 different Wyse thinOS models, both with an older PCoIP client version and newer, but no luck. The Wyse thin clients are 95% of our endpoint devices accessing the VDI world.
Apologies if this is all over the place, it's quite a confusing issue. All of the testing scenarios I mention here we have done numerous times before when the environment was 6.2, and they were always fine.
We do have a ticket open with VMware (or one is being opened shortly). I'm wondering if they come back and tell us to hop to 7.4 (which specifically mentions a resolved issue of connecting across CPA when the environments are different versions).This would be frustrating, since in our discussions, it was brought up we'd be in this state of in between builds, and it didn't get identified as a problem. Not to mention 7.4 is barely out the door.
I'd be glad to clarify this mess of a post if anyone has any insight/questions that could help us out. Thanks in advance.
ThinPrint goes over virtual channel, which is part of the display protocol traffic. You may want to try Blast anyway as part of your speed comparison, just to have the data.
I will ask around about printing performance, but I suspect that the answer may not be what you want to hear: upgrade to 7.4 and switch to Blast because of the adaptive transport that was added recently. But I want to hear from the engineers first before recommending this.
Hello Expert
Can you help me to resolve this issues ? I got stuck at this issues while recomposing the VDI's. Appreciate your help.
Also, what is the OS of the View Agent VM? Are you doing VDI (desktop OS) or RDSH (server OS with RDSH role installed)?
What version of View are you using?
We're seeing a similar issue with 7.3.1, but that version is no longer available for download due to a number of bugs (possibly could be the cause for this). Supports answer was to upgrade to 7.3.2 or 7.4, which have yet to do as the issue is manageable enough for now.
The other times I've seen this is when the agents have been updated on the gold image without doing it in the correct order (90% of recompose issues in fact!):
When updating any agent, I find the only cast iron way to ensure you don't have recompose issues is to ensure you uninstall the other agents in the reverse order of this list until you get to the one you need to update - update it, and then reinstall your other agents in the correct order (with a reboot between each uninstall / reinstall).
If you also use App Volumes, don't forget to export the registry settings before you uninstall an agent for the svdriver /svservice keys), as you no doubt have edited entries in it at some point:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\svservice\
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\svdriver\
Are you using the Horizon View iApp in F5? If so, have you checked that View 7.3.2 is supported on the version you are using.
As far as I am aware, only the very latest Horizon iApp is officially supported with 7.3 (f5.vmware_view.v1.5.3), though we do have a site working at 7.3 that uses v1.5.1 happily.
Also, slightly off topic, but if you use APM then you probably haven't noticed yet is that HTML5 access does not work on 7.3 if you don't update your pools to allow users to choose their own protocol. For F5, you also need to add an additional irule to your VDI https virtual servers (or update BIG-IP):
https://support.f5.com/csp/article/K65620682
BIG-IP APM with Horizon 7.x HTML5 gets a Hotfix For Updated Code
