Make Sure That the Sso Service is Started Before Continuing

Note: While writing this post, VMware has updated the instructions for installing certificates on the vCenter Server Appliance. The KB for this article can be found here.

In my last post, I walked through the process of generating the SSL certificates using OpenSSL and the OpenSSL configuration files for each service on the vCenter 5.5 appliance. So now that you have your SSL certificates, keys, and certificate authority chain, you can install them on your vCenter Server Appliance. This isn't as hard as it actually looks, but the VMware documentation does miss a couple of the steps that are needed to do this successfully.

Getting Started

If you're like me and using a Windows machine, or if your employer only provides you with a Windows machine, you'll need to make sure you have a few tools installed in order to change the SSL certificates on the vCenter Appliance. Those tools are:

• An application to transfer files to a Linux machine (I use WinSCP, which can be downloaded from here)

• An SSH client application (I use PuTTY, which can be downloaded from here)

If you're comfortable a Linux command shell, this process should be pretty straightforward. Until a year or two ago, I wasn't, and I know that there are a lot of other Admins out there who don't have a lot of Linux experience, so I tried to include all of the required commands and screenshots where possible.

Converting the Certificate Chain to .pem

The Microsoft certificate authority only provides certificate chains in a .p7b file format, and these cannot be used on the Linux appliance. So before you copy any files over to the appliance, you will want to convert the certificate chain from your certificate authority from a .p7b file to a .pem file. Since the OpenSSL components are installed on your computer, you might as well do this before copying anything over to the Linux appliance.

To convert the .p7b file to a .pem file, you need to open the windows command prompt as an administrator, navigate to where your certificate chain file is stored, and run the following command:

openssl pkcs7 -print_certs -in certchainname.p7b -out cachain.pem

This will create a new certificate file in the .pem format. You will need to edit the file slightly to remove a few lines of text as the pem file, so you will need to open it up in a text editor. You will want to remove the lines before each "—–BEGIN CERTIFICATE—–." These lines may start with "subject=" and "issuer=" like the screenshot below.

After you save the changes to the .pem file, you should copy it into the folders that you created for each certificate. This will make it easier to work with the chains when you copy the files over to the appliance.

Copying the Certificate Files to the Appliance

Note: I do not use the Auto Deploy service in my lab at this time. Therefore, I will not be covering updating those certificates. I will probably cover this in a future post.

You will need to copy the certificate files, private keys, and the certificate chains over to the appliance before you can change the certificate that each service uses. You will need to open WinSCP and log into the vCenter Server Appliance as root (default password is vmware).

After you successfully login, you may see a MotD banner like the one below. You can click Continue to finish logging in.

Once you have logged in, you will need to navigate to the /SSL folder. This is where you will copy the certificate files, private keys, and the certificate authority chain to. You will need to create three folders inside the /SSL folder for the three groups of files that will need to be copied over. Those folders should be named:

• vpxd
• inventoryservice
• logbrowser

After these folders have been created, you will need to copy over your certificate files to each of these folders. WinSCP allows you to copy by dragging the files from the left side of the screen, which is your local computer, to the right side of the screen, which is the remote computer. When you have finished copying your files, you should have the certificate file (.crt), the certificate chain file (.pem), and the certificate private key file (.key) in each folder.

Updating the vCenter Service (vpxd) Certificate

After you've copied over your certificate files, it's time to rock and roll. Updating the certificates on your vCenter Appliance isn't that difficult, but it does require a little bit of command-linefu to make the magic happen. Before we can start, you need to log into your vCenter appliance using PuTTY to access the command line as the root user.

The first thing that you need to do is stop the vCenter Server service and the Single Sign-On Service. The command to stop these services is:

service vmware-stsd stop service vmware-vpxd stop

After you have stopped these services, you need to change directories to /ssl/vpxd so we can create a certificate chain file that will be used by the vpxd service. This is a step that the VMware Documentation missed, but it isn't hard to do. To create this file, you need to run the following command:

[sourceode]cat certificatefile.crt chainfile.pem > chain.pem[/sourcecode]

Once the chain.pem file has been created, you are ready to change the certificate for the vCenter Service. You need to run the following command to make this change:

/usr/sbin/vpxd_servicecfg certificate change chain.pem vpxdkeyfilename.key

If this completes successfully, you should receive a VC_CFG_RESULT=0. If you receive a result that is not VC_CFG_RESULT=0, you can check this VMware KB article to find out what the problem is. Also check you file names to make sure that you have the correct chain file and key file names.

If everything has completed successfully, you will need to restart the SSO service before continuing on to change the Inventory Service Certificate. The command to restart this service is:

service vmware-stsd start

Changing the Inventory Service Certificate

The next certificate that you need to update is the vCenter Inventory Service certificate. Unlike the other two services on the vCenter Server appliance, the certificate chain for this service needs to be converted to a pfx file. Updating this certificate is a little more complicated as well since you need to unregister the Inventory Service from the Single Sign-On service before you can update the certificate. This is a step that will also need to be repeated with the Log Browser Service.

In order to unregister the Inventory Service, you need to enter the following commands on the appliance:

cd /etc/vmware-sso/register-hooks.d ./02-inventoryservice --mode uninstall --ls-server https://server.domain.com:7444/lookupservice/sdk

You will need to change the url in the second command by replacing server.domain.com with the fully qualified domain name of your appliance.

After you have successfully unregistered the Inventory Service, you will need to navigate to /ssl/inventoryservice to work with the certificate files that you copied over earlier. The first thing that needs to be done is to rename the rui_inventoryservice.crt and rui_inventoryservice.key files and remove the _inventoryservice from the file names. When this is done, the files should be named rui.crt and rui.key. There are multiple ways to do this with Linux, including using cat command to read the contents into a new file or copying the files to a new file name. One of the cleaner methods is to use the mv (move) command. The commands for this task are:

                mv rui_inventoryservice.crt rui.crt mv rui_inventoryservice.key rui.key

Before you can create the pfx file that the Inventory Service needs, you need to create a certificate chain consisting of the rui.crt and the certificate authority chain.

                cat rui.crt cachain.pem > chain.pem              

With the certificate chain file created, you can move onto creating the pfx certificate file for the Inventory Service. Like everything that we've done with certificates so far, we'll be using the OpenSSL command to create the file. The command to create the pfx file is:

openssl pkcs12 -export -out rui.pfx -in chain.pem -inkey rui.key -name rui -passout pass:testpassword

After you have created the PCKS12 file, you will need to copy it along with the rui.crt and rui.key files to /usr/lib/vmware-vpx/inventoryservice/ssl. The command to do this is:

cp rui.pfx rui.crt rui.key /usr/lib/vmware-vpx/inventoryservice/ssl

After you have copied the files, you will need to change to the investory service ssl directory and modify the permissions on the files. The rui.pfx file is set to be read-only by the file owner, and the other two files are set to read-write by the owner and read by everyone else. The commands to do this are:

cd /usr/lib/vmware-vpx/inventoryservice/ssl/ chmod 400 rui.key rui.pfx chmod 644 rui.crt

Finally, you need to reregister the Inventory Service with the Single Sign-On service. When you do this, it will use the new certificate file that you placed in the directory. Before you do this, you will want to run the unset HISTFILE command since you will be entering a plaintext password for a user account that has administrator rights to your single sign-on service. To run this command successfully, you need to change "server.domain.com" to your server's fully qualified domain name, sso_administrator to an administrator account in your SSO administrator (probably administrator@vsphere.local) and sso_password with your SSO password (if you ran the default config, it is blank).

cd /etc/vmware-sso/register-hooks.d ./02-inventoryservice --mode install --ls-server https://server.domain.com:7444/lookupservice/sdk --user sso_administrator --password sso_administrator_password

A successful result will look like the screenshot below:

You can have the vCenter inventory service reregister itself on a reboot by entering the following command:

rm /var/vmware/vpxd/inventoryservice_registered

You can also reregister the service manually by restarting the vpxd and inventory services.

service vmware-inventoryservice stop service vmware-vpxd stop service vmware-inventoryservice start service vmware-vpxd start

Replacing the Log Browser Certificate

Note: This will be the last certificate that we replace in this tutorial as the Auto Deploy certificate is not required if Auto Deploy is not used in your environment.

The last certificate that we need to replace is the Log Browser Service certificate. The process for replacing the Log Browser certificate is very similar to replacing the certificate for the Inventory Service, and you will need to take many of the same steps to complete this task.

To start this process, you will need to unregister the Log Browser service from Single Sign-On. You can do this with the following command after replacing server.domain.com with your appliance's fully qualified domain name:

cd /etc/vmware-sso/register-hooks.d ./09-vmware-logbrowser --mode uninstall --ls-server https://server.domain.com:7444/lookupservice/sdk

After you have successfully unregistered the Log Browser Service, you will need to change to the /ssl/logbrowser directory so you can work with the certificates that you copied over from your machine. The process is similar to what you did with the Inventory Service certificates, and you will need to remove the _logbrowser from the file names before creating a .pfx certificate file. The steps we need to take, like the Inventory Service above, are to rename the certificate and key files, concatenate the certificate and the certificate chain, and then create the .pfx certificate file. The commands to do this are:

                mv rui_logbrowser.crt rui.crt mv rui_logbrowser.key rui.key cat rui.crt cachain.pem > chain.pem openssl pkcs12 -export -out rui.pfx -in chain.pem -inkey rui.key -name rui -passout pass:testpassword

After you create the rui.pfx file, you will need to copy the rui.pfx, rui.crt, and rui.key files to /usr/lib/vmware-logbrowser/conf and then change the permissions on the certificate files. The commands for this is:

cp rui.pfx rui.crt rui.key /usr/lib/vmware-logbrowser/conf cd /usr/lib/vmware-logbrowser/conf chmod 400 rui.key rui.pfx chmod 644 rui.crt

The last step is to reregister the Log Browser service. The command to do this is below. To run this command successfully, you need to change "server.domain.com" to your server's fully qualified domain name, sso_administrator to an administrator account in your SSO administrator (probably administrator@vsphere.local) and sso_password with your SSO password (if you ran the default config, it is blank).

cd /etc/vmware-sso/register-hooks.d ./09-vmware-logbrowser --mode install --ls-server https://server.domain.com:7444/lookupservice/sdk --user sso_administrator --password sso_administrator_password

A successful result will look like the screenshot below:

If you received a success result, you will need to restart the Log Browser service by using the following commands:

service vmware-logbrowser stop service vmware-logbrowser start

The Log Browser service is the last certificate that we're changing, so you will need to reboot the appliance after you have successfully updated the certificate. The reboot allows all of the new certificates to take effect, and you may encounter certificate errors when logging into the web interface or the C# client until you reboot the appliance.

After a reboot, you shouldn't see any certificate warnings when logging into the Appliance management webpage or the vSphere Web Client…provided that you've installed the root and intermediate certificates on your machine.

Look, Ma! No Certificate Warnings!

This wraps up the process of updating certificates on the vCenter 5.5 appliance. I will be coming back to the vCenter Server Virtual Appliance in the coming weeks when I tackle building a VMware Horizon View environment on vSphere 5.5 (spoilers – Horizon View 5.2 works on vSphere 5.5), but I will be moving on to some other topics that I want to cover.

In my last few posts, I focused on configuring the vCenter Server Virtual Appliance. Now that the appliance is up and running, it's time to install and configure SSL certificates from an internal certificate authority. Much like the Windows vCenter application, SSL certificates are very important for vCenter 5.5 appliance.

SSL certificates in vCenter became an issue in vCenter 5.1 when a self-signed or invalid certificate could prevent an upgrade from a previous version from going forward. Those difficulties have been eased somewhat in vCenter 5.5 with the release of a certificate management tool that helps install the required certificates.

Before you can install certificates on the vCenter appliance, there are a few key points you should know about how certificates are used in vCenter and how those certificates need to be created. Derek Seaman covers this very well in his vCenter 5.1 blog. Instead of trying to duplicate his research and work, the links to will be provided below. I HIGHLY recommend that you read his posts on SSL certificates before you attempt to update the SSL certificates on the appliance.

The links to Derek's blog are:

In addition to Derek's blogs, a few tools you will need to generate and install new SSL certificates. Those tools, which are geared towards a Microsoft environment, are:

• WinSCP – used to copy new certificate files over to the appliance

• Putty – used to access the appliance's command line remotely to execute commands to install the certificates

• OpenSSL for Windows – Version 0.9.8y is recommended for creating the certificate signing requests for the vCenter Server Appliance certificates

• A PKI environment to mint certificates. This tutorial will use a Windows-based Certificate Authority

The instructions for updating the appliance's certificates can be found in the VMware Knowledgebase. Those instructions, along with some of the information Derek provided in his blog, will be used for this process.

Getting Started

The first thing that you need to do is create a certificate template on your Windows Certificate Authority. The instructions in Part 6 of Derek Seaman's blog covers this step very well. The template should be set up as a Windows Server 2003 Enterprise template if it should be available in the Certificate Services Self-Service web portal.

The next step is to download and install OpenSSL for Windows version 0.9.8y on a workstation or server. You should add OpenSSL to the Windows PATH variable. This will make it easier for you to use OpenSSL to generate the certificate signing requests later on.

Each service on the vCenter appliance will need to have it's own unique certificate. The best way to keep track of the three (or four if Auto Deploy is used) certificate requests is to create folders to organize the certificate signing requests, certificate files, and OpenSSL configuration files. The folders that should be created are:

• VMware vCenter Service Certificate

• VMware Inventory Service Certificate

• VMware Logbrowser Service Certificate

• VMware vCenter Autodeploy Service Certificate (optional, not required if Auto Deploy is not used)

You will need to create an OpenSSL configuration file for each folder. This file will contain the details that OpenSSL needs to create the certificate signing request, and these files will keep OpenSSL from prompting for information when you go to generate the certificate request. You will need to configure the subjectAltName field because your vCenter server will have multiple names that it can be accessed under, including the DNS single label name, fully qualified domain name, and IP addresses. You will also need to fill in your organizational details in the [req_distinguished_name] section.

Most of the fields in the configuration file only need to be changed once. When testing this procedure out, I found that the easiest way to manage this was to create a template with all the fields filled out except for the organizationalunitname field. I would then copy this template into each of the folders that I created, rename it, and then modify the file to update the organizationalunitname.

To create the configuration file, open up a text editor and paste the code below into it:

[ req ]  default_md = sha512 default_bits = 2048 default_keyfile = rui.key distinguished_name = req_distinguished_name encrypt_key = no prompt = no string_mask = nombstr req_extensions = v3_req input_password = testpassword output_password = testpassword  [ v3_req ]  basicConstraints = CA:false keyUsage = digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth, clientAuth subjectAltName = DNS:<DNS short name change me>, IP:<IPv4 Change Me>, IP:<IPv6 Change Me>, DNS:<FQDN Change Me>  [ req_distinguished_name ]  countryName = <Country Change Me> stateOrProvinceName = <State Change Me> localityName = <City Change Me> 0.organizationName = <Org Change Me> organizationalUnitName = <VMware vCenter Service Certificate, VMware Inventory Service Certificate, VMware Logbrowser Service Certificate, VMware vCenter Autodeploy Service Certificate> commonName = <FQDN Change Me>              

As mentioned above, the organizationalunitname field will need to be different for each configuration file. The value in this field should match the name of the service that the certificate will be used with.

Service	Folder Name	OrganizationalUnitName	Config File Name
vCenter Server	VMware vCenter Service Certificate	VMware vCenter Service	openssl_vpxd.cfg
Inventory Service	VMware Inventory Service Certificate	VMware Inventory Service	openssl_inventoryservice.cfg
Log Browser Service	VMware Logbrowser Service Certificate	VMware Logbrowser Service	openssl_logbrowser.cfg
AutoDeploy Service	VMware vCenter Autodeploy Service Certificate	VMware vCenter Autodeploy Service	openssl_autodeploy.cfg

There is a sample configuration file below. OpenSSL will generate a certificate signing requests for the vCenter Service Certificate when it is run with this configuration file. The lines that have been bolded are the ones that were updated.

[ req ]  default_md = sha512 default_bits = 2048 default_keyfile = rui.key distinguished_name = req_distinguished_name encrypt_key = no prompt = no string_mask = nombstr req_extensions = v3_req input_password = testpassword output_password = testpassword  [ v3_req ]  basicConstraints = CA:false keyUsage = digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth, clientAuth subjectAltName = DNS:vctest2, IP:10.1.1.161, DNS:vctest2.homedomain.private  [ req_distinguished_name ]  countryName = US stateOrProvinceName = Wisconsin localityName = Kimberly 0.organizationName = homedomain organizationalUnitName = VMware vCenter Service Certificate commonName = vctest2.homedomain.private              

Note: Make sure to use your ISO two letter country code otherwise you will get an error when trying to generate the certificate request.

Creating the Certificate Signing Requests

The certificate signing requests are files that the certificate authority will use to mint new SSL certificates. OpenSSL will be used to generate these, along with a new private key, after the configuration files are made. Three (or four if AutoDeploy is used) of these files will need to be created.

In order to create them, open a command prompt as an adminstrator and navigate to the folder where your OpenSSL configuration files are stored. You will need to run the following command to generate the certificate requests:

openssl req -new -nodes -out rui_service.csr -keyout rui_service.key -config openssl_service.cfg

If you wanted to generate the certificate request for the vCenter Server certificate, you'll want to open a command prompt as administrator, navigate to where your openssl_vpxd.cfg file is stored, and run OpenSSL this way:

openssl req -new -nodes -out rui_vpxd.csr -keyout rui_service.key -config openssl_vpxd.cfg

Submitting the Requests to the Certificate Authority

I'm not going to do a step-by-step walkthrough of submitting the requests to your certificate authority.

Once you have created all of the certificate requests, you need to submit them to your certificate authority to generate the certificates. If you are in a windows environment, there are a couple of ways to do this. You can submit them through the self-service web portal that can be accessed by going to http://nameofcertserver/certserv. You can also use the certreq.exe command line tool to submit the request.

If you created the VMware-SSL certificate template per Derek Seaman's post, then you'll want to use that template for generating the certificates. Otherwise you could use the Web Server template.

After you have created each certificate, you will need to download the certificate file as a Base64-encoded certificate file and save it as a .crt file. Windows Certificate authorities usually save the files as a .cer. You will also need a Base64-encoded copy of the certificate authority chain. This will include the root certificate and any intermediate certificates that might be used in your environment. This file comes as a .p7b, but I'll cover converting that to a .pem file in the next post.

Speaking of next posts, I will be covering what to do now that the certificates have been created.

The discussion in the last post of this series focused on getting the vCenter Server virtual appliance ready so the setup wizard could be run. In order to prepare the appliance to run the setup wizard, the following tasks needed to be completed:

1. Accepting the EULA

2. Configuring the network settings

Although it is not essential to running the setup wizard, the default root password was changed.

Now that the appliance's basic configuration is done, it's time to run the setup wizard and configure the vCenter application. The setup wizard will take care of the following tasks:

1. Configuring the database. Administrators will have the option to use the built-in PostgreSQL database or an external Oracle database. Microsoft SQL Server and IBM DB2 are not supported.

2. Configure the Single Sign-On Service for the appliance. Both embedded and external SSO are supported.

3. Join the appliance to an Active Directory Domain

4. Configure a time source for the appliance

It is very important to have completed the network setup and have assigned a hostname before starting the setup wizard as the appliance will generate self-signed SSL certificates that are used for securing the various services on the appliance. If you change the hostname after these certificates are generated, the services may not work properly. I had problems with this particular issue when working with the appliance in my lab.

Starting the Wizard

The Setup Wizard is located on the main dashboard of the appliance's management interface under utilities. Click Launch to restart the wizard.

The first screen of the wizard is the Configure Options screen. The options on this screen will direct how the wizard will run. The options that are available are:

1. Configure with default settings – This option configures the appliance with an embedded database and SSO instances. Active Directory and Time Sync are not configured.
2. Upgrade from Previous Version – This option is for upgrading an earlier version of the vSphere appliance to 5.5. This requires a key exchange with the older appliance.
3. Upload Configuration File – Administrators can provide a configuration file that contains the configuration settings for the database, single sign-on, and Active Directory. Creating and using this file will not be covered in this article (but may be covered in future articles), but documentation may be found here: http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.install.doc/GUID-67BC70A3-B160-4D62-88A6-925AB0C9043D.html
4. Set Custom Configuration – The wizard will display screens for configuring the database, single sign-on, Active Directory Authentication, and time sync services.

For this section, the Set Custom Configuration will be used.

Database

The first screen of the custom wizard is configuring the database. The two options that you can select are:

• Embedded – This is a version of vPostgres that is located on the appliance. If this option is selected, there is no further configuration needed.

• Oracle – This is an Oracle database instance located on another server. If this option is selected, a server name, TCP Port number, Instance name, and login information. This option is currently the only supported option for using the appliance with environments that are larger than 100 hosts and/or 3000 virtual machines.

Select the database option that is best suited for the environment and then click next to continue. The embedded database was selected for the test environment as there was no Oracle database in the environment.

When you click next, the appliance will verify the configuration before moving onto the next step.

Single Sign-On

The next screen on the wizard is for configuring the Single Sign-On (SSO) service. This service, which was introduced in vSphere 5.1, has been redesigned in vSphere 5.5. This component provides identity management for administrators and applications that interact with vSphere, and it can be configured to work across vCenters and applications in multiple locations.

Like the database, there are two options for configuring SSO. These options are:

• Embedded – The SSO service is managed on the appliance.

• External – The SSO service looks to an SSO instance running on another server. Having the time on all SSO servers is important if this option is being used.

A password for the administrator@vsphere.local account will need to be entered if the embedded option is selected. To use the external option, an SSO administrator account and URL to the lookup service will need to be entered as part of the configuration.

The embedded SSO was used when setting up this test lab.

Active Directory Settings

The next screen on the wizard is for configuring Active Directory in the appliance. To set up Active Directory, check the "Active Directory Enabled" checkbox and fill in the following details:

• Domain Name – this is the domain name of the domain. If the name of the local domain is testdomain.local, then that is what would be entered into the domain name field.

• Administrator User – User account with rights to join the appliance to the domain.

• Adminsitrator Password – Password for the user account with rights to join the domain

NOTE: In order to successfully configure Active Directory, the appliance needs to be configured with a fully qualified domain name as the hostname (see the Configuring the Network Settings section in this post ).

The appliance will verify the domain and account information when moving onto the next step. If it fails,it will return an error message and return to the settings page to verify the data that was entered.

If Active Directory is successfully configured, it will automatically configure the appliance's time synchronization to use Active Directory as a time source and skip to the Review Settings page.

Please be aware that this is only the first part of configuring Active Directory authentication in the vCenter Server Appliance. There are additional steps that will need to be taken after logging into the vCenter Web Client. Those steps will be covered in a future post.

Time Synchronization

The final configuration screen of the wizard is setting up time synchronization. If the appliance is set up with Active Directory enabled, this screen will be skipped and the appliance will be configured to use Active Directory as the time source.

There are four options on this screen, but only three of them are available to be selected. Those options are:

• No Synchronization – Exactly what it says on the tin.

• NTP Synchronization – The appliance will retrieve the time for one or more NTP servers such as us.pool.ntp.org.

• VMware Tools Synchronization – The appliance will retrieve the time from the vSphere hosts through VMware Tools

• Active Directory Synchronization is an option on this screen, but it is disabled. This is automatically selected and configured if the appliance is joined to an Active Directory domain.

Select the option that best fits the environment and click next to move onto reviewing the settings for the appliance.

Review Configuration

Like any good software package, there is a chance to review the configuration one final time before it is applied. If something isn't configured correctly, it can be changed by going back to the correct page. If everything is right, the configuration can be applied by clicking Start.

When the process to apply the configuration starts, the appliance will log out any users and reboot. During the reboot, the appliance will generate self-signed certificates for the vCenter Server and SSO, the Inventory Service, and the Log Browser. It's important to make sure you have the correct fully-qualified domain name and IP address configured on the appliance before the self-signed certificates are generated. I ran into a lot of issues changing the appliance's name after the Setup Wizard was run as the SSO and Inventory services would not run if the certificate didn't match the hostname. Regenerating the certificates did not resolve this issue either.

The next article in this series will cover generating and installing new SSL certificates for the three services that require them – the vCenter Server and SSO, the Inventory Service, and the Log Browser service.

Now that the vCenter Server Appliance has been imported onto an ESXi host, it's time to start adding hosts and building clusters, right? Well, not so fast. The install process might be significantly easier compared to vCenter for Windows, but that doesn't mean that the appliance is ready for us just because you've imported it and turned it on.

Instructions for getting the appliance onto an ESXi host were covered in the last post. Now that it is there, some basic configuration tasks will need to be performed before the setup wizard can be run. The setup wizard will take care of handling the Single Sign-On setup, database configuration, and Active Directory and time-sync tasks, and that will be covered in the next post.

So what tasks need to be completed before the setup wizard can be run? There are a few:

1. Time zone configuration

2. Network Setup

3. Accepting the EULA

4. Changing the Admin Password

Only after these tasks have been taken care of can you start the setup wizard that configures Single Sign-On, Active Directory Integration, the database, and time-sync. Those items, and the setup wizard, will be covered in the next post.

So you've got the appliance imported…now what?

Once the appliance has been imported, the appliance will need to be turned on. It may have been powered on automatically if you selected that option during the import process. The next thing to do is open the console through the vSphere Client. The console is necessary for one of the steps in setting the appliance up.

The first configuration step that will need to be performed is one that cannot be done through the web interface – setting up the time zone. There is an option from the console screen to select a new time zone, however, this does not appear to work. The screen flashes black and then goes back to the main console screen.

Logging into the console will be required to change the time zone. You will need to take the following steps to complete this task:

1. Select Login and press enter
   

2. Log in as root. The default password is vmware.
   

3. Enter the tzselect command. This will launch a guided time zone selection utility where you select your continent, country, and then time zone.
   

4. Follow the prompts to select your continent, country, and time zone. For example, if you're going to select the Central (US) time zone, you would select 2 (America), 49 (United States), 11 (Central). Press 1 to confirm.
   

5. Type logout to return to the blue console screen.

Note:  It turns out that timezone selection is no longer supported in the vCenter Appliance per this KB.

Logging into the Management Interface

Once the time zone has been set, you can move on to logging into the management interface. This is a web-based interface that provides a way to manage some systems tasks without having to remember the commands to do them from the CLI. It also provides a wizard-based method for configuring the application.

The vCenter Server Appliance actually contains two web interfaces. There is the vCenter Client Web Interface, which is a web-based version of the vSphere C# client, and the management interface that allows an administrator to configure the client. The management interface is the one that we'll need to log into in order to complete the basic setup.

This appliance is newly installed in the environment, and no network configuration has been done yet. The appliance is set up to retrieve an IP Address and other network settings from DHCP, and no host name has been assigned. The IP address will need to be retrieved from somewhere in order to log into this device. Thankfully, that information is displayed twice on the console.

Location of IP Address on console, circled in red

With the IP address in hand, it is time to log in to the management interface. To do that, take the following steps:

1. Open your favorite web browser.

3. Accept any certificate warnings

4. Log in as root with vmware as the password

5. Upon the first login, a screen to accept the EULA will come up. Check the "Accept the License Agreement" box and click next.
   

6. The setup wizard will launch after the EULA is accepted. Click cancel. The setup wizard will need to be run later in the process.

Changing the Administrator Password

Changing the default root password is one of the first things that should be done on any new system – especially one that is central to the administration of an environment like vCenter Server. A secure, complex password should be used for this account, and it should be stored in a safe place such as a password vault.

To change the root password:

1. Click on the Admin tab.
   

2. Type in the current password

3. Type in a new administrator password and confirm the new administrator password

4. In order to successfully change the root password, one of two things needs to happen:
   A. Password expiration needs to be turned off
   B. An email address needs to be entered to send password expiration reminders

5. Click submit to change the password.

The system will not log the root account out after the password has been changed.

Configuring the Network Settings

The final configuration task that needs to be completed before the setup wizard can be run is configuring the appliance's network interface. This is handled on the network tab. The appliance is set up to use DHCP when it is first imported into the environment. That should be changed to a static IP and have a hostname assigned. The appliance will support both IPv4 and IPv6, but I will only cover the IPv4 setup. The IPv6 fields can be left blank if that protocol is not used in your environment.

This step needs to be completed before the setup wizard is run because the appliance will generate SSL certificates on the first reboot after the setup wizard runs.

To change the network settings:

1. Click on the network tab. This will bring up the network status screen where the current IP configuration can be viewed.
   

2. Click on the Address button. This will bring up the screen to change the network settings.

3. Change the IPv4 Address Type to Static.  This will allow the network properties to be edited.
   

4. Enter a fully-qualified domain name in the Hostname field.

5. Enter the IPv4 Default Gateway in the IPv4 Default Gateway Field.

6. Enter the Preferred and Alternate DNS servers in the appropriate fields.

7. Enter the IPv4 Address and netmask in the appropriate fields.

8. IPv6 cannot be disabled on the appliance. Set the IPv6 Address Type to Auto if that protocol is not used in your environment.

9. Click Save Settings.

Anyone logged into the appliance when the network settings are updated will be logged out. To reconnect to the appliance to run the setup wizard, connect to https://<NewIPAddress>:5480 or https://<appliancehostname>:5480.

That covers the basic setup, and the appliance is ready to run the setup wizard to configure SSO, the appliance database, and Active Directory configuration. Those steps will be covered in the next post.

In this installment of the vCenter Server Virtual Appliance guide, we'll cover getting the appliance into your virtual environment.

Since this is a virtual appliance, the setup is much easier than the Windows vCenter Server. A Windows Server and SQL database will not need to be provisioned and configured as most of this work has been done for us by VMware.

Getting Started

In order to get started with the vCenter Server Appliance, there are a few things that will need to be downloaded and/or installed. Those items are:

1. The vCenter Server Appliance through your MyVMware portal site

2. The vSphere C# Client

3. A supported Web Browser. The supported web browsers for Windows are
   Internet Explorer 8 and Up
   Firefox – Current version
   Chrome – Current version

Importing the vCenter Appliance

VMware provides the vCenter Server Appliance as an OVA file that contains the .vmx, .vmdk and other files that the virtual machine needs to operate. In order to use this in any environment, it will need to be imported.

The following steps are needed to import the appliance:

1. Open the vSphere C# Client

2. Log into a host in your environment that will be managed by this vCenter instance

3. Go to File -> Deploy OVF Template
   

4. Select the vCenter Server Virtual Appliance file that was downloaded from myvmware.com and click Next.
   Note: The file extension of the appliance can be OVF or OVA. OVA includes everything needed to deploy the appliance in one file.
   

5. Enter a name for the virtual appliance. This will be the name that shows up in the vCenter Inventory.

6. Select the datastore that the appliance will be stored on. For new installs, this may be local storage.
   

7. If you want to preallocate space for the appliance, the Disk Format screen will allow the format to be changed to Thick or Thin Provisioning.

8. Map the Appliance network adapter to the correct virtual network. In new environments, this will probably be VM Network.
   

9. Review the summary of deployment settings. Click finish to begin the import. If you want the appliance to power-on once the import completes, check the "Power on after deployment" checkbox at the bottom of the screen.
   

10. Once the import begins, you will see a small progress window. The appliance is now being imported into your ESXi host
    

Depending on your network connection to your host, this could take a few minutes. It also makes a good place to take a break. Part 3 will cover the basic setup of the appliance such as setting the timezone, network settings, and preparing to run the setup wizard.

One of the innovations that was released with vSphere 5.0 in 2011 was a Linux-based vCenter Server virtual appliance. This appliance, while it had potential, was limited in many ways with a maximum of five hosts, fifty VMs and a version of IBM's DB2 as the database.

Fast forward two years, and the vCenter Appliance is starting to come into it's own. The database has been updated to PostgreSQL and the host/guest count has been increased to 100 hosts and 3000 virtual machines. The web client has become the management interface of the future. It has gained a speed boost compared to previous versions, and all new features and support are now accessed through this interface.

Although the virtual appliance is easier to deploy and manage, there are some features that are in the Windows version that are not included with the appliance. Those features are:

• Oracle is the only supported external database. There is no support for IBM DB2 or Microsoft SQL Server.

• Linked-mode is not supported on the vCenter Server Appliance

If you require Microsoft SQL Server or linked-mode in your environment, you will need to use the Windows vCenter Server. Derek Seaman has a great series he's running on configuring the Windows vCenter Server on his blog.

If you have an existing vSphere environment, you might be stuck with the Windows vCenter Server for the time being. There does not appear to be a supported migration path from the Windows vCenter Server to the appliance. The only option for implementing the appliance in an existing environment would be to start over. This may not be feasible if you have customized the permissions, alarms, or reporting for your environment, and this might hurt adoption of the appliance in some cases.

This series will cover the installation and configuration of the vCenter Server Appliance, and it will focus on the following topics:

• Installation of the appliance

• First power-on and initial setup

• Intial Configuration

• Single Sign-On Configuration

• Installation of new SSL Certificates

• Active Directory Integration

• Using the Web Interface

• Possibly some additional topics

Resources and Requirements

VMware has a suite of documentation available for download on their website. Two of the manuals that we will be drawing from are the vSphere Installation and Setup manual and the vCenter Server and Host Management manual. A couple of knowledgebase articles will also be referenced.

The list of hardware requirements is smaller than the Windows Server since there is less to set up – the appliance comes preconfigured with most of the hardware already configured. The appliance must be run on ESX/ESXi 4.0 or later.

The only thing that an administrator would need to change would be the amount of RAM allocated to the VM. That varies by inventory size, and those numbers are listed below.

• Very Small Inventory (less than 10 hosts and/or less than 100 VMs) – at least 4GB of RAM

• Small Inventory (10-100 hosts and/or 100-1000 VMs) – at least 8GB of RAM

• Medium Inventory (100-400 hosts and/or 1000-4000 VMs) – at least 16 GB of RAM

• Large Inventory (More than 400 hosts and/or more than 4000 VMs) – at least 24 GB of RAM

Note: The vCenter Server appliance officially supports 100 hosts and 3000 VMs. The numbers posted above are taken straight from page 19 of the vSphere Installation and Setup manual and may not, in some cases, represent officially supported configurations.

The appliance is configured to use 8GB of RAM when it is imported into your environment. I probably wouldn't change that even if I had a very small deployment. There really isn't a need to unless RAM is a constraint in your environment.

Although the vCenter Server Virtual Appliance does not require a Windows Server instance to run, Windows Server may be required for other components that might have otherwise been installed with vCenter Server.  The two components that come to mind immediately are the vCenter Update Manager (VUM), the ESXi equivalent to WSUS (ok…not a perfect analog, but good enough for now) and View Composer, a component of VDI environments that handle linked-clone VMs.

Use Cases for the Appliance

Is the vCenter appliance right for all environments? No. Like any piece of technology, it may not be the best fit for your environment or the skill sets of your administrators. But it may be right for a lot of environments.

So where could I use the vCenter Appliance? I have a couple of places where I would use it. This is my opinion, and I'd love to get your feedback in the comments.

1. New virtual environments

2. Smaller virtual environments (note – no migration path currently exists from Windows to Appliance)

3. Environments that want to reduce Windows license count as much as possible

The new host and VM limits should make it possible to use the appliance with virtual desktop deployments. I did get a very small (5 desktop) Horizon View 5.2 running on vSphere 5.5 in a test lab using the appliance. I hope to cover Horizon View on vSphere 5.5 in a later series.

There are also a few environments where the vCenter Appliance would not be a good fit.

1. Environments where PostgreSQL is not an approved database

2. Environments that must have an off-box database but do not have Oracle

3. Environments where Linked-Mode is required

4. Environments that exceed the number of supported hosts and/or VMs

Tune in Next Time…

In my next post, I will talk about installing the appliance in an ESXi environment and doing the initial configuration.

winchesterhishoupers.blogspot.com

Source: https://thevirtualhorizon.com/category/vmware/vcenter-server-virtual-appliance/

Share this post