In this article by Daniel Langenhan, author of VMware vRealize Orchestrator Cookbook, Second Edition, will show you how to move an existing Windows Orchestrator installation to the appliance. With vRO 7 the Windows install of Orchestrator doesn’t exist anymore.
(For more resources related to this topic, see here.)
Getting ready
We need an Orchestrator installed on windows.
Download the same version of the Orchestrator appliance as you have installed in the Windows version. If needed upgrade the Windows version to the latest possible one.
How to do it…
There are three ways, using the migration tool, repointing to an external database or export/import the packages.
Migration tool
There is a migration tool that comes with vRO7 that allows you to pack up your vRO5.5 or 6.x install and deploy it into a vRO7. The migration tool works on Windows and Linux. It collects the configuration, the plug-ins as well as their configuration certificates, and licensing into a file. Follow these steps to use the migration tool:
- Deploy a new vRO7 Appliance.
- Log in to your Windows Orchestrator OS.
- Stop the VMware vCenter Orchestrator Service (Windows services).
- Open a Web browser and log in to your new vRO7 – control center and then go to Export/Import Configuration.
- Select Migrate Configuration and click on the here link. The link points to: https://[vRO7]:8283/vco-controlcenter/api/server/migration-tool .
- Stop the vRO7 Orchestrator service.
- Unzip the migration-tool.zip and copy the subfolder called migration‑cli into the Orchestrator director, for example, C:Program FilesVMwareInfrastructureOrchestratormigration-clibin.
- Open a command prompt.
- If you have a Java install, make sure your path points to it. Try java ‑version. If that works continue, if not, do the following:
- Set the PATH environment variable to the Java install that comes with Orchestrator, set PATH=%PATH%;C:Program FilesVMwareInfrastructureOrchestratorUninstall_vCenter Orchestratoruninstall-jrebin
- CD to the directory ..Orchestratormigration-clibin.
- Execute the command vro-migrate.bat export. There may be errors showing about SLF4J, you can ignore those.
- In the main directory (..Orchestrator) you should now find an orchestrator‑config‑export‑VC55‑2024.zip file.
- Go back to the Web browser and upload the ZIP file into Migration Configuration by clicking on Browse and select the file.
- Click on Import. You now see what can be imported. You can unselect item you wish not to migrate. Click Finish Migration.
- Restart the Orchestrator service.
- Check the settings.
External database
If you have an external database things are pretty easy. For using the initial internal database please see the additional steps in the There’s more section of this recipe.
- Backup the external database.
- Connect to the Windows Orchestrator Configurator.
- Write down all the plugins you have installed as well as their version.
- Shutdown the Windows version and deploy the Appliance, this way you can use the same IP and hostname if you want.
- Login to the Appliance version’s Configurator.
- Stop the Orchestrator service
- Install all plugins you had in the Windows version.
- Attach the external database.
- Make sure that all trusted SSL certificates are still there, such as vCenter and SSO.
- Check the authentication if it is still working. Use the test login.
- Check your licensing.
- Force a plugin reinstall (Troubleshooting | Reinstall the plug-ins when the server starts).
- Start the Orchestrator service and try to log in.
- Make a complete sanity check.
Package transfer
This is the method that will only pull your packages across. This the only easy method to use when you are transitioning between different databases, such as between MS SQL and PostgreSQL.
- Connect to your Windows version
- Create a package of all the workflows, action, and other items you need.
- Shutdown Windows and deploy the Appliance.
- Configure the Appliance with DB, Authentication and all the plugins you previously had.
- Import the package.
How it works…
Moving from the Windows version of Orchestrator to the Appliance version isn’t such a big thing. Worst case scenario is using the packaging transfer. The only really important thing is to use the same version of the Windows Orchestrator as the Appliance version. You can download a lot of old versions including 5.5 from http://www.vmware.com/in.html. If you can’t find the same version, upgrade your existing vCenter Orchestrator to one you can download.
After you transferred the data to the appliance you need to make sure that everything works correctly and then you can upgrade to vRO7.
There’s more…
When you just run Orchestrator from your Windows vCenter installation and didn’t configure an external database then Orchestrator uses the vCenter database and mixes the Orchestrator tables with the vCenter tables. In order to only export the Orchestrator ones, we will use the MS SQL Server Management Studio (free download from www.microsoft.com called Microsoft SQL Server 2008 R2 RTM).
To transfer the only the Orchestrator database tables from the vCenter MS-SQL to an external SQL do the following:
- Stop the VMware vCenter Orchestrator Service (Windows Services) on your Windows Orchestrator.
- Start the SQL Server Management Studio on your external SQL server.
- Connect to the vCenter DB. For SQL Express use: [vcenter]VIM_SQLEXP with Windows Authentication.
- Right-click on your vCenter Database (SQL Express: VIM_VCDB) and select Tasks | Export Data.
- In the wizard, select your source, which should be the correct one already and click Next.
- Choose SQL Server Native Client 10.0 and enter the name of your new SQL server. Click on New to create a new database on that SQL server (or use an empty one you created already. Click Next.
- Select Copy data from one or more tables or views and click Next.
- Now select every database which starts with VMO_ and then click Next.
- Select Run immediately and click Finish.
Now you have the Orchestrator database extracted as an external database. You still need to configure a user and rights. Then proceed with the section External database in this recipe.
Orchestrator client and 4K display scaling
This recipe shows a hack how to make the Orchestrator client scale on 4K displays.
Getting ready
We need to download the program Resource Tuner (http://www.restuner.com/) the trial version will work, however, consider buying it if it works for you.
You need to know the path to your Java install, this should be something like:
C:Program Files (x86)Javajre1.x.xxbinHow to do it…
Before you start….
Please be careful as this impacts your whole Java environment. This worked for me very well with Java 1.8.0_91-b14.
- Download and install Resource Tuner.
- Run Resource Tuner as administrator.
- Open the file javaws.exe in your Java directory.
- Expand manifest and the click on the first entry (the name can change due to localization).
- Look for the line <dpiAware>true</dpiAware>.
- Exchange the true for a false
- Save end exit.
- Repeat the same for all the other java*.exe in the same directory as well as j2launcher.exe.
- Start the Client.jnlp (the file that downloads when you start the web application).
How it works…
In Windows 10 you can set the scaling of applications when you are using high definition monitors (4K displays).
What you are doing is telling Java that it is not DPI aware, meaning it the will use the Windows 10 default scaler, instead of an internal scaler.
There’s more…
For any other application such as Snagit or Photoshop I found that this solution works quite well:
http://www.danantonielli.com/adobe-app-scaling-on-high-dpi-displays-fix/.
Summary
In this article we discussed about moving an existing Windows Orchestrator installation to the appliance and a hack on how to make the Orchestrator client scale on 4K displays.
Resources for Article:
Further resources on this subject:
- Working with VMware Infrastructure [article]
- vRealize Automation and the Deconstruction of Components [article]
- FAQ on Virtualization and Microsoft App-V [article]