Tag Archives: SBC

Announcing ThinKiosk 3.1

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.

New features:

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!

Encryption:

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!


Battery Awareness:

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.

Browser navigation buttons:

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.

Debug Mode:

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.

Zorder awareness:

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.

Bug Fixes:

  • 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!


On IOPS, shared storage and a fresh idea. (Part 3) tying it all together in the stack

Note: This is part three, have a read of part one and two.

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:

  1. This isn’t a production idea, you would be crazy to use this idea in a live environment.
  2. Throughout this entire project, we’re focusing on pooled stateless. Stateful desktops would be a separate post entirely.
  3. This wasn’t an attack on products in this market space, merely a fresh view on an old problem.
  4. 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?

Continue reading

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!

Introducing ThreadLocker. A community tool for granular control of processes.

 

ThreadlockerThroughout this blog post, I’m going to be talking about Process Affinity and Process Priority. Understanding these definitions will help. I’m also only targetting server 2008 R2 and Windows 7 for this post.

An issue I see time and time again in Virtual Desktop Infrastructure and Server Based Computing environments is CPU spikes cause sessions to pause and stick. These CPU spikes can be caused by overcommitment or overzealous application usage and the vendors (Citrix, ThreadMaster, RES, Appsense, etc) have come to the rescue frequently with tools to reduce these events from occurring.

The problem with these solutions (Appsense excluded) is they are reactive, I.E. they take a number of seconds to identify a spike and respond by dropping the priority of the process or reducing the Users time on the processor.

These few seconds of high usage, reduce the amount of time the users applications and desktop session can spend on the processor, this reduction of resources cause the VDI desktop of the user to be completely unusable during the pause and ultimately resulting in complaining from the user community. Worse yet, if this is an SBC environment you now have all users on that server locked out!

And all this may sound a bit over the top, but its very easy to reproduce. For example, create a Microsoft Excel sheet and attempt to vlookup over a few thousand cells and watch the processor get chewed up. In this example, yes a vLookup across that many cells would be better served from a server based solution, but what’s stopping your users doing it?… Exactly.

Looking at SBC for a second:

With Server 2008 R2, the Fair Share CPU scheduling feature really is best (free) solution out there for CPU Utilisation management. The processor scheduling is far better than the Citrix equivalent and they also offer a feature (albeit, it feels unfinished) called Windows System Resource Manager to configure the processor affinity along with Process soft rules for performance management.

By setting these extremely intensive Multi-threaded applications to an affinity, we can “Lock” these processes to only run on certain processor cores, allowing the remaining cores to rebalance the rest of the workload. This ultimately, leaves the users session still responsive even if the application no longer responds. Allowing the user to continue working in other application until the intensive process is complete.

The problem with Windows System Resource Manager?

  • It’s a pain to configure on more than one system
  • It requires (yeuck) Windows Internal Database
  • It has been marked as “Depreciated” in Server 2012
  • If a user changes affinity, Resource manager doesn’t re adjust.
  • It still suffers from “pauses” or sluggishness when the Cpu is really being hammered.
So we’re back at the start again, Fair Share CPU scheduling is still the best free product, but how can we cap processes to cpu’s or drop the priority of a “Known Intensive” processes like Excel to stop these pauses?
What about VDI:
Well, there is nothing out there that’s free, move along.
End result:

This was my dillema recently with both XenApp & Xendesktop. Ultimately not happy to Pay for a solution, embrace a depreciated tool, or wash my hands of the problem, I decided to write my own tool, complimenting fair share CPU scheduling but allowing affinity and priority locking.

Introducing Threadlocker:

ThreadLocker has been written to help you target known problematic processes and deal with them pro actively.

Threadlocker also has the added benefit of dropping the priority of known grunty processes to idle, meaning the process will use as much CPU as it can, but any other higher priority process can interupt without sluggishness or pauses.

With ThreadLocker you can target these processes and set their Affinity number of processors they can run on:

Or their Process Priority to drop them out of the normal running context:

  • Threadlocker is light weight and scalable.
  • Threadlocker works flawlessly with Cpu Fair Share Scheduling, so even if a process is “ThreadLocked” the users running those applications will fair share on the designated cores.
  • Threadlockers configuration is xml based and can be copied down to the machine with Startup script or Group Policy preferences.
  • Threadlocker can be used in VDI environments where no other free solution is available.
  • Threadlocker will re-adjust priority, or affinity if the devious user tries to remove the restriction.

Threadlocker has been successfully tested on the following platforms:

  • XenApp 6.5
  • Windows Server 2008 R2 Service Pack 1
  • Windows 7 x64 Service Pack 1
Requirements:
  • Threadlocker Requires .Net Framework 3.5 sp1

Download:

Here

ThinKiosk 2.0 Release!

It gives me great pleasure (and relief!) to announce ThinKiosk 2.0’s release.

Version 2.0 is a complete rework of the code as I adopted some standards, a big thank you again to Pierre Marmignon for taking the time to point me in the right direction!

Preview

ThinKiosk 2.0 is stuffed with new features and supported platforms, here’s a quick list:

  • Enterprise Software Support options.
  • New Supported VDI solutions.
  • Power Management.
  • Offline Configuration tool.
  • Custom Title.
  • Site selection list.
  • Custom tools menu.
  • Home Button.
  • Local Printer management.
  • Desktop Mode (log off the web interface when a session starts).
  • Auto log off redirect.
  • Best practice group policies settings.
  • Group Policy to lock down everything!

For full information on the changes, see the About and Features pages.

To grab a copy and start playing, go here: (note, recreate the group policies in a new OU)

A big thank you to my translators and Beta testers, there was just too many of you to mention!