Forum Discussion
PowerShell implicit remoting without connection to server
My problem was that I didn't understand that PowerShell uses the Compatibility feature and thus implicit remoting for all modules where the variable CompatiblePSEditions is either missing in the module's manifest, or the word Core is not explicitly stated in the variable (for example: CompatiblePSEditions = @('Desktop', 'Core').
What I still don't know is why modules in %SYSTEMROOT%\system32\WindowsPowerShell\v1.0\Modules that are for Desktop only aren't listed with Get-Module; maybe it's a combination of a) the fact that the module is not for Core, and b) the file DACL (TrustedInstaller is the owner of the files and folders). When I copy such modules to the CurrentUser scope folder ($HOME\Documents\PowerShell\Modules), then new files and folders have a different owner than TrustedInstaller (and, I didn't verify this, even the DACL may have changed a bit), and Get_Module successfully lists them even though the manifest files didn't change.
Implicit remoting is a broad PowerShell topic that spans more than this one scenario relating to compatibility.
You're nearly correct in your first paragraph, however, implicit remoting is not applied to "all modules", only those located under %windir%\system32\WindowsPowerShell\v1.0\Modules, as described in the documentation:
As a demonstration that this is indeed the case, here's the output from a few commands in PowerShell (not Windows PowerShell) that I'll refer back to:
Note: I've had to use the All parameter in the Get-Module to override the default PowerShell behaviour of excluding incompatible modules (which even includes libraries) from the list. Both PowerShell and Windows PowerShell use this behaviour of filtering out the things they feel don't matter, but it's not due to permissions as you've suggested above.
The first Get-Module command lists modules that have a manifest where only Desktop has been specified. Unsurprisingly, nearly all of them live in the WindowsPowerShell directory meaning they'd be automatically subjected to the compatibility-driven implicit remoting documented above.
Focusing on the single module - PackageManagement - that exists outside of the WindowsPowerShell directory, the next command tells us we have three different versions installed on the local machine. As the Desktop-only version is old, we have to load it using the RequiredVersion parameter to specify the version we want.
The result of this loading is that the desktop-only PackageManagement module has been directly loaded into PowerShell, i.e. implicit remoting has not been used. The reason it has not been used is simply because the module does not exist in the WindowsPowerShell directory - there's no other reason. This is in line with the documentation above.
Even though the module has loaded successfully, when we try to use the Find-Package commandlet, we receive an error from PowerShell due to the incompatibility of the module.
Here's a new screenshot showing how implicit remoting is triggered manually, which is required for modules that do not support PowerShell (aka the "Core" value featuring in the manifest):
The first command is simply showing we have the desktop-only version of PackageManagement loaded, while the second command unloads it.
The third command re-imports the PackageManagement module, but this time using the UseWindowsPowerShell parameter, which instructs PowerShell to create the implicit remoting session. This is precisely the same action as PowerShell takes automatically for the modules living inside the WindowsPowerShell directory.
We can now successfully run the earlier Find-Package commandlet since PowerShell is actually calling Windows PowerShell in the background.
The final command shows the presence of the behind-the-scenes remoting session that acts as the broker between PowerShell and Windows PowerShell, which simply confirms that the documented implicit remoting is being leveraged.
As I opened with, implicit remoting is a broader topic where it's commonly seen when using commandlets such as Import-PSSession to work with remote hosts. These session management commandlets can also feature in the Windows PowerShell and PowerShell configuration files so that remote sessions are created whenever you open a new PowerShell session (not something I'd recommend, but I've seen others do it), which is worth being aware of when you're diagnosing remoting more broadly.
In summary, Get-Module only lists what it considers relevant by default - to make our lives easier, but you can force it to list everything using the All parameter.
Implicit remoting is not automatically used for all modules, only those that reside under %windir%\system32\WindowsPowerShell\v1.0\Modules. It has nothing to do with file system permissions.
Cheers,
Lain
