Citrix Web Interface shared configuration the right way

Configuring sites on multiple Citrix Web Interface servers can be cumbersome. It is a repetitive task that needs to be executed exactly the same on each Citrix Web Interface server. Missing one setting results in a inconsistent environment, and as we all know those situations suck to troubleshoot.

Shared Configuration

Fortunately Citrix came up with a solution: shared configurations. With shared configuration slave servers use the configuration of a master server, all the changes needs to applied once on the master servers and the slave servers inherit the same configuration.

Unfortunately this solution has one big pitfall: without a master server all slave servers stop working. With a shared configuration a single point of failure (SPOF) is created.

To be honest, shared configuration usually is not a good choice. The dependency on the master server requires you to create a high available master Web Interface server using NLB or load balancing with a Citrix NetScaler (for the share holding the configuration files). A classical example of a cure that is worse than the disease.

Microsoft Distributed File System Replication (DFSR)

With Windows Server 2003R3 Microsoft introduced the Distributed File System Replication (DFSR). Just like with Shared Configuration with Microsoft DFSR the configuration of one Citrix Web Interfaces server can “shared ”between multiple servers. The main difference is that the configuration files are replicated to the replication partners, there is no dependency on the master server because the files are stored on each server.

There are (generally) two replication topologies 1) full mesh and 2) hub and spoke.

With a full mesh topology the files are replicated with all replication partners (or nodes). As a result the administrator can connect to any Citrix Web Interface server, change the configuration and DFSR will replicate the configuration files to all replication partners (or nodes).

With a hub and spoke topology the replication takes only place between the hub (or master) and the spokes (or slaves), there is no replication between the spokes. This limits the number of replications and therefore complexity and bandwidth. The DFSR hub and spoke topology has the most similarity with the Shared Configuration of the Citrix Web Interface, except for the dependency on the master server.

If a Citrix Web Interface server that has the Hub role fails the other servers, with the spoke role, continue to work as before. Because all files are stored on each server (and the Citrix Web Interface server is unaware of the replication) nothing has changed, the service is uninterrupted

If an administrator connects to one of the spoke servers to change the configuration this is only applied to that one server, they are not replicated to the other spoke servers. Once the hub server returns the changes are propagated to the hub server, followed by a replication to the other spoke servers.

Conclusion

Applying changes to multiple Citrix Web Interface servers while keeping a consistent configuration is key for any environment. The shared configuration implementation in the Citrix Web Interface enables a consistent configuration but creates a single point of failure (SPOF) on the master server. With Microsoft DFSR a consistent configuration between multiple Citrix Web Interface servers can be achieved without a dependency on a master server. With DFSR present since Server 2003R2 it is available in (almost) all servers and “free” to use.

Active Directory

Microsoft DFSR is Active Directory integrated, there is no standalone implementation. This means that the Citrix Web Interface servers needs to be domain joined, which is not the case in every environment.

Creating a replication group requires Domain Admin permissions. In certain environments this permission is not granted to simple Citrix professionals (…), fortunately the permissions to create a DFSR replication group can be delegated.

New sites

When a new site is created on one of the nodes opening the pages on another node results in an HTTP error 500 (Internal server error)

Although the configuration of the Citrix WebInterface sites are stored in %systemroot%\inetpub\wwwroot\Citrix\  the meta data of the site and the application pool assignment stored in %windir%\system32\inetsrv\config\applicationHost.config. Unfortunately Microsoft DFSR does not allow you to replicate this folder as it overlaps a Windows system folder (Source: DFSR Event ID: 6410).

So overcome this limitation a second replication is executed on each node. The secondary replication replicates the applicationHost.config file from the Windows system folder to the folder that’s already replicated by DFSR.

The replication is done with a PowerShell script ( SyncFolderScript.ps1 ) that’s executed every 5 minutes with a regular Windows scheduled task. The scheduled task is configured with the following parameters:

• Run whether user is logged on or not
• Run with highest privileges
• One trigger
  • Begin the task at startup
  • Repeat task every 5 minutes for a duration of indefinitely
• Action: Start a program

Command

%Windir%\system32\WindowsPowerShell\v1.0\powershell.exe

Argument

-File "C:\inetpub\wwwroot\Citrix\InetSrvConfig\SyncFolderScript.ps1" -Source "%Windir%\System32\inetsrv\config" -Destination "C:\inetpub\wwwroot\Citrix\InetSrvConfig" -Filter "applicationHost.config"

The file in %systemroot%\inetpub\wwwroot\inetsrv\ is picked up by Microsoft DFSR and replicated to the other nodes where its picked up by the PowerShell script.

.