vCenter Server Appliance 6.0 in VMware Workstation

For demo’s, presentations, breaking environments or just killing time I have a portable testlab on my notebook. Yes I know there are also options for permanent labs, hosted labs and Hands-on labs for these same purposes. Great places for sure, but that is not really what I wanted to discuss here.

As I am break.. ehhh rebuilding my lab to vSphere 6.0 I wanted to install VCSA 6.0 in VMware workstation. Nice, import a my vmware downloaded VCSA-versionsomething.ova (after e-mail address number ####### registered over there) and we are done! …….. Well not quite.
First the vCenter download contains the OVA, but it is a little bit hidden. The guided installer will not help you here. You will need to mount or extract the downloaded ISO and look for vmware-vcsa in the vcsa/ folder.

VCSA Location
Copy the vmware-vcsa file to a writable location (when just mounted the ISO) and rename vmware-vcsa to vmware-vcsa.ova. And now we can import the ova to VMware Workstation. When the import finishes, do not start the VM yet. Certain values that are normally inserted via the vSphere Client or ovftool are to be appended to the VMX file of the imported VCSA. Open the vmx in the location where you let Workstation import the VM. Append the following lines: = “ipv4” = “static” = “” = “8” = “” = “”
guestinfo.cis.vmdir.password = “vmware-notsecurepassexample”
guestinfo.cis.appliance.root.passwd = “vmware-notsecurepassexample”

Note: Change the net and vmdir/appliance.password options to the appropriate values for your environment.

If not appended when you start the VCSA an error: vmdir.password not set aborting installation is shown on the console (next to root password not set) and network connection will be dropped even if you configure these on the VCSA console (via F2).

Save the VMX file.

And now it is time to let it rip. Start up your engines. And be patience until…lo and behold:

VCSA Running in workstation

And to check if the networking is accepting connections from a server in the same network segment open up the VCSA url in Chrome for example. After accepting the self signed certificate unsecure site (run away!) message you will (hopefully) see:

VCSA in Workstation

Next we can logon to the Web client (click and accept the unsecure connection/certificate) and logon via [email protected] and the password provided in the VMX (in the above example vmware-notsecurepassexample). As a bonus you now know where to look when you forget your lab VCSA password ;-).

VCSA 6 Web Client

(And now I notice the vCenter Operations Manager icon in the Web Client Home screen. Why is this not updated like vRealize Orchestrator 🙂 )




Migrating vCenter databases from SQL Express to SQL Server

When installing vCenter you will need a vCenter database, an Update Manager database and with vCenter prior to 5.5 also a SSO database (RSA). With the installation you have the option to point to an (existing) dedicated SQL Server, SQL Server on the same Windows host or use the bundled SQL Express with the installer. Depending on the requirements of the environment a design decision is made to which sort of database setup vCenter will communicate. I prefer to separate the database resources and services from the vCenter server and will often option for a dedicated SQL Server or SQL instance part of SQL mirror/cluster. But sometimes the size of the environment is small enough, and a dedicated SQL license is a constrain at the design/build phase, test/pilot grows into production (don’t!), in these situations SQL Express is `fine’. Fine and supported up to a vCenter inventory of max 5 hosts and or 50 VM’s. No.. your vCenter will not crash immediately after adding a sixth, seventh or whatever hosts but performance is degraded to a point that certain sub processes/services are not running within optimal limits. This can have unforeseen consequences to your environment, and this is not what is wanted in production.

This post will combine the migration of SSO, vCenter and Update Manager databases from SQL Express to SQL Server. Yes you are missing a database, vCenter Orchestrator should be migrated as well. Moving this database should be included when using, use the vCenter Orchestrator Configuration service to point to the destination database server (stop orchestrator server to move.) Unfortunately when using the vCenter simple installation with a bundled SQL Express this combination is not used very often or not at all (a shame).

The proces

Migrating SQL Express from the bundled to a full installation includes the following actions:

  • Assess your environment. What database names are used, what users and do you have the correct administration of users and passwords (see the SSO paragraph below for a way to find out the current RSA_DBA and RSA_USER passwords). Decide on whether you want to use the same users, or use new ones. Same goes for ports of destination SQL Server, Authentication mode used here etc. Always check the interoperability of vCenter with the database version. Do they support each other? Use SQL Authentication with the SSO database, vCenter supports Windows authentication (Best Practice) and SQL users.
  • Plan for some downtime of SSO, vCenter and Update Manager. As your moving services and databases from one server to another, the vCenter, SSO and Update Manager services must be stopped before and until the data is copied and configuration is changed, remain down. No VM workload is hit and remain running, and host can be managed via the standalone vSphere client during changes. That is, versions before 5.5 and hardware version 10.
  • Create back-ups of the to change files, registry keys and such before changing values.
  • Migrate the SSO database. This step is only for pre-5.5 versions as SSO in vCenter 5.5 does not use a database.
  • Migrate the vCenter database.
  • Migrate the Update Manager database. That is when Update Manager is installed on the same SQL Express instance. Normally you would see this combination when a SQL Express Windows vCenter server is used.

Migrating the database itself can be done via a SQL Backup and restore (overwrite), detach-copy-attach, or SQL Server Import/Database Copy Wizard. Prior to the database move the appropriate services must be stopped. When doing the copy in one task, stop the services as described in the following paragraphs. If you use the one go and backup or copy is finished stop the SQL Express (VIM_SQLEXP).


Not sure what your current RSA_USER/RSA_DBA passwords are. Go to the SSOServer\utils directory in an elevated prompt and run the following command:

ssocli manage-secrets -a listallkeys

Stop the vCenter Single Sign-On service. After the service is stopped backup and restore or copy the database files on the destination SQL Server. For SSO two SQL users are created by the installer, RSA_DBA and RSA_USER. RSA_DBA is only used when doing the installation, not needed for this migration. For operational purposes RSA_USER is used. Add the login/user to the destination SQL Server and set the password / required permissions if these where not saved.

Open an elevated command prompt and go to the SSOServer installation directory\utils directory. For example when installed on D:

SSO Directory

Run the following command: 

ssocli configure-riat -a configure-db –database-host newdbhost –database-port newdatabaseport –rsa-user RSA_USER –rsa-user-password password -m master_password

Replace the database hostname, database portnumber 1433 for standard SQL. Add the RSA-USER password and -m master password is the [email protected] password. rsa-user-password works only in combination with rsa-user option.

Open a text editor (also with elevated permissions if required). Open the following two files:

  • SSOServer\webapps\ims\web-inf\classes\

Check the values:

    • com.rsa.db.type=MSSQL.
    • com.rsa.db.instance=RSA. (or whatever your RSA instance dbname is)
    • com.rsa.db.msserverinstance= . Leave empty when using the default MSSQLSERVER instance on the destination server.
    • com.rsa.db.hostname=destinationSQL server.
    • com.rsa.db.port=1433.
    • Note: don’t mix up the com.rsa.instanceName. This is not the SQL Instance, but the SSO instance. This should not be changed.
  • SSOServer\webapps\lookupservice\WEB-INF\classes\

Check the values:

    • db.url=jdbc:jtds:sqlserver://;serverName=;portNumber=1433;databaseName=RSA. PortNumber has to be added here.
    • db.user=RSA_USER
    • db.pass=yourpassword
    • db.type=mssql
    • SQL server fqdn.

Change the lines appropriately to you environment. Save the files.

Start the vCenter Single Sign-On service.

vCenter System

Stop the vCenter services. Include all vCenter services except Update Manager, Orchestartor or SSO. After the service is stopped backup and restore or copy the database files on the destination SQL Server. Add the login/user to the destination SQL Server and set the password / required permissions if these where not saved. The user needs db_owner on the vCenter database and dbo on MSDB system database on the destination server.

Reconfigure the System DSN to use the destination SQL Server. Use the 64-bit ODBC Manager. When using a default installation of MSSQL server, the default MSSQLSERVER instance does not have to be filled in, connection to the SQL server hostname is enough. When using Windows credentials the ODBC is editted in the service account user. Change the default database to the VIM_VCDB or what ever name you gave it. Test the connection to be sure everything works.

ODBC vCenter

Update the ODBC connection in the registry:

  • Click Start > Run, type regedit, and click OK. The Registry Editor window opens.
  • Navigate to HKEY_LOCAL_MACHINE > SOFTWARE > VMware, Inc > VMware VirtualCenter.
  • Modify the key DbInstanceName and remove the current Value data. Do not delete this key.
  • Modify the key DbServerType and change the Value data from Bundled (the SQL Express) to Custom.
  • Navigate to HKEY_LOCAL_MACHINE > SOFTWARE > VMware, Inc > VMware VirtualCenter > DB.
  • Modify Key 4 and change the ODBC driver to the new driver if not changed check this value and leave intact.
  • Modify key 2 and add the vCenter Server SQL user, for example vcuser.

The password that is set (at key 3) is needed to be change, open an elevated command promp and run the following command:

<install drive>:\Program Files\VMware\Infrastructure\VirtualCenter Server\vpxd.exe -p

Go to the SQL Server and recreate the SQL Jobs. Launch SQL Server Management Studio on the SQL Server and Navigate to SQL Server Agent. In the Jobs list create the following jobs:

Rollup Job SQL Job Filename
Event Task Cleanup vCenter Database job_cleanup_events_mssql.sql
Past Day stats rollup vCenter Database job_schedule1_mssql.sql
Past Month stats rollup vCenter Database job_schedule3_mssql.sql
Past Week stats rollup vCenter Database job_schedule2_mssql.sql
Process Performance Data vCenter Database job_dbm_performance_data_mssql.sql
Property Bulletin Daily Update vCenter Database job_property_bulletin_mssql.sql
Topn past day vCenter Database job_topn_past_day_mssql.sql
Topn past month vCenter Database job_topn_past_month_mssql.sql
Topn past week vCenter Database job_topn_past_week_mssql.sql
Topn past year vCenter Database job_topn_past_year_mssql.sql

Adding the jobs: browse to Program Files\VMware\Infrastructure\VirtualCenter Server\sql or whever your install path is. Open the corresponding SQL file (Open > file). Select the vCenter database. Execute Query. And repeat for others.

When finding existing jobs, check that the corresponding SQL user in jobs is correct. Right click the Job, properties and check the user. And the database name is correct, if not recreate them.

Check the file for the corresponding values. On Windows 2008R2 and higher this file is located in C:\ProgramData\VMware\VMware VirtualCenter (check show and uncheck hide files and protected files in explorer). When using SQL authentication set the file value url= ;integratedSecurity\= to False. When using Windows authentication set this value to true. the rest should match sqlserver://<destination server>\\SQL instance;databaseName=\dbname; dbtype=mssql.

It is important that the Windows user has the required permissions on the SQL database and the VMware VirtualCenter Management Webservices and VMware VirtualCenter service is set to run as this user.

Remove the depend on SQL Express in the vCenter services. Open regedit and goto HKLM\System\CurrentControlSet\Services\. Remove the SQL Express service value from the DependOnService Multi string in the vCenter services where set. Do not delete the value, just removing the VIM_SQLEXP from the data is enough. The other dependencies should remain intact. Start the vCenter services. Check the logs if everything starts up correctly.

Update Manager

Last one. Stop the vSphere Update Manager services. After the service is stopped backup and restore or copy the database files on the destination SQL Server. Add the login/user to the destination SQL Server and set the password / required permissions if these where not saved. The user needs db_owner on the Update Manager database and dbo on MSDB system database on the destination server.

Reconfigure the System DSN to use the destination SQL Server. Use the 32-bit ODBC Manager. On Windows 2008R this is located in the C:\Windows\SysWOW64\odbcad32.exe. On Windows 2012 you can select the 32-bit from the apps menu.
When using a default installation of MSSQL server, the default MSSQLSERVER instance does not have to be filled in, connection to the SQL server hostname is enough. When using Windows credentials the ODBC is editted in the service account user. Change the default database to the VIM_UMDB or what ever name you gave it. Test the connection to be sure everything works.

Next go to your installation directory of Update Manager, for example D:\Program Files (x86)\VMware\Infrastructure\Update Manager\, and launch VMwareUpdateManagerUtility.exe (sometimes takes a while to start up). Login with an admin in vCenter (should have the user that installed and registered Update Manager to the vCenter in the user screen.
Click on database settings. Check the DSN name is the same you editted and tested. Type the SQL username and password twice. Click apply.

VMware Update Manager Update Manager database Settings

Start the vSphere Update Manager service.

After all changes be sure to check the vCenter Service Status if all is in green here. Some tracking or statistics roll up need the jobs to complete. This can take some time.

– Hopefully this helps you migrating from your SQL Express.


Design Choice: vCenter Windows or vCenter Server appliance?

A question that is again popping up lately is whether customers must go for the vCenter Server Appliance (VCSA) or a Windows based vCenter system. Yes I have my favorite, but I will often go for the consultant answer: it depends. But on what does this depend? I will try and sum up some of the arguments to take in to account.

But first, what is this VCSA your talking about?

You may or may not know vCenter can be deployed in two ways, the commonly known vCenter installation on a Windows based host(s) or deploying vCenter as a appliance. The appliance is a 64-bit Linux based (SUSE Linux Enterprise for the distro interest) virtual machine with an embedded database (vPostgres) or the option to use an external Oracle database. The appliance has been around since it’s introduction with version 5.0, but has not been really production worthy since the 5.5 version. With the 5.5 version the vCSA supports managing 100 hosts and 3000 VM’s with the embedded database versus the 5 host and 50 VM’s with the previous version. The 5.5 limit for the external Oracle database is even higher (100 hosts and 10000 VM’s), but to be honest I haven’t seen that combination around.


The appliance is build with the following vCenter services: vCenter services (vCenter, Inventory, SSO, Web Client) and services such as syslog collector, dump collector, AutoDeploy (and capable of doing DHCP/TFTP).

vCSA services

What are the arguments to consider?

  •  For organizations that are having a DBMS install base of MSSQL there is currently no support of using this in combination with the vCSA where the Windows based happily works with MSSQL (via ODBC DSN). If there is no experience, no business investment or no DBA’s wanting to manage an additional DB flavor you can stop right here (or wait when a next version of VCSA will hopefully support MSSQL as an external database).
  • Windows vs Linux install base and license. You got your Windows based organizations and you got your Linux based organizations. More often they are mixed. Got Windows data center licenses sorted out for your organization, another Windows VM is often not an issue. Need to save some licensing or just don’t want to invest in new, VCSA will probably be more of your taste. Beware that you can’t install Update Manager on VCSA, this still needs to be set up on a Windows host which can be an existing. Same goes for your trusty toolset, PowerCLI needs Windows PowerShell, RVTools need .Net. These tools can be easily put on a management server or admin workstation (where the toolset are supposed to be on the first place), they connect to VCSA just as vCenter on Windows. Need remote CLI? Added by deploying the vSphere Management Assistant (vMA) appliance. For Windows only based IT departments a knowledge investment is needed to support Linux based appliances.
  • vCenter Orchestrator. Windows vCenter installers installs vCenter Orchestrator on your Windows system or you can use the Windows installer to install Orchestrator on another designated Windows server. vCenter Orchestrator is not installed on the VCSA, but there is the vCenter Orchestrator appliance you can deploy next to it.
  • Linked mode. Want a single management plane, or in other definition a Single Pane of Glass, for multiple vCenter instances linked mode is required. VCSA does not support Linked mode where vCenter on Windows does. There is an other option, leveraging the built-in SSO Replication by joining all (or some you want to share) SSO instances under a common domain. A benefit next to the automatic synchronization, is that you will be able to see the inventory of all SSO instances from whatever Web client.
  • Experience with appliances. I think appliances add simplicity for deployment of the vCenter systems, but can be a hassle to (re)configure and for example do database back-up dumps when you don’t have any experience with Linux. Don’t worry, VCSA has an admin Web interface or the vSphere Web client for configuration tasks and when you need the console commands are documented. The procedures are on Documentation Center, Knowledge Base and widely blogged about in the community. Go ahead and learn appliances as there are a lot of good ones.
  • Monitoring/Back-up. Monitoring of vCenter server services and system parameters. If you use a Windows based or agent type of monitoring, the Windows based monitoring does not work for a Linux appliance. Check if your monitoring solution supports Linux. Same goes with thinking about your back-up strategy and how to back-up the VCSA.
  • Physical vCenter. When there are reasons to install the management of your virtual infrastructure on a physical server outside the virtual infrastructure, than Windows vCenter is the only option. VCSA is a virtual appliance which needs to be deployed on virtual environment. Depending on the requirements, you could also go with an VCSA deployment in an other vSphere cluster than the one vCenter is managing.
  • IPv6. IPv6 is not supported on the VCSA and is supported on Windows. If you happen to use IP addresses in the vCenter configuration or connecting to vCenter these are IPv4 only. To connect to vCenter system in an IPv6 environment you must use the fully qualified domain name (FQDN) or host name of the vCenter Server. FQDN is preferred to be used in any case.
  • vCenter Server Heartbeat. Use this solution to protect your vCenters, you cannot use this with the VCSA. But on the other hand, you should be working on a replacement solution (you have some time) as VMware announced EOA of all vCenter Server Heartbeat versions. See details here: Leveraging vSphere HA instead for example.

Note: These arguments are not ordered by importance, that’s is up to the organization in question.

And what do you think?

I have a favorite, but do keep in mind that there is no one size fit’s all. I happen to like the appliance way of deployment, simplicity at your fingertips and no abuse from Windows admins logging on and hogging the vCenter resources (sizing) with OS / RDS footprint. Or worst destroying to system with all those I needs this and this tool for my work.

Yes you need Windows for Update Manager, which can be combined with other update management tools. And yes you need your Windows based tool set somewhere, are those supposed to be on the vCenter server in the first place?
When a design decision is made to use the Windows based vCenter, please use it as an infrastructure server. Don’t abuse it as an administrator playground (aka RDS server, aka steppingstone, aka PowerCLI test heaven). I like to remove the GUI aka use core when Windows is the design choice (PowerCLI Get-WindowsFeature *gui* | Uninstall-WindowsFeature –Restart). From Windows version 2012 switching from GUI to core does not require a reboot.

What do you think? I’m interested in your views. Let me know in the comments.


vCenter 5.5 SSO after initial installation steps

As you probably know (or don’t) from vCenter version 5.1 Single Sign-On (SSO) has a password policy. This password policy is for the SSO component only, not for the external identities (like AD DS). For version 5.1 the maximum lifetime of a password is default 365 days. This means the password will expire in 365 days and the account will be locked. After installation we are used to either changing this to a setting appropriate for your organizations security policy (smaller or greater than the default) or to an non-expiring (0) value, and adding an additional user/group source to the SSO administrators for access to SSO (like setting permissions on your vSphere infrastructure objects). Preferred is using an domain user/group to add to your SSO administrators. Yes domain does also have a password policy, but you only have to worry about it at the domain level. Expired SSO admin, login to SSO, reset and you good to go using SSO admin again. When using a password policy for the SSO admin be sure to have a procedure in place to notice you on time that the password will expire and how to change this. It if often enough that the system is installed and this or saving the password somewhere is forgotten. It can also be an inconvenience that the vSphere Web Client (or an other task, alarm what ever) won’t remind you when the password is about to expire. Have some procedure in place.
When using a password policy be sure to set it a the correct level so your users won’t be post-it pasting it to their monitors.

Okay, but help me what is SSO again?

SSO is an authentication and security broker between a identity source (like local OS, LDAP or Active Directory) and accessing several vSphere solutions. Want to use vCenter you will be authenticating to SSO, want to use operations you will be authenticated to SSO and so on. Below is a model taken from the site giving a graphical representation on SSO and it’s role.


As you see SSO is a critical component in the authentication/security within a vSphere infrastructure. Lose access to SSO, you will lose access and functionality (when configured to use the expired account) of a lot of components. It’s is a required component when installing a vSphere infrastructure and should be set-up at step one.

What do we need to know in vCenter SSO 5.5?

There is still a password policy for [email protected] (okay that is also change from [email protected]) and is standard set to expire after 90 days. Login to the vSphere Web client with [email protected] (or other SSO administrator). Go to Administration – Single Sign-On – Configuration – policies to take a look for your self.

When trying to reset the maximum lifetime to 0 you will be presented with an nice non-descriptive error message “The error has no message.” Whaaaat?!?
Fortunately there is a KB article 2053196 in the VMware knowledge base for that.


In other words you can’t set it to unexpired. You can set a maximum value of 9999 as the maximum lifetime value. This will keep you going for some years….


Be sure to change the other policies accordant to your organizations security policy. Same goes for the lockout and token policy.

How do we add the additional users to the SSO admin group again?

Login to the vSphere Web client with [email protected] (or other SSO administrator). Go to Administration – Single Sign-On – Users / Groups. Select your group and click the add member button (the plus user). In the Add Principals select your identity domain and user or groups you wish to add.


Great to have that sorted again. Now off to add more roles to my vSphere 5.5 testlab.

– Happy SSO’in !

VMware vCenter – Remove Infrastructure Navigator Extension

Installation of trial applications sometimes goes wrong and you will have to remove the extension from vCenter. How will you do that with the web client?

  1. Go to your Managed Object Browser vCenter URL. That is https://<vcenter fqdn or ip>/mob.
  2. Logon with vCenter credentials.
  3. Click on content link in the Contentservice colum.image
  4. Click on ExtensionManager.
  5. Find your to remove extension in the list. For infrastructure navigator this is com.vmware.vadm. (vadm stands for vCenter Application Discovery Manager which is the predecessor of infrastructure navigator).
  6. Choose the UnregisterExtension method.image
  7. Fill in the extension name in the string box (in this case com.vmware.vadm).
  8. Click Invoke Method.
  9. You will get a response like void. Refresh the extension list to check is it is removed.

You can now browse your infrastructure without the navigator fail messages. Or go and install a licensed version.

– Hope it helps!

Installing vCenter – CA Signed Certificates with the Certificate Automation Tool

With the installation of vCenter 5.1 components (just like vSphere hosts) the components are installed with self signed certificates. No problem when you trust your own systems, but securing your environment when you have different interactions with the services (for example the corporate users of the vSphere web clients) will lead you to implement signed certificates. Especially when the most environments have their own CA infrastructure, use it!

There are seven separate components in vCenter Server 5.1 that utilize certificates to encrypt communication. We want don’t want to spend time generating and installing certificates for each component, we want automation! And what do we have that, the VMware SSL Certificate Automation Tool. Well…..not a complete automation, but automated enough to help updating the vCenter related services (and rollbacking in case something is going wrong). That beats doing it all on yourself.

The VMware SSL Certificate Automation Tool can be used to generate certificate signing requests for the vCenter services, that can be send to the CA to be signed. The Automation Tool can then be used to implement the certificates for the services. Use the planner option to be presented with the correct order of steps. Possibly in a second screen.


The procedure is as follow:

– Download the VMware SSL Certificate Automation Tool.
– Generate CSR’s for the vCenter Service with the automation tool.
– Sign the CSR’s in the CA.
– Creating the PEM chain files.
– Update the vCenter services in the correct order. (Replacing one service and not re-trusting the interacting services will have some errors as result)


The installation starts with downloading the Automation Tool at Download and unzip to a preferred location. For this example I have unzipped to D:Scripts, a the folder structure starts from SSLAutomationTool1.0.1.

Predefining the default values in the tool helps prevent typing errors and save time, you can edit ssl-environment.bat. This lets the tool automatically include specific information that you have defined as the default instead of prompting you for it. Details for the serveral services we will fill in after generating the CSR (plus key’s) and PEM chain files.

For now we add the parameters to: Common parameters (SSO and VC users) and parameters that will be used to generate a CSR (fqdn, ips, country, state, organization and so on).

Now we start the tool: ssl-updater.bat.


We first generate the CSR by choosing action 2. At that menu we choose every service we have to update. With the common parameters we only have to take the default entries (be sure to check them). The CSR’s are saved to the requests directory. There you will also find the keys. Repeat until you have selected all options.

With all the necessary services done, we have a collection of CSR’s to be signed by the CA. The process of signing differs from what product is used as CA. From every directory the rui.csr is the signing request we have to upload or open and copy the contents.

For example Microsoft CA works with a web site you can use to request the certificate:


Choose the request a certificate and an advanced request. Request an BASE64-encoded web server certificate, with the option Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

You will have to repeat the request for every service you wish to update.

We continue when we have received the signed requests. Save the .crt file in a appropriate location and open the file to verify the proper names.

After repeating this we have to create PEM files with the complete certificate chain in one file. Depending on the hierarchy used in the certificate infrastructure you will need the root and all the intermediate (if any) Base64-encoded certificates. Get them from your trusted certificate store or from the CA signing service. Also save these files to the directory. Open a text editor and create a PEM file (name including the service). Open the signed certificate and copy and paste to the PEM, open any intermediate certifcate and past the contents to the PEM (after the —-END Certificate — of the certificate), repeat for any other intermediate. Finish by copying the root certificate in the PEM. This should look like something like this (truncated):

——-BEGIN CERTIFICATE——- <——-Certificate
——-BEGIN CERTIFICATE——- <——-Intermediate Certificate
——-BEGIN CERTIFICATE——- <——-Root Certificate

Close and repeat. And we now have the PEM chain’s for all (or you choice) of vCenter services.

Now we need to implement them at the appropriate services. First edit the ssl-environment.bat for the services and include location for keys and pem files. When you are finished the menu options Update will handle the updates for you.

Here is a screenshot of the the updating of the SSO service. It handles the update and restarting of the appropriate services.


Type 3 to return to the main menu and repeat for the other actions the planner .

In case something goes amiss rollback and you can find the service-update-ssl.log in the logs directory of the automation tool.

One more thing, when updating the vCenter certificate one of the wanted information is “Enter vCenter server original database password”. This is a somewhat confusing line. But it is the vCenter database user password (ODBC System DSN Password for connection to VCDB) that is requested. That is either a Windows user or a SQL user.

—- Enjoy updating!