This is toughest one, I am pretty sure many would have planned to change vRA network to a different network with different Hostname, IP address etc. However due to the complexity very few would have successfully achieved this and many would have dropped this plan.
I was able to successfully migrate two different vRA environment for a customer from one network to another. Yes! of course had few sleepless night to accomplish this. I will share the steps which I followed, even though the steps are given, it would be a task to accomplish but this can be used for reference.
Prerequisites:
Clone the vRA components and leave behind the old one as a rollback plan if anything fails while doing these changes.
Snapshots of all the cloned VMs before proceeding.
Credentials of all the vRA Machines (including remote proxy agents)
CA singed certificate should be generated with new hostnames and IP addresses. (For customers who use CA signed certificate)
Make sure vRA is in good state without any errors.
Steps followed:
- Shutdown the vRA environment.
- Clone the vRA VMs including database to new cluster which has the new network port group access.
- Connect the VMs to new network in edit settings.
- Power on vRA appliance – Since VAMI won’t be accessible in new network. Follow /opt/vmware/share/vami/vami_config_net to modify the IP Address, Default Gateway and DNS details.
Note: I wanted to follow the steps outlined in this link: https://docs.vmware.com/en/vRealize-Automation/7.4/com.vmware.vra.install.upgrade.doc/GUID-D63741F8-69DE-4732-A89B-AFDDB6A36160.html since VAMI will not be accessible in new network updated it through the vami_config_net script. - Change vRA Hostname script does not work completely:
vcac-config hostname-change –host new-hostname –certificate certificate-file-name
This command from link: https://docs.vmware.com/en/vRealize-Automation/7.4/com.vmware.vra.install.upgrade.doc/GUID-E75E76B2-8883-4608-9484-6C04001D5FEB.html
Was giving two errors (1. No Master Node, 2. Timeout).
The above script only updates 2 tables correctly with new hostname – Connector & ServiceInstance, but the strData value of table FederationArtifacts was deleted and this was causing issue during login – Unable to parse message into a DOM.
And OAuth2Client table was not updated.
<<Revert Snapshot>>
So had to hash out #replaceInTable FederationArtifacts id strData in the script to manually update.
We had to manually update two tables FederationArtifacts to fix strData issue. Also we had to update OAuth2Client to fix vRO Control Center login issue.
DB Update Commands: (saas schema)
For FederationArtificats table update command:
For OAuth2Client table update command:
update “OAuth2Client” set “redirectUri”=’https:///vcac/org/vsphere.local/’ where “id”=’3′; - Change the vRA Appliance Certificate with new one. Update the vRA CNAME in Host Settings tab in vRA VAMI.
- Need to enter administrator credentials at vRA VAMI -> SSO tab and click on save to re-initialize SSO and that’s when all the services will come up.
- Changed hostname and IP address of IaaS And proxy machine from guest OS.
- Updated the following configuration files with new hostname:
10. Manually update the IIS binding with new IaaS Certificate. Since VAMI was still having old IaaS entry and not letting to do the update for IaaS certificate.
11. Change SQL database hostname, SQL instance name and IP address. KB article: https://kb.vmware.com/s/article/2074607
Update with new hostname name – “SELECT Name, ConnectionString FROM [database-name].[DynamicOps.RepositoryModel].[Models]”
12. Re-initiate the trust by following:
https://docs.vmware.com/en/vRealize-Automation/7.4/com.vmware.vra.install.upgrade.doc/GUID-402A9AED-ABE8-4C5C-889F-56C0E7F5F03A.html
https://kb.vmware.com/s/article/2110207
13. Reboot the complete vRA stack in sequence.
14. Update Embedded vRealize Orchestrator to Trust vRealize Automation Certificates – https://docs.vmware.com/en/vRealize-Automation/7.4/com.vmware.vra.prepare.use.doc/GUID-CD4AC8E0-168C-43A9-99A1-64C30A5776F8.html