Here is another instalment in this upgrade Horizon Series. In this post we will go through the process of upgrading individual connection server to Horizon 7.12 release and then will refer to POD and Cloud POD architecture. As of previous post, we have successfully upgraded, Horizon clients and View composer server.
Before we go into step-by-step procedure to upgrade connection server to latest release, let’s look at the system requirements for Connection Servers. Horizon Connection can be installed on a dedicated physical or virtual machine with required resources.
Hardware Requirements for Horizon Connection Server
| H/W Component | Required | Recommended |
|---|---|---|
| Processor | Pentium IV 2.0 GHz or higher | 4 CPUs |
| Network Adapter | 100 Mpbs | 1 Gbps |
| Memory | 4 GB or higher | At least 10 GB memory for deployments of 50 or more remote desktops |
Now this is little fun trivia. Since Connection server is a generic term that refers to multiple server roles such as Standard, Replica, Security and Enrollment Server. So whose requirements I am talking about?
Well, these requirements apply to standard, replica and security server Horizon Connection Server instances. Did I miss Enrollment Server? Well not really, that was intentional of course. Enrollment server enables TrueSSO, so it has some add-on requirement, Visit VMware Docs for more details. It shares most of the requirements with other roles. I will keep Enrollment Server out of our discussion here onwards in this post.
Operating System Support for Horizon Connection Server
Below is the list of supported operating systems for standard, replica and security server Horizon Connection Server instances.
| Operating System | Version | Edition |
|---|---|---|
| Windows Server 2008 R2 SP1 | 64-bit | Standard, Enterprise, Datacenter |
| Windows Server 2012 R2 | 64-bit | Standard, Datacenter |
| Windows Server 2016 | 64-bit | Standard, Datacenter |
| Windows Server 2019 | 64-bit | Standard, Datacenter |
I hope you guys remember what I discussed about Windows Server 2008 R2 SP1 in previous posts, so upgrade to at least Windows server 2012 R2.
Security requirements for Connection Server
Read more about security and certificates related requirements for connection server at VMware Docs.
Upgrading Horizon Connection Server
As discussed in initial post, If you have two or more Connection Server instances behind load balancer, in order to minimize the downtime, remove Connection Server instances from the load balanced cluster one at a time while upgrading them.
Procedure I am going to describe in this post is in-place upgrade for upgrading Connection Servers that are not paired with security servers. For example, Connection Servers that are dedicated to LAN connections.
However, if security servers are being used, since Security Servers have one to one relationship with connection servers, hence upgrade each security server and its paired Connection Server instance. We can achieve zero downtime, if security server and connection server pairs are upgraded one by one. Removing each security server from the load-balanced group, upgrading the pair, and then adding the security server back to the group.
Upgrading Connection Server
Verify that you have a domain user account with administrative privileges to run the installer and perform the upgrade. The Connection Server installer determines if an older version is already installed and performs the upgrade. The installer also updates the View LDAP so we don’t need to worry about making changes to ADLDS database.
So let’s get started. The installer gives less options in upgrade process of connection server compared to fresh installation of it.
- Before I started installer, I disabled the connection server. This is generally done for Connection servers that are behind load balancers.
- Since I already downloaded required components, I just went ahead and launched the installer with Run as Administrator.
- On welcome scree, Just clicked next.
- Accepted the license agreement and clicked next. It popped up warning as in image below. So clicked OK to continue.
- It prompted for joining CEIP, which I skipped.
- Then it simply moved to install screen, so just clicked Install.
- After that it was just wait and watch.
- Once completed, clicked finish to end the wizard.
And that was it. We do not require reboot after upgrading connection server.
So in order to quickly confirm successful deployment of connection server, checked programs and it was looking good here.
Now the important part was to access the console, verify details and re-enable connection server, since I had disabled it prior to upgrade.
- So just tried to connect my server with https://CS-SRV.demo.local/admin and I was presented with below screen. So for time being continued with Flex Console. As you can notice, there is update that Flex console will be deprecated. So there is option to make HTML 5 as default.
- Once logged in with credentials, verified the server version.
- That was looking good, so went ahead and re-enabled the connection server.
Now that was quite a relief but still I have not done the test connection to VDI. And to do that, I need to upgrade the Horizon Agent and also update the GPOs.
Upgrading a Cloud Pod Architecture Environment
Upgrade procedure for connection servers in Single POD architecture is quite similar to what we discussed.
Use the following process to upgrade a Cloud Pod Architecture environment.
- Upgrade all Connection Server instances in one pod, according to the usual process for upgrading a single Connection Server instance.
- Repeat the preceding step for the other pods in the pod federation, upgrading each pod one-by-one.
During the upgrade process, some Connection Server instances use the latest version of Horizon 7 and some use the older version. Although mixed-version environment is supported beginning with Horizon 7 version 7.4, new features will not work in a mixed environment.
Thats all in this post. I’ll update Agent upgrade details, GPO upgrade and test connection results in next post Wrapping up with GPO and Agent upgrade.
!!!Cheers!!!
Thanks for that nice elaboration. Glad that we were on the same page. That sounds like a safe and practical upgrade plan. At the same time, since other products also you guys are upgrading especially vSphere so you guys are going to have fun upgrading. Cheers
Good write-up. I will leave you with three thoughts and associated questions:
1. VMware recommends that you not run two versions of Horizon against the same ADAM instance, as the newer version may have changed the schema during installation of the first upgraded connection server. How is this avoided?
2. Do you need to, or should you, disable global entitlements when upgrading pods in a cloud pod federation?
3. Say your current installation is on Server 2012 R2 and you desire to go to Server 2016 during the upgrade process. I think this is a common scenario, and one that we’re working under at my place of employment. How would you go about the upgrade to Horizon now?
Hey,
Thanks for those thoughts.
Here are my views,
1. First backup using vdmexport.exe from any one instance of Connection server instance. You should upgrade all connection servers in a POD in a single maintenance window. One server should roughly take 20-30 mins. It is correct that the new version will update ADAM schema during an upgrade and other instances in POD will show error status since they have different schema versions. So the solution is to upgrade all instances in the POD.
2. Mixed mode is supported after 7.4 with a limitation that new features are not available. So I would say not required but can be done to avoid unnecessary confusion for both users and administrators.
3. Disable one instance of connection server at a time in the POD, Take a snapshot, upgrade the OS. re-enable it once OS is upgraded. All servers should be prepared one by one prior to upgrading horizon.
Otherway around you can use this approach of upgrading one instance of connection server and then using new machines. In fact, I would prefer this since I will get a fresh image of Windows OS instead of upgrade one which may have stale entries in the registry.
https://docs.vmware.com/en/VMware-Horizon-7/7.12/horizon-upgrades/GUID-043C31E0-0E1A-4477-8CA1-1029C753FA51.html
Any other suggestions are always welcome.
You hit the nail on the head with your second idea. It’s the path we’ve decided to follow. It avoids Windows Server upgrades, which are not a preferred approach.
All but one connection servers in the pod are to be powered off. New connection servers on new Windows Servers (2016) are being created with the same names and IP addresses as the originals. They will be added to the pod, one by one, then the final original connection server will be powered off and replaced. As you said this guarantees that older connection servers aren’t running against an updated ADAM database (even though this is supported during the upgrade window).
What we’re not doing, is any work with the load balancers. We’re not removing or adding anything to the pools they manage. The Change Control, the fact that they are managed by another team, the monitoring of the servers behind them, plus all the testing required after every change, makes that option onerous, to say the least. Any load balancer should detect when a node behind it is unresponsive, so shutting down a node is no different to the device than a failure, which is always an expected condition (sooner or later).
As for global entitlements, since we run out of two data centers, each of which can support a full load, we are leaving those entitlements in place. The global traffic manager will just keep all connections to a single site while the other site is upgraded. Global entitlements assure that a user can get a desktop no matter where it’s served from and the GTM decides where it is server from. We have no local entitlements.
Lastly, after much (MUCH) discussion, we decided to jump from our current version of Horizon to version 7.10. It’s a long term service branch with promised updates and bug fixes. We’re not planning on doing any upgrading again for a while, and that seemed like the best path to take. One feature we’re giving up by not upgrading to the latest release is backup pools, but we’ve worked without them for so long, we can continue to do so.
As part of our upgrade process, we’re also ensuring that all our vSphere servers are running the latest versions of ESXi and vCenter Server. There have been numerous vulnerabilities in recent versions of, especially, vCenter. vROps too.