Knowing how to completely remove controllers from a site using PoSH is something that can come in pretty handy at times.  Whether your’e looking to remove a failed or orphaned controller and receive an exception through Studio while doing so or whether you just like doing things the manual way the end result should be the same i.e. a better understanding of XenDesktop architecture….

Before I continue, I have to point out that there is a tool called XenDesktop Site Checker which can be used to automate a good chunk of what I’m about to cover but in many respects that’s taking the easy way out especially for those looking to get a better understanding of  XD architecture and how things fit together. XD Site Checker is also only supported with XD5.x.

So moving on, to successfully remove a Controller from a site we essentially need to remove any trace of the aforementioned controllers service instances (Broker, Config, Host, MCS etc…) from the site DB so that when we run the Get-ConfigRegisteredSericeInstance cmdlet to query all service instances registered in the site we only see references to service instances running on the remaining active Controllers.

Here is an example of what you might see when using PoSH to check for all registered service instances of the Broker service running in a site:

Click on screenshot to view full image:

In the screenshot above we can see that a number of Broker Service instances running on two seperate controllers (DC1 & DC2) are currently registered with the configuration service for an XD site.  At this point you might be asking yourself the following question:

“I thought there was only one Broker service instance running on each Controller?”

Well, that is indeed the case but what you are seeing above is reference to all the interfaces that the service instances support. We’ll talk about interfaces again but for now just think of them as different entry points to engage with the service instance. For example, all services have an SDK interface defined which allows admins interact with the services through Studio and PoSH.

Note: You can view the available interface types through PoSH for the Broker service using the following cmdlet:

Get-BrokerServiceInstance

Now that we know the end goal, let’s work through a basic scenario…

ENV:

Site Name: Training

DataBase Name: CitrixTraining

Controllers: DC1.training.lab, DC2.training.lab

ACTION:

Manually remove active controller DC2.training.lab from the site using PoSH

SOLUTION:

Step 1:

From a PoSH window on dc1.training.lab or from a mgmt workstation, disconnect dc2.training.lab from the Site DB using the following simple script:

XD7.x

Set-ConfigDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-BrokerDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-ProvDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-AcctDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-HypDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-EnvTestDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-MonitorDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-SfDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-LogDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-AdminDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-AnalyticsDBConnection -DBConnection $null -AdminAddress dc2.training.lab (XD 7.6 ONLY)

XD5.x

Set-ConfigDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-BrokerDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-HypDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-ProvDBConnection -DBConnection $null -AdminAddress dc2.training.lab
Set-PvsvmDBCconnection -DBConnection $null -AdminAddress dc2.training.lab
Set-AcctDBConnection -DBConnection $null -AdminAddress dc2.training.lab


Step 2:

Now that dc2.training.lab is disconnected from the site DB the controller is consided to be in an OFF state.

Run Get-BrokerController -AdminAddress dc1.training.lab from the same PoSH window to view the current state and take note of the SID (highlighted in green) value in the screenshot below as this will be required in step 3:

Click on screenshot to view full image:

Note: Although dc2.training.lab is turned off and not actively taking part in site operations at this point, it is still very much part of the site and if returned to an active state, would resume its responsibilities as a working Controller.

Step 3:

Using the SID value obtained in Step 2, generate an eviction script for each of the service instances running on dc2.training.lab.  To do this, run the following simple script on dc1.training.lab:

XD7.x

Get-BrokerDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\brokerevict.sql
Get-ConfigDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\configevict.sql
Get-HypDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\hostevict.sql
Get-ProvDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\provevict.sql
Get-AcctDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\adevict.sql
Get-EnvtestDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\envtestevict.sql
Get-LogDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\logevict.sql
Get-MonitorDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\monitorevict.sql
Get-sfDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\Sfevict.sql
Get-AdminDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\adminevict.sql
Get-AnalyticsDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\analyticsevict.sql (XD 7.6 ONLY)

XD5.x

Get-BrokerDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\brokerevict.sql
Get-ConfigDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\configevict.sql
Get-HypDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\hostevict.sql
Get-ProvDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\provevict.sql
Get-PvsvmDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\pvsvmevict.sql
Get-AcctDBSchema -DatabaseName CitrixTraining -ScriptType evict -sid S-1-5-21-872651969-1959181362-2982015048-1126 > c:\adevict.sql

Step 4:

Execute the eviction scripts generated in step 3 above in SQLCMD mode against the site DB (CitrixTraining). This will achieve the following:

1. All service instances running on dc2.training.lab will be removed from the site

2. Database user [TRAINING\DC2$] for controller dc2.training.lab will be deleted

Step 5:

Run Get-BrokerController -AdminAddress dc1.training.lab again and verify that dc2.training.lab is no longer listed as a site Controller:

Click on screenshot to view full image:

Step 6:

As a final action, we need to clean-up the Site Configuration Service register by removing all the service instances from dc2.training.lab.

To return and sort the contents of the ServiceAccount and ServiceInstanceUid tables use the following string and pipe the results to a text file:

Get-ConfigRegisteredServiceInstance | select serviceaccount, serviceinstanceuid | sort-object -property serviceaccount > c:\registeredinstances.txt

Once you have the output, you can use an advanced text editor like Notepad++ to select the ServiceInstanceUid’s for the service instances on dc2.training.lab and use the data to build and run a simple unregister script:

Unregister-ConfigRegisteredServiceInstance -serviceinstanceuid eb73450b-732f-461d-bf34-fcf761208fa6
Unregister-ConfigRegisteredServiceInstance -serviceinstanceuid 19d6252a-db74-4b34-adfd-bd9025094ab4
Unregister-ConfigRegisteredServiceInstance -serviceinstanceuid afef3dc6-13ba-496e-a26a-ff3d8efa305c
Unregister-ConfigRegisteredServiceInstance -serviceinstanceuid 4a21561d-e2d9-4cd3-9b9d-fd1207db7e02
Unregister-ConfigRegisteredServiceInstance -serviceinstanceuid 79b9edcb-3aa5-4a9c-a75b-c38f7403f7ee
Unregister-ConfigRegisteredServiceInstance -serviceinstanceuid a5ee5a66-6f7b-4f8b-a9c8-d45e00c13dfd
Unregister-ConfigRegisteredServiceInstance -serviceinstanceuid ………………………………
Unregister-ConfigRegisteredServiceInstance -serviceinstanceuid ………………………………

Once the script completes, run Get-ConfigRegisteredServiceInstance | select serviceaccount, serviceinstanceuid | sort-object -property serviceaccount and you should notice that all service instances for dc2.training.lab have been removed from the Site Configuration Service register.

And that’s pretty much it. Six straighforward steps to gracefully remove a Controller and clean-up the Site DB using PoSH.

Although we have a simple UI option to do this in Desktop/Citrix Studio I think it is important to know how to do this through PoSH for the rare ocasion when this UI option fails.

Best Regards
Mick Glover (aka XD Tipster)
Senior Readiness Specialist,
Worldwide Support Readiness [EMEA]
Citrix Systems, Inc