The VMware View 5.0 environment in the lab has been running well and has proven itself as an extremely reliable remote access replacement for the old Citrix Presentation Server 4.0 solution I had in the past. However, in an effort to address a licensing issue related to the View App for iPad demo environment, I managed to force both a pool and a single desktop from within that pool into a perpetually stuck state of ‘deleting’. In addition, the VM representing the desktop was gone, but I could see from within vCenter the parent replica for the pool still remained. I spent some time poking at it from several angles including the View Connection Server, the vCenter Server, and the View Composer Server. It became clear that the underlying issue was deeper, in a database perhaps, and couldn’t be resolved using the standard management tools VMware offers.
The issue isn’t an uncommon one and I quickly turned up familiar hits at VMware’s community forums spanning a few different versions of VMware View. The root cause is explained in VMware KB Article 1008658 which applies to View versions 3.x through 5.0.x:
This issue occurs if a table in the database has an incorrect data. It can also occur if the virtual machine name has been changed in the vCenter Server manually after the pool has been created, causing View Composer and vCenter Server to refer to the same virtual machine with different names.
The problem can largely be avoided by managing the View environment with the intended tool – the VMware View Administrator interface as opposed to making changes outside of View, such as using VMware vCenter.
![]() |
![]() |
Resolving the issue is outlined in detail in the KB article above. Follow the steps carefully and slowly in a production View environment. Identify and remove the offending pae-VM(s) from the ADAM database on the View Connection Server. Optionally remove linked clone references using SviConfig on the View Composer Server as needed. This step removes the rogue parent replica image.









