What is implicit remoting in PowerShell — for example Import-PSSession or Import-Module -PSSession — and what actually runs locally versus on the remote machine?
answer
- local names, remote execution
- generated proxy functions
- every call is a round trip
- -Prefix avoids shadowing
basics
~20 sImplicit remoting imports a remote session's commands into your local session as proxy functions. The names, parameters and tab completion are local; the actual execution happens in the remote runspace, and results come back deserialized like any other remoting output.
solid answer
~50 sWith `Import-PSSession -Session $s -Module ActiveDirectory` (or `Import-Module -PSSession $s -Name ActiveDirectory`), PowerShell inspects the module's commands on the remote host and generates a temporary local module of *proxy functions* with matching names and parameter sets. Calling `Get-ADUser` then looks entirely local — tab completion and parameter validation work — but the proxy forwards the invocation over the session and the real cmdlet runs remotely, returning deserialized objects. The value is that you do not need the module, its dependencies, or its management tools installed locally. The costs are that everything is a round trip, the returned objects are property bags rather than live types, and the whole thing dies with the session. Use `-Prefix` to avoid colliding with a locally installed version of the same command, and `Export-PSSession` if you want the generated proxy module written to disk for reuse.
go deeper
Know that PowerShell can make a remote machine's commands appear in your session as if they were local, and that they still execute on the remote host.
Explain the mechanism: metadata is read from the session and local proxy functions are generated, so binding and completion are local while execution and output serialization are remote. Know -Prefix and Export-PSSession.
Bring the operational judgment: use it to avoid installing management tooling locally, but move loops across the boundary instead of making thousands of proxy calls, and never let deserialized output reach code that expects live types.
Decide when hiding a network boundary is acceptable at all. Convenience that makes latency and failure invisible is a liability in shared automation; prefer explicit sessions and exported, version-pinned proxy modules over ad-hoc imports that drift from the remote module.
## The idea Normally remoting is explicit: you write `Invoke-Command`, you write a script block, and it is obvious which code runs where. Implicit remoting hides that boundary on purpose. You import a remote module's commands into your local session and then call them as if they were installed locally. ```powershell $s = New-PSSession -ComputerName dc01 Import-Module -PSSession $s -Name ActiveDirectory -Prefix Rem Get-RemADUser -Filter * | Select-Object Name, Enabled Remove-PSSession $s ``` No `ActiveDirectory` module is installed on your machine, yet `Get-RemADUser` tab-completes and validates its parameters like a real command. ## What is actually created PowerShell queries the remote session for the module's exported commands and their metadata — parameter names, types, parameter sets, value-from-pipeline bindings — and generates a **temporary module of proxy functions** in your session. Each proxy has the same signature as the remote command and a body that forwards the call over the session. So the split is: - **Local:** the command name, parameter binding and validation, tab completion, the pipeline plumbing on your side. - **Remote:** the actual cmdlet execution, and everything it touches. - **Across the wire:** your bound arguments going out, serialized objects coming back. That last point is the one people forget. Implicit remoting is remoting, so the results are deserialized property bags with the `Deserialized.` type prefix and no live methods, exactly as with `Invoke-Command`. ## Why you would use it - **You do not have to install the management tools locally.** Administering a service whose module only exists on a particular server, or whose RSAT-style tooling you do not want on a workstation, becomes a session away. - **It reads naturally.** Long pipelines built from remote commands are far more comfortable than nesting everything inside script blocks with `$using:` peppered through them. - **Discovery works.** `Get-Command -Module <name>` and tab completion behave normally because the proxies really are local functions. ## Why you would not - **Every call is a round trip.** A loop calling a proxy a thousand times is a thousand remote invocations; the same loop inside one `Invoke-Command` script block is one. When performance matters, send the loop, not the calls. - **Deserialized output.** Piping one proxy's output into another proxy works because the arguments are re-serialized on the way back out, but any local code expecting live .NET types will be disappointed. - **Lifetime is tied to the session.** Close or lose the session and the proxies stop working; they are not a durable install. - **Name collisions.** If you also have the module locally, importing without `-Prefix` shadows the local commands, and later confusion about which one ran is entirely self-inflicted. `-Prefix Rem` turning `Get-ADUser` into `Get-RemADUser` makes the boundary visible at every call site. ## Export-PSSession `Export-PSSession -Session $s -Module ActiveDirectory -OutputModule RemoteAD` writes the generated proxy module to disk. Importing that module later recreates the proxies and opens a session to the original endpoint on demand — useful when the same remote endpoint is used routinely, though it inherits every caveat above and adds a stale-metadata risk if the remote module changes. ## The interview framing This is a differentiator question rather than a screener. What it checks is whether you understand that a comfortable local-looking command can still be a network call with a serialization boundary behind it — and that the convenience is bought with round trips and inert objects. A candidate who says 'it copies the module locally' has the mechanism backwards, and that misunderstanding leads directly to writing loops that make thousands of remote calls.
- Does implicit remoting copy the remote module onto the local machine?No. It reads the remote commands' metadata and generates local proxy functions with matching signatures; the module's actual code, dependencies and data never leave the remote host. That is the point — you get the command surface without installing the tooling. It also means the proxies stop working the moment the underlying session goes away.
- Why can a loop that calls an implicitly remoted command a thousand times be so slow?Each proxy invocation is a separate remote call with its own round trip and serialization of arguments and results. A thousand calls means a thousand trips. The fix is to move the loop across the boundary — put it inside a single `Invoke-Command` script block — so one trip does all the work and only the final results come back.
- What does the -Prefix parameter do and why does it matter?It inserts a string after the verb in every imported command name, turning `Get-ADUser` into `Get-RemADUser`. That prevents the proxies from shadowing a locally installed module of the same name and, just as usefully, makes it visible at the call site that this command executes on another machine rather than here.
- What kind of objects do implicitly remoted commands return?The same deserialized copies any remoting call produces: property bags whose type names carry the `Deserialized.` prefix, with values captured at serialization time and no live instance methods. Piping between two proxies from the same session works, but local code that expects the real .NET type — or calls methods on it — will fail.
saying these in an interview costs you the question
- Says the remote module is downloaded and installed locally
- Thinks the imported commands run on the local machine
- Assumes returned objects are live .NET types
- Ignores that each proxy call is a separate round trip
- Imports without a prefix over an existing local module