Cloud Account Creation Fails in Soft Tenancy with “Duplicate proxy rule <account

Products

VCF Automation

Issue/Introduction

When attempting to create a cloud account in a soft tenancy configuration, the process fails during the account creation registration. The provisioning-service logs indicate a 400 BAD_REQUEST specifically citing a duplicate proxy rule for the FQDN.

Example log snippet from provisioning logs:

INFO provisioning [host='provisioning-service-app-' thread='reactor-http-epoll-1' user='' org='' trace='' parent='' span=''] c.v.a.c.t.TenantManagerClient.createProxyRule:256 - createProxyRule called: https://NSX-T
ERROR provisioning [host='provisioning-service-app-' thread='reactor-http-epoll-1' user='' org='' trace='' parent='' span=''] c.v.a.c.t.TenantManagerClient.lambda$createProxyRule$6:276 - createProxyRule is4xxClientError: status: [400 BAD_REQUEST] reason: [Bad Request], uri:[/cloudapi/1.0.0/proxyRules], error: [{"minorErrorCode":"VCD_50214","message":"Duplicate proxy rule <NSX-T>","stackTrace":"com.vmware.vcloud.api.rest.toolkit.exceptions.BadRequestRestApiException: Duplicate proxy rule <NSX-T>

Environment

VCF Automation 9.x

Cause

A proxy rule associated with the NSX-T FQDN or account hostname already exists in Tenant Manager. During cloud account creation, the system attempts to create a new proxy rule. If a rule with the same hostname already exists (stale/orphaned entry), the API returns: 400 BAD_REQUEST – Duplicate proxy rule

This can occur due to:

Previously failed cloud account creation
Incomplete cleanup of proxy rules
Stale database entries

Resolution

Ensure a full backup of the VCF environment is taken before manual database modifications.

Method 1: API-Based Removal (Recommended)

1. Obtain Bearer Token: Log into the Aria Automation UI, navigate to the Tenant Manager section, and use Browser Developer Tools (Network tab) to capture the Authorization: Bearer <token> from an API request (e.g., to the /orgs endpoint)

2. List Proxy Rules: Execute the following GET request to identify the conflicting rule ID:

curl --request GET \
--url https://<TM_HOST>/cloudapi/1.0.0/proxyRules \
--header 'accept: application/json;version=<version>' \
--header 'authorization: Bearer <TOKEN>'

3. Delete Duplicate Rule: Locate the id (format: urn:vcloud:proxyRule:UUID) corresponding to the duplicate hostname and execute the DELETE call:

curl --request DELETE \
--url https://<TM_HOST>/cloudapi/1.0.0/proxyRules/<PROXY_RULE_ID> \
--header 'accept: application/json;version=<version>' \
--header 'authorization: Bearer <TOKEN>'

Note: The version value in the accept header must match the API version currently used by your Tenant Manager (TM) instance. To identify the correct version, open the TM UI in your browser, enable Developer Tools (F12), navigate to the Network tab, perform a proxy rule action, and check the accept header in the API request to see the version

Method 2: Database Manual Cleanup

If the API does not return the rule but the error persists, manual database intervention is required.

1. Access Postgres Container:

export KUBECONFIG=vmsp-standalone.kubeconfig
kubectl -n prelude exec -it vcfapostgres-0 -- /bin/bash

2. Connect to Database:

su - postgres
psql -d tenantmanager

3. Identify and Delete:

SELECT * FROM proxy_rules;

-- Identify the ID of the duplicate entry

DELETE FROM proxy_rules WHERE id = '<UUID>';

If Tenant Manager registration is not strictly required for the workflow, disable the feature toggle:

curl --request POST \
--url https://<HOST>/provisioning/config/toggles \
--header 'authorization: Bearer <TOKEN>' \
--header 'content-type: application/json' \
--data '{ "key": "enable.tm.registration", "value": "false" }'