We have following error on Cloud Panel. The odd thing is that sometimes works, and sometimes don’t. Authetification is set to basic.
Error!
Connecting to remote server mail.domain.ba failed with the following error message : The server certificate on the destination computer (mail.domain.ba:443) has the following errors:
Encountered an internal error in the SSL library. For more information, see the about_Remote_Troubleshooting Help topic.
KMI Support 2016-09-21 08:55
Are you pointed to a load balancer? Also you may want to check the eventviewer on both servers because that error is being returned by the powershell commands CloudPanel runs which means Remote Powershell is having difficulty connecting.
I wasn’t replying because we were testing so many things. This is what we have discovered by now.
We are using http autorediscover method, and we added second local ip address to exchange for this method. By default, local DNS added second A record for second local ip address.
Now, when CloudPanel uses original local ip address for winrm, everything is ok, but when it uses second address (which is used for http redirect) connection fails. This is why sometimes is working, and sometimes isn’t.
We will try to resolve this by unticking “Register this connection’s addresses in DNS”, and by static adding only first local ip address in DNS.
Maybe Jacob can explain why is this happening.
KMI Support 2016-09-29 09:32
CloudPanel is going to do a DNS lookup. So if you are adding multiple IP addresses to your Exchange server for the autodiscover redirect method (not recommended), then you may be binding those IP addresses to websites in IIS. Which means when it gets the wrong IP (the autodiscover one) then it is going to the IIS website that doesn’t have the Powershell virtual directory.
We don’t have load balancer. When it stops working, we have following error on Cloud Panel server:
A fatal error occurred while creating an SSL client credential. The internal error state is 10013.
KMI Support 2016-09-22 08:04
CloudPanel doesn’t validate the SSL when it connects. I would first make sure both the CloudPanel server and the Exchange server are patched. Do you see SCHANNEL issues on the Exchange end also?
This morning, we patched Exchange 2016 to CU3, and all the windows are also fully patched.
Now we have this message:
Connecting to remote server mail.domain.ba failed with the following error message : The SSL connection cannot be established. Verify that the service on the remote host is properly configured to listen for HTTPS requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: “winrm quickconfig -transport:https”. For more information, see the about_Remote_Troubleshooting Help topic.
?
Winrm is running:
PS C:\Windows\system32> winrm quickconfig -transport:https
WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
?
KMI Support 2016-09-23 10:03
When you patch Exchange it resets the Basic Authentication flag on the /powershell virtual directory. Use ECP and enable it again. No idea why it resets but it ALWAYS resets with updates.
It is set on basic, but I still have the same error message.
KMI Support 2016-09-23 11:56
If you are getting that message then it cannot be set on basic. You need to use Exchange ECP to make sure it is set on Basic. Do not adjust this with IIS. See picture
?
?
Ok, that is perfect explanation. We moved autodiscover redirect site to different IIS server, and now it is working.
Jacob, why do you think autodiscover redirect method is not recommended? You prefer SRV records? Can you explain this a little bit?
KMI Support 2016-09-30 19:25
No the autodiscover redirect method is recommended because Outlook checks that before the SRV (SRV is last). What I was saying is its not recommended to use multiple IP’s like you were on Exchange because you could run into issues like you were experiencing if they all registered in DNS
Ok, now everything is fine. Thank you for your help, Jacob.
