Connector not working/Error

[Nathan-CPSD]

Good Day,

New issue that I have just started to take a look into, but wanted to be proactive and post here incase anyone has ran across it before. This issue started on Thursday of this last week and only one error is currently found in the logs.

Server has been rebooted, updates for the server was applied on 3/14 and connector was working up until Thursday afternoon. I verified that the account was authenticating to Azure with Success and still currently is.

Current connector version 3.1.0.9

Error:

System.Management.Automation.MethodInvocationException: Exception calling "Bind" with "2" argument(s): "The request failed. The underlying connection was closed: An unexpected error occurred on a send." ---> Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. The underlying connection was closed: An unexpected error occurred on a send. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)
at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)
--- End of inner exception stack trace ---
at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.WebServices.Data.EwsHttpWebRequest.Microsoft.Exchange.WebServices.Data.IEwsHttpWebRequest.GetResponse()
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)
--- End of inner exception stack trace ---
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ValidateAndEmitRequest(IEwsHttpWebRequest& request)
at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest1.Execute() at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder(FolderId folderId, PropertySet propertySet) at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder[TFolder](FolderId folderId, PropertySet propertySet) at CallSite.Target(Closure , CallSite , RuntimeType , Object , Object ) --- End of inner exception stack trace --- at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception) at System.Management.Automation.Interpreter.ActionCallInstruction2.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)

Any direction would be appreciated. If I find the error, I will also post the resolution.

Thank you and enjoy the day.

[AdhocAdam]

TLS perhaps?

[Nathan-CPSD]

Checking the additional details on the authentication for the account to Azure it is listing Legacy TLS as True.

[AdhocAdam]

If you throw this at the top of the connector script, you can enforce TLS 1.2

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Where specifically is this setting in Azure/365 you are referring to? I can certainly try my best to repro.

[Nathan-CPSD]

In Azure select the use that is used for the connector, Sign-in Logs (Under Activity). Select a sign-in to bring up the details pane. Ellipsis in the pane and select Additional Details if needed, it may be a header if your monitor allows. Under Additional Details it will list the TLS status.

[Nathan-CPSD]

The update to the connector script seems to have worked.

Thank you for the prompt response.

[AdhocAdam]

Most excellent!

If you want to avoid maintaining this between upgrades, you can enforce Windows to use TLS1.2 as the default so that way PowerShell uses it, rather than you having to declare it explicitly. It should go without saying, this is the kind of thing you'd want to test on the machine (e.g. a workflow server) to make sure there aren't some OTHER kind of dependencies on prior TLS versions.

Reference:

• https://www.reddit.com/r/SCSM/comments/q39mo3/scsm_exchange_connector_41_reply_creates_a_new/
• https://support.microsoft.com/en-us/topic/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-winhttp-in-windows-c4bd73d2-31d7-761e-0178-11268bb10392
• https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-client
• https://github.com/beowulf005/TLS-Config
• https://support.microsoft.com/en-us/topic/tls-1-2-protocol-support-deployment-guide-for-system-center-2016-58f3daa8-655e-e9e7-dafe-cbbd28203118