Adaxes and Exchange in a multi-forest environment

Question

Hello! I have an environment with three separate forests. One has Exchange 2010, the second has Exchange 2013 and the third has Exchange 2016. These environments don't have a trust relationship with each other, but they do all have a trust relationship with a fourth domain. The fourth domain is where the Adaxes server resides and that is also where the service account was created. The service account was added to the built-in Administrators group for each forest. I also have an account in each forest that I used to bind the domains, that account is a domain admin and an organization admin.

The forest with Exchange 2010 works fine, I can see all the Exchange properties. However, I get WinRM errors with the Exchange 2013 and 2016 servers in the other two forests.

My understanding is that Adaxes uses the account that the domain is bound with to access the Exchange properties. If that is the case, then why isn't it working? The account that those domains are bound with definitely has permissions. I thought perhaps that it was trying to use the service account instead so I created a linked Exchange group so I could grant a foreign account permissions but that still didn't work.

I can confirm that I can remote powershell to the Exchange servers if I use explicit credentials.

If I put the Adaxes server in the same forest as the 2013 or 2016 Exchange environments, then it works fine for the forest that it's in.

We don't have an internal CA.

Somebody please help me because I feel like I"m going crazy.

Comments

Hello,

Your assumption is correct. Adaxes uses the account that the domain was registered with to access Exchange properties. Can you post here the WinRM message you get? You can remove the server names etc, we need just the error message.

Also, can you clarify on this:

I can confirm that I can remote powershell to the Exchange servers if I use explicit credentials.

Did you try to remote PowerShell from your own computer or from the server where your Softerra Adaxes Service is installed? Can you repeat the test from the computer where Adaxes Service runs?

Also, how many Exchange Servers do you have in those forests? Did you try connecting to all the servers?

As far as we can judge by the behavior you describe, WinRM cannot establish a secure (HTTPS) connection to the Exchange Servers in the external forests. Since you stated that:

If I put the Adaxes server in the same forest as the 2013 or 2016 Exchange environments, then it works fine for the forest that it's in.

The only difference between connecting in the same forest and across forest boundaries is that within the same forest WInRM uses HTTP, while for connection to external forests, the HTTPS protocol is used.

---

Did you try to remote PowerShell from your own computer or from the server where your Softerra Adaxes Service is installed? Can you repeat the test from the computer where Adaxes Service runs?

Yes, I was able to remote powershell from the server where the Adaxes service is installed. We have 24 Exchange servers in the second forest. The third forest is a new environment and currently only has 2 Exchange servers.

Here are the error messages in the Exchange Powershell Trace for the second forest:

 Selecting an Exchange server for the organization 'forest2.local'.  
 Connected to Failed to connect to the following Exchange servers:  
 CUST-EXARCH01: Unable to connect to Exchange server CUST-EXARCH01.forest2.local. The WS-Management service cannot process the request because the XML is invalid.   
 CUST-EXARCH01: Unable to connect to Exchange server CUST-EXARCH01.forest2.local. The WS-Management service cannot process the request because the XML is invalid.   
 CUST-EXARCH01: Unable to connect to Exchange server CUST-EXARCH01.forest2.local. The WS-Management service cannot process the request because the XML is invalid.   
 CUST-MBDAG05: Unable to connect to Exchange server CUST-MBDAG05.forest2.local. The WS-Management service cannot process the request because the XML is invalid.   
 FOREST2-CAS05: Connecting to remote server failed with the following error message : The WinRM client received an HTTP bad request status (400), but the remote service did not include any other information about the cause of the failure. For more information, see the about\_Remote\_Troubleshooting Help topic.  
 To view errors returned by other Exchange servers see Adaxes Event Log..

Here are the messages from forest 3:

 Get-UMMailboxPolicy  
 Error: Failed to connect to the following Exchange servers:  
 TRIEA-VMBX02: Unable to connect to Exchange server TRIEA-VMBX02.forest3.local. The WS-Management service cannot process the request because the XML is invalid.   
 TRIEA-VMBX01: Unable to connect to Exchange server TRIEA-VMBX01.forest3.local. The WS-Management service cannot process the request because the XML is invalid.

I am running Adaxes 2016 3.7.13430.0 on Server 2016

---

Such an error (The WS-Management service cannot process the request because the XML is invalid.) usually occurs when an Exchange Server replies to a WInRM request with an HTML-formatted error code instead of a valid XML response. Can you check Event Logs on the Exchange Servers mentioned in the error messages? There should be detailed error/warning messages explaining the issue.

---

Ok! I found the following error message on CUST-EXARCH01 which is the first server in the second forest that it tries to connect to:

 Event code: 3005   
 Event message: An unhandled exception has occurred.   
 Event time: 1/11/2018 2:18:23 PM   
 Event time (UTC): 1/11/2018 10:18:23 PM   
 Event ID: 639544a2e7c4471b937f43411be1b303   
 Event sequence: 32648   
 Event occurrence: 9302   
 Event detail code: 0   

 Application information:   
  Application domain: /LM/W3SVC/1/ROOT/PowerShell-1-131277001476601106   
  Trust level: Full   
  Application Virtual Path: /PowerShell   
  Application Path: C:\\Program Files\\Microsoft\\Exchange Server\\V15\\ClientAccess\\PowerShell\\   
  Machine name: CUST-EXARCH01   

 Process information:   
  Process ID: 1712   
  Process name: w3wp.exe   
  Account name: NT AUTHORITY\\SYSTEM   

 Exception information:   
  Exception type: NullReferenceException   
  Exception message: Object reference not set to an instance of an object.  
  at Microsoft.Exchange.Configuration.Core.WindowsIdentityToGenericIdentityModule.OnAuthenticateRequest(Object source, EventArgs e)  
  at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()  
  at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)  



 Request information:   
  Request URL: [https://cust-exarch01.forest2.local:443 ... ersion=2.0](https://cust-exarch01.forest2.local:443/PowerShell?PSVersion=2.0)   
  Request path: /PowerShell   
  User host address: 10.109.0.104   
  User:   
  Is authenticated: False   
  Authentication Type:   
  Thread account name: NT AUTHORITY\\SYSTEM   

 Thread information:   
  Thread ID: 6   
  Thread account name: NT AUTHORITY\\SYSTEM   
  Is impersonating: False   
  Stack trace: at Microsoft.Exchange.Configuration.Core.WindowsIdentityToGenericIdentityModule.OnAuthenticateRequest(Object source, EventArgs e)  
  at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()  
  at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)  


 Custom event details:

---

Hello,

The error message is very generic and does not provide much detail. In the first turn, we would suggest re-creating the Exchange PowerShell virtual directory as detailed in this thread on Technet forums. If that doesn't help, try posting the issue on Microsoft forums.

---

I'm getting this error from a bunch of the Exchange servers. They can't all be wrong, can they? Like I said...there are 24 in the second forest.

Answer 1

Hello,

After a closer look into your issue, we've found that it might be a certificate issue. As we discovered in this thread, there is a common issue where Exchange deletes client certificates or binds an incorrect certificate during upgrades. This can result in an issue as you describe. Also, this can account for the difference in behavior when Adaxes and Exchange are in the same forest and when they are in different forests. When Adaxes and Exchange are within the same forest, the HTTP protocol is used, and it doesn't matter whether a certificate is present and valid. When they are in different forests, the HTTPS protocol is used, which requires a valid certificate to establish a connection.

To check this:

1. On one of the failing Exchange Servers, launch the Internet Information Services (IIS) Manager from Control Panel \ Administrative Tools.
2. Expand your server node, then expand Sites and select the Exchange Back End site.
3. In the right view pane, click Bindings.
   
4. Select the https binding on port 444, and then click Edit.
   
5. Make sure that the Microsoft Exchange certificate is selected.
6. Click the View button associated with the SSL certificate field and make sure that the certificate is valid and not expired.