One of the great things about PowerShell is the ease with which you can perform actions on remote machines, not only by acting upon the machine as a remote target but also by openning a remote PowerShell session on the machine. This is done using the built-in Enter-PSSession cmdlet. This is an excellent and powerful capability for ConfigMgr admins who want to avoid having to RDP in to the server.
However, there is a catch when it comes to the Configuration Manager PowerShell module that comes with ConfigMgr 2012 SP1. The module only supports 32-bit PowerShell, so you must launch the Windows PowerShell (x86) interface to load the modules. The easy mistake to make is launching the 32-bit PowerShell, openning the remote session to the ConfigMgr server, and attempting to load the module…only to be presented with an error:
“PowerShell is not supported in 64-bit version. Run PowerShell in x86 version and import the module again.“
So if we launched 32-bit PowerShell, why are we getting an error saying the module won’t load in 64-bit PowerShell? The reason is that although we launched 32-bit PowerShell locally the remote PowerShell session we launched on the server will default to the native architecture…64-bit. The solution is to specify the architecture using the -ConfigurationName parameter:
Enter-PSSession -ComputerName <sccmserver> -ConfigurationName Microsoft.PowerShell32
Now we have full access to the Configuration Manager PowerShell cmdlets remotely without having to try and load them on our local machine!
Update: If you are looking to leverage that remote PowerShell session to connect to another remote server from that session, David O’Brien has a great post on leveraging CredSSP to ensure credentials are passed through properly.