Most of you will be intimately familiar with vCenter Server. It provides the main management capabilities in a VMware Virtualized Datacenter, including provisioning, monitoring, patching etc for all your hosts and virtual machines. You’ll spend a lot of your time using it if you’re a VMware Admin. But you may not know that it is advisable to reboot your hosts after you upgrade the version of vCenter Server. Otherwise you may get a little surprise the next time you go to patch or upgrade your hosts. I ran into this myself just recently after upgrading to the latest version of vCenter and then immediately attempting to upgrade my ESXi hosts in my lab. Fortunately this isn’t really a problem and is very easy to fix. This article will explain why.

During a vCenter Upgrade the VMware HA Agent on all of the ESXi hosts will be updated. After this happens the “require reboot” flag is set on the hosts, as explained in VMware KB 2034945. There is no visual cue that this is the case, so it is very easy to miss. The most likely time you’ll pick this up is if you are using Update Manager to scan your hosts for updates, or you’re attempting to upgrade ESXi. If you upgrade ESXi manually and haven’t already rebooted, then it’s very likely that the HA agent will fail to initialize the first time when the host restarts. This is very easily resolved by right clicking on the host and selecting the “Reconfigure for vSphere HA” option. This takes about a minute and you’re hosts HA Agent will be reconfigured and working again. Until the HA Agent is fully working and initialized successfully you will not be able to run any VM’s on the host.

If you want to run a PowerCLI Command to see if your hosts need a reboot or not prior to an upgrade check out this article titled How to find VMware ESX(i) servers that need a reboot using PowerCLI.

Final Word

This is really only a minor inconvenience and is easily fixed by reconfiguring HA. But it is better to catch this and know about it first, rather than finding out only after HA fails to initialize, especially in a highly automated environment where the problem might not be caught for a couple of days and you could have problems starting VM’s.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2015 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

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…

According to this article, there are already worms exploiting this bug. So the impact could be wide spread for the vulnerable systems. I would expect most major vendors to come out with security advisories very promptly for this, after they have assessed their systems. For those of you running VMware, they have posted a blog here, and an advisory here. As things stand if you’re running VMware tools on top of Windows, such as vCenter for example, then you are not vulnerable. Also ESXi is not vulnerable as it uses ash shell via BusyBox instead of Bash. However any virtual appliances may well be vulnerable, including the vCenter Server Appliance. I would recommend keeping and eye on VMware KB 2090740 for the latest updates. For home users, lock up your networks tight and try to prevent anyone getting in the virtual front door, until such time as there are widely available fixes.

This bug highlights the importance of keeping patches up to date and staying across the alerts from the likes of NIST. Be aware of this bug and get patched and protected as soon as you can. Not everyone has a vaccine for this one yet, but hopefully it’s not far away. This bug could cause a lot of change to the way systems are designed, implemented and secured. What’s to say another bug of this nature isn’t just around the corner? Better to be prepared.

Final Word

This is probably one of the highest impact and most wide spread bugs with the highest severity that I’ve seen in over 20 years in IT (reminds me of the original internet worm). As the Internet of Things (IOT) spreads bugs of a similar nature will have a much wider impact and much more sever consequences. Security of your systems is going to become an ever more serious issue and this is why Micro Segmentation, and using technologies such as VMware NSX and vCloud Networking and Security will become so important. In addition to more intelligent firewalls, such as from Palo Alto Networks. As much as we give Microsoft a hard time over security and patches, neither Heart Bleed and Shell Shock impacted Windows systems.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2014 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

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?

In his Notes from MWhite newsletter on 7th June, Michael White described the End of Availability as follows:

“This is very odd.  There is no other product to replace Heartbeat.  I know VMware is working on stuff, but this makes no sense to me.  But as of June 2, VMware does not sell Heartbeat any longer.  If you own it already it will be supported to 2018.  But in the meantime, what do you do?  Aside from backups, and HA, there is not much if you want to really have good up-time.  I guess there is quite a back-story here since VMware has put people into a very awkward spot and I don’t think they do that lightly.”

I agree with Michael. This is odd. I’m sure VMware is working on something. The availability of vCenter is critical as more and more products are integrated into it. It’s critical for backups (and more importantly restores) to function, it’s critical for VDI workloads (which are an important business critical app when adopted widely), for monitoring tools and provisioning tools and cloud environments. If you manage a critical environment that must be available 24/7 and have reliable analytics, then vCenter is important and needs to be protected. But availability for vCenter hasn’t been easy for a long time (accept when using heartbeat), and there is a lot of dependence on it. It was never really architected for availability in the first place. It is essentially a single point of failure. We really can’t afford that in the world of the Software-Defined Datacenter. Another good article that explains this is Julian Wood‘s article titled What VMware’s EOL of vCenter Server Heartbeat means for availability?

vCenter Server Heartbeat was the solution of choice when you needed to protect not just against infrastructure failure, but also application service failure and application performance degradation, and have options to protect vCenter across a datacenters or across a WAN environment. I had architected a number of solutions for business critical apps environments or cloud environments that included Heartbeat. I’d also written about it on this blog such as in these articles:

vCenter Server Heartbeat Installation and Validation

vSphere 5.1 and vCenter Server Heartbeat 6.5 Deployment Considerations

Using vCenter Heartbeat to Protect Non-vCenter SQL DB? Think Again!

Changing vCenter Heartbeat to CA SSL Certificates

VMware Products Not Supported with SQL Server AlwaysOn Availability Groups

But vCenter is evolving and eventually something had to change. There was a presentation at VMworld some time ago about vCenters evolution to become much more of a federated solution,  much more scalable and much more highly available. So it was inevitable that the availability options would change too. This is still something for the future though and the plans have not yet been announced. For the here and now we still need to protect the vital SDDC management infrastructure. So what are your options for vCenter availability now that vCenter Heartbeat is not available?

1. Virtualize vCenter! If you don’t have vCenter Virtualized you’re missing out on the easiest way to increase availability. If you create a management cluster for your management VM’s including your vCenters, then you will be able to easily protect them with things such as item 2.

2. vSphere HA. This is how you protect your other VM’s and it works great for vCenter as well. At least up to about 99.9% availability. You can potentially increase availability further by using VM Monitoring and potentially App HA.

3. Backups of vCenter and/or a clone of vCenter or cold stand by.

In truth, none of the above solutions fully replace the functionality of heartbeat that made it valuable and important for critical environments that needed high availability and high availability of their management infrastructure. But vCenter Server Heartbeat didn’t protect all of the tools in VMware’s rapidly growing portfolio of products either. For example there was no support for vCAC, SRM, vCD, VCM, vCOps etc. All of the other tools that you’d like high availability for also. So perhaps that they now don’t have to worry about development of vCenter Server Heartbeat the availability and architecture of some of these other products will improve? Perhaps all of these products will integrate much more easily with each other, be more easily architected in a highly available manner? Maybe this will be one of the big talking points at VMworld in 2014.

But is vCenter Heartbeat Really Gone for Good?

The answer is NO! It’s just gone back to its roots. vCenter Server Heartbeat was always a product that VMware had OEM’d from Neverfail. So now that VMware has dropped vCenter Server Heartbeat Neverfail has taken it back and you can purchase the Neverfail IT Continuity Engine. The good news is that Neverfail’s IT Continuity Engine isn’t just limited to vCenter. It works with a whole host of other products. So while vCenter Server Heartbeat is dead from a VMware perspective, it is not gone, and certainly not forgotten.

Final Word

I don’t agree with removing a product from sale prior to an alternative that is of equal or better functionality being available. This is not the first time it’s happened, it’s happened to other products. How can anyone make sensible product investment decisions when you don’t know what the shelf life is of a product? In this case VMware HA really isn’t equivalent, but it’s the alternative that is included in the price and it’s what’s available from VMware today. Everybody should have their vCenters virtualized in any case. But in this case at least you can still get the additional level of vCenter high availability if required by going to Neverfail, who were the original makers of vCenter Server Heartbeat in any case.

You can have your say and give your feedback directly to the VMware Product Managers for vCenter availability and performance. They have started a survey and they want you to let them know about your environments. They are collecting the requirements around performance, availability and scaleability that will shape the future of vCenter. So have your say in the VMware vCenter Performance Survey.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2014 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

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.

While there are a total of 136 steps in the process to update the CA SSL Certificates in the Windows vCenter 5.1 there are only 81 steps to update it in the vSphere 5.1 vCenter Virtual Appliance. But note that these steps do not include update manager. I will include the link below to the KB regarding update manager also.

Here are the KB articles required to update the vSphere 5.1 vCenter Virtual Appliance and Update Manager.

Configuring certificates signed by a Certificate Authority (CA) for vCenter Server Appliance 5.1 – http://kb.vmware.com/kb/2036744

Configuring CA signed SSL certificates for vSphere Update Manager in vCenter 5.1 – http://kb.vmware.com/kb/2037581

It was another great team effort across the globe within VMware to put these instructions together and test them. Hopefully you find this information useful.

—

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.

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.

This work covers vCenter, and all the related core components such as SSO, Inventory Service, Update Manager etc. The great news is that this work has resulted in KB’s that I and a number of others have tested and verified to work with vSphere 5.1 GA for the Windows installable version of vCenter. There are also updates to some previously released KB’s for vSphere 5.0. These processes will also work with the recently released patches to vCenter. The KB articles for the vCenter Virtual Appliance edition will also be published shortly and I will update this article when they are available.

Below are the links to all of the articles and a note with regard to Update Manager. I want to say a massive thank you to all of the people at VMware that made this happen. It was a big team effort. I’m glad I could make a contribution to the effort.  I will be making sure the process is automated for you as part of the vCert Manager project that I’m working on. My goal would be to automate both the Windows Installable and Virtual Appliance editions for vSphere 5.1.

Note you should start with KB 2034833 – Implementing CA signed SSL certificates with vSphere 5.1.

VMware has also put out a blog article on these KB’s titled Implementing CA Signed SSL Certificates with vSphere 5.1.

Note: I have found a problem with Update Manager when vCenter system is an all in one configuration with everything on the same VM and using a local MS SQL Server database. Update Manager will not be able to log into or register with vCenter when the SSL certificates have been changed. This prevents you from updating the SSL certs for Update Manager and Update Manager may no longer work. This does not appear to occur when the MS SQL Server database is remote. I have not tested this with a local Oracle or other supported local database. I am continuing to work with VMware on this issue and will update this article when it is resolved. In the meantime I would recommend placing the databases for vCenter and it’s other core components on a separate VM, even in small environments.

Final Word

Although changing out the self-signed SSL Certificates is not simple, and is very time consuming to do manually, the above articles make it possible and give you a tested and verified process. I will be automating the processes to take this pain away as part of the vCert Manager project. In the meantime I would recommend you start with KB 2034833 – Implementing CA signed SSL certificates with vSphere 5.1 and work your way through the rest. I hope you get a lot of value out of these articles and the effort that the team has put in. As always your feedback is appreciated.

Derek Seaman has put together a great series of articles on VMware vCenter 5.1 Installation that includes coverage of SSL certificates. I would highly recommend you check it out. Derek has made a great contribution to the process for SSL Certificate Replacement in vSphere 5.1.

—

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.

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.

Simply put, if you install VIN prior to changing your SSL certs, it will cease to function and be completely broken. It will require that you delete the VIN instance and redeploy from scratch. Fortunately the rediscovery afterwards will fairly quickly get the inventory service mapping and dependencies back. But this is not great from an end user experience perspective. There is also no documented way to change the default self signed SSL cert on VIN itself. Given that VIN is a great tool for a secure environment to identify what services are where and connected to what I’m hoping it will work better in the future when SSL certificates are updated and that there is an easy process provided to update the VIN SSL cert.

If you want a way to fully manage the certificate lifecycle and replace certs automatically then you’ll want to check out vCert Manager – Changing VMware SSL Certs Made Easy. This will completely automate the SSL certificate process in vSphere environments. 

—

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.

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.

If you want a way to fully manage the certificate lifecycle and replace certs automatically then you’ll want to check out vCert Manager – Changing VMware SSL Certs Made Easy. This will completely automate the SSL certificate process in vSphere environments. 

The default location for the vSphere Web Client certificates is C:\Program Files\VMware\Infrastructure\vSphere Web Client\DMServer\config\ssl. You will need to restart the vSphere Web Client, or reboot the vCenter Server to load the new certificates into memory. You will then be able to log into the vSphere Web Client to test that it is still functioning.

Updated: In most cases you should use the default keystore password of testpassword for your pfx file. If you chose to use a custom password for your keystore you will need to update the tomcat configuration files with the new password. Please refer to VMware KB 1013472 – vCenter Server Service Status plug-in cannot be enabled. However this doesn’t offer any additional security as the keystore password is still stored in clear text in these configuration files either way. Access to the filesystem locations of the important certificate and configuration files should be locked down to prevent any unauthorized access. Thanks to Dan Corrigan for raising this in the comments below.

You may notice that when you change the vCenter SSL Certificate that vSphere Web Client will pop up a warning box the when you attempt to log in. The warning box will say that secure communication can’t be verified. This is due to the thumbprint of the vCenter Server SSL Certificate being different to what vSphere Web Client recognized when it was registered with vCenter. If you click install the certificate and ignore to continue it will not prompt you again on this system. You will need to unregister the vCenter system on the vSphere Web client using the admin-app url, and then re-register it again. To do this you will need to log into the vSphere Web Client system using RDP (Assumes Windows Version), then opening https://localhost:9443/admin-app in a web browser. Once the vCenter System is registered with the new thumbprint the warning dialog box should not be displayed again.

WARNING: Under normal circumstances you should not blindly ignore these types of warning messages and should not automatically just install certs and ignore to continue. You need to institutionalize Standard Operating Procedures that question every time a warning dialog such as this is present and you must verify the authenticity of the certificate. Here is an example of the warning box with the vCenter Server and SHA1 thumbprint obscured.

So you don’t have to jump back to my previous article just to find the default location for the Inventory Service SSL Certs it is C:\Program Files\VMware\Infrastructure\Inventory Service\ssl.

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.

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.

Prerequisites

Before we get started there are a few prerequisites that need to be taken care of. For this solution to work you will need to have the following:

1. One or more vCenter Servers, preferably protected by vCenter Heartbeat
2. Two or more vSphere Web Client Servers, for this you can use the vCenter Virtual Appliance without the vCenter Services enabled, refer to my article titled Deploy vSphere Web Client without Additional Windows Server License for instructions
3. A load balancer that can load balance HTTPS traffic and must allow configuration of custom ports
4. A client computer that can be used to run the vSphere Web Client and the vSphere Full Client, which will be used for testing and must have the latest Adobe Flash player installed

vSphere Web Client Deployment

This diagram illustrates a logical design of how you might configure the various components to improve availability and scalability of the vSphere Web Client for a large environment.

Load Balancer Configuration

In the above design I’ve chosen to use the vCenter Virtual Appliance with the vCenter Services disabled to act as the vSphere Web Client Servers. I’ve used a F5 BIG-IP LTM VE to provide load balancing for the vSphere Web Client User access to the vSphere Web Client Servers, as well as for the vCenter Servers to access the vSphere License Plug-in. You can use any load balancer that will successfully load balance HTTPS traffic on port 9443, which is the port the vSphere Web Client uses.

You will need to ensure that you configure the correct persistence setting for client connections. For my lab configuration I chose to use cookie based persistence. This will have the effect of ensuring the browser used to authenticate will always be sent back to the same back end vSphere Web Client Servers (assuming it’s still available). If for some reason the vSphere Web Client Server that a user logged into is unavailable they will be directed to a surviving vSphere Web Client Server and be forced to log in again. This is because there is no session or connection sharing between the vSphere Web Client Server systems.

In order for vCenter to use the virtual IP on the F5 LTM to access the License Plug-in instead of an individual vSphere Web Client Server you need to be very careful with how you deploy and register the vSphere Web Client Servers. When you register the last vSphere Web Client Server to the vCenter Servers you will need to do it using the IP address that will eventually be used as the virtual IP on the load balancer. This is unless it is the Windows version of the vSphere Web Client, which allows you to specify the client URL. After the last vSphere Web Client Server is registered using the VIP of the load balancer you must change its IP address. You will need to wait until all the vSphere Web Client Servers are registered before setting up the nodes, pools, and virtual server profiles on the load balancer to prevent the possibility of an IP address conflict.

VMware Support’s stance on this configuration is as follows: If you have a fault and log a support request they may ask you to bypass the load balancer if they believe it is contributing to the problem. This is fair enough as they only support exactly what VMware have tested. The process to bypass the load balancer is very simple, you would disable the load balancer virtual server and pools, and then reconfigure one of the vSphere Web Client Servers with the IP address of the load balancer VIP. In other words the reverse of how you configured it in the final step above.

This screen shot below is an example virtual server configuration for the F5 BIG-IP LTM VE that I used to test the above design. The load balanced pool was configured to do a simple TCP healthcheck, and use least connections as the load balancing algorithm. You could write a customized healthcheck script to ensure the vSphere Web Client is really functioning as expected.

Testing vSphere Web Client and License Plug-in

To test the vSphere License Plug-in log into one of your vCenter Servers using the full vSphere Client. Navigate to Home > Administration > Licensing. Click on the Reporting Tab. Once the Reporting Tab is completely loaded right click anywhere in the screen and click settings. You should see the Adobe Flash Player Settings dialog box appear asking you if you want to allow <VIP Address of Load Balancer> to access your camera and microphone. If you do not see the VIP address of the load balancer here the vSphere Web Client has not been registered correctly.

To test the vSphere Web Client from a broswer navigate to https://<VIP of Load Balancer>:9443/vsphere-client. The vSphere Web Client should load successfully and you should be able to log into any of the registered vCenter Servers. You should be able to manage the vCenter Server as you normally would if there were only one vSphere Web Client.

vSphere Web Client Limits

This version of the vSphere Web Client is limited to connecting to 50 vCenter Servers concurrently. Each vSphere Web Client connects to the vCenter Server with one session per user. There is no current documented limit for the number of client connections to the vSphere Web Client. But the other important limit to consider is the number of connections to the vCenter Server, which is 100 as of vSphere 5.0.

A Final Word

Each vSphere Web Client Server can handle hundreds of individual users and connect to many individual vCenter Servers. With the above architecture you can scale out the vSphere Web Client systems to ensure your availability, performance, and scalability needs can be met. You will be able to potentially have thousands of individual users accessing the objects to which they have been authorized to manage. This might be as simple as viewing performance statistics and a VM console, or could be provisioning new VM’s. The choice is really yours. At least with this design you know that the service your users expect will be available when they want it.

You might also like to check out Joep Piscaer’s article Load Balancing the vSphere Web Client for some additional ideas on Geo Load Balancing for High Availability.

—

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.

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.

Prior to running through the steps below you should have downloaded and deployed the vCenter Server Virtual Appliance (VCVA) ovf version 5.0 from the VMware web site. This process assumes you already have the VCVA connected to the network and configured with the correct timezone already without any further configuration. Please be aware this process has only been validated on VCVA version 5.0, not 5.1. 

This process  assumes that you are not going to be using the VCVA as your vCenter Server. If you are planning to use the VCVA as your vCenter Server then you should not follow this process and should instead follow the VMware documentation for setting up and configuring VCVA. Use this to connect the vSphere Web Client that is included with the VCVA to an already existing vCenter system, without having to deploy another Windows Server and purchasing a Windows Server License.

To de-register the local embedded vCenter System and to register an existing vCenter Server with the vSphere Web Client do the following:

1. Ensure you have logged into the VCVA and accepted the EULA. To do this you will need to access the VCVA Web Administration interface at https://<VCVA IP>:5480/. Log in using root, and click the Accept EULA button, you can then logout. Be sure not to configure or start the vCenter services on the VCVA.
2. Through the console of the VCVA Virtual Machine log in as root using the default password
3. cd /usr/lib/vmware-vsphere-client/scripts
4. The following command will unregister the local vCenter system from the vSphere Web Client:
   ./admin-cmd unregister https://<VCVA IP>:9443/vsphere-client localhost root <rootpw>
5. Now we will register the existing vCenter server(s) that we want to manage with this vSphere Web Client:
   ./admin-cmd register https://<VCVA IP>:9443/vsphere-client <vCenter System FQDN> <admin username> <admin pw>
6. Log out of the vCenter Virtual Appliance by pressing CTRL-D or typing logout and pressing enter, close the VM console.
7. Now to use the vSphere Web Client point your browser at https://<VCVA IP>:9443/vsphere-client and log in using any authorized vCenter account

You have now successfully registered the vSphere Web Client server instance on the VCVA with your existing vCenter systems. You can now use this to manage your virtual machines. Be aware that if you register multiple vSphere Web Client servers with a vCenter system that the License Client Plug-in from the last vSphere Web Client registered is the one that will be used for vCenter License Reporting.

If you want to know why running the vSphere Web Client is a must when you upgrade to vSphere 5 see my previous article here. If you want to take this to the next level and scale the solution to support a full enterprise and increase high availability see my article titled Increase vSphere Web Client Availability and Scalability for Enterprise Environments.

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.