Exchange SE Management Shell & Toolbox HTTPS Connectivity Challenges (Post-Upgrade to Server 2025)

Question

Exchange SE Management Shell & Toolbox HTTPS Connectivity Challenges (Post-Upgrade to Server 2025)

Michael Lovett 5

📝 Question:

I’m investigating an Exchange Management Shell and Toolbox connectivity issue following an upgrade to Exchange Server Subscription Edition (SE).

🔧 Environment Details:

Original hybrid deployment: Exchange 2016 running on Windows Server 2016
Recently added: Exchange 2019 CU15 on Windows Server 2025
Performed in-place upgrade on the new server → now running Exchange Server SE
All remoting connections use Kerberos authentication

✅ Observed Behavior:

I can remotely connect to the new Exchange SE server from the legacy Exchange 2016 server (or other machines with Exchange SE management tools installed) using Exchange Management Shell and Exchange Toolbox only if SSL is not enforced on the /PowerShell virtual directory.
When I enable RequireSSL, remote remoting fails with:

WinRM cannot determine the content type of the HTTP response

—often resulting in a 403.4 Forbidden response, indicating IIS is blocking the HTTP request expected by the client.

Locally, on the Exchange SE server, if I manually launch PowerShell using:

New-PSSession -ConnectionUri "https://exchangeserver.company.org/powershell/" `
  -Authentication Kerberos `
  -AllowRedirection `
  -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck)

…the IIS logs show successful 200 OK responses over port 443, but the session hangs and never returns a usable prompt.

Initially I thought the Exchange Toolbox was connecting locally, but turns out it fails too. It throws the following error:

FX:{714FA079-DC14-470f-851C-B7EAAA4177C1}
Type is not resolved for member 'MonadDataAdapterInvocationException...
System.Runtime.Serialization.SerializationException

This suggests a failed deserialization attempt related to the MonadDataProvider and possibly a version mismatch after the upgrade.

🧪 Troubleshooting Done So Far:

Verified:
WinRM HTTPS listener on port 5986
Certificate binding via netsh http show sslcert
- GPO settings → confirmed AllowUnencrypted = false, TrustedHosts = *.company.org
- Ran EMTshooter.ps1, which showed:
  - HTTP fails as expected when SSL is enforced
    - HTTPS request gets redirected to /PowerShell-LiveID
      - Recommended enabling AllowRedirection, which I confirmed helps—but only if sessions are manually scripted
      - Manually tested the Exchange PowerShell snap-in: loads fine when added directly
      - Confirmed IIS /PowerShell VDir is healthy and responding
      - Checked RPS.Proxy health set → all monitors report Healthy
Observed multiple successful HTTPS POST /powershell requests in IIS logs, but no prompt appears in shell
Followed various steps from here:
https://learn.microsoft.com/en-us/troubleshoot/exchange/administration/connecting-remote-server-failed

Can't Run the: https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/

📉 Monitoring Impact:

In addition to the shell/toolbox behavior, SCOM is generating alerts against the new Exchange SE server due to RPS health probes failing. These probes attempt to use PowerShell remoting to validate availability, but they seem to default to HTTP, which is now blocked if SSL is required.

❓ Questions:

Why does the Exchange Toolbox fail locally while attempting remote management via HTTPS? Is this related to .NET serialization or assembly mismatches from the CU15 → SE upgrade?
Is there a supported or recommended way to force the Exchange Management Shell to use HTTPS with Kerberos, especially if editing RemoteExchange.ps1 isn’t viable?
Has anyone seen similar behavior with Exchange SE running on Windows Server 2025 after performing an in-place upgrade?
What’s the best way to enforce SSL on the /PowerShell VDir without breaking:
- Remote Exchange Shell access
  - Local shell behavior
    - Exchange Toolbox
      - Monitoring probes like those used by SCOM RPS

Any guidance, insights, or experience with these SSL + remoting edge cases in Exchange SE would be hugely appreciated. Happy to share more config or logs if helpful!

0 comments

5 answers

Your answer

Answer 1

Thanks for the fix guys! For anyone coming across this post - the issue is solved but is buried in the comments under the previous post (which we initially missed):

Step 1: View Current WinRM Configuration

A. Open PowerShell as Administrator

B. Run the following command to see the full WinRM client configuration:

winrm get winrm/config/client

Example Output:

Client

NetworkDelayMs = 5000

URLPrefix = wsman

AllowUnencrypted = false

Auth

    Basic = false

    Digest = true

    Kerberos = true

    Negotiate = true

    Certificate = false

DefaultPorts

    HTTP = 5985

    HTTPS = 5986

TrustedHosts = *

🔴 If TrustedHosts = *, this is causing the issue!

Step 2: Remove TrustedHosts Setting from Group Policy (or use local policy gpedit.msc or PowerShell at #3 below)

A. Open Group Policy Management Console (GPMC) on a domain controller

B. Navigate to:

Computer Configuration → Administrative Templates → Windows Components → Windows Remote Management (WinRM) → WinRM Client

C. Locate and edit the Trusted Hosts policy:

Double-click Trusted Hosts

Set it to Enabled with Blank value (not *)

Click OK

D. Force Group Policy Update on the Exchange server:

gpupdate /force

Step 3: If not using GPO to set this, you can change TrustedHosts Locally on the Exchange Server

A. Clear the TrustedHosts Setting:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value ""

As soon as you set this the Exchange Shell works - thanks Microsoft! :)

Answer 2

Wilson, Bob 15

So, we figured out what was causing the issue. We have a GPO that sets the TrustedHosts="*" for the WinRM client. Removing this allowed EMS and Toolbox to load without issue. You would think this value would not be a problem as it is essentially telling the client that it can connect to any WinRM server but who knows. Will be working with our Domain Admins to get this fixed for all our new Exchange servers.

0 comments

Answer 3

Seiun 1

Hi

I've the same problem.

In our envronment we have Exchange 2016 on Windows Server 2016.

We added Exchange 2019 with CU15 on Windows Server 2025 with full update.

Exchnage Management Shell and Exchange Toolbox don't work. Very frustrated.

And soon we'll have to migrate to Exchange SE. I can already see the problems. I don't understand why Microsoft is rushing this when there are so many bugs and imperfections.

To get local access to Exchange 2019 from powershell you have to use Exchange PowerShell snap-in. Only that is working.

Michael Lovett 5 Reputation points

2025-09-15T13:17:31.5433333+00:00

For now, the best solution I can offer is build a Server 2022 system and install the Exchange Management Tools for SE only on that system after upgrading your 2025 server to Exchange SE. At least you'll have something to manage with, the problem is specific to Server 2025 and Exchange 2019CU15 and Exchange SE, I believe it is a new security default on Server 2025 that is causing the issue. It becomes even more complicated if your trying to use Kerberos authentication across the board, but Server 2022 as a management tools server does work, at least it did for me.
Wilson, Bob 15 Reputation points

2025-09-18T18:53:40.8966667+00:00

We have the same issue. We are in coexistence with Exchange 2016 and Exchange SE. We opted to install SE on Windows Server 2025 as opposed to 2022 since the EOL for 2022 would be sooner. Wishing we had not now, especially not being able to even use a local EMS connection, Exchange toolbox, etc. Keep getting this error - The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid.

We have tried everything under the sun at this point with no luck. Interestingly, the same error is returned when running new-pssession -ConnectionUri http://<FQDN>/PowerShell -ConfigurationName Microsoft.Exchange -Credential (Get-Credential) which leads me to believe its nothing to do with the EMS launch scripts but more so with winrm. When running the same command but this time with the -Authentication Kerberos parameter, the new powershell session is created. Seems to be something with how Powershell/winrm is using the Negotiate method.

Been working with Microsoft support to hopefully figure this out.
Michael Lovett 5 Reputation points

2025-09-18T20:54:14.8+00:00

Please post the solution if Microsoft determines the fix, the one thing of note, I have found on the Exchange SE Server, if you launch a PowerShell Admin session, and then load the Snapin:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn;

Then you can at least manage and work with Exchange SE locally using PowerShell. But I haven't determined a work around for the Toolbox.
Michael Lovett 5 Reputation points

2025-09-19T16:24:11.65+00:00

That doesn't make any sense at all we have that setting as well, do you just leave it blank? Or do you have to list specific IP Subnets?
Wilson, Bob 15 Reputation points

2025-09-19T17:37:42.3866667+00:00

I just left it blank.
Michael Lovett 5 Reputation points

2025-09-19T17:44:30.7166667+00:00
Excellent find, and thank you for sharing this as I am going to test myself in our environment, so sad such a simple setting can cause so much grief. After digging deeper into Microsoft’s documentation, it turns out the TrustedHosts setting is really only necessary when you're using older authentication methods like NTLM, or when machines aren't joined to a domain. If you're using Kerberos in a domain environment, you can safely leave TrustedHosts unset.

Here’s why: Kerberos relies on Active Directory for mutual authentication. When both the client and server are domain-joined, the client can verify the server using Service Principal Names (SPNs), and the server can verify the client using domain credentials. The domain itself establishes trust, so there’s no need to manually specify trusted hosts.

On the other hand, TrustedHosts becomes relevant when:

You're using Basic or NTLM authentication

The machines are in a workgroup or separate domains without trust

You're connecting via IP address instead of hostname (Kerberos requires proper DNS resolution)

Microsoft explains it clearly in their documentation:

“If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting.” Source: Microsoft Learn – WinRM Troubleshooting

So in short:

If you're using Kerberos and both machines are domain-joined, WinRM works without modifying TrustedHosts

If you're using an IP address or working across untrusted domains, you'll need to configure it

Here’s a quick example:

Enter-PSSession -ComputerName server01.domain.local -Authentication Kerberos

This works fine in a domain environment. But if you try:

Enter-PSSession -ComputerName 192.168.1.10 -Authentication Kerberos

It will likely fail unless that IP is added to TrustedHosts.

Additional references:

Stack Overflow – WinRM without TrustedHosts

AwakeCoding Blog – PowerShell Remoting Trusted Hosts
Wilson, Bob 15 Reputation points

2025-09-19T18:24:09.23+00:00

Thanks for the write up. After reading that it makes sense now.
Wilson, Bob 15 Reputation points

2025-09-19T18:25:24.4033333+00:00

Thanks for the write up. After reading that it makes sense now.
Faucher, Martin 5 Reputation points

2025-09-30T00:25:51.5166667+00:00

The solution from Wilson, Bob did the trick for me !

Thank you.
Michael Mason 0 Reputation points

2025-10-09T17:20:09.9233333+00:00

Have there been any updates to this? I'm running into the same type of issue with a new install of Server 2025 & Exchange SE. We have an open support case with Microsoft which is being handed off from one group to another. We're likely to create new 2022 server and install management tools there.
Michael Lovett 5 Reputation points

2025-10-09T20:55:21.1733333+00:00
Steps to view the full WinRM configuration and examples of what the output looks like:

Step 1: View Current WinRM Configuration

A. Open PowerShell as Administrator

B. Run the following command to see the full WinRM client configuration:

winrm get winrm/config/client

Example Output:

Client NetworkDelayMs = 5000 URLPrefix = wsman AllowUnencrypted = false Auth Basic = false Digest = true Kerberos = true Negotiate = true Certificate = false DefaultPorts HTTP = 5985 HTTPS = 5986 TrustedHosts = *

🔴 If TrustedHosts = *, it means all hosts are trusted — which is insecure and can interfere with Exchange SE tools.

Step 2: Remove TrustedHosts Setting from Group Policy

A. Open Group Policy Management Console (GPMC) on a domain controller

B. Navigate to:

Computer Configuration → Administrative Templates → Windows Components → Windows Remote Management (WinRM) → WinRM Client

C. Locate and edit the Trusted Hosts policy:

Double-click Trusted Hosts

Set it to Not Configured or remove the * value

Click OK

D. Force Group Policy Update on the Exchange server:

gpupdate /force

Step 3: Change TrustedHosts Locally on the Exchange Server

A. Clear the TrustedHosts Setting:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value ""

B. (Optional) Set Specific Trusted Hosts:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "host1.domain.com,host2.domain.com"

C. Confirm the change:

Get-Item WSMan:\localhost\Client\TrustedHosts

✅ Example Output:

WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Client Type Name Value ---- ---- ----- System.String TrustedHosts host1.domain.com,host2.domain.com

🔁 Step 4: Restart WinRM and Test Exchange Tools

Restart-Service WinRM

Then relaunch Exchange SE Management Shell and Toolbox to confirm functionality.
Michael Mason 0 Reputation points

2025-10-14T19:21:43.5866667+00:00

Lovett,

Thanks for that information, it resolved the issue on one of our servers, but the other is still being a problem child. We have a support case open with Microsoft about this, and I'm hopeful they are able to resolve the issue with the server that is still an issue.

Answer 4

Michael Lovett 5

We've worked through the checklist and even used the Upgrade option with Exchange SE to reinstall and verify that the binaries and files are intact. We suspect the issue lies with the Kerberos configuration.

Ultimately, our goal is to retire the current Exchange 2016 Hybrid Server and transition to the new Exchange SE Hybrid Server. This new server will serve as the sole system for:

Account management for newly created Office 365 users
SMTP mail relay for copiers, notification systems, Microsoft Operations Manager, and other monitoring tools that rely on SMTP

Right now, we're trying to determine the correct permissions and delegation settings, specifically:

What permissions need to be configured on the PowerShell Virtual Directory (VDir)
What delegation settings are required on:
- The Exchange computer account
  - The service account used to run the Exchange Health Check PowerShell script, which generates an HTML report on server health

Do you have detailed guidance on how Kerberos rights, delegation, and permissions should be configured for the relevant virtual directories and accounts?

I have looked at this document, but it doesn't really match our simple single server configuration we are trying to do:

Here are some detailed guides that walk you through setting up Kerberos authentication for Exchange Server:

🔐 Microsoft Official Documentation

Configure Kerberos authentication for load-balanced Client Access services This guide covers setting up Alternate Service Account (ASA) credentials, configuring Service Principal Names (SPNs), and deploying the configuration across Exchange servers.

🛠 Step-by-Step Community Guides

Configure Kerberos Authentication for Exchange Server – Ali Tajran A comprehensive walkthrough including ASA creation, SPN association, PowerShell commands, and verification steps.

Enable Kerberos Authentication in Exchange – AventisTech Focused on Exchange 2016 and 2019, this guide includes script usage and configuration of authentication methods for Outlook and MAPI.

How to Enable Kerberos Authentication for Accessing Exchange in a Resource Forest – Microsoft Tech Community Useful if you're working in a multi-forest or resource forest topology.

All of these seem to indicate this ASA account creation, and I don't see or understand the need to do so for such a simplified 1 server environment when all is said and done. Can you highlight the parts of any of these that we should follow?

Hin-V 14,175 Reputation points Microsoft External Staff Moderator

2025-07-28T14:46:08.52+00:00
Hi @Michael Lovett

Thank you for your responding.

Based on my research, you could refer to configure Kerberos Rights, SPNs, and Delegation:

1. Associate SPNs to the Exchange Computer Account (Instead of ASA):

SPNs map services (e.g., HTTP for Exchange web services) to the account handling authentication. For single-server, register them on the Exchange server's computer account.

Relevant from guides: All guides stress verifying no duplicate SPNs (using setspn -F -Q http/mail.contoso.com) and associating them correctly. Adapt the setspn commands to target the computer account.

Commands (run from an elevated Command Prompt on a domain-joined machine with AD tools):

setspn -S http/mail.contoso.com CONTOSO\EXCHSERVER$ # Replace with your namespace (e.g., external URL) and server name setspn -S http/autodiscover.contoso.com CONTOSO\EXCHSERVER$

Verify: setspn -L CONTOSO\EXCHSERVER$

If duplicates exist (e.g., on another account), remove them first: setspn -D http/mail.contoso.com OLDACCOUNT

This enables Kerberos for services like Outlook Anywhere, MAPI/HTTP, and Autodiscover. Restart the server or IIS (iisreset) after changes.

2. Configure Authentication on Virtual Directories (Including PowerShell VDir):

Exchange VDirs (in IIS) control authentication methods. For Kerberos, enable "Negotiate" (which prefers Kerberos over NTLM) on relevant ones. The PowerShell VDir (/PowerShell) is used for remote PowerShell sessions (e.g., hybrid management), so it needs Windows Authentication (which supports Kerberos).

Permissions on PowerShell VDir: By default, it's set to Windows Authentication (Integrated) only—no Anonymous or Basic. This is sufficient for Kerberos in hybrid setups, as remote PowerShell uses Kerberos tickets. No special NTFS/IIS permissions needed beyond defaults (e.g., SYSTEM, Administrators have full control). Ensure the Exchange Trusted Subsystem group has read/execute on the VDir path. In hybrid, this VDir is used for Exchange Online connections, so Kerberos ensures secure delegation for cmdlets like those in the Hybrid Configuration Wizard.

Relevant from guides: Focus on the VDir config sections in Microsoft, Tajran, and Kolber guides. They cover Outlook/MAPI but apply similarly to PowerShell.

Commands (run in Exchange Management Shell): For PowerShell VDir (enable Negotiate if not already):
Get-PowerShellVirtualDirectory -Server EXCHSERVER | Set-PowerShellVirtualDirectory -WindowsAuthentication $true -BasicAuthentication $false
For other VDirs (e.g., to support hybrid management/OWA/ECP):

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -WindowsAuthentication $true Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -WindowsAuthentication $true Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm,Negotiate Get-OutlookAnywhere | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate

Restart IIS: iisreset

Test: Use Test-OutlookWebServices or tools like Kerbtray to verify Kerberos tickets.

3. Delegation Settings on the Exchange Computer Account:

Kerberos delegation allows the server to impersonate users when accessing resources (e.g., for SMTP relay or hybrid free/busy lookups). In a single-server hybrid, constrained delegation may be needed if the server relays to other services or for cross-forest trusts.

Relevant from guides: Not heavily covered, as delegation is more AD-focused. Microsoft hybrid permissions doc notes that delegation (e.g., for mailbox access) requires Microsoft Entra Connect config for ACL synchronization, but for the computer account, use AD Users and Computers.

Steps in AD Users and Computers: Find the Exchange server computer account > Properties > Delegation tab. Select "Trust this computer for delegation to specified services only" (constrained delegation). Add services: e.g., HTTP on domain controllers or other servers if needed for hybrid auth flows. For Kerberos rights: Ensure the account supports AES256 encryption: Set-ADComputer EXCHSERVER -add @{"msDS-SupportedEncryptionTypes"="28"} In hybrid, this supports OAuth/Kerberos for features like free/busy. If not needed (e.g., no complex relays), defaults suffice—no delegation required.

4. Delegation and Permissions for the Service Account (Exchange Health Check Script):

Assuming this is Microsoft's HealthChecker.ps1 (common for generating HTML health reports), the service account needs Exchange permissions to run checks.

Permissions Required: Add to Organization Management role group: Add-RoleGroupMember "Organization Management" -Member SERVICEACCOUNT Local Admin on the Exchange server for OS-level checks.

Delegation Settings: If the script runs scheduled/locally and accesses remote resources (e.g., AD or other servers), enable Kerberos constrained delegation on the service account in AD: Properties > Delegation > "Trust this user for delegation to specified services only" > Add services like CIFS/HTTP on target servers. For single-server, if running locally, no delegation needed—Kerberos handles local auth.

Relevant Guidance: HealthChecker requires Org Management for full access. Schedule as a task with "Run with highest privileges" using the service account. No ASA/Kerberos tweaks specific to this account unless it impersonates users.
1. Associate SPNs to the Exchange Computer Account (Instead of ASA): SPNs map services (e.g., HTTP for Exchange web services) to the account handling authentication. For single-server, register them on the Exchange server's computer account. Relevant from guides: All guides stress verifying no duplicate SPNs (using setspn -F -Q http/mail.contoso.com) and associating them correctly. Adapt the setspn commands to target the computer account. Commands (run from an elevated Command Prompt on a domain-joined machine with AD tools):
setspn -S http/mail.contoso.com CONTOSO\EXCHSERVER$ # Replace with your namespace (e.g., external URL) and server name setspn -S http/autodiscover.contoso.com CONTOSO\EXCHSERVER$
Verify:
setspn -L CONTOSO\EXCHSERVER$
If duplicates exist (e.g., on another account), remove them first: setspn -D http/mail.contoso.com OLDACCOUNT This enables Kerberos for services like Outlook Anywhere, MAPI/HTTP, and Autodiscover. Restart the server or IIS (iisreset) after changes.

2. Configure Authentication on Virtual Directories (Including PowerShell VDir):

Exchange VDirs (in IIS) control authentication methods. For Kerberos, enable "Negotiate" (which prefers Kerberos over NTLM) on relevant ones. The PowerShell VDir (/PowerShell) is used for remote PowerShell sessions (e.g., hybrid management), so it needs Windows Authentication (which supports Kerberos).

Permissions on PowerShell VDir:

By default, it's set to Windows Authentication (Integrated) only—no Anonymous or Basic. This is sufficient for Kerberos in hybrid setups, as remote PowerShell uses Kerberos tickets.

No special NTFS/IIS permissions needed beyond defaults (e.g., SYSTEM, Administrators have full control). Ensure the Exchange Trusted Subsystem group has read/execute on the VDir path.

In hybrid, this VDir is used for Exchange Online connections, so Kerberos ensures secure delegation for cmdlets like those in the Hybrid Configuration Wizard.

Relevant from guides: Focus on the VDir config sections in Microsoft, Tajran, and Kolber guides. They cover Outlook/MAPI but apply similarly to PowerShell.

Commands (run in Exchange Management Shell):

For PowerShell VDir (enable Negotiate if not already):

Get-PowerShellVirtualDirectory -Server EXCHSERVER | Set-PowerShellVirtualDirectory -WindowsAuthentication $true -BasicAuthentication $false

For other VDirs:

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -WindowsAuthentication $true Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -WindowsAuthentication $true Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm,Negotiate Get-OutlookAnywhere | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate

Restart IIS: iisreset

Test: Use Test-OutlookWebServices or tools like Kerbtray to verify Kerberos tickets.

3. Delegation Settings on the Exchange Computer Account:

Kerberos delegation allows the server to impersonate users when accessing resources (e.g., for SMTP relay or hybrid free/busy lookups). In a single-server hybrid, constrained delegation may be needed if the server relays to other services or for cross-forest trusts.

Relevant from guides: Not heavily covered, as delegation is more AD-focused. Microsoft hybrid permissions doc notes that delegation (e.g., for mailbox access) requires Microsoft Entra Connect config for ACL synchronization, but for the computer account, use AD Users and Computers.

Steps in AD Users and Computers:

Find the Exchange server computer account > Properties > Delegation tab.

Select "Trust this computer for delegation to specified services only" (constrained delegation).

Add services: e.g., HTTP on domain controllers or other servers if needed for hybrid auth flows.

For Kerberos rights: Ensure the account supports AES256 encryption: Set-ADComputer EXCHSERVER -add @{"msDS-SupportedEncryptionTypes"="28"}

In hybrid, this supports OAuth/Kerberos for features like free/busy. If not needed (e.g., no complex relays), defaults suffice—no delegation required.

4. Delegation and Permissions for the Service Account (Exchange Health Check Script):

Assuming this is Microsoft's HealthChecker.ps1 (common for generating HTML health reports), the service account needs Exchange permissions to run checks.

Permissions Required:

Add to Organization Management role group: Add-RoleGroupMember "Organization Management" -Member SERVICEACCOUNT

Local Admin on the Exchange server for OS-level checks.

Delegation Settings:

If the script runs scheduled/locally and accesses remote resources (e.g., AD or other servers), enable Kerberos constrained delegation on the service account in AD: Properties > Delegation > "Trust this user for delegation to specified services only" > Add services like CIFS/HTTP on target servers.

For single-server, if running locally, no delegation needed—Kerberos handles local auth.

Relevant Guidance: HealthChecker requires Org Management for full access. Schedule as a task with "Run with highest privileges" using the service account. No ASA/Kerberos tweaks specific to this account unless it impersonates users.

You can refer to the information provided above. However, if you need detailed guidance on configuring Kerberos, I recommend you reach out to Microsoft Support. This will help ensure you receive tailored assistance for your setup and to get the fast and better assistance we requested for it.

If there’s anything else you’d like to share, let us know.

Warm thanks.
Michael Lovett 5 Reputation points

2025-07-28T22:03:28.5966667+00:00

Thank You, you have given me a lot, and I will verify with you the details and success.
Hin-V 14,175 Reputation points Microsoft External Staff Moderator

2025-07-30T06:29:34.9066667+00:00

Hi @Michael Lovett

Thank you for your responding.

If you futher concern, please share it in comment section. I would try my best to assist you.

If you think my reply is helpful to you, please remember to mark it as an answer.

Warm thanks and have a nice day.
Hin-V 14,175 Reputation points Microsoft External Staff Moderator

2025-08-01T06:23:59.29+00:00

Hi @Michael Lovett

I hope you are doing well. It's been a long time and I haven't received any respond from your side.

Any update would be appreciated.

Warm thanks.
Michael Lovett 5 Reputation points

2025-08-01T13:00:45.24+00:00

Hi, I am sorry, we are working on a big project at the moment and this has been put on the backburner, I will test this and reply within the next couple of weeks. I appreciate all of your help thus far.
Hin-V 14,175 Reputation points Microsoft External Staff Moderator

2025-08-01T13:10:27.5933333+00:00

Hi @Michael Lovett

Thank you for your responding.

If you need any further assistance, please don’t hesitate to reach out to me.

I hope you achieve your goal soon.

Warm thanks and have a nice day.
Michael Lovett 5 Reputation points

2025-08-19T17:58:35.5266667+00:00

I have tested all of the above, and I have gone the route of installing the Exchange Management Tools on a separate Box to remotely check and monitor the health of my new Exchange SE Server. I believe the settings you have given is correct, but I believe there is something related to Kerberos Delegation that I am missing, but since the above got me to the point that I can remotely from a new system monitor and manage my server, I am going to circle back when I have more time to troubleshoot. I have included the updated Kerberos configured Virtual Directories, but as noted the Exchange Health Checker script provided by Microsoft claims this is an unsupported configuration.
Hin-V 14,175 Reputation points Microsoft External Staff Moderator

2025-08-21T11:18:38.9733333+00:00

Hi @Michael Lovett

Thank you for your responding.

As my research, this error often surfaces after enabling Extended Protection (EP) or applying recent Cumulative Updates (CUs). Since everything is functional, the "unsupported configuration" alert for the Default Web Site/PowerShell virtual directory might be something you can safely ignore for now, especially if no other symptoms (like authentication failures or security issues) are appearing.

Regarding Kerberos delegation: For a standard single-server Exchange setup with remote management from a domain-joined machine, delegation isn't typically required remote PowerShell sessions are single-hop and handle authentication directly via Kerberos or NTLM. However, if you're seeing fallback to NTLM (via event logs showing NTLM auth in WinRM or Security logs), or if your setup involves multi-hop scenarios (like scripts on the remote box accessing additional domain resources on your behalf), constrained delegation could be the missing piece. You could take time to review this configuration (references: Kerberos Constrained Delegation Overview | Microsoft Learn). If you have any question on this, do not hesitate to reach out us. I be more than happy to help you reconfigure it.

If my solution had partially help you, you could consider to mark it as an answer. This helps others in the community share the same concern about this feature and contribute to building stronger collective knowledge

Warm thanks and have a nice day.
Hin-V 14,175 Reputation points Microsoft External Staff Moderator

2025-08-26T06:54:47.6966667+00:00

Hi @Michael Lovett
It has been a while and I am writing to see how things are going with this issue.

In case you require further assistance regarding this topic, feel free to reach out. We more than happy to assist

Looking forward to hearing from you!

Warm thanks.
Michael Lovett 5 Reputation points

2025-08-26T15:09:05.6033333+00:00
So I am not any closer locally, but we have narrowed the issue down to Server 2025, so I installed the Microsoft Exchange Management Tools on Server 2019, and then performed an in place upgrade and the tools broke, so I removed them and reinstalled them again, and the exact same behavior started where I could run the Exchange Management Tools remotely like I was prior to upgrade the Server OS. So I went to another server, one running Windows Server 2022, installed the tools and also noted that I could run the tools remotely, with some additional troubleshooting, I was able to get error output that pointed to the following:

Mail flow test: [EXCHANGE_SERVER] Connecting to remote server EXCHANGE_SERVER failed with the following error message : The WinRM client cannot process the request. A computer policy does not allow the delegation of the user credentials to the target computer because the computer is not trusted. The identity of the target computer can be verified if you configure the WSMAN service to use a valid certificate using the following command: winrm set winrm/config/service '@{CertificateThumbprint="<thumbprint>"}' Or you can check the Event Viewer for an event that specifies that the following SPN could not be created: WSMAN/<computerFQDN>. If you find this event, you can manually create the SPN using setspn.exe . If the SPN exists, but CredSSP cannot use Kerberos to validate the identity of the target computer and you still want to allow the delegation of the user credentials to the target computer, use gpedit.msc and look at the following policy: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Fresh Credentials with NTLM-only Server Authentication. Verify that it is enabled and configured with an SPN appropriate for the target computer. For example, for a target computer name "myserver.domain.com", the SPN can be one of the following: WSMAN/myserver.domain.com or WSMAN/*.domain.com. Try the request again after these changes. For more information, see the about_Remote_Troubleshooting Help topic. + CategoryInfo : OpenError: (EXCHANGE_SERVER:String) [], PSRemotingTransportException + FullyQualifiedErrorId : -2144108124,PSSessionStateBroken

Got a similar message with Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Fresh Credentials, as well. So we updated the Group Policy on the remote server for allowing those two settings on the Exchange_Server i.e. WSMAN/Exchange_Server and WSMAN/Exchange_Server.domain.com

Then I could successfully connect remotely to the newer Exchange SE server. Still can't connect locally, but remotely is working on a Server 2022 and Server 2025 box remotely using Kerberos security.

This error is a textbook example of the Kerberos double-hop issue, which occurs when you're trying to pass credentials across two hops in a network using Windows Remote Management (WinRM) and Kerberos authentication.

Let’s break it down:

What Is the Double-Hop Problem?

In a typical remote PowerShell or WinRM session:

First hop: You connect from your client machine to a remote server (e.g., EXCHANGE) using Kerberos.

Second hop: That remote server then tries to access another resource (like Active Directory, a file share, or another server) on your behalf, using your credentials.

Kerberos by default does not allow credential delegation across that second hop unless explicitly configured. So when the remote server tries to use your credentials to authenticate to another system, it fails—because it doesn’t have permission to "re-use" your credentials.

Why Your Error Message Confirms It

The error says:

"A computer policy does not allow the delegation of the user credentials to the target computer because the computer is not trusted."

This is Kerberos saying: “I won’t let this server use your credentials to talk to another server unless you’ve configured delegation properly.”

It also references:

SPNs (Service Principal Names): Required for Kerberos to identify services.

CredSSP and NTLM fallback: Workarounds that allow credential delegation in less secure ways.

Group Policy settings: Specifically the Allow Fresh Credentials with NTLM-only Server Authentication policy, which can bypass the double-hop restriction under certain conditions.

How to Fix or Work Around It

Here are your main options:

✅ 1. Configure Kerberos Delegation

Use Constrained Delegation in Active Directory.

Ensure the SPN for the target service (e.g., WSMAN/exchange.domain.com) is properly registered.

Set up delegation on the account or computer object in AD to allow it to delegate credentials to the target service.

✅ 2. Use CredSSP

CredSSP allows credentials to be passed securely to the remote server.

Enable via Group Policy: Computer Configuration → Administrative Templates → System → Credentials Delegation → Allow Fresh Credentials with NTLM-only Server Authentication

Add the target server’s SPN to the allowed list.

✅ 3. Use HTTPS for WinRM

Configure WinRM to use a valid certificate.

This can help bypass some of the trust issues by validating the identity of the remote server.

Why It Matters

Without resolving the double-hop issue, any script or tool that relies on remote execution and tries to access another resource (like Exchange or AD) will fail silently or throw credential errors—even if everything else looks correctly configured.

Let me know if you want help walking through the delegation setup or testing SPNs. This one’s tricky, but once it’s nailed down, it unlocks a lot of automation potential.This error is a textbook example of the Kerberos double-hop issue, which occurs when you're trying to pass credentials across two hops in a network using Windows Remote Management (WinRM) and Kerberos authentication.

Let’s break it down:

🧠 What Is the Double-Hop Problem?

In a typical remote PowerShell or WinRM session:

First hop: You connect from your client machine to a remote server (e.g., EXCHANGE) using Kerberos.

Second hop: That remote server then tries to access another resource (like Active Directory, a file share, or another server) on your behalf, using your credentials.

Kerberos by default does not allow credential delegation across that second hop unless explicitly configured. So when the remote server tries to use your credentials to authenticate to another system, it fails—because it doesn’t have permission to "re-use" your credentials.

Why Your Error Message Confirms It

The error says:

"A computer policy does not allow the delegation of the user credentials to the target computer because the computer is not trusted."

This is Kerberos saying: “I won’t let this server use your credentials to talk to another server unless you’ve configured delegation properly.”

It also references:

SPNs (Service Principal Names): Required for Kerberos to identify services.

CredSSP and NTLM fallback: Workarounds that allow credential delegation in less secure ways.

Group Policy settings: Specifically the Allow Fresh Credentials with NTLM-only Server Authentication policy, which can bypass the double-hop restriction under certain conditions.

How to Fix or Work Around It

Here are your main options:

✅ 1. Configure Kerberos Delegation

Use Constrained Delegation in Active Directory.

Ensure the SPN for the target service (e.g., WSMAN/exchange.domain.com) is properly registered.

Set up delegation on the account or computer object in AD to allow it to delegate credentials to the target service.

✅ 2. Use CredSSP

CredSSP allows credentials to be passed securely to the remote server.

Enable via Group Policy:
Computer Configuration → Administrative Templates → System → Credentials Delegation → Allow Fresh Credentials with NTLM-only Server Authentication

Enable via Group Policy: Computer Configuration → Administrative Templates → System → Credentials Delegation → Allow Fresh Credentials

Add the target server’s SPN to the allowed list.

✅ 3. Use HTTPS for WinRM

Configure WinRM to use a valid certificate.

This can help bypass some of the trust issues by validating the identity of the remote server.

So I am getting closer to the issue, but it is pointing to Server 2025 having stricter Kerberos enforcement defaults is my current path of troubleshooting.

Answer 5

Hin-V 14,175 Microsoft External Staff Moderator

Hi @Michael Lovett

Thank you very much for the detailed information you’ve shared, it’s greatly appreciated and helps us better understand the situation.

At this time, we are actively conducting a series of internal research to further investigate the issue. As this process involves multiple layers of configuration and synchronization between services, it may take a bit of time to ensure we’re covering all possible angles. Our goal is to be as thorough as possible so that we can provide you with accurate and effective support.

We completely understand how important this is for your environment, and we truly appreciate your patience while we work through it. Please rest assured that as soon as we have any findings or updates, I will get back to you immediately, you’ll be the first to know.

Thanks again for your cooperation and understanding. If there’s anything else you’d like to share in the meantime, feel free to reach out.

Hin-V 14,175 Reputation points Microsoft External Staff Moderator

2025-07-22T09:23:00.8033333+00:00
Hi @Michael Lovett

As my research, you could follow these steps to configure Exchange Management Shell to use HTTPS:

Disable the Serialization Payload Signing Feature (recommended as a first step, but note it reduces security—re-enable after testing):

Run in EMS:

New-SettingOverride -Name "DisableSigningVerification" -Component Data -Section EnableSerializationDataSigning -Parameters @("Enabled=false") -Reason "Troubleshooting Toolbox deserialization error"   Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh   Restart-Service -Name W3SVC, WAS –Force

You can refer via: Exchange Server certificate signing of PowerShell serialization payloads | Microsoft Learn

Close and reopen the Toolbox/EMS. This is for Exchange 2019/SE (post-November 2023 SU); for earlier configs, use Get-SettingOverride -Identity "EnableSigningVerification" | Remove-SettingOverride instead of New-SettingOverride.learn.microsoft.comblog.it-koehler.com

Install the Latest Security Update (SU): Download and apply the most recent Exchange SE SU from Microsoft (as of July 2025, check https://aka.ms/LatestExchangeServerUpdate). This has fixed similar deserialization issues in prior updates, such as those from March 2023.blog.it-koehler.comlearn.microsoft.com

Reinstall Management Tools:

If disabling doesn't help, repair or reinstall the Exchange Management Tools: Run Setup.exe /Mode:Repair /Roles:ManagementTools from the SE installation media (elevated prompt), then restart.

Verify Auth Certificate:

Ensure the Exchange Auth Certificate is valid:

Run Get-AuthConfig | Format-List CurrentCertificateThumbprint,PreviousCertificateThumbprint,NextCertificateThumbprint,NextCertificateEffectiveDate. If expired, renew with Set-AuthConfig -NewCertificateThumbprint <Thumbprint> -NewCertificateEffectiveDate (Get-Date) -Force and publish with Set-AuthConfig -PublishCertificate.learn.microsoft.com

HTTPS-Specific Tweaks:

If the failure only occurs with HTTPS enforced, temporarily disable RequireSSL (Set-PowerShellVirtualDirectory -Identity "Server\PowerShell (Default Web Site)" -RequireSSL $false), test, then re-enable and force HTTPS in Toolbox connections via custom scripts (e.g., modify ConnectionUri to https:// in RemoteExchange.ps1).

If these don't resolve it, check Event Viewer for detailed serialization logs at <ExchangeInstallPath>\V15\Logging\Data\Serialization, and consider Microsoft support with your upgrade details.

To troubleshoot more effectively, you could consider to reach out Microsoft support with your upgrade details, as they are best equipped to address and resolve this type of issue efficiently, you can follow the instructions here:  Get support - Microsoft 365 admin | Microsoft Learn. As forum moderator, we lack of detailed system needed and access to the backend diagnostic tools for such advanced analysis to troubleshoot this effectively. On this forum, we can only provide documentation and guidance to help you resolve issues effectively.

We hope this information is helpful and appreciate your understanding.

Feel free to contact me if you need further assistance.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Michael Lovett 5 Reputation points

2025-07-23T19:04:50.97+00:00

I will work through this and test, thank you for the response, will update.
Hin-V 14,175 Reputation points Microsoft External Staff Moderator

2025-07-25T13:16:03.05+00:00

Hi @Michael Lovett

Thank you for your responding.

Any update would be appreciated.

If there’s anything else you’d like to share in the meantime, feel free to reach out.

Warm thanks.

Share via

Exchange SE Management Shell & Toolbox HTTPS Connectivity Challenges (Post-Upgrade to Server 2025)

5 answers

Your answer