Vmware Horizon Connection Server 7.13 Download
Poppy Yentsch
If pae-ClientSSLCipherSuites or pae-ServerSSLCipherSuites have values in the Active Directory Application Mode (ADAM) database, you must reset those values and make sure they are empty () and then reboot all the connection servers before performing the upgrade. Failure to do this will prevent you from being able to connect to the Horizon console after upgrade.
If pae-ClientSSLCipherSuites or pae-ServerSSLCipherSuites have values in the Active Directory Application Mode (ADAM) database, you must reset those values and make sure they are empty () and then reboot all the connection servers before performing the upgrade. Failure to do this will prevent you from being able to connect to the Horizon console after upgrade.
The default self-signed TLS server certificate generated on Unified Access Gateway, Horizon Connection Server, and Security Server might not be usable by Chrome browsers, Safari browsers, or VMware Horizon clients running on macOS 10.15, iOS 13, and Chrome OS 76. This problem can happen because the requirements for trusted TLS server certificates have been changed by Apple in these OS versions. The default self-signed certificates do not currently meet these new requirements. If the connection to Horizon from a client is through an intermediate load balancer or proxy that terminates TLS, the new certificate requirements must also be met on those devices. On Horizon Client for Mac on macOS 10.15, "Warn before connecting to untrusted servers" mode might not continue without verifying the self-signed certificate, the "Untrusted server connection" dialog box pops up with the error message "VMware Horizon Client cannot verify your connection. Contact your administrator.", and only the "Show Certificate" and "Do Not Connect" buttons are available.
This is more informational than it is a question, but I am surprised it is not documented. We were on Horizon 7.11 Standard, which means we did not have the license for instant clones. Then 7.13 came out and included instant clones with the standard license, I assume to assist users with upgrading to Horizon 8. So on my project to upgrade to Horizon 8 I first upgraded to 7.13, and converted all my pools to IC, and then decommissioned composer. Then, today, I went to upgrade to Horizon 8 2006 and when I ran the Horizon 8 installer on the connection server I received the error: This installer can not upgrade over the existing Horizon connection server version. Please uninstall the existing version before attempting to install this version." I went back to review the upgrade documentation and nowhere does it say you first have to uninstall the 7.x connection server. A bit research on Google, and the only place I see any comment about this is in the esteemed Carl Stalhood's 2006 Connection server document, in the comments -horizon-8-connection-server/ .
We are trying to upgrade our VDI environment from 7.11 to 7.13 to set us up to eventually upgrade to Horizon 8. I wanted to ask about the upgrade process from 7.11 to 7.13 as I have never had to perform an upgrade before. Our environment is relatively simple, we have 2 connections servers(one is a replica) using instant clones and DEM with one production pool for the VMs.
From the research I have done it seems like it is pretty straight forward upgrading from 7.11 to 7.13 but I have been unable to find a good guide for this. Can anyone tell me how smooth the transition is from 7.11 to 7.13? Are there any gotchas I should be aware of? Is it as simple as doing an in place installation on the current connection servers. Any information is appreciated. Thanks!
I have one clarification about Full-Clone Automated pool (Dedicated assignment)
when i rebuild the one of the FC pool machines its deleted and re-created successfully. But the User got assigned some other available machine on the same pool. is there any setting i have to do it from connection server to assign the same existing machine want to assigned the user?
When you have different versions of connection servers weird things can happen, 7.12 to 7.13 may seem like small jump, but they backported changes in 8 which are pretty substantial. I'd do the all in one window.
So you don't need to do them all at once, look at the guide @a_p_ shared, you disable one do the upgrade , enable it and then enable the other one. If you have a loadbalancer in front of the connection servers you shouldn't run into any issues.
When you upgrade the default vdm certificate may be reenabled, normally you would just rename yours to the friendly name of vmd, and name the default one to something else. Really you shouldn't even rely 100% on the snapshots you should have the ldap ldif backup, the ssl cert, and the locked.properties file if you have it configured. That way you have all that is necessary to create the connection servers from scratch without reconfiguring them.
on the connection server is the only way you'll have a real outage. If you use connect directly the virtual desktops(if the security gateways are disabled, or if you use unified access gateways connection server upgrades won't interrupt users.
How is it possible to not interrupt users? The composer server upgrade specifically states that you need to disable provisioning. My simple brain tells me, that means existing machines will continue to work but no one new can be provisioned a machine. Once that is done I can re-enable the provisioning, if the 7.13 composer will work well with the 7.12 connection servers.
Once that is complete, if I change my DNS, I do not have a true load balancer, I could bring the connection servers down one at a time to update them. This part I see a pathway for users to not be interrupted.
Enter the FQDN of a connection server (NOT a Security Server) when prompted to "Enter the Horizon Server Name" hit enter. If you want to set a Security Server pairing password, enter the name of the Connection Server you want to pair here.
Enter 3 to manage and update the Horizon Security Servers bound to the connection server you logged in to - this will open up a GUI The GUI may behind other windows if you don't see it after hitting 3 on the menu.
In order to add a new Security Server - you need to specify a pairing password for one-time authentication to the connection server. This password is good for 30 minutes and just a one-time password. This script allows you to set that password.
While putting together the script I realized that the pae-securityserverpairingpasswordlastchangedtime parameter in the ADAM database which is used to determine when the password was last set and used to compare to the validity time is not being set properly if you connection server is not using the UTC time zone. If you leave the connection server to a non UTC time zone and run this script the password last set time will be the time zone of the connection server which almost certainly deem the password invalid. If your connection server is in a time zone other than UTC you will need to set to set it to the UTC time zone, restart the "VMware Horizon View Connection Server" service. Run the script to set the password, then you can change the time zone on the connection server back.
1) The VMware Horizon Web Server that manages the connection servers, look at that name for proxying connections. even if you have a wildcard certificate and change that name to something that doesnt fit the wildcard the proxy errors out. so when the services are running those fields determine how the connection server will proxy. When using Connection Servers as a Direct Connect not Tunnel Customers would use Specific CN Named certificates myconnect.domain.org, and if it was set to server1.domain.local the connection server would actually error out against the cert providing a bad cert reference to the client. by checking the box fixing the name, saving it as myconnect.domain.org then going back and unchecking it allowed it to work appropriately. At least this was what happened a lot when i worked at VMware's GSS (Global Support Solutions) area way back in the day
2) So when the boxes are checked on a connection server that means that the connection servers are tunneling all traffic, for HTTPs its (443) for PCoIP its (4172 TCP/UDP) For Blast its (22443 TCP/UDP)... Usually when a direct connect fails and a tunnel works there is a firewall between Client and Agent preventing the 22443 Traffic from connecting directly.. however there is a path for the connection servers to get to that subnet, Typically that is the cause of the issue, if you want to get deeper you could also install the Direct Connect Agent on the VMware Agent to see if you can connect Directly to the machine and remove the authentication of the broker out of the equation.
The following configuration diagram shows the natively proxied PCoIP connection deployment scenario described in the guide for View Connection server-only implementations. The deployment guide contains a number of different configuration options.
Thanks for your suggestions. I was able to get it to work. What I did for my environment is I did not enable Radius on the connection server but did enable Radius on the UAG and tested and it worked. We are only concern with MFA with external connections, not in the offices. Again, thanks for this article, helped me set this up on my own.
Great article. Worked great to enable Azure based MFA on my Horizon connection broker. I already had NPS setup for a VPN connection and after following these steps, my VPN automatically used MFA as well. That is fine for this VPN, but is there a way that I can add standard RADIUS clients that don't use MFA after deploying the NPS extension? Another thing I noticed is that after approving the horizon login via Authenticator app, it hangs on authenticating within Horizon for 10-15 seconds before showing my available pools of desktops. Is this expected behavior?
35fe9a5643