In my old lab I ran a lot of Windows 2008 R2 based infrastructure, not only was I running a fully deployed Active Directory Domain but I also had SQL 2008 R2 and SCCM 2007 but I was also running vCenter on 2008R2 as well, the main reason for this was due to the limitations that were in the original vCSA based on ESXi 5.0.
In Home Lab 2013 I decided to upgrade not just the physical side but also the virtual and that meant looking at some of my existing infrastructure and deciding on whether to keep it or upgrade.
Gone is the 2008 R2 based Active Directory Domain, in it’s place I am now running a 2012 Active Directory Domain Controller (no in place upgrade, I just deleted and started from scratch), that also meant that my SCCM 2007 infrastructure went (one of the technologies that I seem to get stuck with with every job so glad it’s gone really ), also gone is the vCenter server that was running on 2008R2, I had played around with installing it onto 2012 and whilst I managed to get it to work (you have to delete a service dependency) I wanted to ensure that all of my virtual infrastructure was actually properly supported so that meant looking at the vCSA.
With the release of vSphere 5.1 there was obviously the additional requirements for the SSO and Inventory services to be installed prior to installing vCenter, with the vCSA 5.1 release this comes bundled up as part of the OVF and makes the installation and configuration very simple (those of you who have installed vCenter 5.1 know that SSO can be a little bit ‘temperamental’).
The version of VCSA that I am installing is 18.104.22.16800 Build 947940 and is based on SUSE Linux 11 (64-bit).
Once installed the appliance is configured with 2 vCPUs and 8GB of RAM. It also has two VMDK virtual disks sized at 25 and 60GB.
The embedded database is PostgreSQL and has a soft limit of 5 ESXi hosts or 50 virtual machines, which is the same limitation as the Microsoft SQL Express db. that’s embedded with the Windows based vCenter server. As with previous versions the 5.1 release of the vCSA can still only utilize Oracle as an external database so if you’re a Windows house you may still want to look at running the Windows based vCenter server instead.
One of the nice things with the vCSA 5.1 is that it also includes the web client component pre-installed, with vCenter 5.1 the web client needed to be installed after the main installation. Additionally the Windows based vSphere client is still supported (although you may find yourself using the web based client more often than you originally thought).
The vCSA still doesn’t support Linked Mode configurations and you’re going to have to use a standalone View Composer if you plan on using VMware View alongside the vCSA. Also worth noting is that the VMware Update Manager is still only available as a Windows binary but once installed on a Windows box can be used\managed via the vCSA.
Prior to actually installing the OVF files you’re going to have to make sure that you’ve created an entry in DNS for the new vCSA appliance. When you create the entry also make sure that you create the reverse entry because if you don’t you’re going to come across problems later on (not just with the vCSA but also various other VMware technologies as well).
Here we can see the steps to add a new host record in DNS based on a Windows 2012 server.
The next step is to download and install the vCSA appliance. One important thing to note is that once you have all of the files downloaded they need to be in the same location prior to importing it.
Next launch the vSphere Client and start the Deploy OVF Template Wizard.
Click the Browse Tab
Browse to the folder where you stored the files
Name your VM, obviously you would probably want to name it the same as your DNS entry from earlier on for house keeping purposes.
Choose your disk formatting preferences, because this is going to have a PostgreSQL db running in the VM you would be better off sticking to a thick provisioned disk.
Check the deployment settings and click Finish (you can of course tick the Power on box if you want to).
The deployment takes a few of minutes and will vary depending on network and disk latency.
In the above screen grab you can see that because I have a DHCP server in my home lab it’s automatically assigned an IP address to the VM (in this case 192.168.2.214), unfortunately this doesn’t match up with the DNS entry we created earlier. There are two ways to change the IP address here and I will show you both.
In the first method we are going to have to launch the console to connect directly to the appliance VM (the console is shown on the right hand side of the picture above).
Once your console has priority hit the Enter key to start the Login process.
The default login credentials are root and vmware, once logged in we are going to run the /opt/vmware/share/vami/vami_config_net command this will allow you to configure the appliance prior to launching the web client.
Go through the different menu numbers to change what’s required and then press 0 to confirm the settings.
Once you’re happy with the config press 1 to exit the menu and then type exit to get back to the main screen.
We can see the above screen now reflects the required settings.
The other way to make changes to the appliance would be to go launch the web browser and go to the original URL. At this stage I have to stress that configuring the vCSA appliance from the web browser is going to have different results based on the web browser you’re using. As an example the machine used for capturing these images has Mozilla Firefox 19 installed alongside Internet Explorer 10, using FF19 highlights a couple of missing tabs.
In the above screenshots you can see the same web views taken from the two different browsers, obviously we are missing 3 extra tabs from the FF19 browser and that will cause a problem later on when trying to configure AD Authentication.
Please ensure you’re using a fully supported browser before continuing on.
Login with the same credentials as mentioned earlier
You will be prompted to Accept the EULA, you can’t do anything before accepting so click the box and then click Next
Now rather than going through the setup wizard straight away you’re going to need to press Cancel
You can see that the appliance has the default hostname and a DHCP allocated IP address, to change this go to the address tab.
Change the Address Type to Static
You can see a load more configuration options here now.
Very important to note the hostname entry above. This needs to be the FQDN entry here, if you don’t have this configured correctly here you’re going to run into issues later on when trying to configure AD Authentication. Once you have made all the required changes hit Save Settings.
When the web browser brings up the login box again go to the appliance console and log in.
Type shutdown –r now to force a reboot of the appliance, if you don’t you run a risk of running into issues with the web interface not functioning correctly and as it says in the Network settings screen a restart is required after changing the network configuration.
Log back into the browser and launch the Setup wizard.
Choose whether to use the default settings or custom config (which allows for AD settings, the option to use an Oracle database server, any SSO settings you may want to change), if you choose the default settings you can use the main web page to configure the other settings later on.
Choosing the default settings brings you straight to the above screen, click start.
After a few minutes (times will vary) the installation will finish and you can click Close.
We can now see that we have the embedded Database and SSO components running as well as the vSphere Web Client and Log Browser services running.
Next we are going to configure Active Directory Authentication.
Click on the Configure Authentication text highlighted, this will open up the Authentication Tab.
Click the Active Directory Enabled box and enter all of the required details.
Click Save Settings.
Going back to the main page we can now see that we also have AD Authentication working.
You can now log out and launch the Web Client or vCenter Server thick client.
Apart from the issues with the different browsers the installation and configuration of the vCSA was fairly straight forward as long as you remembered the pre-requisites, if you forget to configure the FQDN for the hostname you’re going to run into problems along the way, the same for if you don’t configure a reverse DNS entry and unfortunately it may not seem obvious during your troubleshooting as to why things aren’t working as expected. This post should at least point you in the right direction and help you deploy the vCSA Appliance if you want to.