Monday, February 15, 2016

vSphere template "convert to virtual machine" option grayed out

This is apparently an old bug. Seems to be triggered after vCenter and ESXi updates. You can read about it here: started in 2012

The KB 2037005 you will find is utterly useless - this is not a permissions issue and removing/re-adding the template can be very ineffective. The manual solution in the two links above is to deploy a VM and magically the option will reappear.

I did find however a better way, in a post from 2009! by Arne Fokkema

I can confirm this works. If you don't want to paste blindly, here are the related PowerCLI commands. Italics is a variable, inside brackets is a keystroke:

#Connect to a vCenter, it will prompt for your credentials or use AD integration
Connect-VIServer hostname [enter]

#Get a list of templates (more options, such as from a unique cluster, here
Get-Template [enter]

#Convert template to VM (again, remember it's not a permissions problem, this is just a bug)
Set-Template template_name -ToVM [enter]

You will now see a successful task in vCenter that converted the template to a VM. To move it back with Powershell, you will need a variable so you can use .MarkAsTemplate() instead of defining a template with New-Template

$vm_to_tpl = Get-VM template_name | Get-View [enter]
$vm_to_tpl.MarkAsTemplate() [enter]

#remove the variable you created, notice no $ sign
remove-variable vm_to_tpl [enter]

However, his script probably works perfectly fine and is a very automated way of doing it, so if you have a lot of them, customize it, test it, save it to a ps1 and watch the magic. 

I did remove Arne's -RunAsync from mine since I didn't want the possibility of the script to try to perform a task while the vCenter was still performing the conversion.

Tuesday, February 9, 2016

vCenter 6 multi site installation error

First vCenter was a VCSA embedded and I was careful with DNS so everything went all right.

Second vCenter was a Windows embedded that had to join the SSO domain and setup a new site.

Got the error:

failed to run vdcpromoon the top part of the error: "install.vmafd.vmdir_vdcpromo_error"

Sean Whitney's post is the only help I found from a Google Search on such an error (and yes, the installation with the generic error 1603 he mentions)

The path where I saw logs was C:\ProgramData\VMware\vCenterServer\logs though, and they only persisted until the zip file was done bundling up.

I ruled out:

1) that my SSO password had a ! sign, changed it to a @ - it still happened, so that wasn't it... it sounded weird since we've used VMware1! in VMware labs forever...

2) In my second try I got a message that said this windows VM and the VCSA were off by 22 seconds

Thanks to Google I found the commands to check NTP from the VCSA console

Command> ntp.test --server
   Status: red
         Message: Failed to reach ''.

         Result: failure

well well - let's change that

Command> ntp.server.delete --server
Command> ntp.server.add --server
Command> ntp.test --server
   Status: green
         Message: '' is reachable.
         Result: success
Command> ntp.get
   Status: Up

I went to my PDC and updated the time server to match the NTP server

w32tm /config / /syncfromflags:manual /reliable:yes /update

and rebooted the PDC - system event logs confirm it's now syncing to this server.

I cancelled the installation, rebooted the vCenter and tried again.

Now it complans i'm off by 16 seconds. Ayayayayay. Then I got it differs by 5 seconds.

I'm pissed by now.

Let's try to get this VCSA to sync directly from the lone PDC - I can't make it faster than my freaking LAN.

on the PDC, if you hadn't already, make sure it's a reliable time server:

w32tm /config /reliable:yes

On the VCSA - enough with the niceties, give me the shell, set the server in /etc/ntp.conf and stop and start the ntp service, then check with ntpq -p like Ganesh does here to make sure everything is working as intended.

And it didn't complain this time. It went smoothly until completion.

So that big error was really a NTP error.

If that's not a gotcha, I don't know what is!

Wednesday, February 3, 2016

Disabling a Workstation VM set to autologon from login in automatically once moved to ESXi

Workstation has a feature (which it offers to you when you build a Windows OS virtual machine) called Autologin. You can access it manually via the VM, Settings, Option dialog

It basically remembers your login and password for you. Great if you restart the machine a lot, I guess :)

I made a machine, allowed autologin, and later moved it to an ESXi host in my lab. For some reason I thought the autologin was some feature of VMware Workstation. It's not - the VM continued doing the autologin. I then thought it may be in the VM advanced options but I couldn't find anything.

I searched Google but didn't find anything related to VMware Workstation or ESXi auto logon. The trick is that this is a Windows feature, not a VMware feature o.O

Check this KB - - it explains how Autologon works. 

The easy way of disabling it is to open regedit, navigate to

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

And change the value of the AutoAdminLogon key from 1 (true) to 0 (false)

However, you should also clear any information in the other keys mentioned in the article, like Domain, username, and if you find the password key.

It's not a good idea to enable it other than for testing purposes, but at least now I learned that VMware Workstation just does a registry key and this is a Windows feature. In case you run into the same thing on your lab, now you know how to fix it easily :D

There was a gotcha in there (because I just didn't know and assumed) and that's what this blog is about.

Avoid losing Windows activation when moving a VM from one environment to another

You moved it. You didn't copy it.

Don't go breaking any laws now - but that's the way for the computer's OS not to detect hardware changes and trigger re-activation.

Ok, but what if you already messed up?

The online activation will not work. There's a lot of cases and it depends on your license and ... - but if you're doing perfectly legal things you have all the right to run your machine and not have to sit on the phone with Microsoft.

What you want to do is shut down the machine, move it back to where it was originally activated. Turn it on and this time it will activate properly online. Now shut it down and move it back to where you had problems. When you get that dialog: You moved it. You didn't copy it.

There's a gotcha there, and that's what this blog is all about.