The credentials are protected with the SSL stream so there are no security issues.įor examples on connecting to local and remote Exchange forests please review this post.Summary: Learn how to remotely use the Exchange 2010 Windows PowerShell cmdlets in this article written by two authors and Exchange experts. In such cases the connection must be HTTPS and basic authentication is used. When we connect between different forests Kerberos authentication is not available, for example from on-premises to Office 365. Administrators normally discover this when cascading settings down from the root of the web site. If you try and force the PowerShell virtual directory to enforce SSL then you will not be able to connect.
EXCHANGE 2010 MANAGEMENT TOOLS WINDOWS 10 CODE
If you look closely at the PowerShell remoting code included at the top of this post you will see that the authentication type is indeed Kerberos. One common question that arises, is why is TCP 80 used? Does this not mean that the traffic is not secure since that is the HTTP port rather than the HTTPS port? Yes this is the well known HTTP port, but the traffic is protected using the Kerberos authentication of the person connecting. An exception is the Exchange 2010 Edge role, where PowerShell remoting is not used to minimise the attack surface since the Exchange remoting endpoint requires IIS. Since Exchange 20 use remote PowerShell, this means that even if you open up the Exchange Management Shell (EMS) on an Exchange server you are in effect connecting to PowerShell remotely.
To see the WinRM port you could use something like this: Exchange remoting uses TCP 80, and Windows remoting uses 5985 TCP. You will need to manually enable Windows remoting. Windows remoting is not enabled by default. It is worth pointing out that while you may be able to use Exchange remoting, it is separate from Windows remoting. Exchange leverages IIS for its remoting capabilities. As far as base PowerShell is concerned, the remoting endpoint can be hosted in either the WinRM service or IIS. Once we have completed our work, the PowerSession should be removed to clean it up.Įxchange 2010 requires PowerShell version 2.0 and Windows Remote Management 2.0 (WinRM) at a minimum as that was the first version of PowerShell to support remoting. With each of the above examples, the commands can be executed one line at a time, or saved into a PowerShell. $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Authentication Kerberos (Please note they are three separate lines which may wrap) Using Logged On Credentials On Domain Joined MachineĪn example of leveraging logged on credentials could look like this: $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Authentication Kerberos -Credential $UserCredential Prompting For Authentication On Domain Joined Machine Sample code would look like the below examples. Finally the PowerShell session is imported. They are then presented as part of the configuration of the PowerShell $Session. In the below examples we provide credentials and store them in the $UserCredentials variable. Typically this means that we will use the following process to connect to an on-premises Exchange 2010 or 2013 server. Connecting Using Remote PowerShellĪs noted above, TechNet only documents that PowerShell remoting should be used. Loading the .SnapIn Windows PowerShell snap-in and running cmdlets other than the *-TransportAgent cmdlets is not supported and may result in irreparable damage to your Exchange deployment. One example of an exception to this rule is in the Exchange 2013 release notes. Unless you are following a specific process that is documented by Microsoft or are working with a Microsoft support representative, the only way you should be connecting to Exchange is the method documented above. How should we connect to Exchange PowerShell? Use PowerShell Remoting! The same is also true for Exchange Online (EXO). If we look at the Exchange 2010 or Exchange 2013 documentation for connecting to Exchange PowerShell there is no mention of directly loading up the PowerShell SnapIn. An example of what we should notbe doing for Exchange 20 is something like:Īdd-PSsnapin .E2010 However there still seems to be a trend notto use PowerShell remoting and directly load up the Exchange 2010 or 2013 snapin. At this time we should all be using remote PowerShell for Exchange 20 servers.
Exchange 2010 introduced mail admins to remote PowerShell. The case in point here, is how access is provided to Exchange 2010/2013 PowerShell. It is always interesting to see how certain constructs are carried over from previous versions of Exchange without being re-evaluated.
0 kommentar(er)
