How to upgrade vom 5.5.3 to 7.x

[Kagome]

Hello,

i would like to migrate within the next weeks from VMware vSphere 5.5 / vCenter 5.5 and so on to vSphere 6 and Orchestrator 7.0.1.

In the past was EVERY Orchestrator Upgrade a pain in the ass.

So the question is simple: How do i upgrade correctly from Orchestrator 5.5.3 (Windows) to 7.0.1? The documentation is not giving that much information.

I have around 250 own Workflows, some are with Databaseconnections to different MySQL Servers some are going to the ActiveDirectory and some are to different Rest Hosts.

In the past it was every time horrible to reconfigure the Databasesettings, certificates, Mailsettings, AD-Settings and so on...

An other basic Question: That Windows- Orchestrator Version will not be developed in future - so the Appliance is the future way?

I ask because i have some Scripts and so on stored on that Windows Orchestrator which is the Orchestrator downloading to VMs if needed (e.g. extending a Volume in the guest OS after I resized the vHardDisk and so on).

I know that i need to change all Paths in the Workflows with the update ... but how is it when i update the Orchestrator Appliance later? Will the files be deleted in the Appliance or what? Can I access the Filesystem?

[Hazenet]

Maybe consider doing a seperate VMDK for just your files.

That way, you could detach/unmount that during upgrades (to be 100% sure), and then reattach/mount it afterwards, with the same mount-path.

Never done it on a VMware Appliance

[iiliev]

Hi,

There is no automatic migration from Windows installation to appliance - I think you need to deploy a new appliance and manually export/import the configuration and the data from your Windows installation.

vRO 6.x versions are the last ones to feature Windows installer; vRO 7.x are appliance-only (either standalone appliance or embedded as part of vRA appliance).

To transfer your 250 custom workflows, perhaps the easiest way is to add your workflows/actions/resources/configurations/etc to a vRO package, and export/import the package as a whole. In the future, you may consider keeping your workflows and other stuff expanded as XML files and stored in a version control system, eg. Git - we provide some tooling to expand vRO objects as files and build back a vRO package when needed.

You can access filesystem in various ways. There is a vRO scripting API for reading/writing files, there is also SSH plug-in for doing SSH access, etc (you just need to have sufficient user permissions to perform file system operations).

[Kagome]

Hello,

thanks for the first answers.

I did in the past the export / reimport of the workflows (+ resources, + whatever) as a package.
There are only a few problems: All Database Connections / other things with passwords are not working anymore due to a new certificate.

An other point is that all scheduled workflows were in the past missing (maybe Orchestrator server got a new Server-ID for the database or whatever?) so I had to add them manually, too.

Is there a trick to get that scheduled workflows without much work to a new Orchestrator Appliance?

[iiliev]

Scheduled workflows are stored in the database, so if you upgrade to newer vRO version but keep the same database then I would expect scheduled workflows to be still there. If you also switch to a new database, then the scheduled workflows will disappear.

You can think of some script to copy scheduled workflows' tables from the old to the new database, but there is not 100% guarantee that after transferred they won't need further tweaks.

[Kagome]

Well,

when I did the last update, the scheduled workflows were in the database (was the same) but not in the Orchestrator Client visible.

[ivand]

Please, check this: Migrate the Orchestrator Configuration

This describes how to migrate from Windows deployment to 7.0.1 appliance. Use Java deployed with Orchestrator installation to add to the PATH variable.

[prestonville · Accepted solution]

We were running windows 5.5.2 and went to 7.0.1 appliance. Did it via package export and import which worked fine for us. Appliance is definitely the future.

We are also running multiple orchestrators for different vRA tenants and for one production vRA tenant now using the bundled orchestrator on the vRA7 vRA CAFE appliance cluster (small distributed model). This seems to be working no problems. For the workload limits we discussed it with the VMware vRA7 upgrade team and they said that bundled vRO is now supported for production vRA tenants not just POC/tests as in vRA6. Loading looks ok in the new Orchestrator management tools.