Jump to content
  • 0

Replacing Delivery Controllers with new servers?



I am currently replacing our Windows Server 2012 R2 Delivery Controllers with Windows Server 2019 instances.  Will it cause problems if I join 2 new Delivery Controllers to the site, but the existing VDA's don't have them configured (at this point there would be temporarily 4 Delivery Controllers)? We've defined the Delivery Controllers to the VDA manually.


I know I need to add the new Delivery Controllers to the following places:


ADC -> Citrix Gateway -> Virtual Servers -> Gateway vServer -> STA Servers

StoreFront -> Stores -> Store -> Manage Delivery Controllers

StoreFront -> Stores -> Manage Citrix Gateways -> Gateway -> Secure Ticket Authority


Basically my plan is to join 2 new Delivery Controllers to the site, then change the VDA configuration to the new Delivery Controllers and after that remove the old Delivery Controllers from the site. We have about 15 Persistent Desktops to which I need to change the VDA configuration manually. For the Non-persistent desktops and apps I need to change the VDA configuration on the image, and update the machine catalogs. 


I just want to make sure that it won't cause any problems if there are temporarily 4 Delivery Controllers but the VDA's only have 2 of the configured.


One more thing: our second Delivery Controller (2012 R2) is also a license server, and it has Director installed. When I add a new Delivery Controller to the site can I install these features also on the new Delivery Controller? It won't cause problems that two Delivery Controllers have Director installed? I know I need to transfer the license files to the new Delivery Controller.

Link to comment

5 answers to this question

Recommended Posts

  • 0

I think I found an answer from this article:





A deployment has three Controllers: A, B, and C. A VDA registers with Controller B (which was specified during VDA installation).


Later, two Controllers (D and E) are added to the site. Within 90 minutes, VDAs receive updated lists and then accept connections from Controllers A, B, C, D, and E. (The load is not spread equally to all Controllers until the VDAs are restarted.)


Later still, Controller B is moved to another site. Within 90 minutes, VDAs in the original site receive updated lists because there has been a Controller change since the last check. The VDA that originally registered with Controller B (which is no longer on the list) re-registers, choosing among the Controllers in the current list (A, C, D, and E).


So when I have auto update enabled everything should be ok, and I shouldn't have to modify the VDA configuration at all, because auto update handles this.


But I guess it is smart to change the Delivery Controller settings on the master images from which I deploy new non-persistent desktops and apps?

Link to comment
  • 0
On 6/11/2020 at 1:27 AM, James Kindon said:

i always push the listofddcs key via GPP - this pretty much guarantees that life is OK, auto update (on by default) is often disabled in environments where control is required 

Thanks James, I think I'll use this just in case the auto update doesn't work.

Link to comment
  • 0

I am in a similar situation right now. We have to Update the OS of all Citrix Management Servers (Storefront, DDCs, PVS Servers) to Server 2019, since Server 2012 R2 is not supported anymore from Citrix 2003 and above. 


What I thougt about is to create two new DDCs, then shut down one of the old DDCs, Give the same IP and hostname to one of the new DDCs, and then do the same thing with the other one. 


I Migrated the PVS Servers the same way and it worked fine. 



Link to comment
  • 0
On 8/13/2021 at 9:26 AM, Baumgartner AG said:

What I thougt about is to create two new DDCs, then shut down one of the old DDCs, Give the same IP and hostname to one of the new DDCs, and then do the same thing with the other one. 


It's not quite as simple as that as the DDCs' machine accounts are used to authenticate to SQLServer. You can remove one of the old DDCs from the site (using Studio on the other), then remove the machine account references in your SQLServer by looking at the Security nodes in SQL Server Management Studio (on the server instance and on the databases). After that you can give the same IP and hostname to a new DDC, run Studio and join the Site.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...