LHC will handle most of it on CVAD, pvs you need to enable the offline DB mode. But man that’s crazy to do a I place upgrade on a SQL box. I just went through this and migrated the databases for a client.

Most configuration databases will be cashed locally in ddc's using local host cache.. however the loging will not be cashed locally. So the impact might be log files.. However if you have a availability sql configuration. Then it will not be a problem as you will be upgrading slave and then master..

Bear with me, as I’m not a DBA and so I may not be using the correct terminology. But, I was told by the DBA that our named SQL server is actually a SQL always-on cluster made up of three nodes. He will be upgrading each of those on different days. I think this means I shouldn’t have to do anything, but I wanted to verify.

Oh then your good man.

Lovely, thank you so much. I’ve learned a lot and now I’m reading about always on availability groups.

Sweet, learning is great my man

I think it should be ok. If you get tested the upgraded node first on out of business hours with few administrative teams ..then you confirm that the upgrade has no problems. Alternatively you need to upgrade two nodes if your testing period leaves for 1wk or 2. I am sure you will do backups first before upgrading then you always have option to bring back old. Everything should go smoothly without pain .. but again we never know.

Regards to LHC: the registrations to vda with users will be impacted as it will will be looking for sql connections for new vda registrations ..but no problem for already registered vda configurations..

Are you referring to new user sessions, or just registered VDAs? I can make sure our VDAs don’t undergo scheduled reboots during the maintenance period.

The SQL upgrade maintenance period, I mean.

Not completely “During the time it takes all VDAs to register with a secondary broker, that service might not have complete information about current sessions. So, a user connection request during that interval can result in a new session being launched, even though reconnection to an existing session was possible. This interval (while the “new” secondary broker acquires session information from all VDAs during re-registration) is unavoidable. Sessions that are connected when an outage starts are not impacted during the transition interval, but new sessions and session reconnections might be.”

[https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/manage-deployment/local-host-cache.html#what-is-unavailable-during-an-outage-and-other-differences](https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/manage-deployment/local-host-cache.html#what-is-unavailable-during-an-outage-and-other-differences)

The CVAD should go into cached mode (users can only launch applications they've already launched previously) while the database is down. However, PVS will likely go down and those VDAs will probably become unavailable. You'd have to confirm it, but I do believe that is what happens.

The SQL server that is being called by Citrix is actually part of some sort of node group of three SQL servers. These are being upgraded on different days. So, technically, the SQL databases should never be inaccessible. That is what I’m gathering at least.

Ok.. if the SQL is fully HA, then it shouldn't be much of an affect on any of the VDA's. The worst case is that an incoming connection doesn't work, they might have to retry.