question

AdamTyler-3751 avatar image
0 Votes"
AdamTyler-3751 asked AdamTyler-3751 commented

Exchange 2016 and Mangement Tools connection

Can someone help me better understand how the PowerShell component of the Exchange Management Tools install connects to Exchange server 2016 please? I've deployed Exchange into a dedicated network where clients can only connect over port TCP:443. All other inbound traffic is blocked from clients. This seems to be fine for Outlook connectivity, but the Exchange PowerShell component fails to connect with the error:

Connecting to remote server hostname.domain.local failed with the following error message : WinRM cannot complete the operation.

I went as far as collecting a packet capture during the launch of the default Exchange Management Shell icon and all I saw was TCP:80 connection attempts from the client to the server. I went and tried to configure the PowerShell virtual directory to use an "https://" based URL which matches the installed certificate, but the default Exchange Management Shell install still attempts to connect to the internal FQDN of the server using port 80. What am I missing?

I'm not interested in allowing inbound PowerShell management over the public internet, this is only for internal connections from workstations that will be used by admins for Exchange management tasks.

Regards,
Adam Tyler

office-exchange-server-administration
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

AndyDavid avatar image
0 Votes"
AndyDavid answered AdamTyler-3751 commented

You'll need to allow port 80 to the server so that PS can work.
Don't think though that its unsafe. Authentication is over Kerberos, not plain text.

https://docs.microsoft.com/en-us/powershell/exchange/connect-to-exchange-servers-using-remote-powershell?view=exchange-ps


TCP port 80 traffic needs to be open between your local computer and the Exchange server. It's probably open, but it's something to consider if your organization has a restrictive network access policy.



· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thanks @AndyDavid.. This is unfortunate, was attempting to lock things down more. Is there no way to use the Remote PowerShell mechanism to facilitate this connection over TCP:443 only? Even if it is just from internal clients.

How should the URLs be configured for the PowerShell virtual directories in this case? The External URL was empty and internal URL was populated with the internal FQDN by default. I changed both to https:// using an FQDN that matched the installed cert and it didn't seem to make any difference. What's best practice here?

-Adam

0 Votes 0 ·
AndyDavid avatar image
1 Vote"
AndyDavid answered AndyDavid edited


So, for Powershell, dont mess with those URLs

If you are using a load balancer, you could use 443 and switch to basic auth on the PS dirs.

What you would do is enable Basic Auth on the PS virtual dirs.

then you would use remote PS and connect to the load balanced namespace over 443

Example: ( No need to specify the version)

https://techcommunity.microsoft.com/t5/exchange-team-blog/remote-powershell-proxying-behavior-in-exchange-2013-cu12-and/ba-p/604504



Alternatively, you could do the same with kerberos and allow port 80:
https://docs.microsoft.com/en-us/exchange/architecture/client-access/kerberos-auth-for-load-balanced-client-access?view=exchserver-2019

BTW, if you wanted to really lock things down, spin up some jump boxes and allow port 80 only from those servers and that way admins run remote powershell from there only

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

AdamTyler-3751 avatar image
0 Votes"
AdamTyler-3751 answered AdamTyler-3751 commented

@AndyDavid Thanks again. I've reverted the PowerShell virtual directory back to its default setting in my lab and opened port 80 inbound to the Exchange server. Now the default install of Exchange tools on admin workstations seems to work.

You made an interesting comment about a load balancer and leveraging the remote PowerShell virtual directory mechanism of Exchange. Doesn't really apply to us since we just have the one Exchange server, but I'm curious. The running recommendation is for all Exchange servers in the organization use the same internal/external service URL that matches the cert, then have that URL point to the load balancer. At least for services like the Outlook Web App, ECP, OAB, EWS, MAPI, ActiveSync, and Autodiscover. It's interesting that most of these services appear to just proxy from one Exchange server to another auto-magically if the mailbox of the querying user happens to be found elsewhere.

PowerShell on the other hand is a bit different I notice. Using the default install of Exchange tools and launching the Exchange Management Shell while port 80 was blocked to our new Exchange server caused the shell to timeout. Once timed out on the shells first Exchange server choice, it tried to connect to an alternate Exchange server. I guess for most tasks, it doesn't really matter where you are running the cmdlets. You can craft the cmdlet to execute for mailboxes wherever they happen to reside. Or make changes to other Exchange servers using cmdlets executed.. I don't really see the point of using a load balancer with PowerShell connections to Exchange at all. Maybe I am missing something?

Regards,
Adam Tyler

· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Using a load balancer eliminates the need to specify a server, you could connect to the load balanced name space and use that for as long as servers are in that pool. Great for upgrades and decommissions. No need to change any scripts if they are pointing to the load balanced name space!

0 Votes 0 ·

Gotcha. The default Exchange Management Tools install appears to select a server automatically however. I agree that a common namespace for scripts would be key. I have several scheduled scripts in our environment that I now have to go touch during our Exchange 2010 to 2016 migration. I did choose to go with a new namespace for 2016 for other reasons.

Regards,
Adam Tyler

0 Votes 0 ·