cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

AWS EC2 Connection failing in Powershell with other users

Have configured AWS EC2 connector in our production environment, when I execute it with my own AD account (login to server with my own account), import/reconciliation process completes without any issue, whereas when I schedule it with process account, it fails, what may be the reasons to fail with same process with other AD account?

When executes with process account, getting below error -

Import failed. Error: The term 'Set-AWSProxy' 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.

Looks like issue is with Powershell, our process account don't have interactive login privileges so we can't install Powershell by login with process account . I was install "AWS Powershell for Windows" by login on the server with my own account.

Can someone please help me to fix this issue.

Best regards,

Sandeep

(3) Replies
ChrisG
By Community Manager Community Manager
Community Manager

Is it possible that you installed the AWS PowerShell module only for your own account rather than all users? I expect you will want to install the module for all users so the connector can be executed as any user.

If the module was installed for your account, I expect you will see the module files under a directory like C:\Users\<YourUser>\Documents\WindowsPowerShell\Modules. If it is installed for all users, the most likely places you will see the module files would be under C:\Program Files\WindowsPowerShell\Modules or C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules.

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)

Thanks for update.

I was install AWS Power shell module by login using my own account on the server, I am really unknown how it can be installed for other accounts. By looking directory structure that you suggested, it's installed for all users.

1. For my Own account, below is the directory, couldn't see Modules directory under C:\Users\s310266\Documents\WindowsPowerShell,

C:\Users\s310266\Documents\WindowsPowerShell>dir
Volume in drive C is OS Drive
Volume Serial Number is 1464-AC4F

Directory of C:\Users\s310266\Documents\WindowsPowerShell

09/01/2020 04:51 PM <DIR> .
09/01/2020 04:51 PM <DIR> ..
09/01/2020 04:51 PM <DIR> Scripts
0 File(s) 0 bytes
3 Dir(s) 34,627,289,088 bytes free

2. For all users, I could see Modules folder in "C:\Windows\System32\WindowsPowerShell\v1.0"

C:\Windows\System32\WindowsPowerShell\v1.0\Modules>dir
Volume in drive C is OS Drive
Volume Serial Number is 1464-AC4F

Directory of C:\Windows\System32\WindowsPowerShell\v1.0\Modules

11/21/2014 07:27 PM <DIR> Appx
11/21/2014 07:27 PM <DIR> BestPractices
02/13/2017 03:02 AM <DIR> ClusterAwareUpdating
02/13/2017 03:02 AM <DIR> DFSN
02/13/2017 03:02 AM <DIR> DFSR
08/22/2013 10:39 AM <DIR> DirectAccessClientComponents
11/16/2019 07:33 PM <DIR> Dism
08/22/2013 10:39 AM <DIR> DnsClient
02/13/2017 03:42 AM <DIR> FailoverClusters
02/13/2017 03:02 AM <DIR> GroupPolicy
08/22/2013 10:39 AM <DIR> iSCSI
08/22/2013 10:46 AM <DIR> IscsiTarget
11/21/2014 07:27 PM <DIR> MsDtc
11/16/2019 07:44 PM <DIR> MSMQ
08/22/2013 10:39 AM <DIR> NetAdapter
08/22/2013 10:39 AM <DIR> NetConnection
08/22/2013 10:39 AM <DIR> NetEventPacketCapture
08/22/2013 10:39 AM <DIR> NetLbfo
08/22/2013 10:39 AM <DIR> NetNat
08/22/2013 10:39 AM <DIR> NetQos
11/22/2014 12:06 AM <DIR> NetSecurity
08/22/2013 10:39 AM <DIR> NetSwitchTeam
08/03/2016 07:33 PM <DIR> NetTCPIP
08/22/2013 10:39 AM <DIR> NetworkConnectivityStatus
02/13/2017 03:02 AM <DIR> NetworkLoadBalancingClusters
04/21/2018 06:35 PM <DIR> NetworkSwitchManager
08/22/2013 10:39 AM <DIR> NetworkTransition
08/22/2013 10:39 AM <DIR> NFS
08/22/2013 10:39 AM <DIR> PcsvDevice
08/22/2013 10:39 AM <DIR> PrintManagement
04/21/2018 06:35 PM <DIR> PSDiagnostics
11/21/2014 07:27 PM <DIR> RemoteDesktop
08/22/2013 10:39 AM <DIR> ScheduledTasks
11/21/2014 07:27 PM <DIR> ServerManager
08/22/2013 10:39 AM <DIR> SmbWitness
08/22/2013 10:39 AM <DIR> StartScreen
04/23/2017 02:23 AM <DIR> Storage
11/21/2014 07:27 PM <DIR> TroubleshootingPack
08/22/2013 10:39 AM <DIR> UserAccessLogging
11/21/2014 07:27 PM <DIR> VpnClient
08/22/2013 10:39 AM <DIR> Wdac
04/08/2017 03:45 PM <DIR> WebAdministration
08/22/2013 10:39 AM <DIR> WindowsDeveloperLicense
08/22/2013 10:39 AM <DIR> WindowsErrorReporting
11/21/2014 07:27 PM <DIR> WindowsSearch
0 File(s) 0 bytes
45 Dir(s) 34,670,501,888 bytes free

 

Looks like AWS module is install for all users (by looking directory structure) so connector execution should be completed with the process account but not sure why it's failing and getting error -

Import failed. Error: The term 'Set-AWSProxy' 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 help.

Best regards,

Sandeep

@SandeepKolhe - I'm not sure what you've seen that suggests the AWS Tools for PowerShell is installed for all users. That isn't apparent from the directory listings you've shown.

Guidance for installing AWS Tools for PowerShell is available in AWS documentation here: Installing the AWS Tools for PowerShell on Windows

As long as your server has an Internet connection, the easiest way to install this module (and explicitly specify it should get installed for all users) will normally be to execute the following command:

Install-Module -Name AWSPowerShell -Scope AllUsers

 If your server does not have an Internet connection you can download the appropriate .zip file and install the module manually as described in the AWS documentation.

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)