Author Posts

March 21, 2018 at 7:39 pm

We recently had a strange anomaly occur on 2 VMs out of several hundred. The symptoms are very strange but we are unable to run PowerShell out of:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
When opening a window you get:
AuthorizationManager check failed
No modules or components of a profile load
Once you get a prompt the most basic commands do not exist example:
Get-ChildItem, set-location ect. The aliases to these command exists

If I launch PowerShell with
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
We can get a prompt and core registered commands Get-ChildItem, set-location ect.
We have no desire to attempt to run the SysWOW64 but want to fix the issues that's causing this to occur.
Running in the SysWOW64 mode we are unable to load a module in the System32 folder and noticed in the SysWOW64 mode if we set-location to the System32…Modules ect that you are actually in the SysWOW64 folders.

We have also looked at the environment variables ect and are having a difficult time with this one and we are about to open a ticket with Microsoft on this.

Any ideas or comments are appreciated and I will post back our results.
thank you!!!

March 22, 2018 at 9:06 am

Hi Chris,

I am not sure if this is the same error you are having but this link may help

http://tgnp.me/2011/09/powershell-authorizationmanager-check-failed-resolution/

March 22, 2018 at 10:05 am

Not a solution to the underlying issue.
But to get to the "real" System32 and not SysWOW64 from a 32bit shell you can use:

$env:SystemRoot\sysnative\

Also, if it's not really necessary it's not best practice to put custom modules under System32.
If that is what you're trying to reach.

March 26, 2018 at 9:49 pm

I have resolved this issue, another admin built a module for patching of SharePoint systems and ran a rouge Robocopy command to push the module and the modules folder was missing modules lettered A – M. Copying the modules letters A – M from a working machine and was able to run the Shell and expected.
So we are going move our custom modules from
C:\Windows\system32\WindowsPowerShell\v1.0\Modules
To:
C:\Program Files\WindowsPowerShell\Modules

I have had a script for multiple years that I robo copied master modules to the system32 folders I realize it's a better place to have them under “Program Files”.
But we have a global profile that loads 6 – 8 modules and creates 20 or so arrays with multiple if statement ect. This is stored in the System32 folder so is that normal practice if you have an enterprise profile that you want all user to have load when they pull up a shell.

AllUsersAllHosts
C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1

March 27, 2018 at 11:36 am

I also mentioned a second server that experienced the same symptoms but it's root cause was the registry value for $env:PSModulePath was truncated and didn't include the system 32 path. The only path that existed there was the “AppFabric 1.1 for Windows Server” which is prerequisite to some SharePoint components and I am wondering if an upgrade to these component removed values from the $env:PSModulePath
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
Example:
(Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Session Manager\Environment" -Name PSModulePath).PSModulePath.split(";")