MFCOM to PowerShell: How to Make the Transition

MFCOM has been the de facto standard for programmatically interfacing with Citrix XenApp. Whether you wanted to write a simple script or develop an application that interfaced with XenApp, MFCOM was the answer. Now, Citrix is committed to building their management architecture on PowerShell–not just for XenApp, but for all Citrix products. That’s great news for standardization across platforms and aligning with Microsoft on using PowerShell for management architectures. Now, the question is how do you take what you know about MFCOM and translate that to PowerShell?

As you may of may not already know, Citrix has committed to building their management architecture (and SDK) on PowerShell – not just for XenApp, but for all Citrix products.

In XenApp 6.0, MFCOM is not available anymore. The underlying architecture has changed dramatically enough to make backward compatibility with MFCOM impossible. The replacement for MFCOM is PowerShell. MFCOM-based scripts need to be completely re-written in XenApp cmdlets. In most cases, the conversion should be simple and most MFCOM scripts can be replaced with one-liner PowerShell commands.

Source: Citrix XenApp 6 PowerShell SDK reference manual.

That’s great news for standardization across platforms and aligning with Microsoft on using PowerShell for management architectures.  But, that begs the question – what do you do about all those scripts and applications that leverage MFCOM going forward?  I’ll be presenting a session at BriForum 2010 with Brandon Shell about this very topic.  The session will cover:

  • General Object Orientation
  • Specific Citrix XenApp objects
  • Examples of how scripts and applications were done with MFCOM
  • Converting scripts and applications to use PowerShell
  • PowerShell remoting
  • Availability of PowerShell cmdlets on XenApp 5 and XenApp 6
  • C# applications leveraging the PowerShell command wrapper

BriForum takes place from June 15th to June 17th at the Hilton Chicago Hotel.  There is still time to register.

News from Citrix Synergy

I’m blogging the Citrix Synergy keynote in real time. I’ll be adding to things that strike me as interesting to this post as announcements are made.

I’m blogging the Citrix Synergy keynote in real time.  I’ll be adding to things that strike me as interesting to this post as announcements are made.  Unfortunately, I didn’t think about making a crazy cool AJAX out of band update, so you’ll have to refresh your browser.  You can follow me on Twitter at http://twitter.com/JasonConger as well for snippets.

XenClient

In beta for a while, XenClient is now released to the public.  The vision of a client hypervisor is moving toward offline VDI.  Citrix will use a technology called Synchronizer to keep the virtual desktop on the XenClient client machine synchronized with a remote copy in the data center.  Another cool feature is the ability to send a “kill pill” to the XenClient VM.  I think this is a very significant announcement.  One word of caution, there is a limited subset of workstations that XenClient supports.

HDX Nitro

There are a lot of announcements surrounding HDX.  HDX “Nitro” includes several sub technologies:

  • Project Mach 3 will give you 3x performance
  • Project Laser is for printing performance
  • Project Zoom is application pre-launch for instant connection
  • Project Mercury is for WAN acceleration

Check out more on HDX Nitro at http://hdx.citrix.com/nitro

Dazzle

Dazzle was shown at the last 2 Synergy conferences.  I like the idea of where Dazzle wants to go – user self-service, but it still lacks some functionality.  Workflow approval has been shown as a demo, but still doesn’t exist yet.  I also think some of the excessive eye candy animations need to go.  Check it out for yourself here: http://www.citrix.com/tv/#search/dazzle

Twitter updates from the event:

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.

How to Enable AutoComplete for Web Interface Logon

The logon page for Citrix Web Interface explicitly disables the web browser functionality of saving form data. But, what if you want to let your users save their username (especially if they have a particularly long UPN)? This article will show you how to re-enable this functionality for both Web Interface 4.x and 5.x.

The logon page for Citrix Web Interface explicitly disables the web browser functionality of saving form data. But, what if you want to let your users save their username (especially if they have a particularly long UPN)? This article will show you how to enable AutoComplete functionality for both Web Interface 4.x and 5.x.

Disclaimer – I would highly recommend only implementing this solution in a secure internal environment. You do not want your usernames or passwords floating around out there in the public.

 

Citrix Web Interface AutoComplete

 

 

How Web Interface disables AutoComplete
Web Interface hasn’t always disabled the AutoComplete functionality of web browsers.  I actually think it is wise Citrix did start disabling AutoComplete by default because a lot of Web Interface sites are external-facing and AutoComplete can be a bad thing in an external scenario. The way Web Interface disables AutoComplete is by adding a property to the <form> tag in the HTML.  Simply adding autocomplete=”off” will disable AutoComplete for all <input> elements within the <form>. If you look at the rendered WI login page’s HTML, you will see <form… autocomplete=”off”>.

Enabling AutoComplete for Web Interface 4.x
Enabling AutoComplete for Web Interface 4.x is actually quite simple.  All you really need to do is get rid of the autocomplete=”off” property in the <form> tag.  To do this:

Modify loginView.ascx

Change this:  <form method="POST" action="<%=PAGE_LOGIN%>" name="NFuseForm" autocomplete=”off”>

To this:  <form method="POST" action="<%=PAGE_LOGIN%>" name="NFuseForm">

A possible downside to this is that passwords will be saved as well.  If you do not want passwords to be saved, you can tell just the password field to disable AutoComplete.  To do this:

Modify loginMainForm.inc

Change this: <input type='password'…

To this: <input autocomplete="off" type='password'…

Enabling AutoComplete for Web Interface 5.x
Enabling AutoComplete for web Interface 5.x is the same as enabling AutoComplete in Web Interface 4.x with one exception.  Web Interface 5.x does not use a <input type=”submit” /> button to submit form data.  Instead, Web Interface 5.x uses JavaScript to submit the form data.  This causes an issue with AutoComplete because AutoComplete only commits data to Protected Storage via a <input type=”submit” /> button.  So, to get around this bug “feature”, we need to do some trickery.

Since AutoComplete only works with <input type=”submit” /> buttons, we need to add one of these buttons to our login page.  We do not actually want to see this button since it is just there to facilitate the AutoComplete functionality, so we set the display style on the submit button to none (<input type=”submit” style=”display: none” />)

Finally, we need to manipulate the Web Interface JavaScript code that submits to form to tell it to “virtually press” our hidden submit button (this will cause AutoComplete to save the data).  Here are all the steps necessary to implement AutoComplete in Web Interface 5.x:

Step 1 – Modify layout.ascx

Change this:  <form method="post" action="<%=FormAction%>" name="<%=Constants.ID_CITRIX_FORM%>" autocomplete="off">

To this: <form method="post" action="<%=FormAction%>" name="<%=Constants.ID_CITRIX_FORM%>">

 

Step 2 – Modify loginMainForm.inc

Add the following to the bottom (right after </table>):

<input type="submit" value="submit" id="hiddenSubmitButton" style="display:none" />

This is our hidden fake submit button that will trigger AutoComplete to save the data.

Step 3 – Modify login.js

Change this:

function submitForm() {
    if (!isSubmitted) {
        changeLoginBtnColor(false);

        isSubmitted = true;

        var loginBtn = document.getElementById("loginButtonWrapper");
        if(loginBtn){
            loginBtn.style.color = "#aaaaaa";
        }

        disableLinks();

        document.forms[0].submit();
    }
}

To this:

function submitForm() {
    if (!isSubmitted) {
        changeLoginBtnColor(false);

        isSubmitted = true;

        var loginBtn = document.getElementById("loginButtonWrapper");
        if(loginBtn){
            loginBtn.style.color = "#aaaaaa";
        }

        disableLinks();

        var hiddenSubmitBtn = document.getElementById("hiddenSubmitButton");
        if(hiddenSubmitBtn.click) {

                hiddenSubmitBtn.click();
        }
        else {
                document.forms[0].submit();
        }
        return false;
    }
}

The highlighted code basically tells the JavaScript submit function to “virtually click” the hidden submit button we added to loginMainForm.inc.
Again, if you want to disable passwords from being saved, add autocomplete=”off” to all the <input type=’password’ … /> fields in loginMainForm.inc.

 

 

Other factors of using AutoComplete
In order for AutoComplete to save form data, the feature needs to be turned on in your web browser.  For Internet Explorer, this can be found by going to Tools -> Internet Options -> Content tab.

Internet Explorer AutoComplete

For Firefox, this can be found by going to Tools -> Options -> Privacy.

FF-AutoComplete

AutoComplete stores form data in Protected Storage – which means that the Protected Storage service needs to be running.   Protected Storage can, on occasion, get corrupted.  See this Microsoft support article about this situation: http://support.microsoft.com/kb/306895

Citrix turns 20

Citrix turns 20 today. In this post, I will tell you how I got introduced to Citrix several years ago.

Citrix Citrix is 20 years old today (still under the drinking age in the Unites States). I remember when I was first introduced to Citrix. It was back around 1999 when I used to work for an integrator. Most of the work I did was Novell related(yes I was a CNE back in the day). Anyway, one of the projects that came down the pipeline was something totally different. My role in the project was to visit a multitude of nursing homes throughout Mississippi and Louisiana, install a Cisco router and switch (I was actually a CCNA then too), install NICs in computers, and install this thing called a Citrix client on the PCs. My final test was to make sure the Citrix client could “talk” to the Citrix server in the main location. I didn’t really realize what was going on with this Citrix thing until about the 5th install I did. It was then that I started to think this was some pretty cool stuff. By the way, this was all WinFrame 1.x (based on Windows NT 3.51).

I started to learn more about Citrix and later got certified as a CCEA. The integrator I was working for became part of the Citrix channel and I soon found myself working with some really cool SEs like Barry Flanagan. Barry still tells a story from the first time we met – I showed him where I installed a Java Citrix client on a Novell server (Novell supported Java by then). I was like – “Barry, look – you can run NWadmin directly from the Novell server console (NWadmin was a Windows app you used to administer Novell servers).” I guess he thought that was cool, because he still talks about it.

A lot has happened since then. I went to work for Citrix in Fort Lauderdale for a while. I started this Citrix-focused website. Citrix greatly diversified their product portfolio. I’ve written thousands of lines of code (for free) to extend Citrix products. I became a CTP. And, I’ve done quite a bit of technical public speaking (mostly Citrix focused).

So, I guess it is a good thing that I had to travel to all those nursing homes to setup that Citrix thing. By the way, I still remember some of those roads in Louisiana. I remember driving down “Devil’s Swap Road”. I also had to drive down a road that didn’t have a name, but I was told I would recognize it because the sugar cane was really tall that time of year. Also, as it turns out, nursing home food isn’t that bad.

Branding the Citrix ICA Client

Using the techniques described in this article, it is possible to put your own custom logos on the Citrix ICA client during application launch.

Using the techniques described in this article, it is possible to put your own custom logos on the client during application launch. See screen shots below:

Before After
Disclaimer: This article is for informational purposes only. Be sure to reference your license agreement before implementing this in a production environment.
Tools Needed:

  • Citrix Presentation Server Client Packager
  • Resource Hacker (free)
  • Graphics Editing Software (Microsoft Paint is sufficient)

Step 1: Export Existing Citrix MetaFrame ImageThis step is performed to export the existing resource image so you can replace the image with a new one with identical dimensions.

Follow these steps to complete this task:

  • Launch Resource Hacker and open statuiUI.dll. Note: statuiUI.dll is located in C:\Program Files\Citrix\ICA Client\resource\en for an English installation.
  • Navigate to Bitmap -> 101 -> 1033 (Note: since I am using the English version of the client, 1033 is my locale ID. Your locale ID may differ)
  • Right click 1033 and select “Save [Bitmap : 101 : 1033]…” Save this bitmap to any desired location

Step 2: Modify the Exported Image

Using your preferred graphics editor, open up the bitmap exported in step 1.
Modify the image as desired and save as a different name if desired.

Step 3: Replace the Resource in statuiUI.dll

  • Make a backup of statuiUI.dll
  • Launch Resource Hacker
  • Navigate to Bitmap -> 101 -> 1033
  • Right click 1033 and select “Replace Resource…”
  • Click the button labeled “Open file with new bitmap…”
  • Navigate to the bitmap created in step 2.
  • Click the Replace button.
  • Save the new statuiUI.dll file.


You will now have a branded client when launching applications. Go ahead and try it out.

You will probably notice that about half way through the application launch process, the picture you created in this step reverts back to the original Citrix Metaframe bitmap if you are running Presentation Server 3.0 or above. Why does this happen? Read on.

Citrix introduced an improved user logon process in Presentation Server 3.0 and above that included a progress bar indicating connection status throughout the entire application launch process. Basically, when you launch a published application, the process starts on the client computer setting up the connection to the server. Then, the process gets handed over to the server to complete the application launch (logon to the server, load the profile, etc). Prior to Presentation Server 3.0, when the launch process got handed over to the server, the Windows logon dialog boxes were displayed. This created kind of a disjointed look and feel for the end user. In Presentation Server 3.0 and above, the Windows logon dialog boxes were “replaced” with new dialogs that look like the local client dialog. This gave the end user a smooth looking look and feel throughout the entire launch process.

So, how do you stop this seemingly regression from happening? Move on to step 4.


Step 4: Replace statuiUI.dll on the Server.

The “replacement” dialog box for the server piece of the launch process is located at system_drive:\Program Files\Citrix\System32\resource\en\statuiUI.dll. Simply make a backup of this file and replace it with the statuiUI.dll file created in step 3.

Note: this file may be locked if other people are logged in to the server.

Now, try launching an application again and you will notice that the branding stays throughout the entire launch process.

Another file that is fun to play with is the login screen for the PN Agent. That resource is C:\Program Files\Citrix\ICA Client\resource\en\pnagenUI.dll. Have fun!