- Overview
- Requirements
- Installation
- Post-installation
- Cluster administration
- Managing products
- Managing the cluster in ArgoCD
- Setting up the external NFS server
- Automated: Enabling the Backup on the Cluster
- Automated: Disabling the Backup on the Cluster
- Automated, Online: Restoring the Cluster
- Automated, Offline: Restoring the Cluster
- Manual: Enabling the Backup on the Cluster
- Manual: Disabling the Backup on the Cluster
- Manual, Online: Restoring the Cluster
- Manual, Offline: Restoring the Cluster
- Additional configuration
- Migrating objectstore from persistent volume to raw disks
- Monitoring and alerting
- Migration and upgrade
- Migration options
- Step 1: Moving the Identity organization data from standalone to Automation Suite
- Step 2: Restoring the standalone product database
- Step 3: Backing up the platform database in Automation Suite
- Step 4: Merging organizations in Automation Suite
- Step 5: Updating the migrated product connection strings
- Step 6: Migrating standalone Insights
- Step 7: Deleting the default tenant
- B) Single tenant migration
- Product-specific configuration
- Best practices and maintenance
- Troubleshooting
- How to Troubleshoot Services During Installation
- How to Uninstall the Cluster
- How to clean up offline artifacts to improve disk space
- How to clear Redis data
- How to enable Istio logging
- How to manually clean up logs
- How to clean up old logs stored in the sf-logs bundle
- How to disable streaming logs for AI Center
- How to debug failed Automation Suite installations
- How to delete images from the old installer after upgrade
- How to automatically clean up Longhorn snapshots
- How to disable NIC checksum offloading
- Unable to run an offline installation on RHEL 8.4 OS
- Error in Downloading the Bundle
- Offline installation fails because of missing binary
- Certificate issue in offline installation
- First installation fails during Longhorn setup
- SQL connection string validation error
- Prerequisite check for selinux iscsid module fails
- Azure disk not marked as SSD
- Failure After Certificate Update
- Automation Suite not working after OS upgrade
- Automation Suite Requires Backlog_wait_time to Be Set 1
- Volume unable to mount due to not being ready for workloads
- RKE2 fails during installation and upgrade
- Failure to upload or download data in objectstore
- PVC resize does not heal Ceph
- Failure to Resize Objectstore PVC
- Rook Ceph or Looker pod stuck in Init state
- StatefulSet volume attachment error
- Failure to create persistent volumes
- Storage reclamation patch
- Backup failed due to TooManySnapshots error
- All Longhorn replicas are faulted
- Setting a timeout interval for the management portals
- Update the underlying directory connections
- Cannot Log in After Migration
- Kinit: Cannot Find KDC for Realm <AD Domain> While Getting Initial Credentials
- Kinit: Keytab Contains No Suitable Keys for *** While Getting Initial Credentials
- GSSAPI Operation Failed With Error: An Invalid Status Code Was Supplied (Client's Credentials Have Been Revoked).
- Alarm Received for Failed Kerberos-tgt-update Job
- SSPI Provider: Server Not Found in Kerberos Database
- Login Failed for User <ADDOMAIN><aduser>. Reason: The Account Is Disabled.
- ArgoCD login failed
- Failure to get the sandbox image
- Pods not showing in ArgoCD UI
- Redis Probe Failure
- RKE2 Server Fails to Start
- Secret Not Found in UiPath Namespace
- After the Initial Install, ArgoCD App Went Into Progressing State
- MongoDB pods in CrashLoopBackOff or pending PVC provisioning after deletion
- Unexpected Inconsistency; Run Fsck Manually
- Degraded MongoDB or Business Applications After Cluster Restore
- Missing Self-heal-operator and Sf-k8-utils Repo
- Unhealthy Services After Cluster Restore or Rollback
- RabbitMQ pod stuck in CrashLoopBackOff
- Prometheus in CrashloopBackoff state with out-of-memory (OOM) error
- Missing Ceph-rook metrics from monitoring dashboards
- Using the Automation Suite Diagnostics Tool
- Using the Automation Suite Support Bundle Tool
- Exploring Logs
Migration options
For migrating your standalone Orchestrator data to Automation Suite, you can follow one of the two processes available:
You must choose one process to use, you cannot use both.
This page describes the differences between the two options to help you choose which one to use.
Both processes are for moving your data from the standalone installation of Orchestrator to the Orchestrator service in Automation Suite, but there are some differences.
The full installation migration process essentially links your standalone Orchestrator database to Automation Suite, so all the data it includes is available in Automation Suite. You should use this method if, in addition to Orchestrator, you also want to migrate other products and services.
The full migration option ensures high-fidelity data transfer between the standalone product databases and the automatically created Automation Suite databases. If you do not want to use the default Automation Suite databases, you can opt for your own migrated databases provided that you update their connection strings.
The single tenant migration process, on the other hand, uses the Automation Cloud™ Migration Tool to strictly copy the entities present in your standalone Orchestrator. The tool retrieves them from standalone Orchestrator over API and then writes them in Automation Suite over API.
Full migration | Single tenant migration | |
---|---|---|
Scope |
|
|
Outcome |
Orchestrator in Automation Suite contains exactly the same data and is configured in exactly the same way as your standalone Orchestrator. |
All your entities are copied over to Orchestrator, but Orchestrator in Automation Suite uses the default Automation Suite configuration. To get to the same setup you had in your standalone installation, you must perform a first-time configuration of Automation Suite, which you can do at any time - before or after migration. |
Prerequisites |
Requires that you upgrade standalone Orchestrator to a version that matches the targeted Automation Suite version. |
Supports direct migration from a supported standalone Orchestrator version. |
Organization hierarchy |
For every tenant from your standalone Orchestrator, you will have one organization which contains one tenant. For example, if you have 10 tenants, the result of migration will be 10 organizations with one tenant each. |
You can migrate your tenants to the same organization, or to several organizations, as needed. |
Although typically you can only use one migration option or the other, this sample scenario describes a use case where you could use both.
If you intend to perform the full migration, the Automation Cloud Migration Tool can support the migration process by allowing you to more easily set up a test environment in Automation Suite with production data that you can use for end-to-end testing.
If you want to first test Automation Suite and would like to do so on your actual Orchestrator data, here is what the full process might look like:
- Deploy Automation Suite in a test or development environment.
-
Migrate partial data from standalone Orchestrator to Automation Suite using the Cloud Migration Tool. See Single tenant migration for instructions.
This allows you to perform a proof-of-concept or trial on a real dataset. At this point, you have your Orchestrator data, but you are using the default Automation Suite and Orchestrator configurations. You can, for example, readily test run a process, but you cannot readily log in with an SSO account.
- With the partial migration complete, validate critical scenarios and use cases and address any issues.
-
Upgrade the test environment for standalone Orchestrator to the desired version.
Follow the instructions in Updating using the Windows installer and make sure to put the environment in read-only mode.
- Perform a test migration to Automation Suite following the Full migration instructions.
- Redirect all test users and robots to the new Automation Suite test environment.
- Address any issues during and after the migration, validate the process end-to-end.
- Deploy Automation Suite in a production environment.
-
Upgrade you production environment for standalone Orchestrator to the desired version.
Follow the instructions in Updating using the Windows installer and make sure to put the environment in read-only mode.
-
Perform the full production migration to Automation Suite following the Full migration instructions.
Important: This overwrites the previously migrated data, which is lost. With this migration, all your custom configurations are applied, and your Orchestrator entities are also migrated. You should see the same information in Automation Suite as you do in your standalone Orchestrator. - Redirect all production users and robots to the new Automation Suite production environment.
If needed, you can discard tenants from standalone Orchestrator that you no longer need (for example, testing tenants). If you do not create an organization and tenant pair for a tenant from your standalone installation, it is not available in Automation Suite. The data for any discarded tenants is still migrated to the new database, but the tenants are not accessible from the user interface.