Share via

Exchange 2016 and Mangement Tools connection

AdamTyler-3751 431 Reputation points
2021-03-31T20:45:36.57+00:00

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

Exchange | Exchange Server | Management
0 comments
Accepted answer
  1. Andy David - MVP 157.8K Reputation points MVP Volunteer Moderator
    2021-03-31T20:53:33.523+00:00

    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://learn.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.

3 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Andy David - MVP 157.8K Reputation points MVP Volunteer Moderator
    2021-03-31T21:13:02.64+00:00

    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://learn.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

    1 person found this answer helpful.
    0 comments
  2. AdamTyler-3751 431 Reputation points
    2021-04-02T20:01:31.917+00:00

    @Andy David - MVP 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

  3. Muhammad Safeer Saqib 6 Reputation points
    2024-04-01T08:32:13.7333333+00:00

    Hi Team, 

     

    I allow port 80 to the server so that PS can work. But security team concern in why we are not using default port 

    By default PowerShell will use the following ports for communication (They are the same ports as WinRM)

     

    TCP/5985 = HTTP

     

    TCP/5986 = HTTPS

     

    Please guide on this 

    0 comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.