Hi,
I am trying to execute PowerShell script to run the Adfsset.exe through VCO PowerShell plug-in workflow (“Invoke an external script”) on PowerShell host machine(Windows 2008 R2 64bit), workflow complete successfully but it wouldn’t execute AdfsSetup.exe. It start executing script without error but it throws following error when it run AdfsEtup.exe on PowerShell host
Installing with WUSA: ‘c:\...\KB981002.msu
Installation of KB981002.msu failed. Error Access Denied
The PowerShell script file exeSetup.ps1 contains following commandlets
Echo “executing AdfsSetup”
&”C:\AdfsSetup.exe” /quiet /logfile “C:\execLog.log”
If I run the same PowerShell script file though PowerShell console while logged into the PowerShell host machine, it works fine.
Is there a setting you can change to allow to be installed/execute remotely through VCO workflow?
-AnuragR
Perhaps the command you are trying to run doesn't like the security context it is running under: the service account defined for the vCenter Orchestrator Server service. You may need to change that to an appropriate account with the relevant permissions on your network.
It definetly looks like an issue with priviliges. I think it is more like a problem with Windows permissions configuration. You can check
Just to clarify that the PowerShell plugin will use the provided credentials and the scipt will be executed in the security context of the provided user.
What I would try is to invoke the script remotely (e.g using PowerShell Remoting features) because executing the script locally and executing it remotely is a bit different. Once you have this set up you should not have issues with integrating it in vCO.
Note: When you are testing make sure to use the same user used in vCO since as far as I remember there was a difference in requred priviliges if connected with domain user or local one.
Yes, I know this issue is related with privileges but how to resolve this not able to short out.
I don’t know how to pass username password in the script.
One more thing I notice when I was trying this issue. I was not able to add PowerShell host through PowerShell plug-in’s “Add PowerShell host” workflow when I was logged in the VCO client as domain user, it throws following error
Can't validate host: Invocation of script $host threw exception (Dynamic Script Module name: addPowerShellHost#15)
When I log-in into the VCO client virtual machine’s Administrator user- then I able to add PowerShell host successfully
--AnuragR
Sorry for my a bit obfuscated answer.
Unfortunately I am not sure what are the exact permisions that must be set. What I ment is that most likely it is not connected with vCO but it is more like an issue with Windows 2008 Permissions and PowerShell remoting and I suggest searching in that direction. And maybe even posting on windows forums. You have already test the script localy, but as I already mention permissions required by Microsoft Windows when invoking script's remotely are different.
To test it remotely you can try something like :
This code must be executed on a machine diferent from your PowerShell host.
>> I don’t know how to pass username password in the script.
When adding the a powershell host you have 2 choices ("Shared Session" and "Session per user").
If "Shared Session" is selected - you are prompted to provide username/password.
If "Session per user" is selected - username/password are taken from the one provided when logging in the vCO client.
Those credentials are used when “Invoke an external script” workflow is started and configured PowerShell host is selected. What this means is that the powershell script will be executed on the PowerShell host in the security context of the provided user.
>> If I run the same PowerShell script file though PowerShell console while logged into the PowerShell host machine, it works fine.
When you are testing it make sure that you are logged in with the user that you provided when configuring PowerShell host in vCO.
Even if you are able to execute the powershell script with this user localy there is still great chance that this user does not have enough priviliges to execute it remotely.
Hope I was able to help
You can also check the following link. Looks quite simmilar to your issue.