Archive

Posts Tagged ‘Remote Desktop services’

ThinIO Public Beta is go!

September 15, 2014 Leave a comment

logoLets get right to it!

Warm up your labs or fire up your golden images ladies and gents, we’re delighted to announce ThinIO’s brief public beta will begin today!

This project has taught us some really interesting things about Windows IO, how Windows behaves and how the hypervisor and storage can behave. This project really felt like a David vs. Goliath task as we (members of our community with a desire to simplify this issue) attempted to tackle one of the largest issues in our industry, storage bottlenecks and Windows desktops.

What’s really unique about our approach is there are no hardware lead times, no architecture changes needed and no external dependencies. ThinIO can be installed in seconds and the benefits are seen immediately.

Read more…

Date and time shift when using Lotus Notes in Server 2008 R2 / XenApp

August 20, 2012 3 comments

This was an extremely strange / rare issue, so I figured I would share it.

In this customers environment, they are using XenApp 6.5 on Server 2008 R2 for published desktops, this environment is a hosted desktop environment for a number of countries in Europe.

Infrequently an issue could be observed where the users timezones would shift out by one or two hours within the Lotus Notes application. This would case SameTime conversations and Calendar times to display out by the aforementioned value above.

When this issue occurred, it happened to all users on the server. A restart of the server did not fix the issue.

Interestingly, a “TZUtil /g” was reporting the client was in the correct time zone:

If you ran “TZUtil /s GMT Standard Time“, then closed and opened Lotus Notes… The problem was resolved for that user, in that session until they logged off.

It’s worth pointing out, that this issue was only seen in Lotus Notes, not in any other application, java or otherwise.

When comparing the TimeZone settings from a problematic server to a working server, I found the following difference:

These keys are stored under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

And the working server looked as follows:

 

Now that is weird! So we copied the correct keys from the server to server and the issue was resolved. On all servers once users closed and opened Lotus Notes again.

But what caused this?

With a work around in place, I began to dig deeper into what caused the timezone to change on the servers despite the fact that no users have the ability to do so.

Analysing the logins to the servers, I spotted an administrator account logging into each of the servers as the day went by. This user didn’t log into the correctly working servers so this was the first clue.

Now if you’ve used Lotus Notes combined with XenApp and timezones before, you’ll know its a complete nightmare, interestingly the administrator in question (me, shamefully), was logging onto a XenApp session with a linux timezone to replicate an issue.

More embarrassingly, I then decided to Remote Desktop inside of the XenApp session to the affected servers, and with my admin account being who it was… inadvertently changed the timezone for the servers it seems.

That doesn’t sound right? You rdp’d from a client in a different time zone and it changed the server timezone?

I agree, but I have since been able to replicate this in a test environment. As with Server 2008 Microsoft now handle the timezone redirection themselves as part of group policy and administrative accounts will change the timezone of the server intermittently.

Now most customers probably wouldn’t even notice this, unless they are using lotus notes, as all other applications behaved correctly.

How do you work around this issue?

Ensure that the Group Policy you use to configure timezone redirection is configured to “not apply” to any local administrator on the XenApp server that may log in.

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

May 15, 2012 22 comments

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.
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

Removing Screen Resolution and Personalize shell extensions from a users desktop session.

January 16, 2012 11 comments

While working in a XenApp 6 proof of concept I came accross this little feature and decided its time to share it!

When a user right clicks on the desktop, by default they get access to commands to manipulate the appearance of the desktop. As I restricted access to the control panel, the two options below were generating errors in the users sessions:

The error generated is your standard group policy restrictions error message as below:

While digging into this further I found the following registry key that corresponds to the two prompts we see above.

HKEY_CLASSES_ROOT\DesktopBackground

Under this key, you can see both entries that appear on the shell extension menu;

The problem with this key is, its owned by the TrustedInstaller account, and by default administrators cannot modify it. To modify this  key and hide this menu from users (but maintain it for administators) please follow the below steps.

Please note, any hotfixes from microsoft may remove your hard work, so be prepared to redo this work if Microsoft decide to work with this key in future.

  1. Take a backup of this key, you’ll thank me if you get it wrong!
  2. Browse down to desktopbackground\shell\display
  3. right click this key, choose permissions, click advanced then owner
  4. Select administrators from the list, then choose “Apply”.
  5. browse to the permissions tab and remove the “users” group.
  6. Click “apply”, then “ok”.
  7. The “screen resolution” menu should now disappear from any current and future sessions.
  8. Repeat step 2 to 8 on DesktopBackground\Shell\Personalize.
  9. Tada! go grab a coffee to celebrate your domination over the windows operating system.

And that’s it, you should now have a lean, clean and  error free shell extension menu when right clicking on the desktop.

Pedantic, begrudging scripters note:

Now if you’re a pedantic scripting so and so like me, you wont be satisfied to leave this job as a manual task. And despite spending more time than I’d like to admit, I couldn’t perform this work in powershell despite what I tried. Luckily the task was extremely easy to do with Helge Klein‘s setacl program.

Below is an example of a script to achieve this:

setacl.exe -on HKLM\software\classes\DesktopBackground -ot reg -actn setprot -op dacl:p_nc;sacl:p_nc -rec yes

SetACL.exe -on HKLM\software\classes\DesktopBackground -ot reg -actn ace -ace “n:system;p:read” -ace “n:administrators;p:read” -actn clear -clr “dacl,sacl” -actn rstchldrn -rst “dacl,sacl” -rec yes