Removing Problematic Delivery Controller – Method 1

This article will show you how to remove a delivery controller from your environment that is no longer required or functioning. Attempts to re add the controller fail with the same machine name. You do not have access to SQL but you can hand over eviction scripts to your DBA to clean up your Xenapp database.

This procedure worked in my Xenapp 7.x environment with a working Delivery Controller left in my Site.


Example 1

Obtain Controller SID

Launch Powershell as an administrator on your remaining Delivery Controller.

Run Get-BrokerController

Take note of the SID of the Delivery Controller that is no longer functioning.You will need this SID. The state may still show as Active if connections are still active.
Null Connections

Now run the following to null connections to the controller you wish to remove from your Xenapp database. This is carried out on a working Delivery Controller.

Set-ConfigDBConnection -DBConnection $null -AdminAddress DDC02.TSCLAB.COM

Set-BrokerDBConnection -DBConnection $null -AdminAddress DDC02.TSCLAB.COM

Set-ProvDBConnection -DBConnection $null -AdminAddress DDC02.TSCLAB.COM

Set-AcctDBConnection -DBConnection $null -AdminAddress DDC02.TSCLAB.COM

Set-HypDBConnection -DBConnection $null -AdminAddress DDC02.TSCLAB.COM

Set-EnvTestDBConnection -DBConnection $null -AdminAddress DDC02.TSCLAB.COM

Set-MonitorDBConnection -DBConnection $null -AdminAddress DDC02.TSCLAB.COM

Set-SfDBConnection -DBConnection $null -AdminAddress DDC02.TSCLAB.COM

Set-LogDBConnection -DBConnection $null -AdminAddress DDC02.TSCLAB.COM

Set-AdminDBConnection -DBConnection $null -AdminAddress DDC02.TSCLAB.COM

Set-AnalyticsDBConnection -DBConnection $null -AdminAddress DDC02.TSCLAB.COM (XD 7.6 ONLY)
Get-BrokerController will now show the state of the second DDC as Off.

Run Eviction Scripts

Next we need to run the following powershell script using the SID identified on the controller that you are going to remove These commands will generate eviction scripts.

Take care to point the site, monitoring and logging parts to your correct database.

Get-BrokerDBSchema -DatabaseName CITXENSITE -ScriptType evict -sid S-1-5-21-40836310-432886117-331853842-1171 > c:\brokerevict.sql
 Get-ConfigDBSchema -DatabaseName CITXENSITE -ScriptType evict -sid S-1-5-21-40836310-432886117-331853842-1171 > c:\configevict.sql
 Get-HypDBSchema -DatabaseName CITXENSITE -ScriptType evict -sid S-1-5-21-40836310-432886117-331853842-1171 > c:\hostevict.sql
 Get-ProvDBSchema -DatabaseName CITXENSITE -ScriptType evict -sid S-1-5-21-40836310-432886117-331853842-1171 > c:\provevict.sql
 Get-AcctDBSchema -DatabaseName CITXENSITE -ScriptType evict -sid S-1-5-21-40836310-432886117-331853842-1171 > c:\adevict.sql
 Get-EnvtestDBSchema -DatabaseName CITXENSITE -ScriptType evict -sid S-1-5-21-40836310-432886117-331853842-1171 > c:\envtestevict.sql
 Get-LogDBSchema -DatabaseName CITXENLOGDB -ScriptType evict -sid S-1-5-21-40836310-432886117-331853842-1171 > c:\logevict.sql
 Get-MonitorDBSchema -DatabaseName CITXENMONDB -ScriptType evict -sid S-1-5-21-40836310-432886117-331853842-1171 > c:\monitorevict.sql
 Get-sfDBSchema -DatabaseName CITXENSITE -ScriptType evict -sid S-1-5-21-40836310-432886117-331853842-1171 > c:\Sfevict.sql
 Get-AdminDBSchema -DatabaseName CITXENSITE -ScriptType evict -sid S-1-5-21-40836310-432886117-331853842-1171 > c:\adminevict.sql
 Get-AnalyticsDBSchema -DatabaseName CITXENSITE -ScriptType evict -sid S-1-5-21-40836310-432886117-331853842-1171 > c:\analyticsevict.sql (XD 7.6 ONLY)

Execute Scripts on SQL
The above script will generate eviction scripts to run on SQL.
Scripts appear locally on your delivery controller C drive.

Copy these over to your SQL server acting as Principal.

Execute the eviction scripts on the sql server in SQLCMD mode

Open Sql Studio and click OPEN/FILE and choose your .sql script.

Your script will be imported into SQL.

Run your query in SQL CMD MODE.

Then click !Execute
You should get a result similar to the below.

Repeat this procedure for all your eviction scripts that you created.
Run Get-BrokerController. You should only see your remaining Delivery Controllers in your environment.

Clean up Registered Service Instances

Once this is done you need to clean up the registered service instances. You can see the controllers assigned to the services by running the below command.


You will see that the faulty delivery controller is still registered to services.

Run the following in your powershell window.

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

This will generate a text file on c:\registeredinstances.txt.

Inside this file you will see something similar to the below:
In this example we can see DDC01 and DDC02 are registered.

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

Copy your amended text and create a .ps1 file on your local C drive of the Delivery Controller.

Run the file within your administrative powershell cmd window.

Once complete check the registered service instances once again.

You should not see any registered service instances on the delivery controller you have removed.

You should now be able to add your Delivery Controller back in to the environment.


Xenapp 7.x SQL Express Single DB to SQL Mirror Multi DB Migration – Part 2

As you can see below we are using SQL express. That just cannot do for production!

To check what database is being used for your Site, Logging and Monitoring check in PowerShell.

Run asnp Citrix* in administrative PowerShell.

Run the following highlighted commands:




Backup your SQL DB
Now we need to install SQL Management Studio on to the Delivery Controller to manage and backup the Xenapp Database.

Once SQL Management Studio is downloaded launch the executable and run through the wizard.


The screen shot below is highlighting the incorrect choice. You should choose the “Perform a new installation of SQL Server 2012”.

If you continue as above, you will eventually come across this error.

So lets resume choosing the correct option and wiz through this bit.

Choose Management Tools – Basic (That is all you need).

Now launch the installed SQL Studio Management.


Now you can see your Xenapp 7.x database.

Right click your DB/Tasks/Backup.

Choose backup type FULL.

Choose location for .bak backup media set.

Click OK.

Copy the backup file to a local drive on your SQL primary.
Create Delivery Controller machine account Login within SQL Management Studio
Within SQL Management Studio on the Primary SQL server, highlight New Query and type the following to create your Delivery Controller Login:

Create login [DOMAIN\DDCNAME] from windows

Highlight text and click !Execute.

A message will appear stating the command completed.

You may need to refresh SQL Studio to see the Delivery Controller machine account.

Restore your Xenapp Single Site DB to the new SQL server
Now we are ready to restore the backed up database from the local SQL drive.

Right click Database/Restore Database

Choose Device and the radio buttons and click Add and browse to your .bak (sql backup) file.

Click OK.

Check permissions on the DB
Next, we will check the permissions on the Delivery Controller machine account.

Right click Delivery Controller account  within Security/Logins and go to Properties.

Make sure the machine account is mapped to the Xenapp database.

The database role membership for the Xenapp site should match the below screen shots.

There are also updates in article CTX140319 for the role memberships.

ADIdentitySchema_ROLE = 7.0 Onwards

Analytics_ROLE = 7.8 Onwards

AppLibrarySchema_ROLE = 7.8 Onwards

chr_Broker = 7.0 Onwards

chr_Controller = 7.0 Onwards

ConfigLoggingSchema_ROLE = 7.0 Onwards

ConfigLoggingSiteSchema_ROLE = 7.0 Onwards

ConfigurationSchema_ROLE = 7.0 Onwards

DAS_ROLE = 7.0 Onwards

DesktopUpdateManagerSchema_ROLE = 7.0 Onwards

EnvTestServiceSchema_ROLE = 7.0 Onwards

HostingUnitServiceSchema_ROLE = 7.0 Onwards

Monitor_ROLE = 7.0 Onwards

MonitorData_ROLE = 7.0 Onwards

OrchestrationSchema_ROLE = 7.11 Onwards

StorefrontSchema_ROLE = 7.8 Onwards

TrustSchema_ROLE = 7.11 Onwards

Test, Null and Set Connections on Delivery Controller

Now we get to the part where we TEST, NULL and SET connections on the Delivery Controller.
In terms of what connections to TEST, NULL and SET depending on your Xenapp version there is this table of reference.


AnalyticsServiceStatus     # 7.6 and newer

AppLibServiceStatus        # 7.8 and newer






OrchServiceStatus           #  7.11 and newer

TrustServiceStatus          #  7.11 and newer


Amend the scripts accordingly or include all of the above but you may get error responses within your .ps1.
The following .ps1 scripts were used for a Xenapp 7.6 environment.




Remember to amend ServerName and SiteDBName to your environment in the scripts!
Test Connections from your Delivery CONTROLLER
We need to test connections to the migrated SQL DB using a .ps1 script.
This is done within PowerShell from the Delivery Controller. Create a TESTCONNECTION.ps1 script using the below information.


$SiteDBName=”YourXenapp Site”
Open PowerShell and type Asnp Citrix*

Navigate to test connection script in PowerShell and run .ps1.

All looks good below!
Null SQL connections from your delivery Controller
Once confirmed we need to null connections on the Delivery controllers using a .ps1 script.

Create a NULLCONNECTION.ps1 script using the below.

Navigate to your .ps1 script within PowerShell to null DB connections from your delivery controller.

All looks good once more.

Set the connections on your delivery Controller to the new SQL Server
Now we need to set connections so they point at the new SQL server.

Create a SETCONNECTION.ps1 script using the information below.

We get prompts all the connections have been SET. The DBUnconfigured is shown as some of the commands in the .ps1 script are going to NULL connections and then SET them.

Still looking good!

Restart the Citrix Broker Service within services.msc on the delivery controller.

Open up Studio.

Run the following commands to confirm.



BOOM!! Successful SQL Express to SQL 2012R2 Migration.

Now let’s crack on with SQL HA and creating separate databases (Site,Logging and Monitoring) in PART 3 of this series.



Xenapp 7.x SQL Express Single DB to SQL Mirror Multi DB Migration – Part 1

So, for one reason or other you are using SQL express and wish to introduce some best practice in to your production ready Xenapp environment.
Your goals are:

Xenapp should use full blown SQL.

Xenapp should have 3 Databases not one for Site, Monitoring and Logging.

Xenapp should have resiliency at the DB level.
Remember folks the most important 3 rules before any actions are carried out.



Go out in the evening without any worries.

  • Part 1 will provide the overview.
  • Part 2 will provide detailed steps for STAGE 1.
  • Part 3 will provide detailed steps for STAGE 2.
Backup your SQL DB.

Create Delivery Controller machine account Login within SQL Management Studio.

Restore your Xenapp Single Site DB to the new SQL server.

Check permissions on the DB

Test, Null and Set Connections

Test permissions from your Delivery Controller.

Null SQL connections from your delivery Controller

Set the connections on your delivery Controller to the new SQL server.
Create 3 Xenapp Databases

Change Recovery Model of all 3 DB's

Make a full backup of all 3 DB's

Make a transaction log of all 3 DB's

Create the Controller Logins on the SQL server acting as mirror

Failover and test permissions

Test, null and set connections on your delivery controllers

Test connections

Null Connections

Set Connections

Confirm and test connections to both SQL servers

Final word

In the next article we will go in to more detail for the initial stage.