Location of the Default.ica file in Citrix VDI in a Box.
Just in case you wondered, or need to configure options not available in the admin gui, the default.ica file can be found under the following path:
/home/kvm/kvm/install/servlet_container/webapps/dt/WEB-INF/etc/proto.ica
Disabling HTTPS redirection for Citrix VDI in a Box web access.
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
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
Introducing ThreadLocker. A community tool for granular control of processes.
Throughout 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.
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
- Threadlocker Requires .Net Framework 3.5 sp1
Download:
Citrix extends XenApp support, IGNORE IT! you should still upgrade!
As I’m sure you are all aware, Citrix made the bold move last year to mark XenApp 4.5, 5 and 6 end of life between March and July2013. This meant that support for these products was quickly expiring and it caused quite a bit of controversy from experts and concerned customers alike.
Well it seems the controversy has won out and Citrix have now decided to do a “Whoopsie” by extending support XenApp 4.5 and 5 well into 2015. And just to make the matter incredibly infuriating, this extended support for 4.5 and 5 will only be made available via chargeable Extended support.
This is one of those good news bad news situations. Great! customers with XenApp 6 can leverage their investment in a *cough* Beta *cough* product, but now previous platform customers have been extended more confusion?
I suppose before I get into my rant, I should justify why I dont appreciate this move:
Shawn Bass wrote a great article on this move and I’d highly recommend you give this a read, Shawn did have a concern about current XenApp 6 customers, but on the plus side this notification has brought end to his concerns…
I also contributed to an article on TechTarget recently supporting Citrix for this bold and (In my opinion) smart move.
Even just looking at Citrix’s current support model, they are currently standing over four products: (XenApp 4.5, 5, 6 and 6.5), across three base operating system flavours: (2003, 2008 and 2008 R2*), across two architectures (x64 and some x86) and all the while trying to develop new solutions.
* I consider 2008 R2 a separate operating system to 2008, its that much better.
Even from the simplest of view points, the level of consideration to any hotfix, new feature or change to their products must be a complete nightmare for their teams.
Dropping support of their older platforms, to me anyway, indicated their desire to move their customers to next stepping stone and give them the ability to focus their efforts on Server 2008 R2, x64 architecture and the upcoming server 2012 release later this year.
This move was brilliant in my opinion, as it would rid them of support, patch and development of dying platforms to free up their own internal resources to work on improving current products (hopefully), not to mention developing new and complimentary services to their Flexcast design.
I mean, its not like they currently have the resources to pour into their current products! Just for a minute, look at these offerings below in the XenApp platinum suite and honestly ask yourself if you think they are A: finished or B: living up to their potential:
- Citrix Workflow Studio
- Citrix Power and Capacity Management
- Citrix Single Sign on
- Citrix Smart Auditor
- Citrix Edgesight for Load Testing
So with all this in mind, why am I against this recent turn around? and more importantly, why should you still upgrade?
1: The customers decision to upgrade is now more difficult.
This turn around from Citrix isn’t going to stop you (the customer) from migrating, its just noise and confusion while you try to work out how much this extended support is going to cost.
And even if you have have one or two applications that plain wont work in x64, well leave them on the old platform and deliver them to the new, Citrix technologies are particularly good at that! Ultimately, support is only needed if you have a problem.
2: Professional Citrix integrators will have their time-lines for upcoming projects thrown into disarray.
Any current Citrix integrator probably took the “mass end of life announcement” as a good oportunity to contact their customers and offer assistance for upgrade and redesign of the customers current XenApp environment.
These upgrade plans are now going to be delayed if you (the customer) gets caught up in this change of support and contacts your reseller for pricing, dont pay any more for a platform that’s not getting any better.
My honest advice to you, don’t hold up on your own upgrade plan or another customer may take your timeslot. If this does happen, you may be forced into paying for extended support, while migrating at the later point in time, that you were pushed to for delaying now.
3: Sadly, it’s wasted resource from Citrix.
As I mentioned above, Citrix is giving itself a bit of a track record for releasing unfinished products or products not matching their potential.
If the uptake of the extended support is great enough, the free up of resource I mention above will not be as great. Meaning these potentially great products will continue to flounder, fail to deliver or be dropped like poor old EasyCall.
If you are really looking to Leverage your investment in XenApp licensing, upgrading now will deliver more to you in the long run.
4: I’m running XenApp 6, Should I still upgrade?
Firstly, my condolences, only those who early adopted XenApp 6 really know how bad it was, before the 100+ hotfixes. But I promise, XenApp 6.5 is much better.
Upgrade when you can, your upgrade will be fairly simple and you now have less urgency to do so. A few companies I’ve spoken to that early adopted XenApp 6, managed to do their production upgrades over a weekend after some testing.
5: Ultimately, The sooner you upgrade, the better.
If you are on XenApp 4.5 or 5. It really is time you looked to upgrade anyway. With Server 2012 due out this year you are only furthering the gap between your current implementation and the latest and greatest incarnation.
- Server 2003 is nine years old and due to expire itself in 2014. It looks and feels dated just like XP.
- Server 2008 is Windows Vista’s step brother. They’re both as bad as each other.
- x86 on Windows Server is a dying breed, x64 platforms can do so much more.
At the end of the day, your upgrade should already be under-way, if it’s not, start planning ASAP and only fall back on the “payed for” support if you are stuck with a show stopping issue this time next year.
The curious case of slow communication between Xendesktop DDC and VMware vSphere.
Here’s a weird one I came across recently. During a recent XenDesktop proof of concept I noticed the XenDesktop Desktop Delivery Controllers communication with the hypervisor was at best sluggish.
When the DDC’s attempted to communicate with the vSphere SDK the task would take at least 60 seconds. While it was hanging we’d be presented with the following bar looping repeatedly:
Commands sent to vSphere were also very slow, with an average of 30 – 90 seconds between sending a command to the command actually being processed.
While trying to troubleshoot this issue, I ran a “Netstat -ban” while attempting to perform a hypervisor related task and was greeted with the following information:
To my suprise, as you can see above the Citrix SDK management utility (running as the network service account) was sending all requests through a proxy server! Even more strangely, no proxy server issues were encountered anywhere in the environment to explain this delay.
Using “BitsAdmin /util /GetIEProxy NetworkService“, i was able to confirm the proxy configuration was affecting the network service account as below:
Upon further investigation, a default domain policy was applying the “Automatically detect sessions” flag in Windows proxy configuration as below:
This setting was vital to the customers setup, but conflicted badly with XenDesktop. As access to the proxy was not an option, I set about disabling this proxy option for the network service account.
To disable the proxy setting in server 2008 R2 for the network service account, i used the following command:
BitsAdmin /util /SetIEProxy NetworkService NO_PROXY
To double confirm the proxy was now configured, I tried “BitsAdmin /util /GetIEProxy NetworkService” and was presented with the following information:
Once this was in place, I performed a quick restart and XenDesktop began to blaze along as expected.
Weird eh?
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!
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!
Enabling Remote Desktop access to a Windows Server 8 Core machine.
So when you install Server 8 Core by default, Powershell Remoting is configured and a firewall rule is enabled to allow communication, But what if you still need RDP access?
Here’s a quick script that will enable RDP access to Server 8 Core and configure the firewall appropriately.
You can run this from a powershell remoting session, or via the console:
(Get-WmiObject win32_TerminalServiceSetting -Namespace root\cimv2\TerminalServices).SetAllowTSConnections(1)
import-module netsecurity -ea stop ; Get-NetFirewallRule | ? {$_.displayname -like "remote desktop*"} | Set-NetFirewallRule -enabled true
Profile:
Donate:
Recent Comments