VMware Cloud Community
RonPSSC
Enthusiast
Enthusiast
Jump to solution

Problems using the AD Plugin with the "embedded vRO" in vRA 8.0.1

Hello;

Desperately looking for guidance at this point but we'd be grateful for any assistance beyond that.

We're trying to leverage the AD Plugin using the "embedded vRO" integrated in vRA 8.0.1 to perform and duplicate certain Active Directory functions that we're using in vRA 7.6

To provide some context, we first successfully executed the out-of-the-box vRO Workflow "Add and Active Directory server" available in the vRA 8.0.1 Orchestrator. I've attached a few images along with a log file (errors) representing one of the actions we're aiming to complete using a newly-developed vRO Workflow. It appears as though we're unable to achieve the desired outcome in the Workflow because of suspected "missing" functionality in vRA 8.0.1?? Confirmation of this would be appreciated.

For the purposes of this particular posting, we're simply trying to "Destroy a computer" in AD by referencing the "adHostId" using previously-proven code with the vRA 7.6 Plugin.

Below is a brief description some of the discrepancies we were able to discover thus far:

1. The java call to the AD via the adHostId ("dunesId") is simply failing. See Log file error message "Unable to perform operation 'find('AdHost', 'null') on plugin 'AD'...."

2. For some odd reason the "static" Values of the Input/Output "Variables" do not appear to be used...as evidenced by the "null" entries within the Log file.

3. And finally, even when "manually" selecting the Active Directory Server directly via the plugin "Inventory", the auto-mapping of values via subsequent "Output Variables" do not take place...e.g. Type AD:AdHost (Not set).


Please advise if more info is required.

Thx. Ron

Tags (1)
Reply
0 Kudos
1 Solution

Accepted Solutions
stevedrummond
Hot Shot
Hot Shot
Jump to solution

I can't replicate your issue in 8.0.1. I managed to find an ADHost by its dunesId (which I totally would not recommend doing), find a computer object and delete it. This was with separate workflow steps just to make sure it worked via attribute passing.

Have you double checked your inputs? The fact your error stack shows find('AdHost', 'null') makes me think it's being passed a null value. Can you do a System.debug(adHostId) and validate it's got the dunes reference?

You can run Server.findForType('AD:AdHost', null) and you'll receive the same error.

Failing that can you upload the whole workflow?

View solution in original post

Reply
0 Kudos
4 Replies
stevedrummond
Hot Shot
Hot Shot
Jump to solution

I can't replicate your issue in 8.0.1. I managed to find an ADHost by its dunesId (which I totally would not recommend doing), find a computer object and delete it. This was with separate workflow steps just to make sure it worked via attribute passing.

Have you double checked your inputs? The fact your error stack shows find('AdHost', 'null') makes me think it's being passed a null value. Can you do a System.debug(adHostId) and validate it's got the dunes reference?

You can run Server.findForType('AD:AdHost', null) and you'll receive the same error.

Failing that can you upload the whole workflow?

Reply
0 Kudos
RonPSSC
Enthusiast
Enthusiast
Jump to solution

That's precisely what is was, Steve...! Good catch..!!

I had believed that since the "attribute" value was statically set that I could reference it as an "Output" on the initial Scriptable Task (which takes place before the Scriptable Task that actually locates the ADHost) but looks like the output of the initial Script was substituting the static value of the "attribute" with a null. Interesting since I believe vRO 7.6 does not make this distinction but could be wrong..??

In any event, I should be good to continue testing..

Can you elaborate a little further though as to why you would not recommend finding an ADHost by its dunesId? Is there a better/more reliable way of invoking Actions through an Active Directory Server? It's important to note we have a requirement to target individual AD Servers (as opposed to a Default one). Forgive me if the response to this question might not be an easy one. If the correct way is via RESTful APIs, I'm afraid we're novices of sorts .

Thx again

Reply
0 Kudos
stevedrummond
Hot Shot
Hot Shot
Jump to solution

Any time you link an attribute as an Output on a workflow step you must set the value otherwise it will revert to default vRO behaviour (null, empty string, whatever). You do not need to do this if you only ever use an attribute as an Input or include it as both an Input and Output.

The dunesId will change whenever you remove/add an object or move to another vRO. It's better to do a lookup for your plugin host by identifiable information specific to your application domain (programming domain, not Windows domain). In this case you might look it up by connection name "my friendly domain name" or the actual domain fqdn "my.domain.local". This way it works even if people remove/re-add connections or you sync your workflows to another vRO environment.

Unfortunately most of the finder methods for plug-in objects are not implemented well or at all, so you are reduced to getting all connections and applying a linear filter. However it's unlikely you're going to have enough connections for it to be an issue.

An example of what I mean:

Action domains.findByFriendlyName(name)

const hosts = Server.findAllForType("AD:AdHost");

for each (var host in hosts) {

     if (host.name === name) {

          return host;

     }

}

throw 'No host found with name "' + name + '"';

If you're worried about overhead by the lookups you can configure a config element that stores the dunesId and an action that returns the host using that ID. All workflows/actions that need to get the host should then rely on that action. Right now you've hardcoded the ID into your workflow which is extremely problematic.

Hope that helps.

RonPSSC
Enthusiast
Enthusiast
Jump to solution

We'll give your suggestion above a try, Steve.. Thx

Once again, appreciate your insight and recommendations!!

Ron

Reply
0 Kudos