Category Archives: Server Virtualisation

I need your help Server Based Computing / VDI Experts!

Hi Guys and Gals. I’m currently fighting the good fight with Microsoft support and require your help and backing in order to close down a long standing bug in the Windows Explorer Shell.

As you are all aware, hiding the c: drive and restricting access has been a utility we use frequently in shared computing and VDI environments. Restricting this functionality removes views of the shared drive from users and adds a layer of security and complexity* to ensure the users in question have access to only what they need in order to do their jobs day to day.

*I’m not looking to argue the merit of doing this either, it really depends on the business case or environment to dictate whether this option is set. I’m NOT saying it should be done in every case.

We all know it’s not fool proof, there are certain ways for users to circumvent this layer and I particularly don’t want to discuss them here to give potential devious users a landing page for idea’s!

The problem:

Prior to windows Vista, when you hide the c: drive and an application requests access to a c: drive folder, be it from an “open save dialog” or otherwise, Windows detects this event knows that the folder is restricted and merely redirects them to the desktop which they can see then browse to where they wish to open or save a document. This has worked fine to memory since windows server 2000.

But with the changes to Windows Vista’s windows explorer, repeating the above steps will result in the following annoying, unnecessary and interrupting error message “This operation has been cancelled due to.. bla bla blah”:

noname

This issue can be easily recreated, simply hide and restrict the c: drive, then click start > run > browse… bang.

The more annoying problem here, is after the error message, windows simply redirects back to visible folder. In most cases this is the documents library. So the error message is simply poping up then reverting to the functionality seen in previous operating systems.

So to review:

  • Issue introduced in Vista / 2008 and above.
  • error message displays.
  • Previous redirect functionality is still there and occurs after ok is pressed.

To Microsoft!

Being a pedantic individual, along with my colleague we brought this to Microsoft support and somehow lost months in the conversation as follows:

  1. Microsoft then redirected us to RES Software.
  2. Who (although very nice about it) sent us back to Microsoft.
  3. At which point I got involved.

Now with the correct audience and suitable severity, this problem has been identified as “introduced in Windows Vista” as an “Added Security feature“. How an annoying pop up box, masking previous functionality is a security feature is anyones guess, but it’s bloody annoying…

We have raised this as a bug and have requested Microsoft to fix it. The change in question was deemed as large change or substantial change due to WIndows explorer being used by all of the operating systems and basically told, without significant backing, this change wont be implemented.

Bureaucracy and broken policies, yes but that doesn’t help my customer.

Here’s where I need you:

In order to bolster this change and fix an issue in our beloved operating systems for Server Based Computing and VDI environments I need to hear from you and your customers to confirm they have had this issue, or currently face the issue and wish for a fix.

  • If you are a customer and suffer this issue, email me.
  • If you are a consultant and have customers with this issue, email me.
  • If you or your customer have enterprise support with Microsoft, I ESPECIALLY want to hear from you.

What’s in it for you?

Microsoft have provided us a work around, as a process that watches window messages and suppresses this dialog box when it occurs. If you get in touch, I’ll recompile this application with Microsofts permission and pass it on to you for use in your environment while we get “The Man” to fix it!

This fix is a bit of hack, as it’s scraping window messages but it’s light weight and scalable. Use this process for now and I’ll provide you with updates on a fix as and when I get them.

How do you contact me?

Please drop me and email on andrew{at}andrewmorgan{dot}ie with the following information:

  • Customer name:
  • Affected users:
  • Has enterprise support: (yes/no)

Once I have that information, I’ll send you back an executable via dropbox and keep you updated on the call process. This information is merely going to be fed straight to Microsoft with my personal guarantee of confidentiality. No funny business.

If you can’t share customer information, but have suffered this issue in the past, no problem! Please comment on this blog post the number of seats that were affected and roughly how many times you’ve seen it.

That’s it!

Thanks for entertaining my request for help and hopefully you too want to get this issue fixed as much as I.

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

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?