Guest script manager package

Guest script manager package

- 2016-11-01 - Please note that this package has been relocated to the VMware Sample Exchange due to the recent decommission of FlowGrab.com.

- 2015-03-24 - The package is now hosted on fowgrab to allow communities contributions

- Updated 2015-01-05 by Daniel Linsley:

  • Does not break anymore with UAC but UAC may still prevent some scripts to run.
  • Improved sleep for better handling of low script refresh

Running commands or scripts in VM guest is something that has been done with vCO for quite a while using different mechanisms. A popular way was to use the VIX plug-in for vCO. This plug-in is not needed anymore since the VIX functionality is part of the vCenter API since vCenter 5.0 and there are guest operations workflows to copy a script and run it into a VM guest OS since vCO 5.1

Using these library workflows requires to copy scripts from the vCO file system or include the scripts in your workflows. Getting the script output can be tricky and if part of the script include parameters that need to be replaced with your custom workflows inputs it requires a bit more coding.

The Guest Script Manager handle all of this for you so you do not have to reinvent the wheel. You can even create specific workflows to run existing scripts without having to do any vCO scripting !

Features

Script management : Add, edit, delete a script configuration. A script configuration contains:

  • Script type (bash, batch, Powershell) : Each type involve a different way of starting the script and getting the output.
  • Script content: The script itself. May contain parameters that will be replaced right before running the script.
  • Timeout: The time after the script execution is
  • Script interactivity: In case the script open a window that requires user interaction.
  • Script working directory: Where the script will run. Where the optional file will be copied.
  • File to copy: A file to be copied in addition to the script. For example a response file needed for the script.

The script configurations are stored as resource elements in the vCO database. This means :

  • Updating a script does not require updating a workflow
  • The scripts are in a much safer location compared to the file system
  • If you run a vCO cluster, the scripts are available for every vCO nodes
  • That you can export / import the script configurations in a package

The script configuration runner : "Run script in VM guest"

  • Search replace specified strings in the additional file, copy it to the guest (optional).
  • Search replace specified strings in the script, run it in the guest.
  • Get output code and output result, display these (including special characters supported by ANSI thanks to the included cmdAnsi.exe), fails the workflow if script failed.

There is also a workflow to run multiple scripts one after the other and a workflow to upload your files as resource elements.

Links

Credits

  • Reuben for the original guest Operations package.
  • vCO Engineering to make available guest operations workflows in vCO 5.1
  • Benoit for the included / modified "run script in guest" workflow
  • Pierre Torris for creating cmdAnsi. Donateware on www.ptorris.com
  • Burke / Henrik for testing early releases
  • Daniel Linsley for providing enhancements to the original package

Known issues

You must turn off UAC on Windows (2015-01-05) Package updated by Daniel

Use the package with the date to get the latest. The other one was kept for people needing the original.

Disclaimer: These samples workflows are provided AS IS and are not considered production quality and are not officially supported. Use at your own risk. Feel free to modify and expand and share your contributions.

Attachments
Comments

This is a great tool. I have rewritten several of my scripts to utilize these calls.  They do run a little slower than the internal VIX calls, but the output text feedback is worth the extra wait.

Personal Notes:

  • The "Edit Script Configuration" workflow does not properly re-import the script for editing. If you still have the previous "Add script configuration" you can run again and make your changes and overwrite.
  • Certain commands complete successfully but give an error - "A specified parameter was not correct. (Workflow:Delete file in guest / Scriptable task (item1)#9)"
  • Can't use OGNL codes when utilizing script variables. You must use a script to put stringToReplace and replaceString variables into the composite array type. Don't forget to Push it after every value pair.


Great Package and it is a life saver.


~Alex Allen C.

Thanks for the feedback.

I have uploaded an updated version:

  • Fixed "Edit Script Configuration": unfortunately I was missing an action in the package loading the script parameters.
  • Delete file in guest : I added an exception handling since it is likely the file is not there to be deleted so I can end up the workflow successfully
  • I did not fix the case of using OGNL code
  • I made the refresh time after running the script 1 minute instead of 5 seconds since I have been told increasing refresh time improves reliability. If this part of the workflow fails somewhere please post a screenshot so I can pinpoint the issue and find a possible remediation
  • I have got feedback that sometimes the action testVmToolsForGuest returns it is ready while the Guest Operation Manager fails. I have advised to add a System.sleep in the Run script in VM guest workflow to work around this problem and got feedback this fixes it. Again if I get more details on the issue including screenshots and the exception thrown I will be able to update the workflow to attempt a "wait and try again" remediation.

If I run "Add script configuration" but do not elect to copy a file in guest, I do not see the "Resource to copy" in the presentation.  This means the "Delete file after running the script" is stuck at the default of "Yes" and running the script configuration will fail when trying to run "Delete file in guest" in the "Run Script in VM guest" workflow (even though the script actually ran successfully). 

Setting the default value of "Delete file in guest" to "No" in the presentation fixes this.

Thanks for the feedback. I will revisit the package next week.

Another update today. Hopefully this will fix all the issues that have been reported. Please test thoroughly as I only had time to do sanity checking.

NB : The script state refresh time is now part of the script configuration (but is not mandatory and will be set to a default 60 seconds if not set).

Christophe-

I just imported the new package in and took a walk through the newest sets of workflows... This is really starting to look awesome. I only see one problem in run logic that I think needs to be addressed, and it's a pretty easy thing to address (I think). In the execute script block, there needs to be exception handling off of the guest process check for instances where the guest operations agent becomes unavailable (I have a script that causes it to happen in Windows every single time). The way I worked around it in the previous iteration was to put in that handler to a scriptable task which basically loops it back up to the sleep / count task. Usually by the next cycle, the operations API is back, and things go back to normal.

Beyond that, the only thing I'd like to see (and I'd even be happy to help where I can) is some cosmetic things throughout the various workflows: cleanup of the names of the various actions so that it's clear what's happening and setting of business status at critical points of the process so that it's clear what's going on and it's easier to decipher. And I'd also (personally) like to shed the COE branding on where the package / files exist and have it live in something that makes a little more sense / easier to find (i.e. a folder structure like "Guest Script Manager" or something).

Let me know if/how I can help, and I'd be happy to lend a hand. This package has been a lifesaver for our deployment!

-Steve

I too have seen the "guest operations agent unavailable error."  I can make it occur consistently during a Windows reboot from Windows Update.  In addition, It also tries to delete a file from guest that does not exist.  My I guess is that it is because the commands that I run simply have no output. 

The delete file in guest errors have been cleared up with the latest package (there was a logic error in the cleanup portion of the Run script in guest workflow), so.. if you update, that should be all good now. As for the other issue, I'm not surprised you're seeing an error with the guest agent being unavailable during a script that initiates a reboot from within the guest (rather than via the workflow once the script / process completes)... Two problems with doing things that way (in my opinion): 1) the script is, by execution of the reboot, complete.... and; 2) the script refresh time isn't going to be able to get a list of processes and determine if the script is still running if the system is in reboot.  Personally, if a reboot is required , that should be initiated from within the workflow through a vCenter call, rather than from within the VM. It'll be easier to control state, and much more reliable.

In my case, however, the guest operations agent was dying in the middle of the script; I was using dism to perform an online edition change of Windows. After making a slight tweak to the run script in guest workflow, I was able to get clean runs every single time (hopefully Christophe adopts how I solved the problem, or finds a more elegant solution). However, while that fix might solve the problem with the workflow failing, since you're taking the reboot action inside the guest, you'd (probably) lose the ability to capture the output of said script, and use that for extended error handling.

Just my two cents there, though.

-Steve

Just found one more (minor) bug that I thought had been corrected; in the 'Run Script in VM Guest' workflow, the O/S <--> Script type check still has a typo for Linux; it still shows 'kinuxGuest' for bash scripts... I could of sworn that was fixed, but I thought I'd mention it.

-Steve

Thanks Steve,

I have certainly rushed too much doing this update and may have merged the last changes in an older version that did not have the Kinux fix. I hope I will have the time to update it again later this week.

Christophe.

My scripts do not initiate the reboot.  I do a Get Process call to monitor when the powershell script ends. After it ends a Graceful Shutdown and Power on is done. After a Windows update there is a long period where the VM is "Updating" - The service is running, but the aforementioned "unavailable guest operations agent error  occurs."   Prior to the release of the new version, I had manually modified the workflow to loop when the error occurred.  However, it was after this that I also received a delete file in guest error. I will screenshot and document the next case of this.  Again, this only occurs on longer periods when you are patching the VM for the first time.

I have added an error handler for checking the process and looping back, fixed the Kinux typo, added business states. The thing I did not do is refactoring / re arranging / renaming & removing COE as I do not have time to do it & test without risking to break it and also because I think ultimately this should happen if / when this will be productized.

Christophe-

I'll be running through a full regression test on the new package this afternoon / through tomorrow, but I'm pretty sure this is more or less perfect (for me)... The only thing that I noticed, and this is something that came up today because I was actually testing a script that I expected to fail at a certain point -- the point of that process was to change the administrator / root account at the end of a provisioning request under certain circumstances -- was that if I didn't add a throw into the loop processing when the get process list failed... well, it just looped. How I handled it was by having the following text slated in the scriptable task (item40 in the current 'Run Script in Guest' wf):

if (errorCode.indexOf("The guest operations agent could not be contacted") > -1) {

var msg = "Error getting the process list, retry during next loop cycle";

System.log(msg);

Server.warn(msg);

}

if (errorCode.indexOf("Failed to authenticate with the guest operating system using the supplied credentials.") > -1) { throw "Failed to authenticate with the guest operating system."; }

Setting it up that way got me exactly what I needed. Just something to think about; I could imagine if the credentials aren't working, there shouldn't be any point in it retrying.. it should just fail. (at least, that's my opinion).

As always, thanks for the excellent work.. and let me know if there's anything I can do to help clean things up / etc. I'll report back if I find anything else of consequence.

-Steve

[I] Premature end of Content-Length delimited message body (expected: 9; received: 0 (Workflow:Copy file from guest to vCO / Scriptable task (item1)#10)

Sometimes this error appears, sometimes it doesn't. Whatever the case is, it kills my workflow each time.

~Alex

Hi Christophe,

  I'm hoping you can tell me what I am doing wrong.  I have a script to prep the input parameters for "Run script in VM guest" workflow.  I want to call this from a vCAC WF stub, so I'm just reading network properties from the vCACVmProperties ---

scriptVariables = new Array();

scriptVariables = System.getModule("com.vmware.coe.copyAndRunScriptsInGuest").addScriptVariableToArrayOfScriptVariables(scriptVariables,"[IPaddress]",vCACVmProperties.get("VirtualMachine.Network0.Address"));

scriptVariables = System.getModule("com.vmware.coe.copyAndRunScriptsInGuest").addScriptVariableToArrayOfScriptVariables(scriptVariables,"[netmask]",vCACVmProperties.get("VirtualMachine.Network0.SubnetMask"));

scriptVariables = System.getModule("com.vmware.coe.copyAndRunScriptsInGuest").addScriptVariableToArrayOfScriptVariables(scriptVariables,"[gateway]",vCACVmProperties.get("VirtualMachine.Network0.Gateway"));

scriptVariables = System.getModule("com.vmware.coe.copyAndRunScriptsInGuest").addScriptVariableToArrayOfScriptVariables(scriptVariables,"[primaryDNS]",vCACVmProperties.get("VirtualMachine.Network0.PrimaryDNS"));

...I get an error "Cannot set individual field values in an array of composite values" when it runs this script. I cannot figure out why this won't work; I copied the syntax from one of your sample workflows.

Just make sure you duplicate completely one of the sample workflows. This will insure that scriptVariables is of the right type and not set before the scriptable task.

Also as an alternative you can follow the directions in this article : Leveraging the Guest Script Manager package

Hi Christophe, I got the same error today that Alex above was getting.  Do  you have any solutions to correct this? Premature end of Content-Length delimited message body (expected: 39; received: 0 (Workflow:Copy file from guest to vCO / Scriptable task (item1)#10) Thanks, ~Matt

I have never got this issue. Is the file deleted in the guest ?

No, the file is still there which is the strange part.  I was able to open the file and it had txt in the file from the command that was run. Results in file: Updates Required: Installing 3 updates Here is the powershell that was run : 2014-05-13 10:36:24.653] [E] trap {   Write-Error $_     exit 1 } if(Test-Connection -ComputerName Server.domain.local -Count 2 -Quiet){ #Get Windows updates available to download for system $WindowsUpdate = (New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow() #Check for updates $UpdateSession = New-Object -ComObject 'Microsoft.Update.Session' $UpdateSearcher = $UpdateSession.CreateUpdateSearcher() $UpdateSearcher = $UpdateSearcher.Search("IsInstalled=0") #If there are updates apply updates $count =$UpdateSearcher.Updates.Count    if($count -gt 0){       Write-Host "Updates Required: Installing $count updates"   }else{       Write-Host "None: No Updates to Apply"   } }else{   Write-Host "None: Cannot Connect to Windows Update Server" } [2014-05-13 10:36:24.653] [E] /C powershell -OutputFormat text -NoProfile -NonInteractive -ExecutionPolicy unrestricted -f C:\Users\ADMINI~1\AppData\Local\Temp\vco_vmware69.ps1 > "C:\Users\ADMINI~1\AppData\Local\Temp\vco_vmware93" [2014-05-13 10:36:25.376] [I] cmdANSI.exe already exist on vCO server : /var/lib/vco/app-server/temp/cmdANSI.exe [2014-05-13 10:39:18.757] [I] Premature end of Content-Length delimited message body (expected: 39; received: 0 (Workflow:Copy file from guest to vCO / Scriptable task (item1)#10)

This may require to add exception handling for this specific error and retry the copy after a sleep of a few seconds, With that said I am not sure that would fix it. It seems something is going wrong in the VC guest operations.

Hi,

first of all, thanks for you fantastic work, I can see dozens of uses for the workflows which will make my life much easier:)

Now I'm trying to get a simple workflow to run on a vm and get the following error:

[2014-05-19 09:04:27.003] [I] cmdANSI.exe already exist on vCO server : /var/lib/vco/app-server/temp/cmdANSI.exe

[2014-05-19 09:04:27.396] [I] Unable to access file C:\Windows\system32\cmdANSI.exe (Workflow:Copy file from vCO to guest / Scriptable task (item1)#11)

Re-running the script generated another error:

[2014-05-19 09:51:45.133] [I] cmdANSI.exe already exist on vCO server : /var/lib/vco/app-server/temp/cmdANSI.exe

[2014-05-19 09:51:45.548] [I] org.apache.http.conn.HttpHostConnectException: Connection to https://[ESX_Host_IP_the_VM_runs_on]:443 refused (Workflow:Copy file from vCO to guest / Scriptable task (item1)#12)

I understand the script has to be copied from vCO and executed on the guest, but I get a bit lost when it comes to the port communication. Does 443 need to be open only between vCO and the ESX Hosts or between the guests and vCO \ ESX too?

Hi,

cmdANSI.exe is a third party tool I use to convert the script output to ANSI format vCO can use. It seems that in your case it does not get copied to System32. To use guest operations you must turn of UAC in windows. This is what often prevent the file from being copied.

As for 443 I think it needs to be opened between vCO and ESX.

Thanks for the reply.

I have already deactivated UAC and copied the file manually to the guest, but am still getting the second error. Therefore I have removed the 'Copy file to guest from vCO' \ 'Copy file from guest to vCO' workflows from the main workflow (Run Script in Guest) and set the value of the vcoCopiedFileResult to true as default. It's a dirty hack, but it works, the batch script is executed. The only issue so far is, that the workflow gets stuck in a loop at the Waiting timer while checking the process id, but this should be no issue, when I get my port communication right.

Hi Christophe,

     Excellent work on this.  We've just begun deploying vCAC and this tool is already making my life so much easier.

I think I'm missing something when I try to feed in variables.  I'm unable to find the action addScriptVariableToArrayOfScriptVariables referenced in the comments here as well as the "Leveraging the Guest Script Manager package" link.  I have searched in actions and in com.vmware.coe.copyAndRunScriptsInGuest.  Am I missing a plugin or package somewhere?

For reference, I'm using vCAC 5.2 with vCO 5.5, but I've also tried with vCO 5.1.

Thanks!

This action is in one of the sample files: For example Script manager batch script samples (Local administrator and managing DNS records)

hey jddias/group where is this set please?

Setting the default value of "Delete file in guest" to "No" in the presentation fixes this.


these errors are making me crazy. script runs fine.

[2014-07-02 10:03:27.938] [I] A specified parameter was not correct.

(Workflow:Delete file in guest / Scriptable task (item1)#9)

[2014-07-02 10:03:27.999] [I] A specified parameter was not correct.

(Workflow:Delete file in guest / Scriptable task (item1)#9)

If you edit the workflow "Add script configuration" and select the Presentation tab.  Under "Resource to copy" set the properties of "deleteResourceAfterRun" to default value of "no" - but honestly I think that has been fixed.  The version I am using doesn't require me to adjust this and works without error.  I think Christophe addressed this by checking to see if a file was even copied AND the delete resource is true.

thx for the package...its been a big help already.  Question though are VMware tools actually required?  I had hoped to use it to answer some questions on the console.  I have a VM i'm trying to spin up from a shell, mount an ISO, and and input one line then enter.  This is enough to build the server but at this point no OS exists just need a way to fill that first line for it to start.  I have a script with your package already created but again it validates tools are present.

Tools are required since the guest operations are run by it. I would suggest using SSH for your use case.

Thx for the info, good thoughts except that at this point their is no IP.  I was trying to create a VM with the basic workflow, mount the cdrom with a build ISO but then I have to pass a line to the boot prompt to build everything, after that I could use SSH. Is the only way to use a kickstart config  file, is their no other way to pass one line to the console?

On Windows you can use the autorun on the CD. There may be similar feature on Linux but will certainly require KDE or similar that you do not have at this point. The other way would be to build in the script and its startup within your template.

When i put a folder location for the file I want to copy and the WF runs I get " stop (Workflow:Run script in VM guest / Set script filename (item33)#1) " if i leave that field blank it copies the file to c:\users\administrator\app data\tmp (along those line) but I cant seem to get it to put the file in a specific directory (no spaces i the file path either).

I found the answer in " Set script filename " item #33 the second action listed was " throw "stop"; " so no matter what I put down if I listed a path it would stop the WF...removed for now.

Hi,

are there issues with running script on Windows 2012 and 8.1?

I want to run a script that changes the default admins password, using a simple "net user administrator [RandomPassword]". I use the credentials of another account with admin privileges. The workflow runs fine on Win 2008 and Win 7.

When using a powershell script configuration, I get an error when "Run Script in Guest" is run:

[2014-08-01 09:34:01.527] [E] trap

{

   Write-Error $_

    exit 1

}

net user administrator RandomPassword123

[2014-08-01 09:34:01.528] [E] /C powershell -OutputFormat text -NoProfile -NonInteractive -ExecutionPolicy unrestricted -f C:\Users\VIRTUA~1\AppData\Local\Temp\vco_vmware145.ps1 > "C:\Users\VIRTUA~1\AppData\Local\Temp\vco_vmware55"


vCO shows though, that the WF finished with no issues, but the change in the guest is not executed.

When trying to run the script using batch, Run Script in Guest runs without errors, althought I still get the "A specified parameter was not correct. " messages:

[2014-08-01 09:42:07.578] [I] A specified parameter was not correct.
(Workflow:Delete file in guest / Scriptable task (item1)#9)
[2014-08-01 09:42:07.626] [I] A specified parameter was not correct.
(Workflow:Delete file in guest / Scriptable task (item1)#9)

The "Run Script in Vm Guest" WF fails after thet with the red "error: no output" message.

Can it be an issue with cmdansi running under the newer Windows versions?

Also, I get a lot of the

[2014-08-01 09:42:07.578] [I] A specified parameter was not correct.
(Workflow:Delete file in guest / Scriptable task (item1)#9)

errors too, even if the workflow runs fine.

Th[2014-08-01 09:42:07.578] [I] A specified parameter was not correct.
(Workflow:Delete file in guest / Scriptable task (item1)#9)


EDIT:

Just found out after posting this, in the newer windows version, disabling UAC in the Control Panel is not enough, you still have to set the EnableLUA Regkey to 0 - http://social.technet.microsoft.com/wiki/contents/articles/13953.windows-server-2012-deactivating-ua...

This allows for the script to run.

The A specified parameter was not correct. errors are still there though.

When running a powershell script with your code I noticed that it is truncating large logs after the cmdansi runs, if I set this to false I get the full log back.  Do you have any suggestions?

Thanks,

Matthew A. VanBibber

While this stops the workflow from looping, it results in a failed workflow.  What is needed to fix this issue?  I'm experiencing this when running a running a powershell script within the guest VM to promote the VM to a domain controller.  I'm a vCO noob with almost no programming skills at the moment, so please be gentle.

Jeremy

I just posted in the main forum on this issue but wanted to x-post here just in case.

Any time I build a new vm in our environment and try to run a workflow that must first authenticate, i.e. copy a file from vco to guest, I get the error "Failed to authenticate with the guest operating system using the supplied credentials."

The moment I join the domain I can get it to authenticate. Oddly, if I unjoin it and the AD object goes away, I can still run the workflow. So, after it joins something is "caching" even after unjoining. I can't think of what would be preventing me from authenticating with vCO using the local Administrator account without joining the domain.

Our vCenter is joined to the domain and vCO has full access to it.

And I'm trying to do the opposite.  I can authenticate fine when the VM is in a workgroup, but as soon as I make it a domain controller it can not longer authenticate.  Also, and remember I'm still new to vCO and coding, when I ran through the debug on the workflow just to see what was going on every step of the way, the workflow completed successfully.  I send then duplicated the workflows (Run script in VM Guest & Run Script in Guest), modified the Sleep/Count scriptable task (set sleep time for 5 minutes), and wasn't able to get it to work.

My PowerShell script was:

Install-Windowsfeature -Name AD-Domain-Services

Import-Module ADDSDeployment

Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath "C:\Windows\NTDS" -DomainMode "Win2012" -DomainName $domain -DomainNetBIOSName $nbName -ForestMode "Win2012" -InstallDns:$true -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion:$false -SysvolPath "C:\Windows\SYSVOL" -Force:$true -safemodeadministratorpassword (convertto-securestring "14qrafzvZVAFQR!$" -asplaintext -force)

I then changed things up and created 2 scripts:

Install-Windowsfeature -Name AD-Domain-Services

&

Import-Module ADDSDeployment

Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath "C:\Windows\NTDS" -DomainMode "Win2012" -DomainName $domain -DomainNetBIOSName $nbName -ForestMode "Win2012" -InstallDns:$true -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion:$false -SysvolPath "C:\Windows\SYSVOL" -Force:$true -safemodeadministratorpassword (convertto-securestring "14qrafzvZVAFQR!$" -asplaintext -force)

I then used the default package workflows, as my duplicated ones weren't working as I suspect that I forgot to duplicate something or messed something up in the process, to run the Install-WindowsFeature script, but the workflow still looped even though the role was installed on the server.  I'm thinking I may need to set the timer to wait longer before checking the status of the install, but I can't modify the packaged WF's, and when I try to duplicate them they don't seem to work correctly.

~Jeremy

Christophe,


Got a fun one for you... Would it be possible to incorporate versioning for the scripts? The resources can obviously be versioned, and I just ran into an "issue" where I was syncing a large package between vCO instances, that included scripts, but (and this is partially my fault) the versions were the same, it didn't auto queue up the scripts... which caused other issues -- again, my bad. I think it'd be helpful to have the versions so they can be reviewed, and changes can be reverted if they cause issues, etc etc.


I haver no clue how much work that is to actually do, but it'd be a great addition to an already exceptional package.


Thanks for all of the work!


-Steve

You can manage resource versions manually in vCO but unfortunately not from the scripting. I have requested this feature to engineering but it did not get enough traction /attention.

In general I think that all the vCO client features should be able to be scripted with JS and have REST API parity. It is not yet the case even if there were a lot of progress in this direction in the last couple of years.

Regards,

Christophe.

Hi Christophe,

Thanks firstly for the effort put into this, I'm struggling still with the issue of running scripts in guest from vCO, it's an issue that appears in multiple platforms and I'm yet to find a good option that supports Bash.

Unfortunately your workflow appears to not support newline characters in a script, which makes it difficult to perform anything but the most basic tasks. Firstly when you're adding or editing a script and press "Enter" it submits the workflow (not your fault, that's a vCO GUI feature) but even when I paste text with newlines the resulting script strips them.

EDIT: Ok I've found the solution, didn't realise you could also upload files and replace values in files. This seems to work well.

Also the requirement to create and submit a custom CompositeType makes running scripts error prone, since I have to remember the exact wording around stringToReplace and replacingString. It would be easier if this were a custom object that your package imported, but I'm not sure of the technical effort required to do this.

Hi Christophe,

This is a great solution that solves a lot of headache so thank you for this! Smiley Happy

Now that being said, we are experiencing some strange problems with our RHEL guests, where they all consistently fail AFTER invoking the command when the "Copy file from guest to vCO" workflow is invoked.

Every time this fails with the error "No route to host (Workflow:Copy file from guest to vCO / Scriptable task (item1)#10)" which is really strange.. Could it be that we are missing a module from vmware tools? It does not look like an actual networking thing..

Hello,

thanks to cdecanini_ for this awesome package, it helps me solved my troubles with copying files from guest to VCO, and hope that will help me in futere as well, bcs powershell commands will be usable for our automations.

cdecanini_ thank you and all from vcoteam as well

I found a bug in the "Run Script in Guest" workflow, where if the VM say powers off the workflow gets stuck in an infinite loop. We're using this as part of a Decomission workflow so this is actually expected.

Fixed this by changing the Log error scriptable task in Execute the script (item40) to forward to Timeout ? decision (item18) instead of back to Sleep / Count

I tried the new version with the UAC fix.  It does now copy the file over to the guest OS, however it gives me an error that indicates permissions when running the sample script to set IP.  Is this supposed to be able to run powershell with admin rights?

The new version currently does not elevate.  The original version wouldn't even execute a script with UAC enabled.  I'm still researching elevation with runas option, etc.

well thanks for the continued effort,  cool project.  where was the change made that fixes the UAC issue?

In the previous version I was copying cmdAnsi.exe to the system32 folders. Daniel fixed that copying it to a temporary folder.

I thought I mentioned this to Cristophe before, but there's a (minor, and albeit unlikely to occur) logic loop problem in the Run Script In Guest workflow.... In Item 40, which is where the error handle occurs if something goes wrong in the process checking logic, it doesn't handle the condition of a the credential not being valid... Now, that may sound somewhat counterintuitive to think that you could execute a script, then not have the right credential to check the status of that particular script, but..... if the script you're running is being configured to force that particular user account (say administrator for Windows, or root for Linux) to change password on next login.... it's going to initiate a death spiral of pain. What I did was added the following line to the end:

if (errorCode.indexOf("Failed to authenticate with the guest operating system using the supplied credentials.") > -1) { throw "Failed to authenticate with the guest operating system."; }

Just something you guys might want to throw in, because I totally forgot about that until I provisioned a Linux VM, and it auto-changed the root pass... and the script just kind of started in a loop it couldn't break out of because of where it was in the process.

Thanks for all of the continued work on the package.. It's been huge in our deployment!

I'll echo what Steve said.  This package has been quite enabling for us... any chance this will become core/fully supported in the product or will it remain (barely) hidden in the shadows?

I have had the same issue with changing credentials during a puppet run, causing the script manager to get into a loop trying to get the process info back.   A pretty simple fix is to throw an error when it can't authenticate ( I can submit my fixes for this if anyone desires them ). 

You also get a very similar loop if you restart vmware tools, which I have found that during a puppet run that upgraded my vmware tools while I was waiting for puppet to return.  This is a bit harder to respond to as nothing gets returned from the process list, simple to throw an error if that condition occurs, but is there anyway to upgrade vmware tools from a script that is getting called, and preserve the process information so we don't loose our ability to detect the scripts status?

Version history
Revision #:
1 of 1
Last update:
‎01-06-2014 01:12 PM
Updated by: