Aria Automation Day 2 Project Move Fails with 403 Forbidden Exception on Active Directory Integrated Deployments

Products

• VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

When attempting to move existing deployments between projects in Aria Automation 8.x, the operation fails with a 403 FORBIDDEN exception. This typically occurs in scenarios where an environment misconfiguration caused VMs to be deployed into the incorrect Active Directory (AD) Organizational Unit (OU) or domain.

Symptom:

• Deployments cannot be moved to a new project.

• Existing AD integrations cannot be deleted or modified because the system erroneously reports they are still in use by the old project.

• Database records for the affected VMs become "stale," reflecting the old project ID despite the intended change.

Environment

VMware Aria Automation (formerly vRealize Automation) 8.x

Cause

he underlying cause is Database Inconsistency arising from an unsupported workflow.

Aria Automation treats AD integration mappings as immutable for active deployments. The tango-ad service (responsible for Active Directory operations) does not currently listen to or process "Change Project" events triggered by the project-service.

When a project move is attempted, the ad_integration_project_association table remains locked to the OLD_PROJECT_ID. If the new project points to a different AD integration or OU, a conflict occurs. The system blocks the move or subsequent cleanup with a 403 error because the underlying machine records are still hard-bound to the original project’s AD association in the database.

Resolution

Because moving deployments with disparate AD integrations is not natively supported, the following remediation steps are provided on a best-effort basis.

⚠️ WARNING: You must take a snapshot of all Aria Automation appliances before performing manual database modifications.

Option 1: Manual Database Alignment (Workaround)

This procedure manually re-aligns the Active Directory records with the new project ID.

1. Identify IDs: Obtain the UUIDs for both the Old Project and the New Project from the browser URL while viewing the projects in the Aria Automation interface.

2. Access the Provisioning Database:

   • SSH into the Aria Automation appliance as root.

   • Run the following commands:

     Bash

      

     vracli dev psql
     \c provisioning-db
     

3. Execute the Update: Update the association table to point to the new project:

   SQL

    

   UPDATE ad_integration_project_association 
   SET project_id='NEW_PROJECT_ID' 
   WHERE project_id='OLD_PROJECT_ID';
   

4. Manual AD Cleanup: The database edit only corrects the vRA record. You must manually move the computer objects to the correct OU within your Windows Domain Controller.

Option 2: Supported Redeployment Path

If database intervention is not permitted by your organization's policy, follow these steps:

1. Unregister the affected virtual machines from Aria Automation.

2. Manually delete or move the computer objects in Windows Active Directory.

3. Onboard the virtual machines into the correct Project and Deployment.

Additional Information

The manual SQL update bypasses the application-layer block by directly aligning the project_id with the current deployment state in the database. This satisfies the system's requirement that no deployments be associated with the old project ID, thereby resolving the 403 Forbidden error. However, since the tango-ad service lacks the logic to move physical objects post-provisioning, the manual move in Windows AD remains a necessary step for the administrator.