Here’s a fun little customisation if you grow tired of the green bubbles of gloom.
The background above is a png file, with the following dimensions:
- Height: 2048
- Width: 1056
So if you want to replace this file, go find your replacement picture and ensure your picture is of a similar enough size.
Once you have a png file with similar enough dimensions, open the finder application, open the applications folder and right click the Citrix Receiver app, choose “Show Package Contents”.
Browse down to: contents > resources
In this folder, you will find a file “backgroundImage_big_b.png”, before you start, rename this file to back it up.
Now simply copy your replacement file into this folder, using the above name:
And that’s it! You’ve now got a lovely custom Citrix Receiver:
PS: I wouldn’t try to do this with windows, the file is an embedded resource and would require resource hacker to change the file.
With great pleasure I’m announcing the general availability of ThinKiosk 3.1. Quite a bit of change under the hood and some nice features added to match.
VMware View enhanced support:
VMware View has gotten some love in this update, A big thanks to Jarian Gibson for the help.
You can now enforce end of session options for VMware view:
You can also now choose to wipe the last users details from the Kiosk between View sessions:
FTP policy management:
With ThinKiosk 3.1, you no longer are tied to manage the thinkiosk devices by Group Policy or local registry settings, you can now also use an ftp server with a shared xml configuration file:
Just configure a Device as you would like it to appear, unlock the admin menu and you can export the configuration to xml:
Then move it to your ftp server!
The unlock password in group policy can now be encrypted to save it appearing in plain text to anyone capable of viewing the policy. ThinKiosk 3.1 ships with a password encryption tool you can use to encrypt your password.
You can also test reversing the password to plain text to make sure you get it right before applying it en-mass and locking yourself out!
This encryption functionality has now been added to both the offline configuration tool:
And by default the FTP password will be encrypted too!
ThinKiosk is now aware of batteries in laptop devices and will report their status.
When the battery begins to run out, ThinKiosk will throw a warning in the foreground as below:
You can additionally disable this functionality with the offline configuration tool.
Pre launch Citrix Receiver:
A rare issue seen with the latest versions of the receiver was a bit of a hang, pause or complete lock up as receiver came to life. To combat this, you can now choose to early launch the receiver for Citrix, allowing it to gracefully start up in the background before the user requires it.
Early launch process:
A number of customers needed to have third party software launched as soon as ThinKiosk started each day. I’ve now added the ability to early launch a process
You can also choose to launch this process as hidden, away from the user.
ThinKiosk can now act as a locked down browser by adding back and forward buttons.
AM / PM clock:
This feature was asked for quite a few times, so now you can set the clock to 12 hour.
A fully fledged debug window has been added to help timing issues. The debug menu can be accessed via command line (-debug) or via the admin menu in ThinKiosk.
In rare situations (and I’ve been unable to reproduce it) ThinKiosk can jump above the citrix session when a log off of the web interface happens or during the login process.
Zorder awareness will tell ThinKiosk to send itself to the back of the Zorder when the browser finishes rendering. It will also display a hide button, which will send ThinKiosk to the back in this rare event.
Please use this setting as a troubleshooting tool, not a production setting. If this setting fixes the issue for you, please drop me an email and I’ll write it in. As I’ve been unable to reproduce this issue, it’s a bit rough around the edges.
Citrix Storefront timeout screen:
ThinKiosk is now aware of the timeout screen and will automagically redirect back to the login screen if it see’s it.
Hide ThinKiosk when a desktop is active:
If you wish to outright hide ThinKiosk while a desktop is active, you can now do so!
Even More sites:
Support for up to 20 sites has been added, thanks Martijn!
Sticky Home Page:
A request came through to allow the home page always be site 1, this has now been included.
- support for environment variables in custom tools and prelaunch commands. (thanks Nathan).
- Offline config tool not setting password correctly.
- VB Powerpack accidentally bundled with ThinKiosk 3.0
- In process launch mode, power options were intermittently being applied.
And it’s still free!
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 or paying for enterprise support to help me keep this project alive… I would really appreciate it as it will allow me to invest in better development tools to make the product look and feel even better!
Hello there, and thank you for dropping back for part 3…
I suppose I should start with the disappointing news that I have yet to test this option for VDI in a box. And despite Aaron Parker’s suggestions it wasn’t due to lack of inspiration, it was down to lack of time! This series has gathered allot of interest from both community and storage vendors alike, and I feel I should set the record straight before I got any further:
- This isn’t a production idea, you would be crazy to use this idea in a live environment.
- Throughout this entire project, we’re focusing on pooled stateless. Stateful desktops would be a separate post entirely.
- This wasn’t an attack on products in this market space, merely a fresh view on an old problem.
- If i had the skills or funds necessary to run this project to a production solution, I wouldn’t have posted it. I would already be hard at work creating a reasonably priced product!
Now that my declarations are out of the way, I’d first like to talk about the moral of the story. This isn’t an unfamiliar expression:
IOPS mitigation is not about read IOPS it’s about WRITE IOPS!
VMware, Citrix and Microsoft have similar but very different solutions for read IOPS negotiation. Similar in the sense that they try to negate storage read IOPS. But the key difference with XenServer is the local disk cache via Intellicache has the out of box functionality to cache the majority of read’s to local disk (think SSD*) without the baked in soft limit of 512 MB for Microsoft HyperV and VMware respectively.
Long story short, VMware and Microsoft’s solution is about 512mb of recognizable read IOPS negation un-tuned, but enabled. Of course this value can be tuned upwards, but the low entry point of cache would suggest, at least to me, that tuning up will have an upsetting affect on the host.
This to me is why IntelliCache has the upperhand in the (value add product) VDI space for read IOPS negation and they even throw in the Hypervisor as part of your XenDesktop licensing, so win win, but what about those pesky write IOPS?
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?
Welcome back to part two of this little adventure on Exploring the RAM caching ability of our newly favourite little file system filter driver, the Micrsoft Extended Write Filter. If you missed part 1, you can find it here.
So after the first post, my mailbox blew up with queries on how to do this, how the ram cache weighs up vs pvs and how can you manipulate and “Write Out” to physical disk in a spill over, so before I go any further, lets have a quick look at the EWF.
Deeper into the EWF:
As previously mentioned, the EWF is contained in the operating system of all Windows Embedded Operating systems and also Windows Thin PC. The EWF is a mini filter driver that redirects all reads and writes to memory or local file system depending on where the file currently lives.
In the case of this experiment, we’re using the RAMREG method of EWF. Have a read of that link if you would like more information, but basically the EWF creates an overlay in RAM for the files to live and the configuration is stored in the registry.
Once the EWF is enabled and rebooted, on next login (from an adminstrative command prompt) you can run ewfmgr -all to view the current status of the EWF:
So what happens if I write a large file to the local disk?
Well this basically! Below I have an installer for SQL express which is roughly 250mb, I copied this file to the desktop from a network share, as you can see below the file has been stuck into the RAM overlay.
And That’s pretty much it! Simple stuff for the moment. When I venture into the API of the EWF in a later post I’ll show you how to write this file out to storage if we are reaching capacity, allowing us to spill to disk and address the largest concern surrounding Citrix Provisioning Server and RAM caching presently.
Next up to the block. Machine Creation Services…
I won’t go into why I think this technology is cool, I covered that quite well in the previous post. But this was the first technology I planned to test with the EWF.
So I created a lab at home consisting of two XenServers and an NFS share with MCS enabled as below:
Now before we get down to the nitty gritty, let’s remind ourselves of what our tests looked like before and after using the extended write filter in this configuration when booting using and shutting down a single VM:
As with last time, black Denotes Writes, Red Denotes Reads.
So looking at our little experiment earlier, we pretty much killed write IOPS on this volume when using the Extended write filter driver. But the read IOPS (in red above) were still quite high for a single desktop.
And this is where I had hoped MCS would step into the fray. Even on the first boot with MCS enabled the read negation was notable:
Test performed on a newly built host.
At no point do read’s hit as high as the 400 + peak we saw in the previous test. But we still see spikey read IOPS as the Intellicache begins to read and store the image.
So now that we know what a first boot will look like. I kicked the test off again from a pre cached device, this time the image should be cached on the local disk of the XenServer as I’ve booted the image a number of times.
Below are the results of the pre cached test:
Well, I was incredibly impressed with this result… But did it scale?
So next up, I added additional desktops to the pool to allow for 10 concurrent desktop (restraints of my lab size).
Once all the desktops had been booted, I logged in 10 users and decided to send a mass shutdown command from Desktop studio, with fairly cool results:
And what about the other way around, what about a 10 vm cold boot?
Pretty much IO Free boots and shutdowns!
So lets do some napkin math for a second.
Taking what we’ve seen so far, lets get down to the nitty gritty and look at maximums / averages.
In the first test, minus EWF and MCS, from a single desktop, we saw:
- Maximum Write IOPS: 238
- Average Write IOPS: 24
- Maximum Read IOPS: 613
- Average Read IOPS: 83
And in the end result, with EWF MCS and even with the workload times 10, we saw the following:
- Maximum Write IOPS: 26 (2,380*)
- Average Write IOPS: 1.9 (240*)
- Maximum Read IOPS: 34 (6130*)
- Average Read IOPS: 1.3 (830*)
* Denotes original figures times 10
I was amazed by the results, of two readily available technologies coupled together to tackle a problem in VDI that we are all aware of and regularly struggle with.
What about other, similar technologies?
Now as VMware and Microsoft have their own technologies similar to MCS (CBRC and CSV cache, respectfully). I would be interested in seeing similar tests to see if their solutions can match the underestimated Intellicache. So if you have a lab with either of these technologies, get in touch and I’ll send you the method to test this.
What’s up next:
In the following two blog posts, I’ll cover off the remaining topics:
- VDI in a Box.
- EWF API for spill over
- Who has this technology at their disposal?
- Other ways to skin this cat.
- How to recreate this yourself for you own test.
Last up I wanted to address a few quick queries I received via email / Comments:
“Will this technology approach work with Provisioning Server and local disk caching, allowing you to leverage PVS but spill to a disk write cache?”
No, The Provisioning Server filter driver has a higher altitude than poor EWF, so PVS grabs and deals with the write before EWF can see it.
“Couldn’t we just use a RAM disk on the hypervisor?”
Yes, maybe and not yet…
Not yet, with Citrix MCS and Citrix VDI in a Box, Separating the write cache and identity disk from the LUN on which the image is hosted is a bit of a challenge.
Maybe If using Hyper-V v3 with the shared nothing migration, you now have migration options for live vm’s. This would allow you to move the WC / ID from one ram cache to another.
Yes, If using Citrix Provisioning server you could assign the WC to a local storage object on the host the VM lives. This would be tricky with VMware ESXi and XenServer but feel free to give it a try, Hyper-V on the other hand would be extremely easy as many ram disk’s are available online.
“Atlantis Ilio also has inline dedupe, offering more than just ram caching?”
True, and I never meant, even for a second to say this technology from Atlantis was anything but brilliant, but with RAM caching on a VM basis, wouldn’t VMware’s Transparent page sharing also deliver similar benefits? Without the associated cost?