7.4
Table Of Contents
- Migrating vRealize Automation to 7.4
- Contents
- Migrating vRealize Automation
- vRealize Automation Environment User Interfaces
- Migration Prerequisites
- Pre-Migration Tasks
- Review Changes Introduced by Migration from vRealize Automation 6.2.x to 7.x
- Apply Software Agent Patch
- Change DoDeletes Setting on the vSphere Agent to False
- Check Templates in Your vRealize Automation 6.x Source Environment
- Prepare vRealize Automation Virtual Machines for Migration
- Gather Information Required for Migration
- Obtain the Encryption Key
- List Tenant and IaaS Administrators
- Add Each Tenant from the Source Environment
- Create an Administrator for Each Added Tenant
- Synchronize Users and Groups Before Migration to a Minimal Environment
- Synchronize Users and Groups Before Migration to a High-Availability Environment
- Run Data Collection in Source
- Manually Clone the Source Microsoft SQL Database
- Snapshot the Target Environment
- Migration Procedures
- Post-Migration Tasks
- Add Tenant and IaaS Administrators
- Run Test Connection and Verify Migrated Endpoints
- Run Data Collection on Target
- Reconfigure Load Balancers After Migration
- Migrate an External Orchestrator Server
- Reconfigure the vRealize Automation Endpoint
- Reconfigure the vRealize Automation Infrastructure Endpoint
- Install vRealize Orchestrator Customization
- Reconfigure Embedded vRealize Orchestrator Endpoint
- Reconfigure the Azure Endpoint
- Migrate Automation Application Services
- Delete Original Target vRealize Automation IaaS Microsoft SQL Database
- Update Data Center Location Menu Contents After Migration
- Upgrading Software Agents to TLS 1.2
- Validate the Target vRealize Automation 7.4 Environment
- Troubleshooting Migration
- PostgreSQL Version Causes Error
- Some Virtual Machines Do Not Have a Deployment Created during Migration
- Migration Log Locations
- Catalog Items Appear in the Service Catalog After Migration But Are Not Available to Request
- Data Collection Radio buttons Disabled in vRealize Automation
- Troubleshooting the Software Agent Upgrade
Table 6‑3. vRealize Automation Disk Space Monitoring
Option Description
Warning Threshold Percent Accept default: 75
Critical Threshold Percent Accept default: 90
Table 6‑4. vRealize Automation Tenant
Option Description
Tenant Under Test Tenant selected for testing.
Fabric Administrator User Name Fabric administrator user name. For example, admin@va-
host.local.
Note This fabric administrator must also have a tenant
administrator and an IaaS administrator role in order for all of
the tests to run.
Fabric Administrator Password Password for fabric administrator.
8 Click Next.
9 On the Summary page, review the information and click Finish.
The software agent verification configuration is finished.
10 On the SW Agent verification card, click Run.
11 When the test is complete, click the center of the SW Agent verification card.
12 On the SW Agent verification results page, page through the test results and find the Check Software
Agent Version test in the Name column. If the test result is Failed, click the Cause link in the Cause
column to see the virtual machines with an outdated software agent.
What to do next
If you have virtual machines with an outdated software agent, see Upgrade Software Agents on vSphere.
Upgrade Software Agents on vSphere
You can upgrade any outdated Software Agents on vSphere to TLS 1.2 after migration using
vRealize Automation Appliance Management.
This procedure updates the outdated Software Agents on the virtual machines from your source
environment to TLS 1.2 and is required for migration to vRealize Automation 7.4.
Prerequisites
n
Apply Software Agent Patch if you migrated from vRealize Automation 7.1, or 7.3 to 7.4.
n
Successful migration from vRealize Automation 7.1, 7.2, 7.3 or 7.3.1 to 7.4.
n
You have used Health Service to identify virtual appliances with outdated Software Agents.
Migrating vRealize Automation to 7.4
VMware, Inc. 47