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 0

📝 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!

2 answers

Your answer

Answer 1

Hin-V 3,015 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 3,015 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 0 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 3,015 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.

Answer 2

Michael Lovett 0

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 3,015 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 0 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 3,015 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 3,015 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 0 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 3,015 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 0 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 3,015 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 3,015 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 0 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.

Share via

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

2 answers

Your answer