Digging in to Citrix Configuration Logging: Setting up the Database

This is the second part in a series on Citrix XenApp Configuration Logging. When Citrix XenApp Configuration Logging is enabled, all changes are written to a back end database. In this part, we will look at the details of how to create the database, logins, and users.

In part 1 of the Digging in to Citrix Configuration Logging series, we looked at what XenApp configuration logging was and how it worked.  Now, we are going to focus on how to set up the Citrix XenApp configuration logging database.

All Citrix XenApp farm changes are written to a back end database. The back end database can be:

  • Microsoft SQL 2000 and above (Microsoft SQL Express works too)
  • Oracle 9.2 or 10.2 

We will be using Microsoft SQL Server 2005 for this example.

Creating the Database

The first step in setting up the back end database for configuration logging is to create the database and user account(s).  This is pretty easy.  Just open up Microsoft SQL Server Management Studio, right-click Databases, and select New Database…  Give the database a name and accept the defaults.

New Database

Creating the Database Login(s)

The next step is to set up the database authentication.  In SQL Server Management Studio, expand Security, right-click Logins, and select New Login…

NewSQLLogin

Citrix XenApp Configuration Logging supports both SQL Server authentication and Windows authentication.

If using SQL Server authentication, you can make up any login name and password you want.  Keep in mind though that Citrix Configuration Logging does not support blank passwords.

If using Windows authentication, you can type a user name or group name in the form of domain\username or domain\group in the Login name field.  You can also select the “Search…” button to browse Active Directory for users or groups.

SQLSelectObject Tip: by default, only objects of type “User or Built-in security principal” are searched when using the “Search…” button.  You will need to add Groups to the search by clicking the “Object Types…” button.

In either case (using Windows or SQL Server authentication), be sure to change the Default database to the database created earlier.

Mapping the Login to a Database User

Even though you have created a database and a login, the two entities are not yet linked.  In other words, the login you created cannot log on to the database.  That is because a login is not equal to a database user.  The next step in the process is to map the created login to a database user and assign appropriate rights. 

In Microsoft SQL Server Management Studio, expand the Databases node, expand the database you created above, expand the Security node, right-click Users, and select New User…

newDBUser

newUser

Type a name in the Username field and type (or select) the login you created earlier in the Login name field.  The name you type in the User name field does not have to match the name in the Login name field, but I usually keep them the same for simplicity.

You will also have to tick the db_owner box under the Role Members section for now.  This is because the first time the Citrix XenApp farm tries to connect to the Configuration Logging database, the database schema will get created.  After the schema gets created, you can dial back the permissions.  I’ll explain the minimum permissions necessary in the next article.

Digging in to Citrix Configuration Logging – Part 1

This is the first part in a series on Citrix XenApp Configuration Logging. Citrix XenApp Configuration Logging helps keep track of changes made to your server farm. This feature can tell you what changes were made to your server farm, when they were made, and who made them. Part 1 in this series will further define where changes are logged and how the changes are logged.

I have presented on this topic in the past at BriForum and I wanted to share more about Citrix XenApp Configuration Logging here.  This will be a multi-part series that inspects each aspect of Citrix Configuration Logging and some creative ways of extending Citrix Configuration Logging.  So, let’s get started…

What is Citrix Configuration Logging?

According to the Citrix XenApp Administrator’s guide, “the Configuration Logging feature allows you to keep track of administrative changes made to your server farm environment. By generating the reports that this feature makes available, you can determine what changes were made to your server farm, when they were made, and which administrators made them. This is especially useful when multiple administrators are modifying the configuration of your server farm. It also facilitates the identification and, if necessary, reversion of administrative changes that may be causing problems for the server farm.” (emphasis added)

When I worked for Citrix, we had a load evaluator that had no available login times.  If a server was acting up, we could apply this “unavailable” load evaluator to it and figure out what was going on.  Oftentimes, we would discover that the “unavailable” load evaluator was applied to a new server and not know who did it or why they did it. So, we would have to resort to sending out an email asking why this server was assigned to the load evaluator.  Now, Citrix XenApp Configuration Logging tells you who did what and when.  That should be enough information to find out why.

Where are Changes Logged?

Changes that you make to the Citrix XenApp farm are logged to a database.  The back end database can be:

  • Microsoft SQL 2000 or Microsoft SQL 2005 (Microsoft SQL Express works too)
  • Oracle 9.2 or 10.2 

We will explore the details of the database schema in depth later on.

How are Changes Logged?

There are several ways to make changes to a Citrix XenApp Farm:

In order to facilitate logging changes made by any of these methods, Citrix introduced an IMA hook called CitrixLogServer.dll.  As you know, any change made to the data store has to go through IMA first. So, introducing an IMA hook makes sense.

Here are the facts about CitrixLogServer.dll:

  • Located in %ProgramFiles%\Citrix\System32
  • it is a Microsoft .Net assembly
  • it uses ADO.NET to write changes to the database.  Once a connection is made to the database, it will automatically disconnect after 5 minutes of inactivity.
  • Uses a XSD schema that is optimized for writes

 

Citrix XenApp Configuration Logging Architecture

When a change is submitted to IMA, the change is written via a transaction to the configuration logging database and data store.  It is possible to require all changes be written to the configuration logging database before they are allowed to be written to the data store.  This ensures all changes are logged.  Since the change is written via a transaction, a failure writing to the logging database or data store rolls back the transaction and no change is made or logged.

Citrix XenApp Configuration Logging Architecture

Bonus tip: if you clone servers in your Citrix XenApp farm and cannot join the cloned server to the farm, you may have to disable configuration logging.  Once the server joins the farm, you can re-enable configuration logging.