, Rebuilding Horizon View 7 Environment

[Psychomike70]

Looking for a little advice...We currently have a Production Horizon View 7 environment consisting of (2) 7.2 Connection Servers and (2) 7.2 View Composers. These are running on Server 2012r2. We have been unsuccessful upgrading the Connection Servers to Horizon View 7.8 (suspect due to a STIG or ADAM instance issue), View Composers will upgrade without issue. We have a project that has the Horizon View environment getting rebuilt, using Server 2016, and folding into the new vCenter 6.7 environment we are currently building out. We will also be moving to Windows 10 1809 in the next 3-6 weeks, which is not supported with Horizon View 7.2 and is causing some issues with VMware Tools (yes the hpet0.present work-around seems to help but is not 100%). To add another fun wrinkle, the Connection Server certs are going to expire in JAN 2020.  I also want to move to Global Entitlements (Cloud Pod) in this environment and our current Production Connection Servers are failing to initialize (might be part of the upgrade issues).

Current Environment:

(2) Server 2012 based Horizon View Connection servers and View Composers.

(2) vCenters (6.5 VCSAs) that host the non persistent virtual desktop environment

I believe that I have 2 options to get the Connection Servers updated in time to support the move to Windows 10 1809 as we are working through getting the vCenter 6.7 environment up and stable.

Option 1:

Build (2) Server 2016 based Standard Horizon View 7.8 Connection Servers. Initialize Cloud Pod and ensure they are replicating properly. Schedule a maintenance window. Move entitlements off the pools based in one of the vCenters. Delete the desktops/pools running in that vCenter. Remove the vCenter and Composer from Horizon View. Update the View Composer to 7.8. Add the vCenter and Composer to the 7.8 Horizon View pod. Ensure that I can build out machines/pools. Add Move the entitlements back to the Global Entitlement. Repeat the process for the second vCenter and Composer. Update all my endpoints with the new Connection Server LB certificate.

I am hoping that by deleting the virtual desktops, that it keeps everything (database/inventory) clean.

Option 2:

Build (2) Horizon View 7.8 Connection Servers (on Server 2016) and make them replicas of the current 7.2 Production Connection Servers. Schedule a maintenance window. Update the endpoints with the new Horizon View LB certificate. Update the View Composers to Horizon View 7.8. Remove the Horizon View 7.2 Connection Servers from the replica group.This doesn't get me Cloud Pod (yes I can initialize it after the fact, but that is not how VMware says it should be done).

Since these are production assets, I probably would not get approval to take one Connection Server down, export out it's certificates, and replace it with a new (using the same name/IP/certificate) 7.8 Connection Server. Then take the other one down and repeat the process. I also have to plan to build out new View Composers (don't have a DBA atm, hence why I am not going to build them now). Once my vCenter 6.7 infrastructure is up, I can tie the new 7.8 View Composers to them and add them directly to the 7.8 Connection Servers (that will now be Production). This will allow me to keep all the inventory separate as well. Leadership is getting very leery of "in place upgrades" of the Production environments, so if I can use one of the above processes moving forward that is even better.

So which option looks better from everyone's experience...or I am missing other cleaner and easier options? Thanks in advance!

Also, another quick question. Will simply deleting the virtual desktops and pools from the View Composer-vCenter allow a "clean" rebuild of the desktops using the new 7.8 Connection Servers? Or do, or should I, just bite the bullet and build out new View Composers to attach to the existing vCenters? Either way I believe I would want to clear all out the desktop pools/virtual machines to ensure that my inventory is as clean as possible?

[cbaptiste]

I would suggest you do a parallel upgrade. Meaning deploy a completely new environment. I would suggest using a newer version oh Horizon View rather than 7.8. Maybe 7.10? Why would I suggest that? Well, if you are going to put the effort to deploy this environment you might as well do some research on big and fixes, new features, as well as linked clones/instant clones feature parity.

Instead of deploying Horizon View brokers using Win 2016, I would usuggest 2019. Why? End of life support. Why use older version of OS unless license is an issue. Newer version with an extended end of life support equal less worry about upgrading the OS any time soon. I would ditch linked clones and go with instant clones unless there is a feature in linked clones that is not available in instant clones. Once you ditch linked clones you no longer have to deal with composer servers. Now you have 2 less servers to manage.

By doing a parallel deployment you can do your testing without impacting production. It would be clean. You will not be bringing any ADAM database issues along with the install. You can create your desktops, entitled the users to it and when you are ready to migrate them from the previous environment you simply change the F5 LB to point the VIP to the new member servers. With this plan, your scheduled downtime is only a few minutes. :smileyplain:

[sjesse]

Same as above, with the exception if your using cpa you can add the upgraded pod to the cp federation, and slowly move over users to the new one without any downtime. I would do this after testing the pod isolated first to make sure the infrastructure is working, then add it to the federation.This is the method I'm going through right now.

[Psychomike70]

Thank you both for the replies.

Our normal operation is to build out a parallel environment so that we can test everything prior to deploying to production. We just started to build the new vCenter 6.7 environment, however, it is going to take time due to paperwork, change boards, STIGs, and other factors. I was trying to plan a way to move new Connection Servers into production in the event that we have to migrate to Windows 10 1809 before we have time to get the new infrastructure up and running.

I can't go to Horizon View 7.10 atm as it is not been approved on my production network at this time. Horizon View 7.8 is as high as I am currently approved to go.

I have (2) networks, one that isn't running CPA (which happens to be the one where the upgrade fails), and one that is running CPA (which we have to test the upgrade once we get McAfee out of the way).

With the CPA network, worst case is that, as you mentioned, I stand up (2) new replicated servers and add them to the existing Pod. Once the View Composers are upgraded, I can remove the other Connection Servers (using repadmin etc...) and should be good to go.

My biggest concern is moving (2) new 7.8 Connection Servers in to the environment that is not taking the upgrade ( I believe due to an ADAM database issue ). One option is to add them as replicated servers with the existing CS, but I am concerned that I would replicate whatever is preventing those CSs from updating.

I have drafted a process to move one CS in at a time. This is where I would have to delete all the desktop pools on one vCenter/Composer combination, remove it from the current Horizon View configuration and add it to the new 7.8 Pod. Rinse and repeat for the other vCenter/Composer pair. Just hate doing this without any real testing so trying to make sure that all the areas or potential issues are covered.

[cbaptiste]

I only advised against joining the existing CPA because in the original post he mentioned issues with his existing CS. that means the same corruption can potentially be synced to the new brokers.

[sjesse]

The global entitlements are supposed to be a separate ldap database so the corruption shouldn't follow.