This post is inspired by a question asked during my presentation at the last Arizona PowerShell User Group (AZPOSH) meeting. After I demonstrated Exchange management via PowerShell implicit remoting, one of our members said, “Ok, so how do I do that over the internet?”. Due to time constraints, I didn’t go into it the process in great detail, so I’ve decided to do that here, in this post. To demonstrate this configuration, I’ll use a basic topology with a single Exchange 2010 server running the core roles (hub, cas, mailbox). I will be publishing the PowerShell virtual directory to the internet via HTTPS using Forefront Threat Management Gateway (TMG), as shown in the diagram below.
Implementing a TMG server is not a requirement to make this work. But, when it comes to exposing Exchange servers to the Internet, its considered a best practice to publish them using a reverse proxy solution, such as TMG or UAG. However, you could accomplish this using a simple NAT translation on your firewall, directing traffic from the internet directly to your Exchange server on the internal network. If someone wanted to roll the dice and go with that type of configuration, they could skip the upcoming section on TMG, but it increases the attack surface and is considered bad practice.
Configuration Steps on the Exchange Server
The only thing that needs to be done on the Exchange server is a modification to the PowerShell virtual directory in IIS. In the Exchange Management Shell, use the following one-liner to enable Basic Authentication for the PowerShell virtual directory:
Get-PowerShellVirtualDirectory | Set-PowerShellVirtualDirectory -BasicAuthentication $true
Specifying the identity of the virtual directory is easier done via the pipeline, as shown above. However, this command would modify the virtual directory on every Exchange server in the organization, if you had more than one. If you want to specify a particular server, use the -Server parameter with the Get cmdlet, and pipe that over to the Set cmdlet.
I don’t want to reinvent the wheel here, so I’m just gonna focus the bare minimum. I’m assuming that if you have TMG and Exchange, you probably already have at least OWA published . If you need step-by-step guidance on installing certificates, and publishing Exchange services, such as OWA and Outlook Anywhere, then you should read Greg Taylor’s whitepaper titled Publishing Exchange Server 2010 with Forefront UAG and TMG.
The upcoming TMG configuration steps are based on the following assumptions.
- Certificates — You already have a 3rd party commercial certificate installed on the TMG server, it includes SANs for OWA, Outlook Anywhere, and maybe even Autodiscover. For example, mail.interfacettlabs.com, oa.interfacettlabs.com, autodiscover.interfacettlabs.com, etc.
- Listener — The TMG server is running in workgroup mode, you’re using secure LDAP to pre-authenticate users against Active Directory, and your commercial certificate is associated with the listener.
- Publishing Rule — You have publishing rules for OWA, Outlook Anywhere, and maybe even for ActiveSync. We won’t touch these, we’ll create a new publishing rule for PowerShell.
There are several ways to deploy TMG, so in reality, your deployment does not need to match the above configuration. For example, you’re not required to use pre-authentication, although it’s practically pointless not to. Again, check out the whitepaper for more details if you need to deploy TMG from scratch. With all of that in mind, let’s get started.
- From within the TMG console, right click on Firewall Policy, go to New, and select Web Site Publishing Rule:
- On the New Web Publishing Rule Wizard, enter a name for your rule, such as Exchange PowerShell:
- For the Rule Action, select Allow, otherwise we won’t be able to connect. Click Next:
- In our lab topology, we only had one server, so we’ll select Publish a Single Website or Load Balancer and click Next:
- Stick with the default Server Connection Security setting and use SSL to connect to the published web site, which in this case is hosted on the Exchange 2010 server. This will ensure that remote PowerShell connections use bridged SSL; meaning encrypted from the internet to TMG, and then from TMG to Exchange. Click on Next:
- On the Internal Publishing Details screen, enter the FQDN the TMG server should use to connect to the Exchange server and click on Next:
- Next, you’ll need to enter /powershell/* for the path to be published on the Exchange server. Click Next:
- Now you’ll need to enter your externally accessible FQDN in the public name field. Again, the path should be /powershell/* and click on Next:
- As discussed previously, we’ll use a listener that was configured for one of the other Exchange publishing rules. Click Next:
- This next step is important. On the Authentication Delegation screen, select Basic Authentication. This needs to match the authentication settings for the virtual directory, which was already configured in the previous section. Click Next:
- On the User Sets screen, keep the default setting of All Authenticated Users. Click Next:
- Finally, the PowerShell IIS application on the Exchange server has been published. Click on Finish:
Testing it out
Go to any machine external to your environment that has an internet connection. This can be any machine with PowerShell v2, it doesn’t need to be in the same domain as the Exchange server. Start PowerShell and use the following syntax to create a new session:
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://mail.interfacettlabs.com/powershell -Authentication basic -Credential (Get-Credential)
This command will prompt you for your domain credentials, then establish a PSSession with the Exchange server published through TMG. Notice that we’ve specified Basic authentication, and used the public name as the FQDN in the connection uri. After the session is created, the next step is to import it:
As you can see, it works perfectly. You should now have a publicly accessible endpoint for managing your on-premise Exchange environment through PowerShell remoting. As it turns out, the implicit remoting configuration is identical for Office 365, see this post for more details on that.
One Last Note on Testing in Lab Environments
If you are doing this in a lab, you might be dealing with self-signed certificates, or certificates issued from an internal CA. Depending on the client you are testing from, the certificates may not be trusted, and PowerShell may not be able to validate the certificates, depending on a number of factors. To get around this and basically ignore all certificate issues all together, you can create a PSSessionOption object that disables these certificate validation checks:
$so = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
Then make sure you assign that PSSessionOption object to the -SessionOption parameter of New-PSSession:
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://mail.interfacettlabs.com/powershell -Authentication basic -Credential (Get-Credential) -SessionOption $so
And finally, import the session:
That concludes this post, I hope you find it useful, or at least interesting. For more on managing Exchange via remoting, check out my previous posts on the subject, all of which can be found here.