vRA7 to vRA8 migration - Orchestrator

-

Steps to get up and running with vRO 8.

Depending on your previous usage of vRO 7 this might the step that requires the most work when you are migrating to vRA8.

  • Attribute Parameter Contains vCAC/vCACCAFE type! cafeHost|vCACCAFE:VCACHost| Switch to vRealize Automation 8 Types
  • Input Parameter Contains vCAC/vCACCAFE type! subtenant|vCACCAFE:Subtenant Switch to vRealize Automation 8 Types
  • Input Parameter Contains Payload Properties! payload|Properties Ensure the selected properties are supported by vRealize Automation 8
The first two will be quite common for everyone who has automated vRA7 using the vRA Plugins for vCAC and vCACCAFE the only working rewrite here is to move to the REST API and redo the work directly.

The last one is also heavily used by everyone who relies on the Subscriptions both by pick up information in vRO and sending information back to vRA with "virtualmachineAddorUpdateProperties".

With just about 190 workflows to redo/rewrite or so i guess i can feel lucky,

Many can be fixed prior to migration, where we can adapt easier methods for passing along data between workflows, using native datatypes. This probably will be a huge performance gain anyways so be forced to is not a all bad situation.

Tho looking at the amount of time needed to fix all the workflows for managing vRA7 is a bit of hazzle, but will at least get to know vRA8.

Kommentarer

Legg inn en kommentar

Populære innlegg fra denne bloggen

vRealize Automation 8 - Migration Assistant - Entitlements

-
While assessing the migration to vRA8 most definitely you will run into deprecated entitled actions or extensions. A lot of the internal VMware Actions or Extensions are no longer valid, here is a small list of common ones: Connect using SSH Connect using VMRC Connect using RDP Execute Reconfigure Cancel Reconfigure Scale In Scale Out Power Cycle ... A dirty quick fix is to loop all your entitlements before running the migration assistant and remove all of these deprecated if you do not depend on anyone using them in your vRA7 environment. var entitlements = Server.findAllForType("vCACCAFE:Entitlement"); for each (var entitlement in entitlements) { System.log(entitlement.name); var updated = false; var host = vCACCAFEEntitiesFinder.getHostForEntity(entitlement); var client = host.createCatalogClient().getCatalogEntitlementService(); var entitledResourceOperations = entitlement.getEntitledResourceOperations(); for each (operation in entitledResourceOperations) {
Les mer

vRealize Orchestrator and Microsoft Powershell Double Hops

-
Recently started automating Microsoft DNS and the best way in seems to be through Powershell . One of the common ways to deal with this is through a Powershell Host defined in vRO. You set it up securely with HTTPS and Kerberos and specify the credentials of a user with DNS server rights enough to see and manipulate the content of the zones and records you want to automate. So far so good, and you start developing the PowerShell commands you might need. Resolve-DnsName (Get-ADDomain).DNSroot -type ns | ? {$_.type -eq "A"} | select name,Address,IP4Address,IPAddress | ConvertTo-Json -depth 1 -Compress Get-DnsServerZone -ComputerName (Get-ADDomain).DNSroot Get-DnsServerResourceRecord -ComputerName (Get-ADDomain).DNSroot And they all work out nicely when you run them from your Powershell host, but once you run them from vRO in the Powershell session you run into the double-hop auth problem . There are many ways to deal with this, but often you need to thinker both with the Powers
Les mer

vRealize Orchestrator - SSH Keys - Idea for how to easy manage multiple keys

-
Many are using SSH to run commands something similar to  var  passwordAuthentication = false; var password = ''; var session = new SSHSession(hostName, username, port); session.connectWithPasswordOrIdentity(passwordAuthentication, password, path); Where the path leads to the private key file for the connection. Storing several key files in the vRO filesystem could easily lead to forget it when moving to a new vRO or add a new vRO node. Also when moving forward with vRO 8 it's less of a good idea to add elements to the local filesystem as a manual step. My suggestion for a solution is to make use of the vRO resource element. Store your key file as a vRO resource element, using the following step of code can runtime make the key available for SSHSession. var tempDirectory = System.getTempDirectory(); filePath =  tempDirectory + "/" + keyfile.name; keyfile.writeContentToFile( filePath ); Send the private key file as a resource to the action or workflow and you will h
Les mer