User Profile
FrankPlawetzki
MicrosoftJoined Sep 07, 2016
User Widgets
Recent Discussions
TLS 1.2 is coming to Exchange on-premises using hybrid and free/busy might fail
This article is intended to help customers and motivate them to check their on-premises TLS settings. This spring, your on-premises users might not be able to do free/busy requests in calendaring from on-premises mailboxes towards Exchange online mailboxes. In addition, your on-premises Exchange servers might start logging events like this: Log Name: Application Source: MSExchange Availability Date: 17.03.2022 09:45:01 Event ID: 4001 Task Category: Availability Service Level: Error Keywords: Classic User: N/A Computer: server01.contoso.com Description: Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[System.String]: <User1@contoso.mail.onmicrosoft.com>SMTP:User1@contoso.mail.onmicrosoft.com failed in application Mailtips. Exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverFailedException: Autodiscover failed for email address User1@contoso.mail.onmicrosoft.com with error 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 The interesting parts of the event above are the following pieces of information: AutoDiscoverFailedException: Autodiscover failed and The underlying connection was closed: An unexpected error occurred on a send Since Autodiscover fails, let’s test it from the on-prem server and see if it can reach the server in Exchange online via Powershell: Invoke-WebRequest -Uri "https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc" On a non-working on-prem server, I get the result: The underlying connection was closed: An unexpected error occurred on a send. This error is unexpected, whereas this 401 would have been expected: This raises some suspicion, if the TLS settings on-premises are ok when the on-prem servers try to reach the servers in Exchange online. You can verify that your on-prem TLS settings are outdated, by forcing TLS 1.2 for the above test connection trying this Powershell call: [Net.ServicePointManager]::SecurityProtocol += [Net.SecurityProtocolType]::Tls12 Invoke-WebRequest -Uri "https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc" The result now as expect is: Invoke-WebRequest : The remote server returned an error: (401) Unauthorized. You now have proof that the TLS settings on-premises are outdated and your on-prem server not using TLS 1.2 prevents your server from connecting to the Exchange online servers. Microsoft hast announced in Messager Center Post MC240160 and here: Disabling TLS 1.0 and 1.1 for Microsoft 365 https://docs.microsoft.com/en-us/microsoft-365/compliance/tls-1.0-and-1.1-deprecation-for-office-365?view=o365-worldwide that we are enabling TLS 1.2 more and more in Exchange online starting October 2020 and now it affects more and more Exchange customers who so far have not enabled support for TLS 1.2 on-premises. Microsoft has announced the deprecation of TLS 1.0 and TLS 1.1 already in 2018. Those articles also contain detailed information on how you can enable TLS 1.2, which in short is only adding some registry keys and doing a reboot: Exchange Server TLS guidance, part 1: Getting Ready for TLS 1.2 Exchange Server TLS guidance Part 2: Enabling TLS 1.2 and Identifying Clients Not Using It Exchange Server TLS guidance Part 3: Turning Off TLS 1.0/1.1 As these articles above explain, you can enable TLS 1.2 in addition to your current usage of older TLS versions and solve your Free/Busy issue. Later, you can disable TLS 1.0 and 1.1 since they are not secure anymore. To prevent configuration errors like this, Microsoft recommends running the Exchange health checker on your on-premises Exchange servers on a regular basis, e.g. each month: https://aka.ms/ExchangeHealthCheckerError event “MSExchange Configuration Core” with ID no. 1 in the application event log every minute
I wanted to provide the solution to an issue I was troubleshooting this week. For some time now so, a whole bunch but not all of the Exchange 2016 servers were throwing this event: Log Name: Application Source: MSExchange Configuration Core Date: 29.11.2018 10:47:39 Event ID: 1 Task Category: (1) Level: Error Keywords: Classic User: N/A Computer: MBX2016.contoso.com Description: The description for Event ID 1 from source MSExchange Configuration Core cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event. The following information was included with the event: 29464 w3wp.exe Exception from CmdletHealthCountersModule.Task_Release: System.TypeInitializationException: The type initializer for 'Microsoft.Exchange.Configuration.TenantMonitoring.TenantMonitor' threw an exception. ---> System.InvalidOperationException: Cannot load Counter Name data because an invalid index '' was read from the registry. at System.Diagnostics.PerformanceCounterLib.GetStringTable(Boolean isHelp) at System.Diagnostics.PerformanceCounterLib.get_NameTable() at System.Diagnostics.PerformanceCounterLib.get_CategoryTable() at System.Diagnostics.PerformanceCounterLib.CategoryExists(String machine, String category) at System.Diagnostics.PerformanceCounterCategory.Exists(String categoryName, String machineName) at Microsoft.Exchange.Configuration.TenantMonitoring.TenantMonitor..cctor() --- End of inner exception stack trace --- at Microsoft.Exchange.Configuration.TenantMonitoring.TenantMonitor.LogActivity(CounterType counterType, String organizationName) at Microsoft.Exchange.ProvisioningMonitoring.PerTenantCmdletHealthCounters.UpdateSuccessCount(ErrorRecord errorRecord) at Microsoft.Exchange.Configuration.Tasks.CmdletHealthCountersModule.IncrementSuccessCount(ErrorRecord errorRecord) at Microsoft.Exchange.Configuration.Tasks.CmdletHealthCountersModule.Task_Release(Object sender, EventArgs e) at Microsoft.Exchange.Configuration.Tasks.CriticalFeatureHelper.Execute(ICriticalFeature feature, Action action, TaskContext taskContext, String methodNameInLog) the message resource is present but the message is not found in the string/message table Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="MSExchange Configuration Core" /> <EventID Qualifiers="49152">1</EventID> <Level>2</Level> <Task>1</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2018-11-29T09:47:39.941532000Z" /> <EventRecordID>9382221</EventRecordID> <Channel>Application</Channel> <Computer>MBX2016.contoso.com</Computer> <Security /> </System> <EventData> <Data>29464</Data> <Data>w3wp.exe</Data> <Data>Exception from CmdletHealthCountersModule.Task_Release: System.TypeInitializationException: The type initializer for 'Microsoft.Exchange.Configuration.TenantMonitoring.TenantMonitor' threw an exception. ---> System.InvalidOperationException: Cannot load Counter Name data because an invalid index '' was read from the registry. at System.Diagnostics.PerformanceCounterLib.GetStringTable(Boolean isHelp) at System.Diagnostics.PerformanceCounterLib.get_NameTable() at System.Diagnostics.PerformanceCounterLib.get_CategoryTable() at System.Diagnostics.PerformanceCounterLib.CategoryExists(String machine, String category) at System.Diagnostics.PerformanceCounterCategory.Exists(String categoryName, String machineName) at Microsoft.Exchange.Configuration.TenantMonitoring.TenantMonitor..cctor() --- End of inner exception stack trace --- at Microsoft.Exchange.Configuration.TenantMonitoring.TenantMonitor.LogActivity(CounterType counterType, String organizationName) at Microsoft.Exchange.ProvisioningMonitoring.PerTenantCmdletHealthCounters.UpdateSuccessCount(ErrorRecord errorRecord) at Microsoft.Exchange.Configuration.Tasks.CmdletHealthCountersModule.IncrementSuccessCount(ErrorRecord errorRecord) at Microsoft.Exchange.Configuration.Tasks.CmdletHealthCountersModule.Task_Release(Object sender, EventArgs e) at Microsoft.Exchange.Configuration.Tasks.CriticalFeatureHelper.Execute(ICriticalFeature feature, Action action, TaskContext taskContext, String methodNameInLog)</Data> </EventData> </Event> In the beginning of the exception the error states: “Either the component that raises this event is not installed on your local computer or the installation is corrupted" together with “Cannot load Counter Name” From the component mentioned in the event you can see that the component TenantMonitoring is affected. The Process ID 29464 mentioned on the server we checked belonged to PowerShell. In this environment the event was happening for some time and there was no inclusive action that could be linked to what caused the event to be thrown. TenantMonitoring is Exchange internally used for per tenant performance monitoring although on my test Exchange servers there was not performance counter with this name. I was not in a position to identify the root cause for this event, but the solution was as follows: The following article describes how to add information for a missing performance counter: "Performance counter updating error" after you install an Exchange Server 2013 cumulative update https://support.microsoft.com/en-us/help/2870416/performance-counter-updating-error-after-you-install-an-exchange-serve The procedure that stopped this event being thrown was: Close Performance Monitor, and then stop any other monitoring services that might be trying to use the missing counters. In Exchange Management Shell, type the following command, and then press Enter: Add-Pssnapin Microsoft.Exchange.Management.PowerShell.Setup Run New-PerfCounters to add the performance counter: New-perfcounters –definitionfilename “C:\Program Files\Microsoft\Exchange Server\V15\Setup\Perf\MSExchangeTenantMonitoringPerformanceCounters.xml" After adding this performance counter, you need to reboot the Exchange server, in order for the change to take effect.Unintended recipient getting added to sent email
This week, I was working on an issue that caused me to scratch my head. Issue was, user R (recipient) complained, that he started to receive e-mails from various senders he does not know and does not do business with. After checking some samples of e-mails from the sent items folder in the senders mailboxes, I realized, user R was in the To or Cc lines of the mails that were sent. Certainly, the issue happened infrequently and the senders varied. So, the golden question was, how did user R get onto the To or Cc lines on those mails. Similar issues are described here, e.g.: https://social.technet.microsoft.com/Forums/lync/en-US/fbd34bb5-442c-46c9-b131-7920b59f4722/unintended-recipient-getting-added-to-sent-email?forum=outlook https://answers.microsoft.com/en-us/msoffice/forum/msoffice_outlook-mso_win10-mso_365hp/outlook-2016-adding-unintended-recipients-to-my/18a13af0-e274-4db2-b5cd-5e82029eb2dd?auth=1 Thanks to my co-worker Rahul, who gave me the hint to check for incorrect AD properties of the recipient, and there it was: Get-ADUser UserR -Properties * […] ObjectClass : user ObjectGUID : cf55f28a-ce78-4078-b9e6-d2326b58257f otherTelephone : {,} […] The AD property otherTelephone contains the unexpected comma character. This customer has the otherTelephone property included in ANR resolution, so if a sender in Outlook mistakenly types the comma into the To or Cc field, it will get resolved against User Rs e-mail address. This totally explains the issue where the recipient user R unexpectedly got e-mails from people he does not do business with and was on the To or Cc lines in the senders Sent-Items.X-OWA-Error: Microsoft.Exchange.Diagnostics.ExAssertException and the Microsoft Exchange Server Auth
I used to blog at https://blogs.technet.microsoft.com/mspfe/ , but since that location has been deprecated, I want to share my learnings here in the TechCommunity. This week I was troubleshooting an issue on Exchange Server 2016 CU8 where OWA clients could not logon with error: X-OWA-Error: Microsoft.Exchange.Diagnostics.ExAssertException The error message is kind enough, to list the front-end and back-end servers being used in the request through the X-FEServer and X-BEServer property. Upon investigation, I realized that the “Microsoft Exchange Server Auth Certificate” was missing on the backend server. You can check if the certificate is available via this CmdLet: Get-ExchangeCertificate (Get-AuthConfig).CurrentCertificateThumbprint In case the CmdLet returns empty, the required certificate is missing. The back-end server in question was part of a whole bunch of servers in a new active directory site. All Exchange servers in this site were missing the “Microsoft Exchange Server Auth Certificate”. Usually the certificate deployment component in Exchange is responsible for copying the certificate over from other servers. The first Exchange 2013 or 2016 server usually provides the self-signed “Microsoft Exchange Server Auth Certificate” and it is replicated to other servers in the AD site. When you deploy the first Exchange 2013 or 2016 server into a new AD site, this copy of the certificate does not happen. Without checking for the root cause, it appears that the new server realizes, that a certificate is already available in the organization (This can be checked via Get-AuthConfig). Then the server is not able to copy the certificate over from another AD site. The mechanism for fixing the missing “Microsoft Exchange Server Auth Certificate” in general is explained here: Exchange Troubleshooting: Federation or Auth certificate not found https://social.technet.microsoft.com/wiki/contents/articles/34914.exchange-troubleshooting-federation-or-auth-certificate-not-found.aspx However, the steps provided above configure a whole new Auth configuration in the organization. I believe it is much more elegant to just add the available “Microsoft Exchange Server Auth Certificate” to the servers where it is missing. You just need to export the “Microsoft Exchange Server Auth Certificate” via MMC including the private key and import it into the machine certificate store on only one of the mailbox servers in the new AD site where it is missing. Within approximately an hour, the certificate deployment component will replicate it to the other Exchange servers in the new AD site and the problem will be solved. Hope, this is helpful
