Troubleshooting vCloud Automation Center Endpoints and vCloud Director 5.1


Note: For this troubleshooting article, I’m using vCloud Director 5.1 and vCloud Automation Center 5.2.

Having fun with my lab. Lots of fun – and as readers may have noticed, my current focus is around deploying vCloud Director (vCD) and integrating it with vCloud Automation Center (vCAC). However, all is not plain sailing.

Firstly, the installation of vCAC v5.2 is much better than installing v5.1. By better I mean more streamlined, the deployment packages retain more explanation, and lots of the installation ‘gotchas’ have been either removed, fixed or simply hidden from the installation process. I’ll not detail the installation process here as there are lots of other guides out there.

This break-fix article is about a particular issue I came across in the lab, and it’s solution, and it concerns using vCAC and adding vCD endpoints.


Symptoms of the error were:

  • The vCloud Automation Center service kept stopping on the server, wether started manually or Automatically on boot.
  • In vCAC Administrator > Log Viewer, there were several errors about Access Denied for service account credentials and defined vCloud Endpoints.
  • Entries in logs (C:\Program Files (x86)\VMware\vCAC\Server\Logs\All) showed errors about starting manager services.

Failed to start manager services: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

Part of the installation process relates to installing the vCAC Self Service portal, and defining IIS properties for secure communication. In my lab, I use the semi-usual method of having machine names that conform to a naming standard, but I want my web interface to have a ‘human’ name. So, I have a mis-match between the web portal certificate name and the machine name.

This is addressed in the installer with an innocuous looking checkbox ‘Surpress Certificate Mis-Match Checking’ which when checked will adjust the vCAC installation suitably. You NEED this checked if you are using mis-matched certificates.

Unfortunately, it seems that even if this checkbox IS checked, the required configuration changes are sometimes still not made, as the ‘picky’ nature of the installer prevails from v5.1 in the permissions need to be exactly correct to make all the changes. If the installer completes and doesn’t report and errors, this issue may still be present, and is caused by some XML config being omitted for certificate checking.


To fix these presented issues, I followed this process to get the endpoints collecting vCD tenant information.

1. Make sure that the service account you are using has local administrator privilidges, to enable editing of certain configuration files later on.

2. Make sure the vCAC service is not running as Local System, but as a domain service account.

3. Stop all the vCAC services, including any DEM-Worker or DEM-Orchestrator services running under the instance.

4. Open C:\Program Files (x86)\VMware\vCAC\Server on the vCAC server.

5. Open ManagerService.exe.config in NotePad. (This is where the bit about local admin comes in – opening and editing files is fine as other users – even Domain Admins – but saving locally is a different matter….!)

6. At the end of the config file, find the lines at the very bottom of the config: </encryptionKey> and </configuration>.

7. Between these 2 closing key tags, add the following section:

<servicePointManager checkCertificateName=”false” checkCertificateRevocationList=”false” />

8. The end of the config file should now read like this:

<servicePointManager checkCertificateName=”false” checkCertificateRevocationList=”false” />

9. Save the changes to the file. If permissions are an issue, use the old trick of copying the config file to the desktop, make the changes detailed above, then save, and move the file back to the original location. I’ve done it both ways – in situ and move and move back, and both work fine.

10. Restart IIS, the vSphere agent, the DEM-Worker and DEM-Orchestrator and the vCAC service.


Once all the services have been restarted (in my case – the server hosting the vCAC components was restarted too), log back in to the vCAC Administration portal (https://<hostname>/vCAC) and authenticate as vCAC administrator. Things to check:

1. Check the endpoint configuration. In my case, all my cloud tenants are available for provisioning so the endpoint is configured as follows:

  • Type: vApp (vCloud Director)
  • Name: *As required*
  • Address: Cloud Root Address (e.g.
  • Credentials: Cloud Global Admin User
  • Organisation: *Blank*

2. Manual data collection. Hover over the endpoint to get the context menu. For vCloud, select ‘Data Collection’ to rediscover the endpoint resources. (This might take a while with large or diverse cloud resources assigned).

3. Configure and assign Enterprise Groups – assign resources discovered under data collection above.

4. Check resources – in endpoints hover for the context menu again and select ‘View Compute Resources’ – all the tenant resources from the cloud should now be visible.

That’s it! Once this fix has been applied then endpoints will be available again and the certificate issues should at least me managed by vCAC instead of producing errors.

Jeremy loves all things technology! Has been in IT for years, loves Macs (but doesn't preach to others about their virtues), loves virtualization (and does shout about it's virtues), and sometimes skis, bikes and directs amateur plays!


  1. Viktor - says

    Hi! Great tip which worked out fine for me. A small note: when you copy + paste the text straight from your website, the wrong type of quotation marks are copied which leads to an error. After correcting this, everything works just fine!

  2. Viktor - says

    Hi, had to repeat this trick for the vCACreports website as well. Configuration is available in C:Program Files (x86)VMwarevCACServerReport Websiteweb.config….cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *