Powershell calls are failing

Products

• CA Process Automation Base

Issue/Introduction

Powershell calls in ITPAM server/agents are failing for some users that are used as the installer account.

Environment

Release : 4.3

Component : ITPAM - Process Automation

Resolution

Based on further testing, tracing and research, the issue appears to be related to a GPO having to do with Folder Redirection, specifically on MyDocuments, and its reference to a network share.
 
Fundamentally, when Powershell runs a command that it doesn’t already know about, it will attempt to hunt that command down, first at the Windows level via the PATH variable, then at the modules level via PSMODULEPATH.  

It was found that for certain users, Powershell was only going as far as PATH.  It never tried to traverse PSMODULEPATH even though it was defined at the system level ->  PSMODULEPATH = C:\Program Files\WindowsPowerShell\Modules;C:\windows\system32\WindowsPowerShell\v1.0\Modules
 
There’s a slight algorithm behind how PSMODULEPATH gets defined and, based on certain criteria, whether or not the path to MyDocuments gets prepended to PSMODULEPATH, which is what was happening in our case.
 
This problem isn’t specifically tied to the fact that a user is able to reference the network share itself since they are able to interactively log on to any given server and use Powershell cmdlets without any issues whatsoever, but there does appear to be some sort of security restriction when running commands under a remote connection while attempting to reference the remote share under normal cmdlet discovery.  
 
The primary fix would be to exclude this GPO Folder Redirection for those accounts that use Orchestration.  This way, instead of Mydocuments pointing to a network share, which acts as a central destination of sorts across servers for that user, it will instead default to the local C:\users\.. folder.
A secondary mitigation would be to manipulate PSMODULEPATH at a user scope level to prevent MyDocuments from becoming part of the path altogether.  Doing something like this for example would prevent the algorithm from prepending MyDocuments:
[Environment]::SetEnvironmentVariable('PSModulePath', 'C:\Program Files\WindowsPowerShell\Modules;C:\windows\system32\WindowsPowerShell\v1.0\Modules', 'User')
 
We can conclude that there must be some sort of security restriction within Windows that prevents this.
 
Also, the problem was occurring when the user would first log on to the target server interactively and then attempt to run a remote Orchestration process under that same account.  
 
The reason for the failure was because the user was logged in, with an HKU hive that had MyDocuments defined pointing to the network share.  
When the user is not logged however, and an HKU hive does not already exist for that user, Windows will create a hive for that user based on the Default User account instead, which will not have a network share MyDocuments reference, which is why it would work.