One of my colleagues ran into some trouble with connecting a vCenter Virtual Appliance to Active Directory for authentication. He was getting a weird error saying that the FQDN (Fully Qualified Domain Name) was wrong. The actual error message was as follows:
Failed to execute ‘/usr/sbin/vpxd_servicecfg ‘ad’ ‘write’ ‘administrator@<domainfqdn>’ CENSORED ‘<domainfqdn>’
VC_CFG_RESULT=302(Error: Enabling Active Directory failed.)
After quite a bit of research the solution was found.
If you thought Ebola was deadly to humans wait till you get a load of the latest security issue impacting the world wide web and most everything connected to it including potentially your phone, lights, servers and the list goes on (excluding Windows systems). If Heart Bleed wasn’t bad enough at the start of the year the new Shell Shock bug certainly is. It is what I would term the Mother of All Bugs (MOAB). It impacts almost all Unix, Linux and Mac systems and allows a remote attacker to execute arbitrary code and potentially steal your data, credit cards and other information. So how serious is this? Well the NIST CVE Alert Rating on this is a 10 for severity, and a low for complexity to exploit (read my 7yr old could exploit this bug). So basically the worst possible kind. Oh, but wait, there’s more…
On 2nd June VMware announced the End of Availability of VMware vCenter Heartbeat. It is no longer available for sale after this date, but existing customers are supported through to 2018. This marks a turning point for availability when it comes to vCenter. Is this another in a line of cases where VMware has killed a product before there is a suitable replacement or alternative? With vCenter Server Heartbeat gone, your options for availability of vCenter are now limited to VMware HA. But is it really gone?
Recently I wrote about Updating CA SSL Certificates in vSphere 5.1 which applied to the Windows installable version of the vCenter 5.1 and it’s supporting components including SSO. VMware has now also released the instructions to update the CA SSL certificates in the vSphere 5.1 vCenter Virtual Appliance.
Over the past few weeks I have been working behind the scenes with a team of people at VMware spread around the globe on the process to successfully change out the self-signed certificates in vSphere 5.1. With the introduction of Single Sign-On in vSphere 5.1 the process is somewhat more complicated than vSphere 5 (ok quite a lot more complicated). But now I’m able to bring you some of the solutions you’ve all been waiting for.
Like a lot of people I was quick to download and implement VMware vCenter Operations Manager 5 Enterprise when it became available. One of the great tools that is included in the suite is Virtual Infrastructure Navigator (VIN), which will discover and map all the dependencies and also DR protection status of VM’s in a linked mode group. However there is a bit of a gotcha if you want to use VIN and you also want to change the SSL Certs in vCenter and/or vSphere Web Client.
I’ve had a few people ask me over the last couple of days why their vSphere Web Client SSL certificates are not being updated when they change the vCenter SSL Certificate as per my article The Trouble with CA SSL Certificates and vCenter 5. The normal reason for this is that the vSphere Web Client, when installed on the vCenter Server, stores it’s SSL certificates in a completely different location to that of vCenter Server. I’ve also since found out since publishing my other articles that this is true for the Inventory Service also. Why both of these services when installed on the vCenter Server don’t leverage the same SSL certificate location I’m not sure. My previous article has now been updated to include the replacement of the SSL cert for the Inventory Service, and also mentions the vSphere Web Client when installed on the same system as vCenter.
A little while ago I posted an article outlining a design that provides a solution for Scalability and High Availability for the vSphere Web Client in vSphere 5 for enterprise environments. Many of these enterprise environments that might want scalability for the vSphere Web Client may also be deploying the new vCenter Operations Manager 5 Suite, Enterprise Edition (or above), which includes Virtual Infrastructure Navigator. I’m pleased to report that so far my testing seems to suggest that both will integrate successfully. When I deployed VIN I needed to ensure it was on the same network as vCenter, else the asset wouldn’t appear in vCenter License section and I couldn’t apply the license or start the discoveries. If you haven’t seen or heard about vCenter Operations Manager 5 Suite yet I would encourage you to check it out.
This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.
Previously I’ve written about why the vSphere Web Client is a must when you upgrade to vSphere 5 and how to deploy the vSphere Web Client without having to purchase an additional Microsoft Windows Server License. This article will now reveal how you can increase the availability and scalability of the vSphere Web Client and also for the all important vSphere License Plug-in for an enterprise environment. The design described in this article should allow you to scale to hundreds if not a few thousand concurrent vSphere Web Client Users.
So you want to run the vSphere Web Client server but you don’t want to install the Windows version, which may require you to purchase an additional Microsoft Windows Server License? Well I have good news for you. You can download and deploy the vCenter Server Virtual Appliance, which is a SUSE Enterprise Linux based appliance and use the vSphere Web Client server instance on that to manage any other vCenter system. You don’t have to use the VCVA itslef as a vCenter server. This will give you all the features and functions of a vSphere Web Client without having to purchase an additional Windows license from Microsoft. Thanks to Barrie Seed aka @vStorage for the inspiration for this article and the original idea. Let’s walk through the procedure.