Citrix Web Interface shared configuration the right way

Written by Ingmar Verheij on April 21st, 2013. Posted in Citrix

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.

Citrix Web Interface - Shared 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.

Citrix Web Interface - Shared configuration - Failure

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).

Microsoft DFSR - Full mesh topology

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.

Microsoft DFSR - hub and spoke topology

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 Duim omhoog

Microsoft DFSR - hub and spoke topology - Failure

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)

HTTP error 500 - Internal server error

The DFS Replication service failed to initialize replicated folder C:\Windows\system32\inetsrv\config because the service detected that one of its working folders overlaps a Windows system folder. This is an unsupported configuration.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.

Internet Information Server (IIS) applicationHost.config local synchronisaton

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

Argument

Synchronize IIS configuraton file - GeneralSynchronize IIS configuraton file - TriggersSynchronize IIS configuraton file - Actions


Edit Trigger2013-08-22 14_23_31-

 

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.

Internet Information Server (IIS) applicationHost.config full synchronisaton

 

 

.

Ingmar Verheij

At the time Ingmar wrote this article he worked for PepperByte as a Senior Consultant (up to May 2014). His work consisted of designing, migrating and troubleshooting Microsoft and Citrix infrastructures. He was working with technologies like Microsoft RDS, user environment management and (performance) monitoring. Ingmar is User Group leader of the Dutch Citrix User Group (DuCUG). RES Software named Ingmar RES Software Valued Professional in 2014.

More Posts - Website

Follow Me:
TwitterLinkedInGoogle Plus

Tags: , , ,

Comments (6)

  • 23 April 2013 at 15:14 |

    If you are going to use DFS-R, make sure you have all the Microsoft updates for DFS-R.

    http://support.microsoft.com/kb/968429
    http://support.microsoft.com/kb/958802

    • Ingmar Verheij
      23 April 2013 at 15:20 |

      Good to mention indeed
      Thanx Carl

  • 18 June 2013 at 11:58 |

    Hey Ingmar,

    In which case Domain Admin permission is not granted to create a replicate group?
    I am facing the same problem.

    • Ingmar Verheij
      19 June 2013 at 18:47 |

      You can’t create a replication group with Domain Admin privileges?

  • Brad Owen
    28 June 2013 at 21:45 |

    Exactly what folder\files are setup with DFSR?

    • Ingmar Verheij
      2 July 2013 at 08:50 |

      If you replicate the folder C:\inetpub\wwwroot\Citrix all sites wil be replicated.

Leave a comment

*

Donate

%d bloggers like this: