Search This Blog

Thursday, February 17, 2011

VMWare View 4.5 - Ensure Proper Timing on all Connection Brokers to Avoid JMS and AJP Service Failures


I have ran into several issues involved with View Messaging services JMS and AJP failing with a variety of issues. Today I noticed one of my View Connection Managers (4.5) stopped working due to AJP service stopped working. Error was "Event ID 104  - Failed to Fetch AJP Service".

The underlying cause seems everytime seems to be the affected server's clock source is skewed by more than an hour from the other View Connection Manager servers.


Ensure all your VM's are timing from the same source. Domain Controllers, NTP servers, etc... or change the setting in VMWare tools to "Sync with ESX Hosts" on each VM and ensure your ESX hosts are timed correctly. During View Manager installation procedures, the installation will fail if your clock sources are skewed, but that does not stop anyone from changing the source after the fact or the clock source is invalid.

If the View service fails, change the clock to the correct settings and you will need to restart the Windows server to ensure a clean start up of the View Manager services.

Wednesday, February 16, 2011

VMWare View 4.5 Provisioning Failure - "LDAP Error code 51 .... problem 5001 (BUSY)"


Now that VMWare View Clusters are growing into the 100's+ (even 1000's+ in some cases), provisioning new desktops or re-composing existing desktop pools can cause issue with overloading your vCenter. I fully recommend having a dedicated vCenter for VDI Desktops and a dedicated vCenter for Servers, but that is for another day. I have observed this in vCenter clusters managing around 1000 VM's (200+ Servers and 700+ Desktops). All the VDI Desktops are Floating (non-persistenet) and refreshed after logoff, so pretty active cluster.

Other that that, overall perfromance is awesome. (yes, another post coming on observed performance with VMWare View 4.5)


If during provisioning of your View Environment, you receive the "LDAP error code 51...problem 5001 (BUSY)" error message, there are a couple of options to perform:

1) Change the setting in your View Desktop Pool "Stop Provisioing on Error", just uncheck the option. This will not stop the provisioing, but will generate an event; or
2) Reduce the number of concurrent Power on and Provisioing limits in View Manager Advanced settings for vCenter. Defaults are 8 and 5.

  • Cloning failure
The pool manager disables provisioning when it encounters an error when cloning a virtual machine. This error message is displayed in the desktop's overview page.  
The following two log messages indicate that the VirtualCenter has been overloaded. Try reducing the provisioning and power operation limits for that VirtualCenter in VDM:
LDAP: error code 51 - 0000200E: SvcErr: DSID-02080499, problem 5001 (BUSY)
No disk space: Insufficient disk space on datastore 'm81 sdb (1)
The following log messages indicate a connection problem. Make sure you can connect to the VDM Connection server/VirtualCenter server.
WARN  <PendingOperation-/flat-dc/vm/bignp2/bignp2-5> [ServiceConnection] Problem while performing VC operation: '(0)null' [org.apache.axis.AxisFault] Message: (0)null
WARN  <PendingOperation-/flat-dc/vm/bignp2/bignp2-2> [ServiceConnection] Problem while performing VC operation: ' Connection reset' [org.apache.axis.AxisFault] Message: ; nested exception is: Connection reset Cause: Connection reset
The following message means that VirtualCenter has been overloaded. Reduce the number of concurrent operations allowed for that VirtualCenter.
WARN  <PendingOperation-/flat-dc/vm/bignp2/bignp2-4> [ServiceConnection] Problem while performing VC operation: 'Permission to perform this operation was denied.' [com.vmware.vim.NoPermission]

Monday, February 14, 2011

Unable to connect from the View Client on Windows 7 to the View Connection Server after installing the patch in Microsoft Knowledge Base article 2482017 or 2467023

Follow this link for complete details. Just ran into this issue:


  • Unable to connect from the View Client on Windows 7  to the View Connection Server
  • Connecting the View Client on Windows 7 to the View Connection Server fails
  • You have installed one or both these Microsoft patches 2482017 or 2467023


This issue occurs when you have installed one of these Microsoft patches, 2482017 or 2467023.
If you have already installed these patches, you can install VMware View Client (build 353760) or uninstall the Microsoft patches.
If you have not installed these patches, delay the installation of the Microsoft patches until you have installed VMware View Client (build 353760).
VMware View Client build 353760 has been tested on: 
  • Windows 7 Enterprise 32 bit +  Internet Explorer 8
  • Windows 7 Enterprise 64 bit +  Internet Explorer 8
  • Windows 7 Home 32 bit +  Internet Explorer 8 
The View Client patch can be downloaded from here. Enter your credentials, accept the EULA and download the appropriate file:
  • If you are using Windows 7 32-bit, use VMware-viewclient-4.5.0-353760.exe.
  • If you are using Windows 7 64-bit, use VMware-viewclient-x86_64-4.5.0-353760.exe.
Note: If you are using View Client 4.0.x and are experiencing this issue, you can install the appropriate View Client 4.5 for your environment.
Disclaimer: Using Windows 7 with a View Client 4.0.x is not supported. This information is provided as-is and without testing.
To apply this patch: 
  1. Click Start > Settings > Control Panel > Add or Remove Programs.
  2. Choose the previously installed VMware View Client and click Remove.
  3. Navigate to where you downloaded VMware-viewclient-xxx-4.5.0-353760.exe and run the executable file.
  4. Follow the installation wizard to complete the installation.
  5. Reboot the computer.
Note: VMware View Clients with build number 353760 or later are not affected by this issue.
Note: The preceding links were valid as of February 8, 2011. If you find the links are broken, please provide feedback and a VMware employee will update the link.

Thursday, February 3, 2011

VMware View 4.5 - Repurpose your old computers to View Based Thin Clients


As the Virtual Desktop revolution is swinging into high gear, there is a glaring issue of what to do with your existing PC's that still have some value. The View VDI solution is agnostic to end user devices allowing connections from Windows, Linux, and Mac OS's along with smartphone plug-ins (Wyse Pocket Cloud and VMware app coming soon). Sooo the big question is what to do with your existing PCs and notebooks that still have investment value.


There are several options out there to repurpose existing computers, but there several concerns around continued OS maintenance, updates and power consumption with using existing computers. Thin clients are a valid option for PC refresh cycles, since Thin Clients draw around 12 KW/h vs. traditional desktops that draw around 80-100 KW/h. However, the cost of thin clients that support advanced protocols like PC-over-IP cost about $300-400 per device, which is about the cost of a new PC these days, so the power consumption is the "green" tipping point for decision makers. Actually, the power money savings alone for 500-1000 desktops can more than justify a Thin Client for PC replacements. I have one customer in production estimating $50K saving from 8 months last year for 400 desktops replaced with thin clientsJ Thin Clients in general will be discussed in a later blog post, so I will not delve into that area right now.

I want to focus on two (2) solutions that I find work really well for re-purposing existing compute infrastructure. My recommendations are always based on MSRP (Manageable, Scalable, Reproducible and Predictable) architectures, like View vs. Citrix. You know my stance on that.

The first solution is a windows based application call ThinLaunch ( that will completely lock down the windows OS and only launch the View client to connect to the View broker(s). This is a great cost effective solution that is a “Trojan” type approach to lock down the desktop; multiple OS support (XP/7 and even 2000) and no need to apply any updates to the existing OS. It has a very small footprint and overhead and personally has been a big hit with my customers so far. You can purchase this directly or through my company (I will provide training and support) and can be purchased in small quantities. Please refer to ThinLaunch website for technical details or email me through this blog for more information.

The second solution that a really like is a new product from Wyse called Wyse PC Extender ( This is a SUSE Linux based solution that utilizes the Wyse Device Manager control for a "Vonage VDI" type solution. By using DHCP tags and FTP server(s), the end devices can be auto configured and updated with little or no hands on after setup. All devices are controlled by Wyse "ini" files and customization is very easy after setup. Some of the issues at this point are the lack of end device support and minimum quantities the end user must purchase in blocks of 1000. Below is the current list of supported end user devices, but I have this working on some older HP laptops, but had to install the network drivers to get working for SUSE Linux:
  • Dell Optiplex GX170
  • Dell Optiplex GX 270
  • Dell Optiplex GX280
  • HP 7900
  • HP D530
  • HP 7900
  • HP DC5100
  • HP 5150

Like I stated earlier, there are several other options out there, home-grown and commercial, but I always look at the MSRP value of sundry solutions because at the end of the day MSRP="Cost Effective":)

For more information, please research the technology websites listed or send me an email and we can discuss further.

Wednesday, February 2, 2011

VMware vSphere HA Error – “cmd addnode failed for primary node"


I have ran into this problem since ESX 3.5 and vCenter 2.5 and is still present today in vSphere 4.1 HA configuration. I have had several clusters initiate HA events today due to bad weather in our region and rolling black outs. 90% of the clusters recovered without errors, but some of them had the HA failure with "cmd addnode failed for primary node". All VMs came back and this is more of a minor issue, but still not clean.

I believe the race conditions with HA recovery and and cluster monitoring may be an issue.


I tried to use the "Reconfigure HA" from the vCenter options but failed continuously. I found out the method of just removing and adding HA to the cluster fixed the issue. I will be submitting this again to VMWare for resolution.

VMWare View 4.5 Success Story - Texas Public Schools


This is our latest success story around our end-to-end VMWare View implementation. Just one of many more coming down the pipe.

The only parts missing was the use of Solarwinds and ThinLaunch ( software for monitoring and re-purpose/lockdown PCs and Laptops.