CODEWITHSUNDEEP
c#powershellexchange-serverpowershell-remoting
makerofthings7
makerofthings7

Reputation: 61463

How do I create a "Remote Powershell" server object that can be called by clients?

In Microsoft Exchange, it's common for clients to call a remote server object by using the following commands 

$s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://server01/PowerShell/ -Authentication Kerberos
Import-PSSession $s

My understanding is that no software is needed on the client, and the calls are remotely executed on the server "Server01"

My question is:

  1. Assuming I have a basic powershell object created, how do I expose it in such a way that it can be called in a similar manner by a client?

  2. Is this "remoting" possible with any arbitrary powershell commandlets, or are there a set of prerequsites that must be met?

Upvotes: 0

Views: 319

Answers (3)

Keith Hill
Keith Hill

Reputation: 201652

Yes, it is available for arbitrary modules. The feature is called implicit remoting. You create a remote session with whatever modules you want loaded and then Import-PSSession although you may want to use -Prefix to distinguish between local and remote versions of the same command. Those commands can then be run from the local computer but they will target the remote computer. If the object you are creating in #1 above, is on the remote end, be aware that implicit remoting does not import remote variables (or providers).

Upvotes: 1

TheMadTechnician
TheMadTechnician

Reputation: 36297

As for prereqs it relies on WS-Management, so you've got to have your WinRM service running on both the host and remote computers. That's not uncommon, but some companies have it disabled in their environment for one reason or another (usually security), so you may want to double check it if things don't work right off the bat.

By default the user must be an administrator on the remote computer. This can be changed, and custom settings for access can be specified by an administrator on the remote computer, but you'll want to read up on that if you want to go there. http://go.microsoft.com/fwlink/?LinkID=145152 (Personally I started reading that and gave up on it since it was just between my laptop and desktop and I'm an Admin on both, but since you'll have users connecting to a server you may want to invest some time figuring it out.)

Keep in mind that anything that is loaded from a profile on the remote machine will not be executed by default for a remote session, so if you want access to commands loaded by a profile be sure to Invoke-Command the profile to load on the remote session before you Import-PSSession. (I learned that one the hard way.)

That's all true for remote PSSessions in general, not just Import-PSSession.

Also, due to the way it imports commands (it converts them to functions before importing) you have to have your execution policy set to a less restrictive Scope than Restricted or AllSigned.

Upvotes: 1

mjolinor
mjolinor

Reputation: 68273

To add to what Keith has provided, what you get are not actually cmdlets, but proxy functions. The functions you get will depend on what RBAC roles you belong to in Exchange. If you aren't a member of role group that's authorized to perform a certain function you simply don't get the proxy functions for those cmdlets. If you try to use them it will just tell you the command is not found. Also, you don't have to use the import-pssession. If you're only using a limited number of cmdlets, once you have the session established you can use Invoke-Command targeted to that session to run the Exchange cmdlets and save the overhead of doing the import which will load proxy functions for all the available cmdlets into your local session.

Upvotes: 1

Related Questions