Home > Citrix, Server Virtualisation, Virtual Desktop Infrastructure, VMware, XenDesktop > The curious case of slow communication between Xendesktop DDC and VMware vSphere.

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?

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: