A system administrator can use backups to restore vRealize Automation in an environment that is isolated from other networks.
Prerequisites
- Verify that the environment has a DNS server with identical zones and records to the production server and that the vRealize Automation virtual appliance and Windows and IaaS servers are configured to work with it.
Procedure
- Configure the vRealize Automation virtual appliance.
- Check the vRealize Automation virtual appliance PostgreSQL status, and reset secondary node if needed.
- If the primary node is unable to start, reset RabbbitMQ on the primary node.
- Shut down the secondary node.
- Restart the primary node.
- Wait 30 seconds, and restart the secondary node.
- Verify that the primary server has all services except IaaS as Registered.
- If needed, perform a join cluster operation on the secondary node.
- Verify that both servers have all services except IaaS as Registered.
If the environment uses Active Directory, you can skip all following steps. - Configure IaaS machine authentication.
Option Description Using a local administrative account This option is the most secure and simulates a production environment with an Active Directory and Integrated Authentication to the SQL server, so tests can be closer to reality.
Create a user with administrative privileges and with the same user name and password on all servers, including the SQL server. Grant this user sysadmin rights on the SQL Server and owner rights on the IaaS database. You can also modify the connection string to reflect this new user or configure it to use SQL authentication.
Using the local system account This option is less secure and might cause problems with the manager service authenticating to the Web repository.
Start all services with the local system account and grant the local system accounts on all servers sysadmin rights on the SQL Server and owner rights on the IaaS database.
- Configure the Web IaaS machine.
- Check connection string in the web.config file of the Model Manager Web installation folder and modify it according to the account you used for IaaS machine authentication.
If you are using SQL authentication, it should look similar to the following:
Max Pool Size=200;MultipleActiveResultSets=True;Connect Timeout=200;User Id=sa;Password=password;" />
- Change the IIS IaaS application pools to use the account you used for IaaS machine authentication.
- Restart the IIS services by running iisreset in command prompt on the IaaS Web severs.
- Check connection string in the web.config file of the Model Manager Web installation folder and modify it according to the account you used for IaaS machine authentication.
- Configure the Manager Service IaaS machine.
- If the machine running the SQL server is part of a failover cluster, disable the cluster service and reboot the machine.
- If the SQL server is part of a failover cluster, disable the cluster service and reboot the SQL server.
If the machine running the SQL server is part of a failover cluster, the cluster service does not work because there is no Active Directory. In a failover cluster, the MSDTC service is controlled by the cluster service. When the Active Directory domain is missing, the cluster service is not able to bring up its resources and keeps the DTC in a locked state. When you disable the cluster service and reboot the machine running the SQL server, this unlocks the local DTC, and the Manager Service can successfully initialize.
- Enable No Authentication Required on the DTCs of both the SQL server and the manager server from their respective component services console.
- On the DEM Orchestrator IaaS machine, change the service account to the account you used for IaaS machine authentication.
- Change the management agent service account on all IaaS machines to the account you used for IaaS machine authentication.