Connect-ExchangeServer fails with input XML syntax error RRS feed

  • Question

  • Hi all,

    I have a freshly installed Exchange Server 2019 CU 2 Standard in a DAG cluster of three nodes. Two of them are running on hardware, one on VMware. The ones on hardware are working as intended, but on the VM, I cannot open the Exchange Management Shell with the infamous XML syntax error message described on

    I have already reinstalled Exchange on the VM and the problem persists.

    I have also recreated the Powershell virtual directory without any effect using Get-PowerShellVirtualDirectory -Server vm | Remove-PowerShellVirtualDirectory; New-PowerShellVirtualDirectory -Server vm -Name PowerShell ...

    I have compared the web.config of the Powershell directory on the VM with a working server and found no difference (except of the server name) except for an additional line break at the end of the file. Removing the line break has no effect.

    As the link above lists the system time as potential cause, I verified that (i) the VM and the other Exchange servers receive the time from the same NTP server (the domain controller) using w32tm /query /source, (ii) that time synchronisation with the hypervisor using VMware Tools is not enabled and that (iii) the time on the Exchange servers does not differ (to the extent it is possible to check this using the Get-Date command; the difference is two seconds that I need to switch between the RDP windows).

    Is there any other potential reason for that error? Is there any way to diagnose this except for the error message of the Connect-ExchanegServer command which is of limited use?

    Thanks in advance,

    Thursday, November 7, 2019 7:40 PM


All replies

  • Hi

    I assume you installed Exchange 2019 on Server 2019?

    Do you have enough resources assigned to the VM?

    Hope this helps. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, November 8, 2019 5:13 AM
  • Yes, the resources should be sufficient. I have minimum allocations well above what the system requirements say and fixed disk allocations on an all-flash RAID. The server OS is 2019 Datacenter. I can also see no problems with other services than the EMS. Databases, client access and hub transport seem to work without any issue.

    In the meantime, I have also checked the A, AAAA and PTR entries, because I found some other posts pointing towards DNS problems, but that did not change anything.

    Furthermore, I have upgraded from CU2 to CU3, but the problem persists, making me believe the issue is related to the server OS/WinRM and not to the Exchange application.

    Friday, November 8, 2019 8:59 AM
  • Hi Christoph,

    Please synchronize the time between the virtual machine and Exchange Servers. I did some research and found this blog may help you with your issue: Exchange Servers Running on VMware Time Sync Errors

    Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.

    If the issue persists, please check the Event Viewer. Some related event logs may be generated.


    Lydia Zhou

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact

    Friday, November 8, 2019 10:01 AM
  • Hi Lydia,

    thanks for the link. I have checked the time again and I am pretty sure that the servers are drifting at most a second if at all.

    Nevertheless, as the article mentioned Kerberos, I checked the event log for Kerberos-related issues and found an KRB_AP_ERR_MODIFIED on the problematic server. I think something might have gone wrong during the load balancer setup ( - need to check this in detail. I did not find the KRB_AP_ERR_MODIFIED for the working servers.

    Best regards,

    Friday, November 8, 2019 10:23 AM
  • I think I have fixed the SPN issue now (need to wait a bit to confirm, because the error occurs every hour), but it did not help.

    However, I was able to further narrow the issue by looking into what the EMS actually does. The problem is not related to Exchange and the Exchange services, but to Winrm and Powershell remoting. Enter-PSSession works for the two servers without EMS problem, but not for the problematic one. Interestingly, the error is not the same, but "Access denied".

    Friday, November 8, 2019 4:36 PM
  • Things are getting weird. If I call Enable-PsRemoting (which has no persistent effect, but only affects the current shell), I can successfully connect using Enter-PSSession. However, it does not work in other shells, although I would expect Enable-PSRemoting to have persistent effects.

    Furthermore, in the shell where Enter-PSSession works, the error of Connect-ExchangeServer changes to

    New-PSSession : [...] Beim Verbinden mit dem Remoteserver "..." ist folgender Fehler aufgetreten: [ClientAccessServer=...,BackEndServer=...,RequestId=f5b61da4-05ad-42b8-aa4c-82e4dca29785,TimeStamp=08.11.2019 16:48:58] Access Denied

    So the error is not the weird XML thing any more, but "access denied". Note: I use -UserName to provide Connect-ExchangeServer with Exchange admin credentials as Enable-PSRemoting requires an elevated shell.

    I therefore investigated the authentication settings of the PowerShell end points in IIS. Both "PowerShell" end points have no authentication enabled. The "PowerShell-Proxy" cannot display it, because of a configuration error in line 61. However, this error also occurs on the working servers. The line in question is on all servers <authentication mode="Windows" />. Is this configuration (and the effect that the IIS UI fails to display authentication methods) normal?

    Friday, November 8, 2019 5:00 PM
  • I finally got it. Using the location of the event logs for WinRM described on and the suggestion from to run

    Enter-PSSession -computername localhost -SessionOption(New-PSSessionOption -NoMachineProfile)

    I developed the idea that the problem was somehow related to my own user profile. I therefore tested another account, which worked, then deleted my own profile on the Exchange server, logged on - and it worked for me, too. Unfortunately, I do not know what the offending part of the profile was ...

    Friday, November 8, 2019 9:17 PM
  • It's great that your issue is resolved and thanks for your sharing. Here is a brief summary about this issue, hope more people can get help from your reply.

    Issue Symptom


    Exchange Server 2019 CU2 DAG with three nodes. Two of them are running on hardware, one on VMware. The ones on hardware are working as intended, but on the VM, cannot open the EMS with XML syntax error: "WinRM cannot process the request because the input XML contains a syntax error. For more information, see the about_Remote_Troubleshooting Help topic".

    Possible Cause


    The problem may be related to the user profile corruption.

    Test with another account and it worked well. Then deleted my own profile on the Exchange server and logged again. It worked this time.



    Use the following command:

    Enter-PSSession -computername localhost -SessionOption(New-PSSessionOption -NoMachineProfile)

    Reference Links


    Troubleshoot WinRM with PowerShell—Part 1

    WSMan operation CreateShell failed, error code 2150858770


    Lydia Zhou

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact

    Tuesday, November 12, 2019 11:02 AM