Automation 101 – Orchestrator & AD, Revisited

imageAs mentioned here, I have been playing around with the “nuke from orbit” bits in vCO for both Virtual Machines & their AD objects. One of the snags I hit was the fact that one of these things was not like the other. That is, the VC:VirtualMachine bits that the vCenter plug-in uses could not be passed directly to the AD:ComputerAD that the Active Directory plug-in uses.

Translation from VC:VirtualMachine to AD:ComputerAD

So to go from one to the other we need to use the getComputer method from the ActiveDirectory scripting class (from the plug-in) and call it using the name of the VM we’re working with:

computer = ActiveDirectory.getComputer(;
System.log (computer);

Wait, what?

Yeah, trying to explain that in a way that was non-programmer speak can get be interesting. Basically, we’ve got a foreign and domestic car and need to have a way for the mechanic to be able to work on both. So what we did was give him a set of tools and manuals to make the conversion. I think…

Why is this important?

For the AD use case it’s pretty important that you be able to target the right object if you are going to be deleting it from AD. If you are beginning with a VM, you’ll need to know how to find that VM in different systems. On a grander scale, being able to talk about the same thing between several systems is critical.

Picture credit to this guy.

4 thoughts on “Automation 101 – Orchestrator & AD, Revisited

  • Nice but what happens if your VM name and guest name are different ?
    It would be safer then to get the guestname from the VM (vm.guest.hostName).
    Also you have a typo in ActiveDirectory.

  • An annotation to vm.guest.hostName: It’s only there if the VM (excatly spoken: the vmware-tools) is running!
    So a robust workflow should check this before, or be able to handle a “null” for the hostName without hard error…

  • Sure. You should always check for null & undefined & sometimes 0 length or object type != then notFound object (yes such thing exist !) before calling a method. You can also use try catch block and use workfows exceptions.
    This is for the wild world our customers lives on. For those who do not have the tools installed (shock horror) you can implement a remediation installing them or a per minute looping email notification saying “I will never run a VM again without the tools installed” 😉

  • 1) Spelling fixed 🙂
    2) Good catch, there are a few ways to skin this particular cat
    3) Also a good point, that is one of the downsides to a home lab… what I do may not always mimic “the real world”. I think yours would work much better in the wider world.

Comments are closed.