Citrix introduced a new feature in Citrix Presentation Server 4.5 called Configuration Logging. Configuration Logging keeps track of every change to every object in your Citrix Presentation Server Farm. This information is kept in a back end database and you have the ability to run reports on these changes via the Report Center in the Access Management Console. For more details on setting up Configuration Logging and running reports, check out this article by Al Solorzano.
I think this is a really cool feature that lets you know who did what and when they did it. But, in order to get this information, you have to run a report from the Report Center in the AMC. Granted, you can automate reports, but it would be nice if there was some mechanism to alert you when a change was made. This is where Project S-Bend Phase I comes in to play. Project S-Bend was originally created as an exercise for my session titled “Digging into Citrix Presentation Server 4.5 Configuration Logging” at BriForum Europe 2007.
Project S-Bend Phase I consists of 3 main parts; an “Alerts” table added to the Configuration Logging database, a SQL trigger, and a Windows Service. Project S-Bend uses these parts to send email alerts whenever a change is written to the Configuration Logging back end database.
Alerts Table This is a very simple table that is populated by the SQL trigger.
SQL Trigger The SQL trigger is added to you Citrix Configuration Logging database and fires any time a change is written to the database. The trigger writes the ID of the change to the Alerts table.
Windows Service The Windows Service reads the Alerts table populated by the SQL trigger. For each row in the table, the Windows Service sends an email to the specified email address with details concerning the object changed.
How it all works The process is actually quite simple.
- When a change is made in your Citrix Presentation Server 4.5 farm, a log entry is created in the Configuration Logging database.
- When the log entry is created, the SQL Trigger fires and writes an entry to the Alerts table.
- The Windows Services reads the Alerts table on a configurable timed interval. When the Windows Service encounters unprocessed alerts in the Alerts table, it sends and email with details of what was changed.
What about Phase II? I guess it is quite obvious that there is a Phase II in the works since I named this thing Phase I. Actually, Phase II is a provider. “A provider for what?” you may ask. Phase II is a provider for reports. Web Interface for Resource Manager will consume this provider as mentioned in the Web Interface for Resource Manager Roadmap.