Hi team,
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.
You may try these approaches:
In the ps1 script, add the full path of the aws.exe, not only the aws
Try the same process in a Windows-Legacy and in a Windows
Let us know if this helped.
Hello @Naveen.Ch
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.
Thanks
Yes , it’s enabled even though getting error
If you are having any steps to follow please let us know
Thank you for the response
After installing AWS tool and powershell paths able to execute commands
But when we tried to execute aws ssm start-session --target”sessionid” , the uipath is keep on executing and not given any response
Is there any specific powershell script we have to use to start the AWS session manager instead of AWS start command
Try the same process and see the behaviors in a Windows-Legacy and in a Windows. Maybe it will work.
Also, try to provide the full path of the aws when you are executing the script.
Example:
C:\Folder\Subfolder.…\aws.exe ssm start-session --target ”sessionid”
I have tried same but getting different error
Check first the script outside of UiPath and then run it in UiPath. It seems that you tried two times to run aws.
It may be that when you are specifying the full path of the exe file to put in “aws.exe”.
Outside uipath able to start the session
Able to execute AWS —version command and getting the response when tried to start the session facing issue
If you are having 5 minutes of time then. We can connect and resolve this issues
Awaiting for your response
Can you please take a look at this example and try to adapt it for your case?
PowershellExample.zip (26.1 KB)
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.
Let us know if this helped.
Hi @Naveen.Ch and @marian.platonov,
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.
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
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)
Thank you for the details
I have executed your workflow using uipath and able to execute successfully without any issues, below is the response based on your code
And I am able to see windows powershell (x86) as well
The below script when I have used to run through uipath to start the session , uipath keep on running without throwing any error
@jeevith thank you for the response
Yes I am using windows legacy type
The point is not if you see or not see. Access windows powershell (x86) separately and run the same script inside it. It is working?
Also, add to your script in the last line a | Out-File -FilePath C:\TestDir\AliasNames.txt.
Thank you
I am able to execute the script using uipath in the text file, I am able to see the result like below session started
But if you see in below screen shot , the uipath continuously running and not completed the execution even though the specific command executed and written in the text file
And powershell also not completing the session , continuously loading
And I want to execute other commands as well once the session started
Are you sure that for Windows-Legacy the path for the powershell.exe is correct?
I found that actually, these are the paths based on the bit version type.
Example for Windows10:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe → 64-bit
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe → 32-bit
I think so. Here is how we tested the difference.
Do the above in Windows UiPath project
5. Inspectt the popup PowerShell will be in from the user scope and not the system scope. (may be set a delay i nyour PS script to let you see the window name)
Alternatively, publish the project to Orchestrator and run the two automations from UiPath Assistant.
This showed us that our AD module was available in Windows-Legacy but not the Windows version of the project.
Maybe I am digging this topic out a bit, but please refer to this post:
My current assumption is that Windows projects use the PowerShell from this dependency that comes with the System package:
This was kind of confirmed by a quick test of printing the PS version from the PS window and from Studio → the one from Studio returns PS 7.1.
I was already able to work around the issue with script execution policies getting in the way by adapting the execution policy at the start of my scripts and changing it for the current process.
Otherwise, the machine policies did not affect the PS instance run by the robot, as you can see here:
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.
