XenApp 6.5 – PowerPoint 2010 flickering

I noticed my screen will flicker from time to time while working with PowerPoint via XenApp 6.5.  Although no one was complaining about it, it really began to annoy me and figure I look into it.

I found out that Office 2010 utilizes hardware acceleration for displaying images (enabled by default), from time to time you will see constant screen flickering when you try to display a presentation with images via XenApp 6.5.  I remember back in my XenApp 5.0 days this really occurred a lot with PowerPoint 2010 as that environment lived on a Server 2003 infrastructure.

The fix:

For Windows 2003,  the issue is fixed by installing this Microsoft Hotfix.

For Windows 2008, you can disable hardware acceleration in PowerPoint via File, Options, Advanced, Display, then click Disable hardware graphics acceleration for each user…

Since most of us XenApp folks are all about automating user profiles, you can set the following regkey into your mandatory profile, or hive it in via a GPO, or AppSense, Citrix Profile Manager, or however you manage your profiles.

Windows Registry Editor Version 5.00





EdgeSight for XenDesktop 5.6

Not being a true Citrix EdgeSight guru (I don’t think I really want to be one), I’m faced with more and more implementations where EdgeSight is utilized to monitor both XenApp and XenDesktop.  At my last company, I ended up not running XenDesktop with EdgeSight as we could not get it to fully work during the POC process, and of course it came back to hunt me (At the time, it was XD 5.5) – Lesson learned :P

This time I was helping a friend of mine with a new XenDesktop 5.6 implementation he was working on (I got your back amigo).  After some initial challenges we were able to get things working and figure I share this with you.

Back end:

– Edgesight v. 5.4

– XenDesktop v. 5.6

– XenApp v.6.5

– Provisioning v.6.1

– Citrix DataStore is SQL Server 2008 R2

– Operating systems for all servers are Windows 2008 R2

– Operating system for VDI desktops is Windows 7 x64

The EdgeSight installation for XenDesktop begins with a basic process (Next, Next, Next, type of thing).  After this you can add a XenApp servers etc to be monitored. This is pretty straight forward.

With XenDesktop, a component is added to the architecture of EdgeSight, an Agent Database Broker.  The database broker saves data that the VDI agent is sending, but before the agent is allowed to write data, it has to contact the EdgeSight server, it does this so it knows which server the agent database broker will redirect the agent to the broker server.  A bit complex, so here is a pic of flow

The flowchart below is from Edoc at Citrix and shows what I just described.

The next component that is required is a share that is utilized to save data like log files.  These logs are INI files that are not saved on the EdgeSight or database broker itself.  The share can be located on the Edgesight server or even better the Agent Database Broker.

This folder will require the following rights.

  • List Folder / Read Data
  • Read Attributes
  • Read Extended Attributes
  • Create Folders / Append Data
  • Delete
  • Read Permissions


The VDI agent on the XenDesktop stores the same log files on the VDI  itself in a default folder at C:\ProgramData\Citrix\SystemMonitoring\Data.  When running PVS, make sure to move this directory to your cache folder (Normally cache to device’s hard drive)

If you experience issue with communication between the agent and the Edgesight backend check the SYS_EVENT_TXT.TXT file.

Errors like the one below states that something is wrong, and the error says a lot but not exactly what you want to know.

Current service state is ‘START_PENDING’
Core Collector Starting…
Core Collector Database connection is brokered.
Core Collector Connecting to database broker http://serveraddress:80/edgesight/app/Services/DbBroker.asmx
Core Collector Error obtaining database connection. Failed to contact database broker at http://serveraddress:80/edgesight/app/Services/DbBroker.asmx for pool ‘Windows 7 – VDI’. Error=0x80072EE2 SoapClientError=SEND_ERROR

If you look in the EdgeSight console you’ll see the Device count is 0, this is of course because of the error above.

I checked the Citrix eDocs over and over but never saw that one line about the Agent Database Broker.  I thought it was that you just add a Agent Database Broker server to the infrastructure so that you have two server running; 1 EdgeSight and 1 Agent Database Broker server.

I was so wrong about that, after reading eDocs again, one line stood out that I missed or mis-interpreted before. The pic below is a small part of eDocs about the broker.

It says that if you have multiple EdgeSight installations (whatever they mean by that) you select one to act as the broker. That made me think, I had only done one broker server installation, there was not a lot to choose.  So my guess was that if I installed the broker software on the Edgesight server and pointed it to the broker that might work.

That turned out to be exactly what it had to be done… :) The minute I hit finish at the installation GUI, was the minute the VDI agent could talk to the broker. I changed the broker address in the VDI agent to the EdgeSight server (who is responsible for direction clients like shown in the flowchart in the beginning).

As you can see the Broker server address, ( the address is hidden or course) has to be filled in. This is I think not so clear as it might give you the idea that you can point to the actual broker server, but you have to point to the EdgeSight server instead.

If you install the agent or the broker, make sure you set the pool name correctly, without that you’ll never get it to work.

After the installation of the broker is done, you’ll see a logging like this in the console.

After a while you will notice pinging checks appear to check the existence of the broker.

With PVS, it’s surely possible and even wise to add a persistent disk that is maintained during reboots. on that disk you could save the data that is now going to the broker.

Lastly, take note that the agent won’t start when the provisioned desktop is in private mode. This can be over ruled with changing a registry key value (this is by design)

On the Desktop edit the registry key HKLM\Software\Citrix\System Monitoring\Agent\Core\4.00\IgnorePVSMode and change it to 1.

Hope this will help you get more understanding of EdgeSight and XenDesktop.  I sure learned something new this time, which is one of the reasons I just LOVE what I do.

NetScaler SSL offload with firmware nCore 10 build 69.4

One excellent feature of Citrix NetScaler is the SSL Offload capabilities.  Based on the MPX specs (Physical appliance), they all include a Cavium SSL accelerator card, this card has the ability to handle SSL encryption/decryption cycles using a hardware card, rather than consuming valuable CPU resources.

After reading and speaking with fellow Citrix engineers, the VPX (Virtual appliance) can also have the SSL offload feature enabled (I always thought it didn’t since there is no SSL card), however as there is no Cavium card, the SSL offload performance is not as high as an MPX appliance, and generally consumes a ton of CPU, hence it can severely impact the scalability of servers that host content requiring SSL encryption (be careful when you are sizing your NetScaler)

Here are some real world examples of how this is used:

  • Microsoft Outlook Web Access/Client Access (Ah that Source IP Mike!)
  • Inspection of SSL traffic and switching based on content
  • SSL based websites (no payment information exchanged*) – Been looking at PCI initiatives very closely lately

“*When payment information is exchanged, it is usually mandated that the data cannot be viewed in transit, this is a requirement of PCI-DSS compliance” – Citrix Tech

The NetScaler can instead use SSL-Bridge for these types of transactions, and not utilize the SSL Offload technology.  What this means is the NetScaler will simply pass the SSL traffic directly to your back-end servers, and not act as the SSL terminator.

Now… let me thank Citrix and Simon Barnes from ITVCE for sharing this information.

SSL offload is designed to function in a similar manner to the below image:


In essence all encryption/decryption between the client and server is handled by the NetScaler SSL offload vServer. Once the data has been decrypted it is then sent on the destination service in plain text HTTP.


This configuration assumes that an SSL certificate already exists on the NetScaler for the chosen FQDN. The SSL Certificate is named “SSLapp”.

1. Create a back-end HTTP service

The first step in creating a new service is to create a server object, This is achieved by using “SSL Offload -> Servers” and then select “add”. The resulting item is purely an object that the NetScaler references in further configuration options. The name field does not need to match the hostname of the server, but it is recommended. In this example the webserver is named WinSvr01 and has an IP address of


Now that a server object exists, you can create a service object to reflect the HTTP service that is running on this web server.

A NetScaler service consists of a server object (created in the previous step), a protocol, port and a monitor. The monitor is used to determine if the service is available, in the event that the service is unavailable the NetScaler will mark the service as down, removing it from load balancing decisions.

In this example we are running a HTTP service (using default of port 80) on the previously created server object, whilst using a standard HTTP monitor to confirm that HTTP services are responding with a response code of “200” – this is HTTP for “ok”.


2. Create your vServer

Now that a service exists, you are ready to present the service to the outside world. This is achieved using a NetScaler virtual server (vServer). The first step is to create the object and provide the following information:

  • Name
  • IP Address
  • Port
  • Bound services

In this example we only have a single service to bind to the vServer, however in a production installation there may be 20 backend webservers all delivering the content, if this was the case these could be added in to a service group and then bound to the vServer, load balancing would then be used to ensure that the load is distributed to services that are UP and are able to service the client’s request.

The IP address that is added to the vServer here will be used by clients to connect to the backend services:


A certificate must also be bound to the vServer, this is the certificate that the vServer will present for client connections.


Client connections should now be directed to the vServer’s IP address – The vServer will present the SSL certificate when a connection is made using HTTPS (TCP 443), any encryption/decryption of data will be processed using the NetScaler’s built in Cavium card.

If the NetScaler is configured as a HA pair and the primary unit’s Cavium card fails, then HA failover will be invoked and the secondary unit will become the primary.

NetScaler 10 build 69.4 Bug

The GUI appears to incorrectly report the status of a feature, offering only the “disable” option for each feature. I have seen scenarios whereby the above configuration has been completed and the vServer immediately appears down, even though everything appears correctly configured.

The first thought is that SSL may not be enabled; checking in the GUI will only show you the option to disable the feature:

To view the reason that the vServer is down you can simply connect using SSH and then issue the following command:


As you can see in the above screenshot the SSL feature is disabled, causing the vServer to appear down. Enable the SSL feature using the following command:

The vServer will immediately come online:


XenApp 6.5 Desktop Director 2.1 installation and configuration

Looks like Citrix will be getting rid of the AppCenter console (I still call it CMC :)) for  application management.

They are finally looking into centralizing both application and virtual desktop management with a single interface.  Specially with the next version of XenApp, you will no longer need AppCenter for your app deployments.  You can read more on Project (Avalon) Excalibur Technology on one of my previous posts

Citrix has released a nice install guide to install and configure Desktop Director 2.1 to use with XenApp 6.5 and would like to share it with you.


  • A XenApp 6.5 Farm
  • An available server to install Desktop Director, it can also be added to the XenApp 6.5 Controller
  • An install Media for XenDesktop 5.6 Feature pack 1
  • IIS 7 installed on the server that hosts the Desktop Director
  • .NET Framework 3.5 Sp1
  • Adobe Flash 10.x or above
  • Firewall exceptions for port 80, 2513 and 5985


  • Ensure you have downloaded the ISO for XenDesktop 5.6 Feature pack 1; it is needed this for the DesktopDirector install.
  • If it is not already installed on the operating system, install .NET 3.5 Sp1 and Adobe Flash 10.x or above
  • Mount the XenDesktop ISO and launch the autorun option from the media and select the XenDesktop Option. Agree to the Licensing Agreement on the next page.

  • Select Desktop Director on the Select Components to Install and input the XenApp 6.5 controller FQDN in the Enter the address of the XenDesktop Controller field. Note: If the XenDesktop Controller option is not displayed, you are installing on a XenApp 6.5 server.

  • Click Next, at the install prompt, click the Install tab. When the installation completes, click Close.

  • Open IIS Manager on the Desktop Director Server to be able to log on to the Desktop Director Console. Select the Desktop Director site under Default Web Site

  • Locate Service.AutoDiscoveryAddresses in Application Settings. Double click this option and rename it to Service.AutoDiscoveryAddressesXA and ensure the controller FQDN is present. Note: If you have installed this on a XenApp 6.5 server and you are not able to enter the FQDN of the controller at installation, you can change it from Localhost to Your 6.5 Controller FQDN here, refer following image:

  • Run an IIS reset in the command prompt after the above options are updated. Note: You will be able to log in now, however you will not be able to view user-session specific details yet. You must follow the subsequent steps to be able to log in and view user-session specific details.
  • On the XenApp 6.5 controller, setup the WinRM permissions using a tool in the XenDesktop 5.6 FP 1 ISO (previously called ConfigRemoteMgmt.exe which was used to access information about session).
  • Open the command prompt window, browse to the following directory and run the application <Drive Letter>:\x64\Virtual Desktop Agent\ConfigRemoteMgmt.exe. Use the switch – ConfigRemoteMgmt.exe /configwinrm Domain\User.

The user-session specific information can be viewed if the XenApp 6.5 Controller has its permissions set for remote management.

Note: If you are not setting up certificates on the server for SSL, you can disable the SSL verification by changing the UI.EnableSslCheck to false.

View the original article for more information.

XenApp 6.5 Universal Print Server

Traditionally… one of the biggest hurtles for me over the last 12 years have been around ICA print management (Policies, Universal Printer Driver, native drivers, 3rd party tools, native print spool, Citrix print manager, etc).

Although printing via ICA is now pretty darn good with a combination of native drivers and the Universal Printer technology, I always felt there was a need for a 3rd party tool such as ThinPrint or Tricerat for those special cases.  As you are aware, Citrix released the Universal Printer Server to make printing a lot easier with XenApp 6.5 Hotfix Rollup Pack (HRP01) and now for XenDesktop 5.6 FP1

What is UPS?

The Universal Print Server introduces the EMF functionality to the print server as the client.  Sweet!

That means, again, no native or 3rd party printer driver must be installed on the XenApp server for any printer on the Windows print server. In many environments that should help reduce the installation of printer drivers on the XenApp server dramatically. Having only the Citrix EMF would keep the XenApp farm stable and help with user logon times.

This also resolves two common issues that administrators are faced with today. Leveraging the UPS means the no printer drivers have to be managed on the VDA or XenApp servers at all. Universal Print Servers also can be placed in branch offices to optimize print WAN traffic.

You can read further information on UPS by clicking here as well as Thomas koetzing’s FAQ

Installed correctly?

With the release of Citrix Universal Print Server, Citrix released a new KB article which clearly describes how to check whether Citrix Universal Print Server has been installed and enabled correctly on your XenApp 6.5 HRP01 environment and would like to share with you

  • The Universal Print Server feature comprises a client component – Universal Print Client (UPClient) that needs to be installed on the XenApp server along with Hotfix Rollup Pack 1 (HRP01) that provides the necessary updates implementing support for the UPS. When installed, the two items will appear in the installed programs list in the server Control Panel->Programs->Programs and Features

Note: The Citrix Universal Print Server package also contains Group Policy Management software that Administrators can install on the system from where they wish to manage the UPS policies. It can be a XenApp server (see Citrix Group Policy Management (x64) item).

  • After configuring the use of the UPS and the Citrix Universal Print Driver (UPD) in the relevant Citrix policy rules:

scription: UPS comp policies.png

Review the following registry locations on the XenApp server to verify the implementation:

scription: Ups enable reg3.png

scription: Ups enable reg2.png

In this example, value 2 indicates UPS has been enabled with no fallback to Windows native remote printing.

Installing the UPClient software modifies the print provider order list to be as expected.

escription: Untitled.png

The Citrix universal printing provider module filename and location can be checked here.

  • It is also possible to verify if the Citrix UpProv.dll is in use and loaded into the Print Spooler by issuing the following command in the command line window.

tasklist /m /fi “imagename eq spoolsv.exe”

scription: E:UPS Screen-shotsSpooler loaded dlls.png

Here’s the link to the original document.

Citrix VDI-in-a-Box – 1030 Connection Error


Was helping out a friend with a deployment of Citrix VDI-in-a-Box for their company.  After setting up the environment we kept receiving a 1030 Connection error when accessing the virtual desktops from an external connection which utilized CAG 5.04.  After thinking that some ACL in the firewall was missing and waited around for the network folks to return emails, I noticed a very important step you need to configure inside vdiMgr.

Checked all the usual places
  • Is the STA generated from the vdiMrg in the CAG.
  • Used an SSL checker to see if the SSL was created correctly.
  • Checked that the vDesktop DHCP range is in the ICA access control list on the CAG.
  • CHecked that the correct ports are opened up on the firewall.

I found the issue by looking at the default.ica file from WI, and noticing the “Internal HDX gateway IP Addresses” is wrong inside the ICA file and seeing if it has been marked with the internal IP address.

If you log in to the vdiMgr console and go to advance properties and look under gateways ensure that you have specified the “Internal HDX gateway IP Addresses” which HAS TO point to the internal IP address of the CAG.

Server Name Indication (SNI) and SSL VPN

Been working a lot around PCI Citrix initiatives for the last couple of months.  After speaking with some very smart Citrix NetScaler folks, they were kind enough to provide a lot of information to me around security and SSL VPN which I am sharing with you.  Take notice that Windows XP and IE 7 is not supported and it puts so many companies at risk.

Many People are unfamiliar with Server Name Indication (SNI).  In a nutshell, when client computer browsers or SSL based VPNs are negotiating encryption with a server, there is no information which can be gleaned by the server in order to determine which virtual host the client is actually requesting.  This is due to the fact that the HOSTNAME of the subsequent request is contained in the encrypted header which would not be visible until after the received data was decrypted as it made its way down the stack.  This is problematic with respect to virtual hosting since each server or appliance can serve many hosts through the same address.  If it is desired to secure the data of that host through SSL, then a 1:1 mapping of hostname to IP address is currently required (not so good)

Client: (TLS Handshake) Hello, I support XYZ Encryption.
: (TLS Handshake) Hi There, Here is my Public Certificate, and lets use this encryption algorithm.
: (TLS Handshake) Sounds good to me.
: (Encrypted) HTTP Request
: (Encrypted) HTTP Reply

What about ‘STARTTLS’ or TLS ‘Upgrade’ in HTTP/1.1?

STARTTLS is another standard which is commonly used by protocols such as SMTP, POP, IMAP, and LDAP.  Back in the day, it was common practice to have parallel secure ports for most protocols.  For example,  with SMTP, POP, IMAP, and LDAP, and HTTP you have 25/465 110/995 145/993 389/636, and 80/443 respectively. The idea of  STARTTLS was born when the IETF which governs internet assigned numbers and ports decided back in 1997 at some meeting that the issuing of paralell “secure” ports for all protcols should be depricated.   With STARTTLS, when the connection to the server host is established, the client sends a plantext command with the virtual host name.  This has enough information for the server to decide which certificate to offer for the SSL/TLS handshake.

Client: (TLS Handshake) Hello, I support XYZ Encryption.
Client: (Cleartext) I am using server ‘access.mycompany.com
Server: (Cleartext) By The Way, I also support TLS Encryptionn.
Client: (Cleartext) Lets use Encryption, aka ‘STARTTLS’.
Client: (TLS Handshake) Hello, I support XYZ Encryption.
Server: (TLS Handshake) Hi There, Here is my Public Certificate, and lets use this encryption algorithm.
Client: (TLS Handshake) Sounds good to me.
Client & Server: (Encrypted) Exchange Data
 A similar method for web browsers, and SSL VPN clients was derived in the HTTP/1.1 specification and is called TLS Upgrade. HTTP/1.1 TLS Upgrade method can be applied to upgrade an open HTTP connection. In a nutshell, the client would include this in a request:
GET http://access.mycompany.com/securestuff HTTP/1.1
Host: access.mycompany.com
Upgrade: TLS/1.0
Connection: Upgrade
The server in turn might respond with:
HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
The main benefit with these methods are that you can have both naked and secure traffic traversing through the same  port.  Main problems to this and likely why these methods have not been adopted are that all methods would require that any proxy servers in between the client and server also support this method.  A proxy server that did not acknowledge it or perhaps strips the command (could also happen on a legacy firewall), would potentially present a man-in-the-middle attack.  A lesser issue might be that you have a user perception issue as there is a certain familiarity with port 443 being the “secure” port.  On the server end of things, you would also need to have the unsecure port open for the application in question which may not be the case.

The Solution

An extension to SSL/TLS called Server Name Indication (SNI) addresses this issue by sending the name of the virtual host as part of the SSL/TLS negotiation. This enables the server to bind the correct virtual host early and present the browser with the certificate containing a CN matching that in the SNI header.  This method also has far fewer complications associated with it as compared to TLS Upgrade or STARTTLS.  The SNI extension is described in gross detail here. With SNI, you would have a sequence like:

Client: (TLS Handshake) Hello, I support XYZ Encryption, and I am trying to connect to
Server: (TLS Handshake) Hi There, Here is my Public Certificate, and lets use this encryption algorithm.
Client: (TLS Handshake) Sounds good to me.
Client: (Encrypted) HTTP Request
Server: (Encrypted) HTTP Reply

But Don’t Browser’s and Servers need to support this extension in order for this to work?

Yup, that is the idea.  As with any RFC, extension, or modification you have to have adoption by the software developers, and hardware vendors which in turn are driven by the adoption or request of the technology by the IT community.  The latter is only done through education and practical application examples which is one of my main drivers for writing this blog post.  At the time of this writing, there are no known Remote Access Appliances which support this RFC extension.  Below is the list of known browsers, servers, and SSL application libraries which do support the SNI extension:



  • Apache with mod_gnutls or mod_ssl
  • Cherokee if compiled with TLS support
  • New versions of lighttpd 1.4.x and 1.5.x
  • Nginx with an accompanying OpenSSL built with SNI support
  • OS X 10.5.6


  • Mozilla NSS
  • OpenSSL
    • 0.9.8f – not compiled in by default, can be compiled in with config option ‘–enable-tlsext’.
    • Unreleased 0.9.9 is likely to include SNI compiled in by default.

Unsupported Operating Systems Browsers, and Libraries

The following combinations do not support SNI.

  • Windows XP and Internet Explorer 6 or 7
  • Konqueror/KDE in any version
  • Microsoft Internet Information Server IIS
  • Sun Java System Web Server
  • Microsoft.Net
  • Sun Java JSEE

What SNI could add to SSL-based VPN Solutions?

So what does this mean with respect to Remote Access Solutions such as Citrix Access GatewayF5 Firepass, or Juniper Secure Access remote access solutions?  The benefits of adopting support for SNI are wide an varying, but here is my first pass at a few:

  • Since the SNI would be presented to the access appliance before the SSL negotiation finalized, specific SSL policies such as supported cipher suites, could be bound to the session.   This would be useful where you needed to meet more stringent security requirements such as FIPS level 1/2 for specific hosts, or where you had a client application which used a specific type of encryption that you needed to utilize.
  • As cloud computing is becoming more prevalent, service providers are going to need a means to offer customers secure access to their applications and content.  Since many cloud services are based on anycast addresses (floating IP), CNAME records, and also servicing 1000′s of users, a 1:1 option for customer:IP is not practical or possible. SNI presents a cheap, workable alternative to having no secure offering.
  • Enterprises who wish to publicly expose their intranet or line of business applications securely may want to do so through a remote access appliance, but not want to allocate multiple public IP addresses.
  • Businesses who have only been allocated a single IP address and are using Port Address Translation (PAT) to serve up multiple applications.  This is actually pretty common since many businesses are provisioned with ADSL which uses DHCP assign IP addresses. Most companies use a remote access device as an all-in-one solution for outbound RNAT, inbound VPN, and line of business applications, and firewall.

Get every new post delivered to your Inbox.

Join 65 other followers