Invoke powershell unable to recognized aws keyword

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.

1 Like

You may try these approaches:

  • In the System → Path variable, add the location of the aws.exe path folder


  • 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.

1 Like

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.


1 Like


Yes , it’s enabled even though getting error

If you are having any steps to follow please let us know

Hi @marian.platonov

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.


C:\Folder\Subfolder.…\aws.exe ssm start-session --target ”sessionid”

1 Like


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”.

1 Like


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? (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.

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)

1 Like


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.

1 Like


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

Hi @marian.platonov

I think so. Here is how we tested the difference.

  1. Open your windows legacy project in UiPath.
  2. Create an Invoke PowerShell activity
  3. Now navigate to your UiRobot.exe
  4. Use the UiRobot.exe to run your .xaml file (How to : Arguments Description (
  5. Inspect the popup PowerShell is a system level PowerShell and not the user specific PowerShell (may be set a delay i nyour PS script to let you see the window name)

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.

1 Like

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.