BenFB's Posts

It's advised to upgrade the Horizon Agent as soon as possible. However, it appears that the connection server is designed to be backwards compatible with older horizon agents for this exact reason. There are a few exceptions where cipher/protocol changes were made that were not backwards compatible but that's typically with major versions. I believe this note has been in every Horizon 7.x release If you use Horizon 7 servers with a version of View Agent older than 6.2, you will need to enable TLSv1.0 for PCoIP connections. View Agent versions that are older than 6.2 support the security protocol TLSv1.0 only for PCoIP. Horizon 7 servers, including connection servers and security servers, have TLSv1.0 disabled by default. You can enable TLSv1.0 for PCoIP connections on these servers by following the instructions in VMware Knowledge Base (KB) article 2130798, Configure security protocols for PCoIP for Horizon 6 version 6.2 and later, and Horizon Client 3.5 and later.

We load balance our internal and external connection servers along with our unified access gateways. This allows us to do maintenance and tolerate a failure a physical failure (We use host and storage anti-affinity rules to keep the connection servers and UAG on separate hosts and storage).

markbenson​ We did some additional testing and the connection server logs have all of the information that we need except for the client IP address. It instead shows the IP address of our load balancer. We've verified that we are sending the X-Forwarded-For (XFF) headers to the connection servers but they aren't adding that IP to the logs. Is there something on the connection server that we need to configure to support X-Forwarded-For (XFF) headers?

dmuligan​ You can do it either way. The default and simplest configuration is to flow the BLAST/PCoIP traffic from the Horizon Client > Load balancer > UAG > virtual desktop. We use the load balancer for the primary protocol and for the secondary protocol (BLAST/PCoIP) the Horizon Client talks directly to the UAG. You configure the tunneled external URL on the UAG which tells the horizon client the URL to connect to which bypasses the load balancer and talks directly to the UAG. It requires additional public IP and potentially additional certificates but we prefer taking the load off of the load balancer.

Right now we maintain two independent Horizon 7 environments that mirror each other including the pools. We have 1000 linked clones and 500 full desktops. Whenever a parent VM is updated at our primary site we clone it to or DR site and recompose the pool. We leverage array replication for our full desktops and would have to manually recover them (Leveraging SRM or Zerto for this would make life easier but we are working on converting everyone to linked clones instead. We are planning to add Cloud Pod Architecture to simplify entitlements and give us the ability to redirect select pools. We are then going to add F5 BIG-IP DNS/GTM so we have a single namespace for all internal and external clients.

We were on 3.0 and were stable for 3-4 months. We made some adjustments to the cipher/TLS settings and the next day both of our UAG were locked up and a simple reboot fixed the issue. We left one of the UAG in a broken state and worked with support but they couldn't figure it out. In our case we would see this error logged in esmanager.log when a user tried to connect. We've decided that any configuration change should be done by redeploying the UAG or at the minimum immediately accompanied by a reboot. 09/19 16:42:53,117[nioEventLoopGroup-34-4]INFO  processor.ViewSession[terminateSession: 297][]: Horizon session terminated due to expiration - Current Session count:1986 09/19 16:42:53,119[nioEventLoopGroup-34-4]ERROR proxy.HttpsProxyRequestHandler[write: 172][]: Unexpected exception: bsg.unavailable.UNCONNECTED java.lang.IllegalStateException: bsg.unavailable.UNCONNECTED at com.vmware.euc.gateway.products.view.bsg.BsgManager.assertAvailability(BsgManager.java:501) at com.vmware.euc.gateway.products.view.bsg.BsgManager.removeConnection(BsgManager.java:347) at com.vmware.euc.gateway.products.view.interceptor.processor.ViewSession.closeConnections(ViewSession.java:435) at com.vmware.euc.gateway.products.view.interceptor.processor.ViewSession.terminateSession(ViewSession.java:303) at com.vmware.euc.gateway.products.view.interceptor.processor.ViewSession$1.sessionExpired(ViewSession.java:280) at com.vmware.euc.gateway.edgeservice.sdk.session.Session.notifyExpirationListeners(Session.java:120) at com.vmware.euc.gateway.edgeservice.sdk.session.SessionManager.expireSessions(SessionManager.java:322) at com.vmware.euc.gateway.edgeservice.sdk.session.SessionManager.setExpirationFuture(SessionManager.java:296) at com.vmware.euc.gateway.edgeservice.sdk.session.SessionManager.create(SessionManager.java:156) at com.vmware.euc.gateway.networkcore.proxy.HttpsProxyRequestHandler.write(HttpsProxyRequestHandler.java:116) at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:724) at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:716) at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:802) at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:709) at com.vmware.euc.gateway.networkcore.proxy.HttpRequestAggregator.write(HttpRequestAggregator.java:115) at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:724) at io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:787) at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:800) at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:780) at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:817) at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1011) at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:289) at com.vmware.euc.gateway.networkcore.HttpsRequestRouter.write(HttpsRequestRouter.java:243) at com.vmware.euc.gateway.networkcore.HttpsRequestRouter.channelRead(HttpsRequestRouter.java:144) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:334) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:326) at com.vmware.euc.gateway.networkcore.session.AuthenticatorHandler.channelRead(AuthenticatorHandler.java:42) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:334) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:326) at com.vmware.euc.gateway.networkcore.session.SessionRequestHandler.channelRead(SessionRequestHandler.java:72) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:334) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:326) at com.vmware.euc.gateway.networkcore.LocalContentHandler.channelRead(LocalContentHandler.java:91) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:334) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:326) at com.vmware.euc.gateway.networkcore.DoSPreventionHandler.channelRead(DoSPreventionHandler.java:232) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:334) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:326) at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:334) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:326) at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1070) at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:904) at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:334) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:326) at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1320) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:334) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:905) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:123) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:563) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:504) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:418) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:390) at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742) at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:145) at java.lang.Thread.run(Thread.java:748)

We've also configured it this way. NIC0 is the Internet NIC and default gateway. It has static routes to reply to our load balancer for health monitoring (You must do health monitoring on the Internet NIC). We then have a single static route on NIC1 for our internal network (e.g. routes1=10.0.0.0/8 10.0.1.1).

At this time they still have it disabled and will revisit it at another time. The feeling is that the NAS where the images were located was not keeping up/disconnecting. This resulted in the VHD dropping and Windows thinking that a hard disk had corrupted.

Thanks for responding markbenson​. Are there any plans to improve UAG logging? Is there a way to at least map the UUID (XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX) that is in the UAG logs to something useful like a username? I tested logging in with the same username back to back and it was a different UUID with each request. With the volume of sessions that we see it's not always possible to correlate similar timestamp between the connection server and UAG.

We also have FlexAPP/ProfileUnity and determined that FlexApp was the cause. The team that manages FlexApp/ProfileUnity is still working through resolving the issue but once we disabled FlexApp the issue went away.

Definitely go with UAG, there are many improvement over security servers. For us going with security servers was a non-starter since they are paired 1:1 with a connection server. We have our environment deployed with load balancer>multiple UAG>load balancer>multiple connection servers. What issues are you running into with the UAG? They are tricky at first but once deployed we only have to touch them to do upgrades.

RADIUS only needs to be configured on the UAG and should not also be configured on the connection server (We have this deployed and working with two UAG behind a load balancer). It sounds like something isn't configured correctly on the UAG. Can you verify on the UAG that "Auth Methods" is set to "radius-auth" under Edge Service Settings>Horizon Settings>More. Also verify that "Enable RADIUS" is set to "Yes" under Authentication Settings>RADIUS. If you are doing a two NIC deployment the RADIUS traffic will originate from the internal/management NIC. Verify that you have the firewall configured appropriately.