Tag Archives: vSphere

logo

Altaro VM Backup Review

logoWell you may be asking yourself what an EUC focused guy is doing reviewing a backup product, I’ll be honest, I wasn’t sure either but then something happened and I suddenly grew a strong appreciation for this product… but more on that later.

As one who still remembers (and has the scars) from those dreaded tape restore days to off site locations. I remember spending 72 hours + trying to restore machines to different hardware, struggle with different tape drive manufacturers and trying to find the right tape!  I jumped ship from sys admin long ago and moved to EUC, avoiding the backup market like the plague in later years so I really was a fresh set of eyes to this age old conundrum.

Recently I stumbled across Altaro VM backup as part of my usual day to day readings and my interest was piqued. Withstanding that as a home lab owner and a hypervisor snob I really only run vSphere and Hyper-V was normally not something I enjoyed working with… I got talking to a nice gentleman from Altaro and I was invited to join the closed beta for vSphere.

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?