WilliamLam.com

How to Update vSphere Infrastructure Navigator (VIN) After Changing vCenter Server IP Address

by // 2 Comments

If vSphere Infrastructure Navigator (VIN) is deployed in your environment and you change the IP Address of the vCenter Server, VIN will no longer function even after a reboot. The reason for this is that when VIN first registers with the vCenter Server, information is generated and stored within VIN such as the IP Address as well as security thumbprint. Since the IP Address of the vCenter Server has changed, we simply just need to re-register VIN with the vCenter Extension vService.

In my lab I have VIN deployed and connected to a vCenter Server (note the IP Address 172.30.0.229):

I then update the vCenter Server's IP Address to 172.30.0.230 which will break communication with VIN. To resolve this, start off by shutting down the VIN appliance. Once it is shutdown, edit the settings and click on "Manage->vServices" and at the bottom click on the Edit button. Next change the Provider drop down to "No Provider" and then click OK.

Now we will reset the Provider back to the vCenter Extension vService by going through the same workflow again but now selecting "vCenter Extension vService" as the provider.

You will also notice at the bottom there is a validation message and you should also see the new IP Address of your vCenter Server. Once you are done, click OK to save the settings and then power back on your VIN appliance. Once VIN is up, connect to the vSphere Web Client and you should be able to see your VIN data again!

Automate vCenter Orchestrator Configuration Backups

by // Leave a Comment

Last year I wrote an article on how to quickly configure a new vCenter Orchestrator 5.1 appliance which automatically goes through the necessary steps of configuring your vCO appliance and enabling the vCenter Server plugin and associating it with your vCenter Server. These steps are usually performed manually, but when you are looking at deploying multiple vCO instances or even quickly spinning up vCO appliance for testing, this will definitely help speed up your deployment.
Something that I did not consider after completing the vCO setup was backups. Fortunately, this was something that was shared with me recently from a customer who had this exact workflow on backing up their vCO configuration after their initial deployment. This may not be a very well known feature, but vCO provides a very simple mechanism to export your vCO configurations and allows you to restore the configuration in case of a miss-configuration or even deploying a similar configuration to another vCO instance.
Using the same HTTP request trick, to export the vCO configuration you would need to make a request to the following URL:

https://${VCO_IP_ADDRESS}:8283/config_general/ExportConfig_export.action

Similar to the vCO UI, the backup will be stored on the vCO appliance itself and the path will be provided back to you in the message response. To help demonstrate this, I created a simple shell script called backupVCO51.sh which is similar to the setup script in my previous blog article. You can easily take the few lines of code and integrate that with the setup script.

Here is a screenshot of running the backup script:

From the output we can see where the backup configuration is stored on the vCO appliance and you can easily copy the backup to an external system using SCP.

Whether or not you are automating your vCO setup, you should definitely consider performing periodic backups of your vCO configuration, especially before making any changes to your vCO Server.

vSphere Security Hardening Report Script Updated for vSphere 5.1

by // 10 Comments

A public draft of the vSphere Security Hardening Guide for vSphere 5.1 was released a few weeks back by my colleague Mike Foley. Since then I have been asked by several people if I had a chance to update my vSphere Security Hardening Report Script. The answer was unfortunately no due to other projects I had been working on and this script as well as others are maintained outside of my normal day job. I finally found some time this past weekend to go through the 5.1 revision of the hardening guide and make the necessary updates to my script which includes a few additional checks.

The script continues to provide backwards compatibility to previous releases of the vSphere Security Hardening Guide for vSphere 5.0, 4.1 and 4.0. Maintaining this compatibility is actually quite a challenge due to small minor changes in the hardening guide from previous versions, but I am please to say the latest 5.1 draft has now been implemented.

Disclaimer: This script is not officially supported by VMware, please test this in a development environment before using on production systems.  

Here is a sample output for the Security Hardening Report for a subset of my vSphere 5.1 home lab environment using "profile1" check:
vmwarevSphereSecurityHardeningReport-SAMPLE.html

For more details about the security hardening script, please refer to the documentation here.

If you have any feedback/questions on the vSphere Security Hardening Guide itself, make sure you to leave your comments and questions here. If you have any feedback/questions regarding the script, please join the vSphere Security Hardening Report VMTN Group for further discussions.