Tag Archives: Remote Desktop services

Creating an automated VMware Horizon RDS Pool with Horizon 6.2

 

horizonSo VMware Horizon 6.2 was announced at VMworld just a week ago and the one feature I sorely wanted to see was automated provisioning (golden image management) of a Microsoft Remote Desktop Services farm.

The provisioning process is fairly straight forward, so in this blog post I’ll walk you through the steps to avoid any issues.

Prerequisites:

  • Download the Agent, Connection Server and Composer software.
  • Upgrade your Connection Servers to 6.2.
  • Upgrade your Security Servers to 6.2 (remember you’ll need to repair with the connection servers).
  • Upgrade your Composer.
  • A Microsoft RDS server.

Continue reading

ThinIO facts and figures, Part 3: RDS and Ram caching.

logoWelcome back to the third instalment of this blog series focusing on our new technology ThinIO!

To recap, below you will find the previous articles:

Off topic note:

two years ago at an E2EVC event, the concept behind ThinIO was born with just a mad scientist idea amongst peers.

If you are lucky enough to be attending E2EVC this weekend, David and I will be there presenting ThinIO and maybe, just maybe there will be an announcement. Our session is on Saturday at 15:30 so pop by, you won’t be disappointed.

Back on topic:

So here’s a really interesting blog post. Remote Desktop Services (XenApp / XenDesktop hosted shared) or whatever you like to call it. RDS really presents a fun caching platform for us, as it allows us to deal with a much higher IO volume and achieve deeper savings.

We’ve really tested the heck out of this platform for how we perform on Microsoft RDS, Horizon View RDS integration and Citrix XenSplitPersonality with Machine Creation Services.

The figures we are sharing today are based on the following configuration and load test:

  • Logo_Login_VSI_TransparentCitrix XenDesktop 7.6
  • Windows Server 2012 r2
  • Citrix User Profile Manager.
  • 16gb of Ram.
  • 4 vCpu.
  • LoginVSI 4.1 medium workload 1 hour test.
  • 10 users.
  • VMFS 5 volume.

Fun figures!

Diving straight in, lets start by looking at the volume of savings across three cache types.

image001

 

Continue reading

ThinIO facts and figures, Part 2: The Bootstorm chestnut.

logoWelcome back! This blog post is part of a number of posts in advance of our upcoming release, for reference you can find part one below:

Getting right to it:

In this industry when somebody says ‘boot storms!’ – most of us will respond with:

image002

Boot storms are a well documented, boring problem and have many solutions available from vendors and hypervisors alike. Most solutions today rely on a ‘shared memory’ storage area to cache ‘on boot’, in theory caching only one startup or one pattern in order to then serve it back to the proceeding desktops to boot.

But why are boot storms an issue? While working on ThinIO we had the unique ability to really dive into the Windows boot process and analyse why boot storms cause the damage they do and in this post we thought we’d share our findings to better document the issue.

Continue reading

ThinIO Public Beta is go!

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.

Continue reading

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

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_MACHINESYSTEMCurrentControlSetControlTimeZoneInformation

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.