VMware Horizon Community
Cannoli
Contributor
Contributor
Jump to solution

Manually Deleted Linked Clone VM's, Recreated but Composer Skipped Numbers

I did a huge rebalance after adding new datastores and all went well... until the last few VM's  It appears the account that View uses to communicate with the Composer database and vCenter Server was locked out (another story) so several VM's were partially rebalanced which caused them to be non-operational and couldn't delete them through the View Connection Server Admin console.

I removed the VM's from the ADAM database with ADSI Edit and removed the remnants from the Composer Database (the manual method).  I removed the VM's from Active Directory and from vCenter Server using the vSphere Client and by browsing the datastores when needed.

When I re-enabled the pool to provision, all the VM's were recreated but one VM number was skipped.  The pool is for 60 Win7VM's but VM7 isn't being recreated, it made a VM61 to meet the minimum of 60.

How can I force it to make VM7?  We are required to list all the computer names in a security profile and a gap in numbering will be a pain in the butt.  Not to mention my OCD will drive me crazy! Smiley Wink

Reply
0 Kudos
1 Solution

Accepted Solutions
dvhorvath
Enthusiast
Enthusiast
Jump to solution

I posted a response before I had carefully re-read your entire post. I think the key to this is the part where you say you "removed the VM's from Active Directory and from vCenter Server using the vSphere Client and by browsing the datastores when needed." While the ADAM and Composer databases had no remnants of the VMs left in them, it is possible that there is still some piece of VM7 left in the vCenter database that's causing Composer to see it as already there. I'm no SQL DBA, so I'm not going to presume to give any instructions on how to fix that, but if you have anybody there with the right knowledge and skills (or if you're such a person) you may be able to ferret out the offending record and get VM7 back again. It's someplace to start anyway. I hope that helps.

Dave

View solution in original post

Reply
0 Kudos
4 Replies
uday_s
Enthusiast
Enthusiast
Jump to solution

Did you try changing the naming pattern used for the desktops?

Reply
0 Kudos
dvhorvath
Enthusiast
Enthusiast
Jump to solution

I posted a response before I had carefully re-read your entire post. I think the key to this is the part where you say you "removed the VM's from Active Directory and from vCenter Server using the vSphere Client and by browsing the datastores when needed." While the ADAM and Composer databases had no remnants of the VMs left in them, it is possible that there is still some piece of VM7 left in the vCenter database that's causing Composer to see it as already there. I'm no SQL DBA, so I'm not going to presume to give any instructions on how to fix that, but if you have anybody there with the right knowledge and skills (or if you're such a person) you may be able to ferret out the offending record and get VM7 back again. It's someplace to start anyway. I hope that helps.

Dave

Reply
0 Kudos
Cannoli
Contributor
Contributor
Jump to solution

That did it!  Thank you!!

Reply
0 Kudos
dvhorvath
Enthusiast
Enthusiast
Jump to solution

Excellent! Glad to hear it.

But I'm a big idiot, and edited my original post with what now turns out to have been a wrong answer, so I have to make amends in case anybody else runs into the same problem. So, to recap what I had said earlier, this sometimes happens when View is trying to protect itself from creating multiple VMs with the same name. What I had originally suggested was disabling provisioning on the pool, waiting a few minutes and then re-enabling provisioning so the pool would use the next available number. It turns out that worked, which is great. My edited post can now be disregarded. I'm really sorry for the confusion. Lesson learned.

Dave

Reply
0 Kudos