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

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.

I will work through this and test, thank you for the response, will update.

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.

Thank You, you have given me a lot, and I will verify with you the details and success.

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.

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.

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.