Manually I am able to execute aws - - version command using powershell and got the response
But when try to execute using invoke powershell activity getting below error
Invoke Power Shell: The term ‘aws’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Please check IsScript is enabled in the property panel .If the issue is not resolved, you will have to add the path of the aws to environment variables, then activity can access that path.
Else you will have to write a powershell script declaring the path of the aws as well.
It will open and execute the script in a PowerShell 32bit (x86). You should check separately before running it in UiPath if it will run. If not, try to install first the aws cmdlet in this PowerShell version.
As @marian.platonov rightly noted. This is the correct reason why cmdlets are not recognized by Invoke PowerShell.
Why though? - User vs System PowerShell
If you are using Windows version of UiPath Project, the PowerShell exe used by Invoke PowerShell is the one linked to your user
C:\Users\YOURUSERNAME\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell
So this forces the Robot user to also have the same module installed and since it does not have access to system level modules you installed in your robot server / vdi / vm. Your modules may be installed in C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe scope.
If you are using Windows Legacy version of UiPath Project, the PowerShell exe used by Invoke PowerShell activity is the one linked to your system.
You might have installed your module in one, but the other one does not have that module installed so the Robot / UiPath fails at the Invoke PowerShell activity.
Two weeks ago we found this out the hardway. Our AD module worked great on Windows Legacy project. We wanted to start using windows, but the documentation did not highlight that doing so has many unwanted consequences (for example Read/WriteText File, Read/Write CSV activities break, if you try to use workflows from windows legacy in your windows project)
However, I’m not sure if this will be as easy of a fix in terms of any additional modules that are installed on the machine and which might indeed not be accessible to that SDK instance of the PS.
@jeevith Does the above give you any hints and/or help here? I feel like it might actually work if you install the modules from within your script before using the module, but I also immediately see how this might not be the best experience.