Digging in to Citrix Configuration Logging: Exploring the Database

This is the fifth part in a series on Citrix XenApp Configuration Logging. This part will focus on the database schema, the information contained in the database, and how to decode certain parts of the data.

This is the fifth part in the Citrix Configuration Logging Series. In part 1, we discussed what Citrix Configuration Logging was.  In part 2, we discussed how to prepare the database to log configuration changes. In part 3, we discussed how to set up the Citrix XenApp farm for Configuration Logging, in part 4, we looked at the “out of the box” reporting tools. In this part, we will look at the back end database schema.

Schema on the Surface

Here is what the database schema looks like on the surface.

ConfigLogSchema_thumb1

Just 3 tables – looks pretty easy…  But, if you look at some of the data in those tables, things become less obvious.  Let’s break each table down:

CtxLog_AdminTask_LogEntry – Every change to the XenApp farms creates a new row here.
LogEntry_RecordID Unique Identifier (primary key)
SiteId I honestly don’t know why this is here.  It seems like it might be some kind of farm identifier, but you can only have one farm per database.
LogEvent This holds events that happen on the log (database) as a whole.  This is a numeric value that corresponds to an enumeration.  Possible values are:

  • 0= None
  • 1= Created
  • 2= Cleared
DateTime Date/Time the change occurred.
LogonUserName The user that made the change.
LogonUserId The SID of the user that made the change.
LogonHostName Hostname of server that joins the farm.
LogonHostId SID of a server that joins the farm.
HostName IMA server used to make the change – remember that every change has to go through IMA.
HostId SID of the host HostName above.
Status Status of the change.  This is a numeric value that corresponds to an enumeration.  Possible values are:

  • 0 = Success
  • 1 = Neither success nor failure
  • 2 = Failure
CtxLog_AdminTask_Object – Object(s) changed.
Object_RecordID Unique Identifier (primary key)
SiteId Again – don’t know why this is here.
LogEntry_RecordID Foreign key to CtxLog_AdminTask_LogEntry table.
SequenceID Another one I’m not sure about.
AdminTaskType Enumeration – type of task performed:

  • 0 = None
  • 1 = Created
  • 2 = Modified
  • 3 = Removed
ObjectType Enumeration:

  • 0 = Application
  • 1 = Application Isolation Environment (AIE)
  • 2 = AIE Application
  • 4 = Farm
  • 5 = File Type Association
  • 6 = Folder
  • 7 = Installation Manager Application
  • 8 = Printer
  • 9 = Server
  • 10 = Server Group
  • 11 = User
  • 12 = Policy
  • 13 = Monitoring Profile
  • 14 = Load Manager
  • 15 = Virtual IP Farm Range
  • 16 = Virtual IP Server Range
  • 17 = Print Driver
  • 18 = Database
  • 19 = Zone
ObjectName Name of the object changed.
ObjectUid Internal object ID.  More specifically, this value comes from the object’s ID property in MFCOM.
PropertyList XML field.  Holds before and after values.
AdminTaskFormatResID ID of field in language specific resource file.
CtxLog_AdminTask_ReferenceList – Some objects reference other objects.  For instance, a published application can reference many server objects.  This table keeps track of changes to referenced objects.
ReferenceList_RecordID Unique Identifier (primary key)
SiteId
Object_RecordID Foreign key to CtxLog_AdminTask_Object table.
SequenceID
ObjectType Same as parent table.
ObjectNamesOriginal Tab delimited list of the names of the original referenced objects.
ObjectIdsOriginal Tab delimited list of internal object IDs of the original referenced objects.
ObjectNamesAdded Tab delimited list of the names of the added referenced objects.
ObjectIdsAdded Tab delimited list of internal object IDs of the added referenced objects.
ObjectNamesRemoved Tab delimited list of the names of the removed referenced objects.
FormatResId_Added Resource IDs of added objects.
FormatResId_Removed Resource IDs of removed objects.

 

Identifying Changes

As stated above, the PropertyList field in the CtxLog_AdminTask_Object table is a XML field.  This field maps out the before and after values of each property of an object after a change.  Here is an excerpt of what a PropertyList field looks like:

<?xml version="1.0"?>
<propertylist>
  . . .
  <property nameresid="290042">
    <valuelist original="0">
      <value>
        <valstr>Notepad - test</valstr>
      </value>
    </valuelist>
    <valuelist original="1">
      <value>
        <valstr>Notepad</valstr>
      </value>
    </valuelist>
    . . .

Notice that each property has a value where original=”0” or original=”1”.   If the two values are different, that is a change.  Original=”1” is the before value and original=”0” is the after value (that seems backwards to me).  So, from the excerpt above, we can see that “Notepad” was renamed to “Notepad – test”.

Resource IDs

Several of the fields have “ResID” somewhere in their name.  This is short for Resource ID.  The values in these fields are numeric and correspond to a language specific Resource File.  For instance, the nameresid in the excerpt above is 290042.  This maps to “Display Name” in the en-US resource file; however, 290042 maps to “Anzeigename” in the de-DE resource file.  The resource file(s) used to decode the numbers can be found on the computer running the AMC at:

%ProgramFiles%\Common Files\Citrix\Access Management Console – Report Center\Reports\ConfigurationLoggingReport

The English resources are located in ConfigurationLoggingReport.dll.  Other localized languages can be found in a subdirectory of the path given above.  For instance, the German language resources would be in:

<above path>\de\ConfigurationLoggingReport.resources.dll

This concludes our “behind the scenes” look at the database schema.  Now that we know exactly what information is stored in the database and how to decipher the data, we will look at how to do some custom reporting in the final post in this series.

Digging in to Citrix Configuration Logging: Reporting

This is the fourth part in a series on Citrix XenApp Configuration Logging. This part will foucus on out of the box reporting tool. In a later article, we will look at custom reporting.

This is the fourth part in the Citrix Configuration Logging Series. In part 1, we discussed what Citrix Configuration Logging was. In part 2, we discussed how to prepare the database to log configuration changes. In part 3, we discussed how to set up the Citrix XenApp farm for Configuration Logging. In this part, we will look at the out of the box reporting tools (in a later article, we will look at custom reporting).

Citrix Report Center

Report Center is part of the Citrix Access Management Console. Report Center allows you to create, schedule, and distribute various types of canned reports. One of the types of reports available is the, you guessed it, “Configuration Logging Report”. There are several other reports available as well including, but not limited to:

  • Alerts Report
  • Application Usage Report
  • Client Type Report
  • CPU Utilization Management Report
  • Policy Report
  • Server Availability Report
  • Environment Usage Report

Report Specification

Before you can run any report in the Access Management Console, you have to create a report specification. A report specification basically tells a report where to get its data and where/how to output the data. Different reports will have different data sources. For instance, the Configuration Logging Report’s data source would be the Configuration Logging database, whereas the Application Usage Report’s data source would be the Resource Manager Summary Database. There is a wizard in the AMC that will step you through setting up a report specification. To start the wizard, simply right-click the Report Center node in the AMC and select “Generate specification”. The wizard is pretty self explanatory, but I do want to point out one part.

ReportStorage

When you choose to store a report for later viewing, the report is stored in your user profile (actually, all report specification options as well as the report specification itself is stored in the user profile). The bad thing about this is all this stuff is stored in your local profile by default in the following path:

%USERPROFILE%\Local Settings\Application Data\Citrix\ReportCenter\

If you are using roaming profiles, these reports/specifications will get wiped out when you log off (since Local Settings do not roam). However, there is an option to store reports in your roaming profile. This setting is located in the middle column of the AMC when you select the Report Center node.

storageprofile

Scheduling Reports

One of the interesting things you can do is schedule a report to run on a recurring basis. Say you wanted to get a summary of configuration changes every morning. You could create a schedule to run this report and email it to you. To schedule a report, right-click the report specification and select “Schedule report”.

ScheduleReport

Clicking “Schedule report” brings up a wizard that looks a lot like Windows Task Scheduler. The reason it looks like Windows Task Scheduler is because you are actually creating an ordinary Windows Scheduled Task. However, if you try to look for this scheduled task in Windows, you probably will not see it. That is because Citrix was sneaky and made the scheduled task hidden. To view the schedule task in Windows, you will have to enable “View Hidden Tasks”.

ScheduledTask

Viewing Reports

To view a report, you first need to run a job. You can run a job by right-clicking on a report specification and selecting “Run report now”. Scheduled reports create jobs as well. Once a job completes, you can view the report from the “Jobs” section of Report Center. Reports can be generated in HTML format or CSV format. The default format of a report is specified in the report specification; however, you can view any report in either format via the AMC.

ReportJob

Modifying the Report Layout

There isn’t much to discuss about the CSV format, but I do want to show you a few things about the HTML format. By default, the HTML format report looks pretty ugly.

HTMLReport

There are a few things we can do to make this report look better. To better understand how to modify the report, it is important to understand how the reports are generated.

The raw data behind a report is XML. A command line utility called genrep.exe is responsible for going out to the data source and generating the XML in the form of a dataset. Once the data has been retrieved, a XML style sheet transformation (XSLT) is applied to produce the resulting HTML. The XSLT files are stored in:

%ProgramFiles%\Common Files\Citrix\Access Management Console – Report Center\Reports\ConfigurationLoggingReport

There are some common and language specific transforms here. The simplest way to style the report is to modify ConfigurationLoggingReportHTML.xslt. Here is a screen shot of a report generated with a modified transform:

HTMLReportStyled

This concludes our look at “out of the box” capabilities. Even though we were talking mainly about Configuration Logging reporting, most of this information also applies to other reports in Report Center. In the next posts, we will explore the back end database and how to do some custom reporting.

Digging in to Citrix Configuration Logging: Setting up the Citrix XenApp farm for Configuration Logging

This is the third part in a series on Citrix XenApp Configuration Logging. This part will show you how to configure your Citrix XenApp farm for Configuration Logging, what all the settings mean, what happens when you configure your farm for logging, what happens when things go wrong, and more.

This is the third part in the Citrix Configuration Logging Series.  In part 1, we discussed what Citrix Configuration Logging was.  In part 2, we discussed how to prepare the database to log configuration changes.  In this part, we will discuss how to set up the Citrix XenApp farm to use the database and what happens under the covers when we do this.

Configuring the Citrix XenApp Farm to use the Database

You use the Access Management Console to configure the XenApp farm for Configuration Logging.  Configuration Logging is a farm setting, so once you open the Access Management Console, simply right-click your farm name and select “Properties”.  Select “Configuration Logging” from the Farm-wide properties.

ConfigLoggingFarm

Now, we need to point our farm to the database we created before.  To do this, click the “Configure Database…” button to start the database configuration wizard.

DBWizardStep1

The screen shot above is pretty self-explanatory, but here are a couple of tips:

  • Even though there is a drop down next to the “Server name” box, the discovery does not always work.  I suggest just typing in the database server name or IP address.
  • Be sure to specify server\instance if you are not using the default database instance.
  • If using Windows integrated security, type domain\username in the “User name” field
  • Keep in mind that the username and password is saved in the data store.  So, be sure that the password does not expire, or remember to change this when the password does expire.
  • Discovery does not work well with the database name on the next step either.  Again, you will most likely have to type in the database name.

DBWizardStep3

The screen shot above shows a lot of settings, but there is not a lot of explanation of what these settings do.  Remember, Configuration Logging is built on top of ADO.NET.  In order to make sense of these settings, you can look at ADO.NET properties.  So, here ya go:

  • Connection time-out (seconds) – amount of time to wait for a command to execute.  If a database write command cannot execute in 20 seconds, you’ve got a problem.
  • Packet size (bytes) – the size of the network packet.  8192 is the default.  This value can be anywhere from 512 to 32767.
  • Use encryption – more on this in a minute…
  • Connection pooling enabled – connection pooling is just like session sharing.  Building up and tearing down database connections can be an expensive process.  Connection pooling allows a connection to stay up for an amount of time before closing just in case another database request comes in.  If another database request comes in before the time out, the request will use the same connection.
  • Minimum pool size – specifies the minimum number of connections to maintain in a pool.  If you set this number to 3, for example, ADO.NET would create 3 connections the first time you connect to the server. Zero is the ADO.NET default.
  • Maximum pool size – maximum number of connections in a pool.  100 is the ADO.NET default.
  • Connection lifetime (seconds) – specifies the maximum age of connections. If a connection has been open for more than this number of seconds when you call its Close() or Dispose() method, it will be destroyed rather than being returned to the pool. Zero is the ADO.NET default, which means that connections are kept in the pool regardless of age.
  • Connection reset – specifies whether the database connection is reset when being removed from the pool.  True is the ADO.NET default.
  • Enlist – specifies whether to enlist this connection into a current transaction context of the creation thread.  In other words, if this is set to true and the database server is doing some transactions, let the connection use the already generated transaction.  True is the ADO.NET default.

Almost all of those defaults are just great.  The only one you need to be careful about is the “Use encryption” option.  This option is set to “Yes” by default.  But, in order to use Configuration Logging encryption, you must be using IMA encryption.  If you are not using IMA encryption, you cannot use Configuration Logging encryption.  You will get this nasty undescriptive error when you test the connection if there is a mismatch:

EncryptionError

For information on how to setup IMA encryption, check out the Citrix XenApp documentation.

Configuring the Citrix XenApp farm to Log Changes

Now that we have the farm configured to point to the database, we have some options on how to log changes.  Remember this screen shot?

ConfigLoggingFarm

This is pretty easy, there are only 3 checkboxes:

  • Log administrative tasks to logging database – this is what tells the IMA service to use the CitrixLogServer.dll hook to log changes explained in part 1.
  • Allow changes to the farm when database is disconnected – this is self explanatory.
  • Require administrators to enter database credentials before clearing the log – “the log” referred to in this option is all the data in the database.  An administrator can clear the log by opening the AMC, right-clicking on the farm name – > All Tasks –> Clear configuration log.

If you do not allow changes to be made to your farm and your Configuration Logging database is offline, you will get the following error message when trying to make a change:

error

Wow – that error message is actually pretty descriptive!

Note – even if you do not allow changes to be made to your Citrix XenApp farm when the Configuration Logging database cannot be reached, you can still change which database your farm uses.  That means if you are trying to make a change and your database took a dive and it doesn’t look like it will be back up anytime soon, you can always change which database logs the changes and carry on.  Of course, changing which database logs changes gets logged <- say that 5 times fast…

Adjusting Database Permissions

As you may recall, when we created the data base user in part 2, we had to make sure the database user belonged to the db_owner role.  This is due to the fact when the XenApp farm connects to the database, the schema is checked.  If the schema does not exit, it is created – which requires db_owner rights.  So, after that first connection, you can dial back the permissions.  Here are the minimum operating permissions:

Configuration Logging Task Database permissions needed
To create log entries in the database tables INSERT for the database tables,
EXECUTE for the stored procedures, and
SELECT for sysobjects and sysusers (SQL Server) or sys.all_objects (Oracle)

(Oracle also requires SELECT for sequence objects and the create session system privilege)

To clear the log DELETE/INSERT for the database tables,
EXECUTE for the GetFarmData stored procedure, and
SELECT for sysobjects and sysusers (SQL Server)
or sys.all_objects (Oracle) (Oracle also requires SELECT for sequence objects and the create session system privilege)
To create a report EXECUTE for the Citrix Configuration Logging
stored procedures
SELECT for sysobjects and sysusers (SQL Server) or sys.all_objects (Oracle)
(Oracle also requires the create session system
privilege)

 

Delegated Administration

Delegated administration is supported to an extent.  It is basically an on or off thing.  It is a good idea to make sure administrators have to enter credentials to clear the log as well.

delegatedadmin

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.

Web Interface for Resource Manager is now in Spanish

The latest version of Web Interface for Resource Manager is now available in Spanish (other languages supported are English, Dutch, French, German, and Italian). Web Interface for Resource Manager is an ASP.NET 2.0 web application that contains several SQL queries to display useful information contained in the Citrix Resource Manager Summary Database.

Thanks to Gustavo Gurmandi, Web Interface for Resource Manager now has a Spanish translation. That makes Web Interface for Resource Manager available in six languages:

    English English
    Dutch Dutch – provided by Michel Roth
    French French – provided by Laurent FALGUIERE
    German German – provided by Josef Zeiler
    Italian Italian – provided by Francesco Dipietromaria
    Spanish Spanish – provided by Gustavo Gurmandi

If you are interested in providing a translation, feel free to send me an email.

Download Web Interface for Resource Manager version 2.2

Web Interface for Resource Manager is now in Italian

The latest version of Web Interface for Resource Manager is now available in Italian (other languages supported are English, Dutch, French, and German). Web Interface for Resource Manager is an ASP.NET 2.0 web application that contains several SQL queries to display useful information contained in the Citrix Resource Manager Summary Database.

Thanks to Francesco Dipietromaria, Web Interface for Resource Manager now has an Italian translation. That makes Web Interface for Resource Manager available in five languages:

    English English
    Dutch Dutch – provided by Michel Roth
    French French – provided by Laurent FALGUIERE
    German German – provided by Josef Zeiler
    Italian Italian – provided by Francesco Dipietromaria

If you are interested in providing a translation, feel free to send me an email. Even if you don’t speak Italian, you might still want to download the latest version as it has a few minor bug fixes in it. Speaking of bug fixes, the next version of Web Interface for Resource Manager (version 3.0) has a few more bug fixes as well as some new features. Here is a list of some of the features that are in the works:

Farm level reports will provide statistics on a farm-wide basis.
ASP.NET AJAX enhancements will provide UI and performance improvements.
MFCOM integration will provide real-time application and server statistics.
Citrix Presentation Server 4.5 configuration logging database integration will provide reports on historical farm changes.

Hmm, I might have to rename this thing since it is starting to reach beyond Resource Manager. Until then, go get Web Interface for Resource Manager version 2.2

Web Interface for Resource Manager 2.2

Got Citrix Resource Manager? Try out Web Interface for Resource Manager! Web Interface for Resource Manager is an ASP.NET 2.0 web application that contains several SQL queries to display useful information contained in the Citrix Resource Manager Summary Database.

version 2.2

UPDATE March 1, 2007 – The resolution to errors received when saving your configuration is posted in the Known Issues section of this article.

Got Citrix Resource Manager?  Try out Web Interface for Resource Manager!

Web Interface for Resource Manager is an ASP.NET 2.0 web application that contains several SQL queries to display useful information contained in the Citrix Resource Manager Summary Database.  Web Interface for Resource Manager displays this information in a drill-down graphical and tabular manner.

What’s new in version 2.2?
Web Interface for Resource Manager version 2.2 includes everything in version 2.1, plus the following new features:

  • New information on the Client report
    • When no client version is stored in the Citrix Resource Manager Summary Database, the Client report performs a lookup based on the build number.  Special thanks goes to Alex Danilychev for creating a Client Build vs. Version chart.
    • The Client report has an icon that will show all workstations that have used a particular client. 
    • When you click on the user icon in the Client report, the workstation the user used to launch the session is displayed in the report.
  • There are 3 new features on the Client report:

  • Microsoft Excel exports on every tabular report
    The ability to export viewed results to Microsoft Excel is now on every report that presents tabular data.
  • Active Directory group security for Configuration options
    The configuration page is now optionally securable by specifying an Active Directory group in the configuration page.
  • Web.Config connection string encryption
    When you enter your database connection details in the configuration page, the resulting connection string that is stored in Web.Config is now encrypted.

 

  • Active Directory group security for Configuration options
    The configuration page is now optionally securable by specifying an Active Directory group in the configuration page.

 

  • French Translation
    Thanks to Laurent FALGUIERE, there is now a French translation of Web Interface for Resource Manager.  Resource Manager for Web Interface is also in German (thanks to Josef Zeiler), Dutch (thanks to Michel Roth), and English.

 

  • Farm name display in page titles
    The name of your farm is now displayed in the title of each page.  This helps keep things straight when you have multiple farms and an instance of Web Interface for Resource Manager for each farm.

Another thanks goes to Michel Roth for creating a Web Interface for Resource Manager Premo.  What is a Premo? “A Thincomputing.net Premo is a crossover between a preview and a demo of a new (version of a) product or technology in the field of Server Based Computing and Virtualization.”  Be sure to check it out…

  Download Web Interface for Resource Manager version 2.2 (for Presentation Server 3.0 and above) 

What’s on the radar for the future?

  • More “higher level” reports – meaning more reports that show entire farm data.  These reports will include drill down capabilities in to some of the more granular existing reports. 

Known issues

Issue
You receive a message stating “In order to modify configuration settings, the ASP.NET process account (either the local ASPNET or Network Service account, by default) must have write permission granted for the Web.config file in the web site directory.”

Resolution
Make sure the NETWORK SERVICE account (or whichever account is configured for the IIS Application pool identity WI RM is in) has write access to the directory where Web.Config resides. This is due to the way the Configuration.Save() method works in the .Net Framework. When this method is called, a temporary config file is created before overwriting the Web.Config file. If the NETWORK SERVICE account does not have write access to the directory, the temporary file cannot be created and you will receive the error message stated above. Also, ensure Web.Config is not a Read Only file.

If all database tables are not owned by dbo, you will receive errors. For more explanation on this phenomenon, see this article.

If you do not properly set up your database authentication, you will not be able to view any reports. Please refer to this article for database authentication guidelines.

Note: Version 2.2 is only intended for Presentation Server 3.0 and above. This is due to the differences in the Resource Manager Summary Database schema.  The MetaFrame XP Summary Database schema does not include the tables necessary to generate these new reports. Please use Web Interface for Resource Manager Version 1.1 for MetaFrame XP.

Screen Shot of Web Interface for Resource Manager’s GUI Configuration Tool


Click to enlarge

Be sure to check out Access Tracking Manager (ATM) from XTS as well. ATM leverages Microsoft SQL Server Analysis Services and OLAP Cubes to provide even more detailed reports for your Citrix environments.

Web Interface for Resource Manager 2.1

Got Citrix Resource Manager? Try out Web Interface for Resource Manager! Web Interface for Resource Manager is an ASP.NET 2.0 web application that contains several SQL queries to display useful information contained in the Citrix Resource Manager Summary Database.

version 2.1

Got Citrix Resource Manager?  Try out Web Interface for Resource Manager!

Web Interface for Resource Manager is an ASP.NET 2.0 web application that contains several SQL queries to display useful information contained in the Citrix Resource Manager Summary Database.  Web Interface for Resource Manager displays this information in a drill-down graphical and tabular manner.

What’s new in version 2.1?
Web Interface for Resource Manager version 2.1 includes everything in version 2.0, plus the following new features:

  • Graphical Configuration Tool
    In the past versions of Web Interface for Resource Manager, you had to manually edit the Web.Config file to set up your database connections and time zone overrides. This new graphical tool allows you to set up your options much like you set up an ODBC connection using Windows.
  • Oracle Support
    Many of you have asked for an Oracle version of Web Interface for Resource Manager. Version 2.1 has Oracle support integrated. Just open the configuration tool, select Oracle as your Database Server Type and supply your TNS Service Name. One thing to note though, you will need to have the Oracle client installed on your web server.
  • Multiple Language Support
    Web Interface for Citrix Resource Manager has been globalized to support more languages. Currently, Web Interface for Resource Manager supports the following languages:
    • US English
    • German (thanks goes to Josef Zeiler for the translation)
    • Dutch (thanks goes to Michel Roth for the translation)

  Download Web Interface for Resource Manager version 2.1 (for Presentation Server 3.0 and above) 

What’s on the radar for the future?

  • Using MFCOM and WMI to move reports beyond the Summary Database.
  • Of course, more reports.

Known issues

If all database tables are not owned by dbo, you will receive errors. For more explanation on this phenomenon, see this article.

If you do not properly set up your database authentication, you will not be able to view any reports. Please refer to this article for database authentication guidelines.

Note: Version 2.1 is only intended for Presentation Server 3.0 and above. This is due to the differences in the Resource Manager Summary Database schema.  The MetaFrame XP Summary Database schema does not include the tables necessary to generate these new reports. Please use Web Interface for Resource Manager Version 1.1 for MetaFrame XP.

Screen Shot of Web Interface for Resource Manager’s GUI Configuration Tool


Click to enlarge

Web Interface for Resource Manager version 2.1 is coming soon

Check out the new features coming in Web Interface for Citrix Resource Manager. Web Interface for Citrix Resource Manager will be easier to configure, easier to read, and will be available to a entire new audience.

Web Interface for Resource Manager version 2.1 is coming soon and there are three new features. The first feature is a GUI for setting up configuration parameters. No more fumbling with the Web.Config file to set up your connection to the database. Check out the screen shot below:

You may notice the other two features from this screen shot. First, Web Interface for Citrix Resource Manager is now poised to support multiple languages. Second, you may also notice that Web Interface for Citrix Resource Manager will finally support Oracle as a database server for the Citrix RM Summary Database.

Okay, so now you know what is coming out but, I need some help with this one. The first thing I need help with is testing the Oracle release since I only have an Oracle server running in a test Virtual Machine with copied data from a SQL server. If you are interested in testing out the Oracle functionality, please drop me an email. Second, if you would like to see Web Interface for Resource Manager in a language besides English US or German, I need help with translations. (Thanks Josef Zeiler for the German translation!) Again, if you are interested in contributing some translation skills, drop me an email and I will send you the resource file that contains all the text for the web application as well as the help files.

Stay tuned…