Import-Module command failing

D

DLN

Hello all,

I have a powershell script that, after all the error handling is removed,
boils down to the following two lines:

Import-Module FailoverClusters
Move-ClusterVirtualMachineRole -Name $args[0] -Node $args[1]

The script is then invoked with the command:

"powershell.exe" -ImportSystemModules -ExecutionPolicy RemoteSigned
-NoLogo -NonInteractive -File ./LiveMigrate.ps1 "resource_group_name"
"node_to_migrate_to"

If I run this command using an elevated command prompt, it runs to
completion without error.

We use some third-party software in-house to remotely manage our servers.
This software installs an agent on the remote host that runs under the
"Local System" account. Through this agent, we can execute WSH, native and
(up until this point) PowerShell commands on the remote host.

This same script that executes without error when I run it through an
elevated command prompt, fails with the following error when run as the Local
System account:

Import-Module : The specified module 'FailoverClusters' was not loaded
because no valid module file was found in any module directory

I should also mention that any other PowerShell script I execute via the
agent that does not use the "Import-Module" command works without error.

I'm thinking the problem stems from running the script under the LocalSystem
account, but I've no idea as to how to get around the problem.
Unfortunately, because it's third party software, we can't modify it nor can
we change the configuration of the agent service to run under anything other
than the Local System account.

Does anybody have any ideas as to what might be the problem.

Thanks.
 

My Computer

D

DLN

After digging into this a bit more, it does seem as though that the agent is
introducing the problem. I was able to launch a command shell as NT
AUTHORITY\system and the command ran to completion. I'm at a loss to explain
what the agent could be doing to the environment, but at least I've
eliminated the user account as the potential culprit.

Regards.

"DLN" wrote:

> Hello all,
>
> I have a powershell script that, after all the error handling is removed,
> boils down to the following two lines:
>
> Import-Module FailoverClusters
> Move-ClusterVirtualMachineRole -Name $args[0] -Node $args[1]
>
> The script is then invoked with the command:
>
> "powershell.exe" -ImportSystemModules -ExecutionPolicy RemoteSigned
> -NoLogo -NonInteractive -File ./LiveMigrate.ps1 "resource_group_name"
> "node_to_migrate_to"
>
> If I run this command using an elevated command prompt, it runs to
> completion without error.
>
> We use some third-party software in-house to remotely manage our servers.
> This software installs an agent on the remote host that runs under the
> "Local System" account. Through this agent, we can execute WSH, native and
> (up until this point) PowerShell commands on the remote host.
>
> This same script that executes without error when I run it through an
> elevated command prompt, fails with the following error when run as the Local
> System account:
>
> Import-Module : The specified module 'FailoverClusters' was not loaded
> because no valid module file was found in any module directory
>
> I should also mention that any other PowerShell script I execute via the
> agent that does not use the "Import-Module" command works without error.
>
> I'm thinking the problem stems from running the script under the LocalSystem
> account, but I've no idea as to how to get around the problem.
> Unfortunately, because it's third party software, we can't modify it nor can
> we change the configuration of the agent service to run under anything other
> than the Local System account.
>
> Does anybody have any ideas as to what might be the problem.
>
> Thanks.
 

My Computer

B

Bob Landau

DLN,

Powershell will at least "load" under the LocalSystem account but I would
think really really really hard (thats not a typo) prior to doing this. I did
check a few cmdlets and they do work as expected but I don't think this is a
good idea.

1) While Powershell is "secure by default" to run a script you'll need at
least "AllSigned" since LocalSystem account has access to everything on that
specific machine.

2) LocalSystem has no access to the network

3) LocalSystem has no entry under HKey_Users which defines many attributes
for the logged on users.

This latter I believe is what is causing Import-Module to fail the default
$ModulePath variable doesn't exist so you will need to give a complete path
to get this to load.

I have no idea if there are other problems

bob

"DLN" wrote:

> After digging into this a bit more, it does seem as though that the agent is
> introducing the problem. I was able to launch a command shell as NT
> AUTHORITY\system and the command ran to completion. I'm at a loss to explain
> what the agent could be doing to the environment, but at least I've
> eliminated the user account as the potential culprit.
>
> Regards.
>
> "DLN" wrote:
>

> > Hello all,
> >
> > I have a powershell script that, after all the error handling is removed,
> > boils down to the following two lines:
> >
> > Import-Module FailoverClusters
> > Move-ClusterVirtualMachineRole -Name $args[0] -Node $args[1]
> >
> > The script is then invoked with the command:
> >
> > "powershell.exe" -ImportSystemModules -ExecutionPolicy RemoteSigned
> > -NoLogo -NonInteractive -File ./LiveMigrate.ps1 "resource_group_name"
> > "node_to_migrate_to"
> >
> > If I run this command using an elevated command prompt, it runs to
> > completion without error.
> >
> > We use some third-party software in-house to remotely manage our servers.
> > This software installs an agent on the remote host that runs under the
> > "Local System" account. Through this agent, we can execute WSH, native and
> > (up until this point) PowerShell commands on the remote host.
> >
> > This same script that executes without error when I run it through an
> > elevated command prompt, fails with the following error when run as the Local
> > System account:
> >
> > Import-Module : The specified module 'FailoverClusters' was not loaded
> > because no valid module file was found in any module directory
> >
> > I should also mention that any other PowerShell script I execute via the
> > agent that does not use the "Import-Module" command works without error.
> >
> > I'm thinking the problem stems from running the script under the LocalSystem
> > account, but I've no idea as to how to get around the problem.
> > Unfortunately, because it's third party software, we can't modify it nor can
> > we change the configuration of the agent service to run under anything other
> > than the Local System account.
> >
> > Does anybody have any ideas as to what might be the problem.
> >
> > Thanks.
 

My Computer

sticky27

New Member
I'm battling the same problem. Did you find an answer to this issue?

In my scenario, I'm trying to run a powershell script as a service. One of the things the script does (like yours) is to import a module - which in my case, is a custom one I've created. The script is reporting the same error - ie:

"The specified module 'Custom' was not loaded because no valid module file was found in any module directory."

I don't believe this is related to the account the service is running under either, as it made no difference when I changed the service account to the local admin or domain admin accounts.

I did however, find something interesting. It seems that my custom module (and others) are not actually available to be loaded in the context of the service.

I determined this by getting the service to open a PowerShell shell by:

- Setting the service application to 'powershell.exe'
- Setting the service to run under the local system
- Enabling the option 'interact with desktop'

So when the service is started, a PowerShell shell appears which is running in the context of the service under the local system account.

What I found here is when I manually tried to import the module, it told me I couldn't find it.

My module (and others) is not listed as available:

Code:
PS C:\Windows\system32> Get-Module -ListAvailable
 
ModuleType Name                      ExportedCommands                          
---------- ----                      ----------------                          
Manifest   BitsTransfer              {}                                        
Manifest   PSDiagnostics             {}                                        
Manifest   TroubleshootingPack       {}                                        
Manifest   WebAdministration         {}
When normally I'd see this:

Code:
ModuleType Name                      ExportedCommands
---------- ----                      ----------------
Manifest   ActiveDirectory           {}
Manifest   AppLocker                 {}
Manifest   BitsTransfer              {}
Manifest   Custom                    {}
Manifest   GroupPolicy               {}
Manifest   NetworkLoadBalancingCl... {}
Manifest   PSDiagnostics             {}
Manifest   TroubleshootingPack       {}
Manifest   WebAdministration         {}
The modules paths are defined as follows:

Code:
PS C:\Windows\system32> (Get-ChildItem Env:\PSModulePath).Value
WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
This is where it got interesting. If I do a dir of the modules directory, I only see the folders for the modules listed by the Get-Module cmd:

Code:
PS C:\Windows\system32\WindowsPowerShell\v1.0\Modules> dir
 
    Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules
 
Mode                LastWriteTime     Length Name                              
----                -------------     ------ ----                              
d---s       14/07/2009  5:37 p.m.            BitsTransfer                      
d----       14/07/2009  5:32 p.m.            PSDiagnostics                     
d----       14/07/2009  5:37 p.m.            TroubleshootingPack               
d----      22/01/2010  11:48 a.m.            WebAdministration
Whereas If I do a dir in a normal session, I see all the module folders, as I'd expect:

Code:
    Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules
 
Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d---s       17/08/2009  2:01 p.m.            ActiveDirectory
d---s       14/07/2009  7:23 p.m.            AppLocker
d---s       14/07/2009  5:37 p.m.            BitsTransfer
d----      14/05/2010  11:58 a.m.            GoNAS
d----       17/08/2009  2:01 p.m.            GroupPolicy
d----       17/08/2009  2:01 p.m.            NetworkLoadBalancingClusters
d----       14/07/2009  5:32 p.m.            PSDiagnostics
d----       14/07/2009  5:37 p.m.            TroubleshootingPack
d----      22/01/2010  11:48 a.m.            WebAdministration
So there must be a difference with the folders that are excluded, such as security settings. However so far I haven't figured out what - the ACLs appear identical (even wrote a script to check). If you've already figured it out, please share!

Will post back here if I make any progress :).

Michael
 

My Computer

T

Thomas Lee

In message <[email protected]>, sticky27
<[email protected]> writes

>
>I'm battling the same problem. Did you find an answer to this issue?
one thing you might try is to import the module and provide the full
path. Like This:


PSH [C:\foo]: import-module
C:\Users\tfl\Documents\WindowsPowerShell\Modules\module1
PSH [C:\foo]: import-module C:\foo\module2

It looks like your service is not seeing the normal module folders - but
Import-Module will take a full path. It might be worth trying.

HTH

Thomas
--
Thomas Lee
[email protected]
 

My Computer

sticky27

New Member
Thanks for the suggestion Thomas - if I move the module folder somewhere else, I am indeed able to load it!

It seems this is a Windows 7 (and probably Win 2008 R2) thing. I also tried copying my module to a Win 2003 Svr and had no problems loading the module from the standard module directory there. Which is great as I'm going to be running the service from a Windows 2003 machine anyway!

I did find though that while the module folder permissions under C:\Windows\system32\WindowsPowerShell\v1.0\Modules were identical, the files themselves had different permissions.

For the modules that loaded OK, the files were owned by the 'TrustedInstaller' user, which it turns out isn't actually a user, but represents the service itself.

I was able to change the ownership of my modules to 'NT SERVICE\TrustedInstaller', but this made no difference. I also tried changing the ownership to that of my custom service, which also made no difference.

I'm not pursuing this any further on my Windows 7 machine, but hopefully this info is of use to someone else that comes across the same problem.
 

My Computer

Top