6.2
Table Of Contents
- Migrating vCloud Automation Center 5.2.3 to vRealize Automation 6.2
- Contents
- Migrating from vCloud Automation Center 5.2.3 to vRealize Automation 6.2
- Updated Information
- Understanding vRealize Automation Migration
- Preparing for Migration
- Running the Pre-Migration Task
- Performing Manual Operations After Pre-Migration
- Stop IaaS Services in Target vRealize Automation System
- Back Up the Target vRealize Automation System
- Backing Up the Target vRealize Automation SQL Database
- Disabling Access to the Source System
- Stop IaaS Services in Source vCloud Automation Center 5.2 System
- Replacing the Target vRealize Automation Database with the Source vCloud Automation Center 5.2 Database
- Update Migration Table to Parse Port Value Data
- Running the Migration Task
- Performing Post-Migration Tasks Checklist
- Troubleshooting
- Cleaning Up Migration Tables in Source 5.2 Database
- Database Name Mismatch During Pre-Migration
- User Principals Cannot be Migrated
- Cannot Connect to Model Manager Web Service
- Cannot Connect to Remote Server
- Cannot Create Application Services Reservation
- Model Manager Web Service is Offline
- Pre-Migration Fails with a Load Balancer Timeout Error
- Migration Fails when Port Number is Part of Database Server Address
- Migration Fails with a Wait Operation Timeout Error
- Migration Fails with a RepoUtil Assembly Timeout Error
- Machines Not Visible on Items Page After Migration
- Reservation Not Available After Migration
Migrating User and Group Identities
Standard users and groups are migrated, provided that the target system exists in the same domain as
the source system or the target domain has identical trusts as the source system.
Other users and roles are captured in the reports and are not migrated.
Local machine users are not migrated. Built-in user accounts, such as BUILTIN\Administrator or
BUILTIN\Everyone, are also not migrated. However, for resources that belong to a built-in administrator
account and for which a machine has been provisioned, that machine is migrated and assigned to the
tenant administrator.
For user names that the migration process cannot translate, the migration process performs the following
actions:
n
Replaces the user name with the UPN of the default tenant
n
Reports the occurrence in the pre-migration and migration reports
Although the group names are not changed during migration, some classification terms have changed.
Table 1‑3. Group Name Terms Before and After Migration
vCloud Automation Center 5.2 Group Name vRealize Automation Group Name
Enterprise group Fabric group
Provisioning group Business group
Migrating User Security Settings
Windows Security Identifier data in the User Authorization Manager data store is extracted from the
source system and converted to User Principal Name format. This data is migrated to the target
vRealize Automation system.
Role membership identifies users and groups who are using Windows Security Identifier (SID) format. In
vRealize Automation, this information is stored in a Single Sign-on (SSO) authorization store. The SSO
store identifies each user and group by using a UPN format. All security identifiers are migrated to the
SSO store in the target system.
The following table contains an example of the two formats.
Table 1‑4. Example of User Name Equivalent in SID and UPN format
Source SID Domain Format Sample User Target UPN Format Sample User
mycompany.local\joe.user joe.user@mycompany.local
vRealize Automation only accepts security identifiers in UPN format.
During the process of migrating user information, vCloud Automation Center 5.2 security data in Windows
Security Identifier format is extracted and converted to UPN format by connecting and querying the Active
Directory domain for UPN identifiers. The converted fully qualified UPN identifiers are cached in
temporary tables to be committed to the vRealize Automation authorization store.
Migrating vCloud Automation Center 5.2.3 to vRealize Automation 6.2
VMware, Inc. 13