vro workflow changes

[CarlLink]

I noticed something very strange when auditing changes to workflows.

An action was changed by the user account "cafe-xxxxxx@vsphere.local".  This is a vRA environment but I was wondering if anyone here knew why vRA would be rewriting a vRO Action.  The action happens to be com.vmware.vra.ad.getObjectByDN.  Below is a capture from the Events tab of the action.

Any insight much appreciated.

Carl L.

[iiliev]

Such log events could be generated during action import (ie. importing a single action, importing a vRO package that contains the action, uploading a plug-in that has this action as part of its content, etc.)

[CarlLink]

I know that from a user perspective, but from a "cafe" account is what I find unusual.  And no one is fessing up to changing the vRA plugin (which this action seems to be associated with).  This is our QA system so if they did, they had better fess up :-).  Could this be caused by a reboot of the vRO appliance (and the plugin getting loaded during the reboot)?

Carl L.

[iiliev]

Could be, if the plug-in has its installation mode set to "always" in its vso.xml descriptor file (which will cause the server to try to redeploy the content of the package bundled in the plug-in).

Could you check which is the exact build number of the plug-in containing this action?

[CarlLink]

It is the embedded vRO in vRA 7.4 HF11

---------------------------

vCAC 7.4.0.8072010

vRealize Automation Center Infrastructure Administration plug-in for vRealize Orchestrator

vCACCAFE 7.4.0.8074348

vRealize Automation plug-in for vRealize Orchestrator 1

Thanks,

Carl L.

[iiliev]

OK, the plug-in indeed has its installation mode set to "always".

But I can't seem to find such action inside the plug-in (and the other actions there follow different naming convention - com.vmware.library.vcaccafe.<something>).

Could you check where this action is coming from? Is it possible that it is part of some non-standard plug-in or package, for example a package deployed by QA people for testing?

[CarlLink]

Interesting.  So I checked the other vRA actions and all the actions in com.vmware.vcac and com.vmware.vra have this behaviour.  The workflows related to vRA do not get touched, just the actions.  Now that I have a clue where it might be coming from, I will check with the team about vRO reboots.  Our monitor has only been running a couple of days so a bit more history will also prove useful.  This was the first time I saw this so there might be other things happening (like a reboot).

Thanks so much Ilian.  I will post here anything further I notice.