Tag Archives: VDI in a Box

Citrix Personal vDisk Image Inventory, a potential solution to the golden image nightmare?

While at Citrix Synergy in Barcelona this week, I attended the Citrix Personal vDisk deep dive session. The session was interesting and informative but there was a mention of the inventory and scanning piece of the personal vDisk suite that really got me asking myself “what if?”.

From my understanding of the presentation, when you add a revision to the golden image, Personal vDisk scan’s both images then compares these items to the personal vDisk in an attempt to figure out which bits belong in the vDisk and which bits belong in the base image.

If you’ve read my previous blog post on golden image management with PVS (questionable assumptions and why I don’t trust people), you know I have a great fear with auditing and control of this image. Without having to read the old article, it basically translated to “Provisioning server is great, but I don’t trust people to audit and document the changes they have made to the golden images”.

While sitting in this session, I had another “lightbulb moment” . If the Personal vDisk has baked in technology that audits the changes to the golden image layer and registry, could it be extracted from personal vDisk? If so, wouldn’t this give you a granular view of changes to the golden image from point to point? I.E. a list of changes between snapshots (MCS) or versions (PVS)?

The more I think of it, the better this idea sounds. Imagine having a catalog of changes, searchable for file or registry key names that would help you track back changes, or even view changes made to the golden image to be reviewed before or after you seal the image? This technology would work well with Citrix Provisioning server, XenClient and Machine Creation Services, delivering a matrix of changes to the golden image.

I can’t see wrapping a gui around this auditing as being a challenge, this is Citrix we’re talking about! and as Citrix has mostly adopted Microsofts vhd file type, it would be a single image type to scan.

For me, this would address my concerns with moving most implementations from automated installs, to snapshot mechanisms while still achieving auditing and a deep view of the changes to the file system.

So Citrix, please consider this approach, it would be an immediate value add and put your image management head and shoulders above your competition.

So what do you the readers think? Would this give you more confidence of changes by others? Do you see this technology and a post change report as an extra safe guard on change management?

Thinkiosk 2.2.1 is now available.

Just a quick update to address a few bugs found in ThinKiosk 2.2.

ThinKiosk Updates:

  • ThinKiosk will now better handle url’s typed incorrectly (i.e. two full stops) Thanks Geert.
  • ThinKiosk will now correctly supress script errors, Thanks Dane / Igor.
  • ThinKiosk will no longer allow you to specify a url on first launch, as it was close to impossible to correct due to policy settings.

Offline Configuration tool

  • The Offline Configuration tool will no longer allow non administrators run the application when UAC is turned off.
  • The Offline configuration tool has been updated to include an option to log off the desktop when a remote session ends.

Caffeine integration is still not quite finished, so expect it in 2.3.

ThinKiosk development has taken quite some time and it takes time to support you via email. If you use ThinKiosk in your environment or appreciate the savings its made for you, please consider making a donation to help me keep this project alive… I would really appreciate it! 

ThinKiosk, works well on Thin Clients too, apparently!

This was a bit of a revelation to me, but after thinking about it, it makes perfect sense and I feel a bit naive for overlooking this use case originally!

Before I launch into my little discovery, here’s something I want to share:

Since ThinKiosk was released in January, It’s been downloaded over 5,000 times and I have counted (only from those who have contacted me) that there are well over 10,000 instances running in customer environments to this day. Version 1 was released with just 700 lines of code and version 2.3 is just shy of 6,000. This is absolutely amazing to me, seeing an idea that I thought was a “Publish and Forget” blog post be embraced so passionately by the community. So for this, I just wanted to thank you guys for all your help, support and idea’s.

Anyway, back to it. While reviewing my emails recently, it struck me that there are many, many customers using ThinKiosk, not on old PC’s which I had written the program for, but on Thin Clients from top vendors… Now this doesn’t bother me one bit, as the more people using this tool the better, but why aren’t these people using Linux Thin Clients? I’m a large advocate of linux based thin clients in my day job, hell, they’re much cheaper, easier to manage and in most cases boot faster… Why choose Windows?

So confused and curious, I decided to perform a little poll on Twitter:

"Monday morning poll, why do you choose Windows based thin clients?"

And to my surprise, the feedback was great, below I’ve included the top reasons why community members choose Windows Thin Clients:

  • HDX Redirection (Aero, Flash, Printing, Scanning)
  • Better feature set on Windows / Future proof for upcoming features.
  • Central Management via Active Directory / Group Policy.
  • Driver support (proxy card’s, smart card’s)
  • Familiar User Interface.
  • Familiar support platform / Unified support platform / No in house linux knowledge.

So all this got me thinking, even with a list that long of why Windows based thin clients are preferred, why are these guys using ThinKiosk on out of box Thin Clients? Surely a paid for solution will be an end to end solution?

Well not really and why is this? Citrix receiver.

Citrix receiver for Windows (Previously the Program Neighbourhood agent) has been designed for published applications running inside of the users local desktop session, not for Thin Clients connecting to virtual desktops and this is very clear when you consider that Receiver will by default place your published desktop on the start menu or desktop of your session.

This approach will normally lead you to have to log the user into the Thin Client as themselves, which you would prefer to be locked down in the first place. This also leaves you with the challenge of how do you log them off after their desktop session has ended!

Sure Citrix have added some additional desktop related functionality along the way (Desktop Viewer) but even desktop viewer itself is designed for running inside a users session allowing the user to jump back to the local device via the home button.. which can’t subsequently be locked down sadly.

Citrix did also release the desktop lock tool, which is good for very small use cases, but lacks the functionality of multiple desktops, workspace control, user customisations etc… Hence why ThinKiosk came to be!

Thin Client vendor work around?

Most Thin Client vendors will allow you to present glorified shortcuts to ICA files on the desktop of the Thin Client device, or auto launch them on boot… But this approach eliminates the benefits of Workspace Control, XenApp preferencial load balancing and requires trickery to get pass through authentication to work… Not only this but managing these shortcuts in a multi desktop and multi language environment where users roam from country to country is a complete administrative nightmare!

But What about the web access products from Citrix?

Now the obvious alternative to the Citrix Receiver is the Citrix’s web access platforms… The web interface or Cloud Gateway, unlike the desktop lock, or ica files offers multiple desktops, workspace control, load balancing policies etc. You can also leverage web interfaces built in password changing feature for the user with them having to be logged in to the local device and even allow them to reset their own password or unlock their account with Citrix Single Sign on!

And the best part is? the users will already be very familiar with this interface if you have an access gateway or Secure gateway for remote access.

Aha! now it makes sense!

I accidentally provided an easy to use, unified access approach across all windows devices…and I feel blind for not seeing it before!

What ThinKiosk also accidentally addressed, was allowing this web access platform to be leveraged with ease, security and minimal configuration… from any windows platform, Thin Client or old pc.

So in short, I think this was the success story for ThinKiosk I hadn’t considered… so much so that I’ve changed my own approach and mindset for Linux based Thin Clients too, locking down a local copy of  Firefox and presenting the Web Interface or Cloud Gateway.

So if you’re considering rolling in windows Thin Clients for your current or next VDI project… Consider using ThinKiosk, it’ll save you alot of pain, will work seamlessly with all your clients (thin or fat), and will save you time in management in the long run!

Caffeine for Citrix Receiver!

Update: Caffeine 1.2 has been posted to include support for receiver 4.2 and above.

In this post I’m announcing a new little tool from my lab for managing power saving and screen saver settings while using the Citrix Receiver for windows. I’ve been using this tool for months, I love it and miss it when I use a workstation without this tool. I’ve also sent this out for feedback to a select few experts in the VDI market space and the feedback was very positive.

That being said, this tool will be welcomed by some (users) and hated by others (admins). I’m a bit torn about whether to publish it or not so if you want to add to the feedback drop me an email on andrew@andrewmorgan.ie.

A big thanks to Mike Stanley, Kees Baggerman, Simon Pettit & Dan Garcia for the feedback!

Caffeine will also be available in the next release of ThinKiosk.

The Mission statement:

Often when using the XenApp, XenDesktop or even Citrix VDI in a Box, double prompting for passwords from windows devices is both common and a pain in the backside.  When you’re local workstation locks out you need to re input your workstation password, then re input your password again in the remote session… irritating and unnecessary.

From a security perspective its necessary to configure a secure screensaver on their desktop in the datacenter to ensure any connecting device receives a password prompt when the user is idle a certain amount of time, but it can be a management nightmare to exclude users from receiving double password prompts from managed windows devices.

Removing the double password scenario:

This issue extends from desktops, to laptops and to thin clients too and it often bugged me how often I spent entering my password twice each day.

With Caffeine for receiver, you  install a lightweight application that runs in the system tray. This application automatically attaches to Receiver sessions (via the ICA Client Object) and sends a keep alive every minute to ensure the remote screen saver never kicks in. Leaving just the local secure screensaver to lock the users out.

This works really well from Enterprise devices with double screensavers or home devices that are secure by default. This also allows you to keep your secure screensaver policies on the datacenter side and work around them from managed devices.

Sleep settings:

As a father, I struggle to find alot of time to work while my son is awake. Often I’ll start working on something and get dragged away for hours only to return to my pc asleep and my remote session disconnected and logged off due to policies. This infuriates me and I disable sleep on most of my devices for this reason… Which is costing me a fortune in electricity!

Further to just screensaving, Caffeine can also be configured to stop computers from going to sleep while a remote session is active. This will keep your pc awake when you are running a remote session if you need to step away but allow it to sleep when you don’t have a remote session… Best of both worlds!

If you still wish to use power saving while on battery, this is still available as above.

Wasted resource?

Well if I’m sending a keep alive from my enterprise device this means the sessions will never reach enough of an idle timeout to satisfy idle timeout policies. Which from an admin perspective mean’s these sessions will never terminate unless the remote machine is restarted.

With Caffeine you can configure these idle time-outs for managed devices via the settings (above) or via GPO meaning you can mirror your idle time-out settings…and dare I say feel confident they’re work reliably for once!

But.. but.. but.. security!!! We can’t have users turning off their secure screensavers!

Well, yes. This is the conflict of interest here, users want it and the admins wont! In order to make Caffeine as secure as possible I’ve included the following options for enterprises:

Caffeine requires administrative permissions to install:

By default only administrators of their local machines will be able to install Caffeine.

Enterprise Kill Pill:

Caffeine has a “Kill Pill” built in, you can download the enterprise GPO to stop Caffeine from working on your devices.

Secure screensaver requirement:

By default caffeine will only work if a secure screensaver is present locally. If the user attempts to remove the screensaver after login, they will be alerted and Caffeine will no longer keep the sessions alive:

Advanced Access Control.

Using Advanced access control with access gateway you can target machines running caffeine and exclude them from using your citrix environment.


The Caffeine for Citrix Receiver beta is now available for download.


  • .Net Framework 2.0
  • Citrix Receiver 3.2 and upwards.

Tested Platforms:

  • Windows 7 x64
  • Windows 8.1 x64



Caffeine for Citrix Receiver

Group Policy Template

Disabling HTTPS redirection for Citrix VDI in a Box web access.

Update: 22/08/2012 For VDI in a Box 5.1

One of my dislikes for VDI in a Box is the SSL redirection that takes place as soon as you attempt to log in to the web access portal.

SSL redirection I can live with, but the self signed certificate in VDI in a box can’t even be trusted and added as a known host due to the spaces in the name.

So, if you are doing a proof of concept and like me, can’t be arsed fighting with certificate import on these devices, here’s a quick tip to flat out turn off the SSL redirection for desktop logins.

Fire up winscp, and log into the VDI in a box appliance.

Navigate to /home/kvm/kvm/install/servlet_container/webapps/dt/web-inf

take a copy of the web.xml (you’ll thank me if you balls this up)

edit the Web.xml file and remove the highlighted section below:

Save the file

Putty / SSH to the device and issue a “tc_start” to restart tomcat

Note: For VDI in a Box 5.1, I’ve found early copies of the appliance didnt contain this command. If tc_start is not available, reboot the virtual machine via the console or web gui.

Now browse to the http address, tada! No more silly ssl errors.

NOTE: the admin console will still redirect, if you wish to disable this too, remove the following if statement from /home/kvm/install/serlet_container/webapps/admin/index.jsp