I'm trying to figure out how to add or create a user based on the requestor of the VM..
I'm using a clone workflow in my blue print so I'm guessing that VirtualMachine.Admin.AddOwnerToAdmins is out of the question. Currently I have a script that runs after the vm is provisioned, part of this is to scan GuestAgent.log for VirtualMachine.Admin.Owner then create a local user and add it to the Administrators group.
I'm guessing that this isn't the best or right way to do things so any pointers would be appreciated
Your conversion theory would definitely explain this one but I’m afraid solving this little riddle is a little outside my level of comprehension at this time…Sorry...This is my first attempt at creating a Workflow. :smileyblush:
How would I go about to ensure the proper "string" conversion takes place before my first Action item? Is there another Action Element I need to introduce beforehand or do I need to simply change or add another Input Parameter in the current Action. Or, do I just substitute the current Action Element with a more apt routine? (Not sure if this is relevant but the follow-on Scriptable Tasks in my Workflow do depend however on the output of the vCAC Entity.)
I’m also not sure I follow you as far as checking the vCAC stub action is concerned?? The stub which calls this particular workflow is the MachineProvisioned WF. I’ve attached a screenshot of the first scripting element which happens to be the actual area of the conversion failure. I hope I’ve answered your questions and that this is sufficient for you.. If not, I did attach the complete Workflow in an earlier post if that helps as well.
Hi Ron, I think we are getting somehwere closer ... looking at your screenshot you can actually see that your CALLED vCO workflow expects a GUID in "string" format, which should look sth like this: "3F2504E0-4F89-41D3-9A0C-0305E82C3301".
So you now have to look at the place where you CALL the vCO workflow. This is probably inside the vCAC workflow stub "WFMachineProvisioned" via the vCAC Desginer. Or how did you register/setup your vCO workflow? So in the place where you CALL your vCAC workflow you have to make sure that you pass the ID (GUID) of the vCAC machine being provisioned as a string (and not as a native "object" or property thereof).
If in doubt just send another screenshot of the CALL to your vCO Workflow and we have another look.
Hmmm, the plot does thicken..! Here's the thing, I didn't use the vCAC Designer to call the vCO workflow. I used the vCAC Extensibility Plugin in vCO to bind the vCO Workflow to the Machine Provisioned WF Stub (as well as select Blueprints). (See attached screenshot). Is this not the way I should've associated the vCO Workflow??
Do I need to perhaps remove the State Change Workflow and re-assign (due to a registering anomaly) or do I now need to manipulate the built-in WFStubMachineProvisioned in vCAC in order to ensure the ID (GUID) of the vCAC Machine being provisioned is passed as a "string" instead of a native "object"..?? That doesn't seem right, does it??
I was able to figure this one out by trial and error. Dropping the 1st Action element altogether (which called the MachineId parameter) resolved this issue entirely!! Merely targeting the properties of the vCAC Entity was all that was required. Can't explain this but I suspect, given the State of the Machine (Provisioned), that this particular Input is simply redundant and not required or is getting clobbered because of a conflict with another Stub WF in the machine's provisioning cycle invoking this same call??
Nonetheless, happy to report this now works. I'm able to add the VM Owner/Requester to the VM's Local Admin Group without the use of the Windows Guest Agent. I've taken the liberty of attaching the complete package (Workflow and PS Script) once again.
Apologize, just revisiting this issue now. Not sure if the link below will be of any help or not but figured I'd post it here in case you (or anyone else) may be looking for an alternative, perhaps easier, way around this issue using the Guest Agent. The link below identifies deficiencies with actual native Custom Properties not being called or interpreted correctly and offers a safe, intelligent way around this. Not sure why VMware hasn't recognized or resolved this so that these particular native properties could be made available for provisioning by cloning operations (perhaps there are indeed residual issues when using these during cloning??), but the workaround described certainly appears valid and is supported with plenty of rationale to substantiate the fix.