I am doning Citrix for some years now but I never had to do a Windows OS migration of the Management Servers (DDC, SF, PVS) - there is a first time for everything! 🙂 We have two nodes per role DDC1/2, SF1/2, and PVS1/2 and I would like to keep the IP and Names of the servers. My idea was to remove the "2" servers from each service, rebuild the server with the new OS using the same Hostname and IP, reinstall the Citrix Components and rejoin it to the existing site, farm, or deployment. After some tests that they are stable enough, I would repeat that with the "1" Servers from each service. The Only "issue" I found is that SF does not support different OS Versions in the same Server-Group, but then will just export the config and import it and create a new Server-Group. Obviously there is a risk because only one server is available for some time and the rollback would probably be more complicated. Has anyone used this approach? Any recommendations? Is it valid and are there any issues or recommendations I should consider?

A collegue of mine, just did that with the DDCs, and that exploded. One of the issues were, there were a bunch of SSID information in the site database, which needed to be changed. He straight up recommended never to that again, but create new VMs, join to site.

Hi Daniel, if have done a OS upgrades with the same setup as you do. Just make sure that you install the exact same version of Citrix.

It should work, just make sure that the "2" servers are properly removed from the Citrix site configuration so it doesn't leave any traces. There are documented procedurs for this on the Citrix support site I think. And as @Remy says, make sure that the Citrix-version you install on the new server is the same as the existing DDC ("1" server). It can be a bit tricky to find a mix of Server OS version and Citrix version that fits your need, of course. The whole Citrix-site can be upgraded to a new Citrix-version once the servers have been replaced with new updated servers.

I will check my notes tomorrow at work @Daniel E. but it shouldn't be an issue 🤘

@Daniel Madsen I am pretty sure that if the removal is done properly, it shouldn't be an issue. Any SSID information etc should be cleaned out if the removal is done the correct way. I think I have done something similar in the past myself...

@geir.sandstad I've done it aswell, and advised my collegue to it as Daniel describe, but my collegue needed to work several hours, to get it working, after adding machine with the same name.

Yeah, things don't always go as planned. I have had my issues with site databases in on-premise sites that have been corrupted or outdated causing issues during upgrades. The issues didn't show up in daily operations. There are a lot of things to consider when doing major changes...

i ran an in-place upgrade last time I had to do this (with snaps, obv). It actually worked fine

i did this about 2 years with the help of support, there's actually a kb for this. on the other side, snap, upgrade and rollback if issues during the weekend or whatever...i upgrade my DC's all the time this way.

Thanks a lot for all your input and tips! Sounds promising, I'll try it that way!

Remove DDC2 from the site, wait 24hours for the database server to forget the SID. There is a registry key that you can set on the sql server to not cache sids. When the sid is gone from the registry on the database server, you can rejoin the reinstalled DDC back to the site.