Study guide
Technical reference and lesson notes
Overview
This post documents the process I followed while rebuilding a Citrix Virtual Apps and Desktops on-prem lab environment. The lab had previously been configured with both MCS and PVS, but I rebuilt the Delivery Controller as a new server named CVAD02. During the rebuild, I ran into several issues related to SQL Express, Citrix Site database creation, stale database connection strings, Delegated Administration Service errors, and partial database creation.
The main goal was to get the CVAD Site back online cleanly so I could later reconnect or recreate my PVS and MCS machine catalogs and delivery groups.
This was for a non-production practice lab only.
Licensing Note
The built-in on-prem Citrix evaluation period is limited, so the proper path for a longer-term lab is to work with Citrix, a reseller, distributor, or Citrix partner program to request a legitimate evaluation, demo, lab, or NFR entitlement.
For a lab, rebuilding is useful for learning the install process, but it should not be treated as a licensing workaround. I wanted to keep the environment clean and legitimate.
Lab Design Decision: CVAD01 vs CVAD02
The old server was named CVAD01. For the rebuild, I decided to create a new Delivery Controller named:
CVAD02
Using CVAD02 was cleaner than reusing the old hostname because it avoided potential issues with stale DNS, old AD computer objects, old certificates, cached service references, and confusion between the old and new lab builds.
Reusing the same hostname could have made existing VDAs easier to reconnect, but for a dev lab, creating a clean CVAD02 was the better option.
SQL Express Service Check
After installing SQL Express locally on CVAD02, I verified the SQL services with PowerShell:
Get-Service *SQL* | Select-Object Name, Status, DisplayName
The important service was:
MSSQL$SQLEXPRESS
That service needed to be running.
The SQL Server Agent service was stopped, but that was not a blocker. SQL Server Agent is not required for basic CVAD Site database creation in a SQL Express lab.
The important takeaway:
SQL Server (SQLEXPRESS) / MSSQL$SQLEXPRESS must be running.
SQL Server Agent (SQLEXPRESS) does not need to be running for this lab.
Initial Mistake: SQL Instance Name
The major issue was that I was trying to connect using:
localhost
That does not work for a named SQL Express instance unless SQL Express was installed as the default SQL instance.
The correct values were:
.\SQLEXPRESS
or:
localhost\SQLEXPRESS
or:
CVAD02\SQLEXPRESS
In SQL Server Management Studio, the working value was:
.\SQLEXPRESS
This was a key fix.
Installing SQL Server Management Studio
At first, I only had PowerShell and did not have SQL Server Management Studio installed. PowerShell was useful, but once the Citrix Site database creation partially failed, SSMS became the easiest way to see what was actually happening.
Installing SSMS allowed me to:
Connect to .\SQLEXPRESS
View partially created Citrix databases
Delete failed/partial databases
Confirm SQL permissions
Validate that SQL Express was actually working
For troubleshooting this type of issue, SSMS was worth installing.
Citrix Database Names
When recreating the Site, I used simple database names with no spaces:
CitrixCVAD02Site
CitrixCVAD02Logging
CitrixCVAD02Monitoring
I avoided names like:
Citrix CVAD02 Site
Citrix CVAD02 Logging
Citrix CVAD02 Monitoring
Keeping the names simple avoids unnecessary problems, especially with the Monitoring database.
Error: Failed to Validate Central Configuration Service
The Citrix Site creation initially failed with an error similar to:
Failed to validate Central Configuration Service.
Valid Delivery Controller services were not found at the specified location.
Reason: Database cannot be contacted.
Check the status of the database on the SQL Server.
The database may not be allowing remote connections.
Make sure the database server is set up correctly and that the firewall is not blocking the connection.
At first, this looked like a firewall issue. In a lab, temporarily disabling the firewall can be a valid isolation test, but in this case SQL Express was local to CVAD02. The real issue was not the Windows Firewall. The real issue was a combination of:
Wrong SQL instance name
Partial Citrix database creation
Stale Citrix database connection strings
Citrix services pointing to databases that no longer existed
CTX462378 and TLS Settings
The error matched Citrix article CTX462378, which discusses Studio failing to open or validate the Delivery Controller because the database cannot be contacted.
In this lab, I also reviewed TLS settings because the article referenced TLS-related causes. For a lab, TLS changes can be used as a troubleshooting step, but I would treat enabling older TLS versions as temporary and lab-only.
The registry paths involved are under:
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
The general lab test was to ensure TLS protocols were enabled for both Client and Server, and also to make sure .NET used the system TLS defaults.
PowerShell used for Schannel TLS settings:
$protocols = @("TLS 1.0", "TLS 1.1", "TLS 1.2")
$roles = @("Client", "Server")foreach ($protocol in $protocols) {
foreach ($role in $roles) {
$path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\$protocol\$role" New-Item -Path $path -Force | Out-Null
New-ItemProperty -Path $path -Name "Enabled" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $path -Name "DisabledByDefault" -Value 0 -PropertyType DWord -Force | Out-Null
}
}
PowerShell used for .NET TLS defaults:
$netPaths = @(
"HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319",
"HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319"
)foreach ($path in $netPaths) {
New-Item -Path $path -Force | Out-Null
New-ItemProperty -Path $path -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $path -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWord -Force | Out-Null
}
After TLS changes, I rebooted the server.
Important note: TLS 1.0 and TLS 1.1 should not be left enabled unnecessarily outside of a controlled lab/troubleshooting scenario.
Citrix PowerShell Errors
After the failed Site creation, Citrix PowerShell showed several symptoms.
Running:
Add-PSSnapin Citrix*
Get-BrokerSite
returned an insufficient privileges-style error.
Running:
Get-AdminAdministrator -AdminAddress CVAD02
reported a problem communicating with the Citrix Delegated Administration Service, even though the Windows service showed as running.
This was misleading at first.
The key lesson was:
A Citrix service can show as Running in Windows but still be unhealthy because it cannot contact or use the Site database.
Checking Citrix Database Connection Strings
I checked Citrix DB connection strings with:
Add-PSSnapin Citrix*Get-ConfigDBConnection
Get-AdminDBConnection
Get-BrokerDBConnection
The result was important:
Get-ConfigDBConnection returned a connection string.
Get-AdminDBConnection was blank.
Get-BrokerDBConnection was blank.
That told me the Site was only partially configured.
The Configuration Service had a database connection string, but the Broker and Delegated Administration services did not.
Testing the Broker DB connection also returned something like:
DBNotFound
That meant the service was pointing at a database that did not exist or was not usable.
At that point, the Site database creation was clearly broken/partial.
Decision: Stop Fighting the Partial Site
Because this was a dev lab, the better move was to stop trying to manually repair the partially created Site and instead clean up the failed databases and stale Citrix connection strings.
The bad state looked like this:
Partial Citrix databases existed in SQL.
Some Citrix services had connection strings.
Other Citrix services had blank connection strings.
The Broker service could not find a usable DB.
The Delegated Admin service could not communicate properly.
Studio could not validate the controller/database state.
For a lab, that is not worth fighting.
Deleting the Partial Citrix Databases
After installing SSMS and connecting to:
.\SQLEXPRESS
I deleted the partial Citrix databases.
Before deleting them, I stopped the Citrix services:
Get-Service Citrix* | Stop-Service -Force
Then in SSMS, I removed the failed Citrix databases.
If the database was in use, this SQL pattern could be used from a new query window:
USE master;
GOIF DB_ID('CitrixCVAD02Site') IS NOT NULL
BEGIN
ALTER DATABASE [CitrixCVAD02Site] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [CitrixCVAD02Site];
END
GOIF DB_ID('CitrixCVAD02Logging') IS NOT NULL
BEGIN
ALTER DATABASE [CitrixCVAD02Logging] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [CitrixCVAD02Logging];
END
GOIF DB_ID('CitrixCVAD02Monitoring') IS NOT NULL
BEGIN
ALTER DATABASE [CitrixCVAD02Monitoring] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [CitrixCVAD02Monitoring];
END
GO
I made sure not to touch the system databases:
master
model
msdb
tempdb
Clearing Stale Citrix Database Connection Strings
This was the step that made the difference.
After deleting the partial Citrix databases, Citrix still had stale DB connection strings. If those are not cleared, Studio may continue trying to talk to a database that no longer exists.
From elevated PowerShell on CVAD02:
Add-PSSnapin Citrix*Set-ConfigDBConnection -DBConnection $null -Force
Set-BrokerDBConnection -DBConnection $null -Force
Set-AdminDBConnection -DBConnection $null -Force
Then I verified:
Get-ConfigDBConnection
Get-BrokerDBConnection
Get-AdminDBConnection
Once the stale connection strings were cleared, I was able to open Studio and recreate the Site successfully.
This was the main fix.
Recreating the Citrix Site
After cleanup, I reopened Citrix Studio / Site Manager as Administrator and recreated the Site.
For SQL, I used:
.\SQLEXPRESS
For the databases, I used:
CitrixCVAD02Site
CitrixCVAD02Logging
CitrixCVAD02Monitoring
I allowed Studio to create and configure the databases automatically.
This time, the Site came up successfully.
Key Lessons Learned
The biggest lessons from this rebuild were:
SQL Express is usually a named instance.
Use .\SQLEXPRESS, localhost\SQLEXPRESS, or CVAD02\SQLEXPRESS.
Do not use plain localhost unless SQL was installed as the default instance.
SQL Server Agent being stopped is not a blocker for a SQL Express CVAD lab.
MSSQL$SQLEXPRESS is the important service.
If Citrix Site creation partially fails, do not keep forcing it.
Delete the partial Citrix databases and clear stale Citrix DB connection strings.
Citrix services can show as Running but still be broken if the Site database connection is bad.
Get-ConfigDBConnection working does not mean the entire Site is healthy.
Check Get-BrokerDBConnection and Get-AdminDBConnection too.
If Get-BrokerDBConnection and Get-AdminDBConnection are blank, the Site is probably only partially configured.
Next Phase: Reconfiguring PVS and MCS
After the CVAD Site was repaired, the next goal was to reconnect the previous lab work for PVS and MCS.
The correct order is not to start with Delivery Groups. The correct order is:
Golden image / vDisk / snapshot
Machine Catalog
Delivery Group
User assignment
Launch test
The Delivery Group is the user-facing layer, but the machines need to exist in a Machine Catalog first.
PVS First
For PVS, I need to determine whether I still have existing PVS target VMs or whether I need to create new ones.
There are two likely scenarios.
Scenario A:
The PVS target VMs already exist.
The PVS vDisk exists.
The target devices can boot.
The devices are in a PVS Device Collection.
In this case, I can use the PVS Console to export or add the devices into a CVAD machine catalog.
Scenario B:
The PVS vDisk/golden image exists.
The target VMs need to be recreated.
In this case, I would use the Citrix Virtual Desktops Setup Wizard from the PVS Console to create the target VMs, assign the vDisk, create the AD computer accounts, and add the machines to a CVAD catalog.
The PVS side should be handled from the Citrix Provisioning Console, not just from Studio.
PVS Checklist
Before creating or reconnecting the PVS catalog, I need to confirm:
PVS server is online.
Citrix PVS SOAP Server service is running.
The PVS farm, site, store, and vDisk are healthy.
The vDisk is available and assigned correctly.
The target devices exist or can be recreated.
The target devices can boot from the vDisk.
The VDA is installed in the image.
The VDA points to CVAD02 or can discover CVAD02.
A CVAD hosting connection exists if power management is needed.
For a clean lab, I plan to create:
Machine Catalog: Lab-PVS-Catalog
Delivery Group: Lab-PVS-Desktop
MCS Later
After PVS is working, I can configure MCS.
For MCS, the general flow will be:
Create or verify hosting connection to VMware/hypervisor.
Select the golden image snapshot.
Create an MCS machine catalog.
Create a delivery group.
Assign test users.
Launch the desktop.
For a clean lab, I plan to create:
Machine Catalog: Lab-MCS-Catalog
Delivery Group: Lab-MCS-Desktop
Keeping PVS and MCS separate will make troubleshooting much easier.
Final Working Summary
The rebuild succeeded after the following sequence:
Installed SQL Express locally on CVAD02.
Confirmed MSSQL$SQLEXPRESS was running.
Installed SQL Server Management Studio.
Connected to SQL using .\SQLEXPRESS.
Deleted the partially created Citrix databases.
Stopped Citrix services while cleaning up the databases.
Cleared stale Citrix DB connection strings using Citrix PowerShell.
Reopened Studio as Administrator.
Recreated the CVAD Site using .\SQLEXPRESS.
Used clean database names with no spaces.
Allowed Studio to create the databases automatically.
The most important fix was clearing the stale Citrix database connection strings after deleting the failed databases.
Without that step, Citrix Studio and the Citrix services continued trying to reference the broken or deleted database state.
Final note to self:
If this happens again, do not spend hours trying to repair a half-built lab Site.Install SSMS, delete the partial Citrix DBs, clear the Citrix DB connection strings, and rerun Sit