Released: December 2019 Quarterly Exchange Updates
Published Dec 17 2019 08:00 AM 54.3K Views

Today we are announcing the availability of quarterly servicing cumulative updates for Exchange Server 2016 and 2019. These updates include fixes for customer reported issues as well as all previously released security updates. 

Setup Now Requires .NET Framework 4.8

As previously announced .NET 4.8 is now required and enforced by setup with the updates released today.

Calculator Updates

Cumulative Update 4 includes a significant update to the Exchange 2019 sizing calculator.  After the initial re-work and optimization for Exchange 2019 previously delivered, we’ve updated some formulas based upon new Big Funnel performance data gathered from the O365 service and real-world customer experiences.  Version 10.3 of the calculator includes improvements to calculations and default settings which allow for better and smoother utilization of disk resources.

We’ve received feedback from customers that they’d like more information on constraints which impact system design, specifically disk resources.  Included in this update, is an indication on the Input worksheet will provide information as to whether the design is constrained by IOPs throughput or disk capacity.

Dec2019 CU Post Image 1.png

 

We’ve added additional explanatory messages when the calculator detects a setting conflict, made additional improvements in input performance and improved support for using manual/override configurations.  The Volume Design sheet had a complete re-work to improve the presentation and accuracy of the information being displayed to support these changes.

All-in-all, this version of the calculator provides the best possible experience to plan your Exchange 2019 deployment and replaces all previous releases.

Address Book Policy Changes

When organizations deploy Address Book Policies to users they can sometimes hit an issue when a locally logged in user without a mailbox tries to open a mailbox linked to another user account using Outlook. This conflict results in ABP’s being inconsistently applied.

The updates released today contain a change detailed in KB4532747 which resolves this issue and ensures the ABP’s assigned to the mailbox being opened are always used.

Release Details

The KB articles that describe the fixes in each release and product downloads are available as follows:

Additional Information

Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate documentation.

Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.

Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the currently supported cumulative update for the product version in use, e.g., 2013 Cumulative Update 23; 2016 Cumulative Update 15 or 14; 2019 Cumulative Update 4 or 3.

For the latest information on Exchange Server and product announcements please see What's New in Exchange Server and Exchange Server Release Notes.

Note: Documentation may not be fully available at the time this post is published.

The Exchange Team

25 Comments
Brass Contributor

Thanks guys, just a hint the KB is still showing .NET 4.72 as a prereq while it should be 4.8 by reading this Blog post

Copper Contributor

@The_Exchange_Team has released update about disk capacity that which i needed. Thanks

@Martin_Aigner good catch Martin. All fixed now. 

Copper Contributor

Another update without DKIM and DMARC support on-premises. 

Brass Contributor

Hello,

I updated my test exchange server from CU14 to CU15 . No issue for the exchange mailbox and cas server but big issues on the edge exchange server .

I raised a ticket to the premier support

It's failing at step 10 of 12 : Edge Transport Role

 

[12/19/2019 10:34:11.0256] [2] [WARNING] The performance counter definition file C:\Program Files\Microsoft\Exchange Server\V15\Bin\Perf\AMD64\ItemAssistantPerfCounters.xml could not be found.
Parameter name: DefinitionFileName
[12/19/2019 10:34:11.0256] [2] The performance counter definition file is invalid.
[12/19/2019 10:34:11.0256] [2] [WARNING] The performance counter definition file is invalid.
[12/19/2019 10:34:11.0256] [2] [WARNING] The performance counter definition file is invalid.
[12/19/2019 10:34:11.0272] [2] Ending processing new-perfcounters
[12/19/2019 10:34:11.0272] [1] The following 1 error(s) occurred during task execution:
[12/19/2019 10:34:11.0272] [1] 0. ErrorRecord: The performance counter definition file is invalid.
[12/19/2019 10:34:11.0272] [1] The previous errors were generated by a non-critical task and will be ignored.
[12/19/2019 10:34:11.0272] [1] Setup will continue processing component tasks...
[12/19/2019 10:34:11.0272] [1] Processing component 'ADAM Configuration' (Configuring the local AD LDS instance.).
[12/19/2019 10:34:11.0272] [1] Executing:
install-AdamSchema -LdapFileName ($roleInstallPath + "\Setup\Data\schemaadam.ldf")


[12/19/2019 10:34:11.0272] [2] Active Directory session settings for 'install-AdamSchema' are: View Entire Forest: 'True',
[12/19/2019 10:34:11.0272] [2] User specified parameters: -LdapFileName:'C:\Program Files\Microsoft\Exchange Server\V15\\Setup\Data\schemaadam.ldf'
[12/19/2019 10:34:11.0272] [2] Beginning processing install-AdamSchema
[12/19/2019 10:34:11.0272] [2] Running <C:\windows\ADAM ldifde.exe> with arguments <-i -f "C:\Program Files\Microsoft\Exchange Server\V15\\Setup\Data\schemaadam.ldf" -s localhost:50389 -j "C:\Users\edgetest\AppData\Local\Temp\1f15ef97-9aaa-4fcc-a23a-415df29873f5" -c "<SchemaContainerDN>" "#schemaNamingContext">.
[12/19/2019 10:34:12.0334] [2] Process ldifde.exe has finished with exit code 8224.
[12/19/2019 10:34:12.0334] [2] [ERROR] The AD LDS schema import process ldifde.exe failed with error code 8224. No schema has been imported into AD LDS. View the Setup logs for more information.
[12/19/2019 10:34:12.0334] [2] [ERROR] The AD LDS schema import process ldifde.exe failed with error code 8224. No schema has been imported into AD LDS. View the Setup logs for more information.
[12/19/2019 10:34:12.0334] [2] Ending processing install-AdamSchema
[12/19/2019 10:34:12.0334] [1] The following 1 error(s) occurred during task execution:
[12/19/2019 10:34:12.0334] [1] 0. ErrorRecord: The AD LDS schema import process ldifde.exe failed with error code 8224. No schema has been imported into AD LDS. View the Setup logs for more information.
[12/19/2019 10:34:12.0334] [1] 0. ErrorRecord: Microsoft.Exchange.Management.Edge.SetupTasks.AdamSchemaImportProcessFailureException: The AD LDS schema import process ldifde.exe failed with error code 8224. No schema has been imported into AD LDS. View the Setup logs for more information.
at Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
at Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
at Microsoft.Exchange.Management.Edge.SetupTasks.InstallAdamSchemaTask.InternalProcessRecord()
at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__91_1()
at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)
[12/19/2019 10:34:12.0334] [1] [ERROR] The following error was generated when "$error.Clear();
install-AdamSchema -LdapFileName ($roleInstallPath + "\Setup\Data\schemaadam.ldf")

" was run: "Microsoft.Exchange.Management.Edge.SetupTasks.AdamSchemaImportProcessFailureException: The AD LDS schema import process ldifde.exe failed with error code 8224. No schema has been imported into AD LDS. View the Setup logs for more information.
at Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
at Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
at Microsoft.Exchange.Management.Edge.SetupTasks.InstallAdamSchemaTask.InternalProcessRecord()
at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__91_1()
at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)".
[12/19/2019 10:34:12.0334] [1] [ERROR] The AD LDS schema import process ldifde.exe failed with error code 8224. No schema has been imported into AD LDS. View the Setup logs for more information.
[12/19/2019 10:34:12.0334] [1] [ERROR-REFERENCE] Id=AdamComponent___3dc0bdb578114784859fe9bf9663d1f3 Component=EXCHANGE14:\Current\Release\Shared\Datacenter\Setup
[12/19/2019 10:34:12.0334] [1] Setup is stopping now because of one or more critical errors.
[12/19/2019 10:34:12.0334] [1] Finished executing component tasks.
[12/19/2019 10:34:12.0350] [1] Ending processing Install-GatewayRole
[12/19/2019 10:34:24.0537] [0] CurrentResult setupbase.maincore:396: 0
[12/19/2019 10:34:24.0537] [0] End of Setup
[12/19/2019 10:34:24.0537] [0] **********************************************

Brass Contributor

Issue of the update CU15 on the edge server is fixed

We verified the connectivity on port 50389 : OK

We force from the exchange mailbox server a edge synchronization

 

Start-EdgeSynchronization -ForceUpdateCookie
Start-EdgeSynchronization -ForceFullSync
Test-EdgeSynchronization

 

Wait a few minutes and restart the CU15 update . Then it was fine

Iron Contributor
Hello Microsoft, What is Microsoft s recommended procedure to upgrade Exchange 2016 CU12 servers running .NET 4.7.2, keeping in mind that CU12 does not support .NET 4.8 and CU15 does not support .NET 4.7.2 ? i.e. in what exact order should we upgrade these two components? Thanks
Brass Contributor

Trying to upgrade an installation of Exchange 2019 Management Tools from CU3 to CU4 on Windows 10 1909 fails at the prerequisite analysis with "This computer requires .NET Framework 4.8". Installing the management tools on 64-bit Windows 10 is supposed to be supported, and obviously .NET Framework 4.8 is built into 1903 and 1909. How are you supposed to get past this (presumably defective) check? What is it checking?

Copper Contributor

CU4 fails to install with:

Error:
This computer requires .NET Framework 4.8 (https://support.microsoft.com/kb/4503548).
For more information, visit: https://docs.microsoft.com/Exchange/plan-and-deploy/system-requirements?view=exchserver-2019

 

But .net 4.8 is already installed on Windows Server Core Version 10.0.18362.535

Copper Contributor

Exchange Calculator 10.3
In my testing I noticed that the capacity-based results seemed a bit off for what I was looking to do and (u
nless I am missing something) it appears related to the math used to determine the database disk capacity requirements when utilizing mailbox tiers. When compared to older versions of the calculator, I don't see the ratio for the tiered mailbox configuration being applied properly.


In order to more easily explain what I am seeing, I have created a quick (1.5 minute) video of my experience:


https://www.youtube.com/watch?v=tjNSmudDlUc

I leave plenty room to be incorrect here...That said, it does seem to work as expected when averaging those tiers out manually ahead of time and utilizing a single tier in the calculator.

Copper Contributor

Same problem as Neil above. Existing installation of management tools, exchange 2019 CU3 on Windows 10 Pro 1909. Upgrade fails prereq check demanding dot net 4.8. The dot net 4.8 web installer refuses to install claiming an equivalent or later version is already installed. Catch-22. Same failure whether you use the GUI setup or command line /m:upgrade option. I don't see any way around this. Hopefully we can continue to use the management tools from CU3. Not updating the management tools has been a problem in the past.

Brass Contributor

To answer my own question: the prerequisite check for the .NET Framework looks at the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full. On Windows 10 1903 and 1909 the value is 528040, on all other versions of Windows it is 528049 (https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-ar...). If you change the key on 1909 to 528049 the check passes and upgrade / installation of the management tools on Windows 10 1909 succeeds. Obviously you then change it back again.

Copper Contributor

In this article, Cumulative Update 23 is the only CU listed as a supported environment for a hybrid deployment (with Exchange Server 2013). I was hoping that CU22 was also still a valid CU for a hybrid deployment.

 

So, do I understand it correct that the statement that "the most current or the prior Cumulative Update" in a hybrid deployment is no longer valid for Exchange Server 2013?

 

Did I miss something?

Iron Contributor
The silence is deafening.

@Sam_T 
When upgrading Exchange from an unsupported CU to the current CU and no intermediate CUs are available, you should first upgrade to the latest version of .NET that's supported by Exchange and then immediately upgrade to the current CU. This method doesn't replace the need to keep your Exchange servers up to date and on the latest supported CU. Microsoft makes no claim that an upgrade failure will not occur using this method, which may result in the need to contact Microsoft Support Services.

 

https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019

Copper Contributor

for me I had the same problem with .NET 4.8 prerequisite check. I changed the registry setting Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\Release from 528040 to 528049 as suggested by Neil_Flanagan. The setup can then be run. (I had permission issue with the registry key since only the TrustInstaller has write permission and it was the owner. So I needed to change the owner and then to grant myself to have write permission)

Copper Contributor

@Olivier Debonne , If CU23 is the final CU issued for Exchange 2013 and it's been more than three months since CU23 was issued, then it makes sense that you need to be on that release for support in a hybrid environment.  CU22 being more than six months old would have fallen off by now.

Copper Contributor

Can you please add a SHA256 hash for the Exchange 2013 and 2016 CU ISO downloads?  Cumulative Update CU15 for Exchange Server 2016 (KB4522150) at https://www.microsoft.com/en-us/download/details.aspx?id=100780 lacks this information, and I'm not sure I have a valid download of entire 6.6 GB file ExchangeServer2016-x64-CU15.ISO.

Brass Contributor

@The_Exchange_Team, it looks like a feature that became broken in CU14 is still broken in CU15.  The eDiscovery PST export tool still throws a "FailedToLoadStatus" error.  The fix that finally worked for us is described in the comments at the following page (note that it's a different Robert, not me) : https://eightwone.com/2019/11/13/security-updates-exchange-2013-2019/

 

For an Exchange admin, it's not such a big deal perhaps to copy DLLs from an earlier, working version of the export tool.  But it's the legal folks that run the tool in some organizations and they may not be so technical.  Note: I also tried wiping out my Windows profile on a 2012 R2 server that was throwing the error and that didn't help.  I had to copy the old DLL to get relief.  I hope this can be fixed in the next CU.

Copper Contributor

After 2016 CU15 unable to fix the unheathy status:

 

Server State Name TargetResource HealthSetName AlertValue ServerComponent
------ ----- ---- -------------- ------------- ---------- ---------------

Server1 NotApplicable MaintenanceFailureMonitor.OLS User Store - Query OLS User Store - Query Unhealthy None

 

>Get-ServerHealth -HealthSet "OLS User Store - Query" -Server Server1 | Format-List

RunspaceId : 522ba05e-d5f7-44cc-9022-593a22cee5d0
Server : Server1
CurrentHealthSetState : NotApplicable
Name : MaintenanceFailureMonitor.OLS User Store - Query
TargetResource :
HealthSetName : OLS User Store - Query
HealthGroupName : ServiceComponents
AlertValue : Unhealthy
FirstAlertObservedTime : 16.03.2020 12:27:52
Description :
IsHaImpacting : False
RecurranceInterval : 300
DefinitionCreatedTime : 16.03.2020 12:08:16
HealthSetDescription :
ServerComponentName : None
LastTransitionTime : 16.03.2020 12:27:52
LastExecutionTime : 16.03.2020 13:12:53
LastExecutionResult : Succeeded
ResultId : 482515544
WorkItemId : 2033339796
IsStale : False
Error :
Exception :
IsNotified : False
LastFailedProbeId : -274855559
LastFailedProbeResultId : 128480061
ServicePriority : 0
Identity : OLS User Store - Query\MaintenanceFailureMonitor.OLS User Store - Query\
IsValid : True
ObjectState : New


EVENT Viewer: Microsoft-Exchange-ManagedAvailability/Monitoring
Maintenance workitem "OlsQuery.Maintenance.Workitem" (ID: 2045954113) has failed. Health Manager has detected it is either set to run once and failed, or has been failing consistently. Maintenance workitem failure could cause monitoring gap and should be investigated.
The error message from the last result is:
System.FormatException: Input string was not in a correct format.
at System.Number.ParseDouble(String value, NumberStyles options, NumberFormatInfo numfmt)
at System.Double.Parse(String s)
at Microsoft.Office.Datacenter.Monitoring.ActiveMonitoring.Recovery.AttributeHelper.GetAttribute[T](Dictionary`2 attributes, String attributeName, Boolean isMandatory, T defaultValue, Func`2 parseMethod)
at Microsoft.Office.Datacenter.Monitoring.ActiveMonitoring.Recovery.AttributeHelper.GetAttribute[T](String attributeName, Boolean isMandatory, T defaultValue, Func`2 parseMethod)
at Microsoft.Office.Datacenter.Monitoring.ActiveMonitoring.Recovery.AttributeHelper.GetDouble(String attributeName, Boolean isMandatory, Double defaultValue, Nullable`1 minimum, Nullable`1 maximum)
at Microsoft.Exchange.Monitoring.ActiveMonitoring.Local.OlsQuery.FailureRateProbeSettings..ctor(WorkDefinition workDefinition, String prefix)
at Microsoft.Exchange.Monitoring.ActiveMonitoring.Local.OlsQuery.FailureRateProbe.AddWorkDefinitions(MaintenanceWorkItem maintenanceWorkItem)
at Microsoft.Exchange.Monitoring.ActiveMonitoring.OlsQuery.OlsQueryDiscovery.CreateMonitoringContexts(LocalEndpointManager endpointManager)
at Microsoft.Exchange.Monitoring.ActiveMonitoring.OlsQuery.OlsQueryDiscovery.DoWork(CancellationToken cancellationToken)
at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Office.Datacenter.WorkerTaskFramework.WorkItem.<ExecuteAsync>d__b.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Office.Datacenter.WorkerTaskFramework.WorkItem.<StartExecutingAsync>d__7.MoveNext()

@stennukas - I've checked with a few people and we're not familiar with this one - please open a support case. 

Copper Contributor

When i tried upgraded Exchange 2016 CU 10 to CU15, i am getting below error and hanged in the 7th stage. Can please get the cause of this error.

 

Below i specified the setup log.

 

[03/12/2020 13:35:39.0279] [2] Beginning processing Write-ExchangeSetupLog
[03/12/2020 13:35:39.0279] [2] [ServiceControl.ps1] (0) Starting WinMgmt...
[03/12/2020 13:35:39.0280] [2] Ending processing Write-ExchangeSetupLog
[03/12/2020 13:35:39.0280] [2] Active Directory session settings for 'start-SetupService' are: View Entire Forest: 'True', Configuration Domain Controller: 'DC.***.**', Preferred Global Catalog: 'DC.***.**', Preferred Domain Controllers: '{ DC.***.** }'
[03/12/2020 13:35:39.0281] [2] User specified parameters: -ServiceName:'WinMgmt' -ErrorVariable:'script:serviceControlError' -IgnoreTimeout:'True'
[03/12/2020 13:35:39.0281] [2] Beginning processing start-setupservice
[03/12/2020 13:35:39.0282] [2] Ending processing start-setupservice
[03/12/2020 13:35:39.0283] [2] Beginning processing Write-ExchangeSetupLog
[03/12/2020 13:35:39.0283] [2] [ServiceControl.ps1] (0) Exit: RestoreServiceAndDependents 'WinMgmt'
[03/12/2020 13:35:39.0284] [2] Ending processing Write-ExchangeSetupLog
[03/12/2020 13:35:39.0287] [2] Beginning processing Write-ExchangeSetupLog
[03/12/2020 13:35:39.0288] [2] [ServiceControl.ps1] Script completed succesfully.
[03/12/2020 13:35:39.0288] [2] Ending processing Write-ExchangeSetupLog
[03/12/2020 13:35:39.0291] [1] The following 1 error(s) occurred during task execution:
[03/12/2020 13:35:39.0293] [1] 0. ErrorRecord: Unexpected end of file has occurred. The following elements are not closed: Objs. Line 28254, position 9.
[03/12/2020 13:35:39.0293] [1] 0. ErrorRecord: System.Xml.XmlException: Unexpected end of file has occurred. The following elements are not closed: Objs. Line 28254, position 9.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.ThrowUnclosedElements()
at System.Xml.XmlTextReaderImpl.ParseElementContent()
at System.Xml.XmlReader.ReadEndElement()
at System.Management.Automation.InternalDeserializer.ReadPSObject()
at System.Management.Automation.InternalDeserializer.ReadOneDeserializedObject(String& streamName, Boolean& isKnownPrimitiveType)
at System.Management.Automation.InternalDeserializer.ReadOneObject(String& streamName)
at System.Management.Automation.Deserializer.Deserialize(String& streamName)
at Microsoft.PowerShell.Commands.ImportXmlHelper.Import()
at Microsoft.PowerShell.Commands.ImportClixmlCommand.ProcessRecord()
at System.Management.Automation.CommandProcessor.ProcessRecord()
[03/12/2020 13:35:39.0299] [1] [ERROR] The following error was generated when "$error.Clear();
& $RoleBinPath\ServiceControl.ps1 EnableServices $RoleRoles.Replace('Role','').Split(',') -IsDatacenter:([bool]$RoleIsDatacenter) -IsMSMessageTracingClientEnabled:([bool]$RoleDatacenterFfoMessageTraceServiceEnabled)
& $RoleBinPath\ServiceControl.ps1 Start Critical -IsDatacenter:([bool]$RoleIsDatacenter)
" was run: "System.Xml.XmlException: Unexpected end of file has occurred. The following elements are not closed: Objs. Line 28254, position 9.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.ThrowUnclosedElements()
at System.Xml.XmlTextReaderImpl.ParseElementContent()
at System.Xml.XmlReader.ReadEndElement()
at System.Management.Automation.InternalDeserializer.ReadPSObject()
at System.Management.Automation.InternalDeserializer.ReadOneDeserializedObject(String& streamName, Boolean& isKnownPrimitiveType)
at System.Management.Automation.InternalDeserializer.ReadOneObject(String& streamName)
at System.Management.Automation.Deserializer.Deserialize(String& streamName)
at Microsoft.PowerShell.Commands.ImportXmlHelper.Import()
at Microsoft.PowerShell.Commands.ImportClixmlCommand.ProcessRecord()
at System.Management.Automation.CommandProcessor.ProcessRecord()".
[03/12/2020 13:35:39.0299] [1] [ERROR] Unexpected end of file has occurred. The following elements are not closed: Objs. Line 28254, position 9.
[03/12/2020 13:35:39.0306] [1] [ERROR-REFERENCE] Id=AllRolesPostFileCopyComponent___59d55cd8c5a3413c9831d20dd2178f39 Component=EXCHANGE14:\Current\Release\Shared\Datacenter\Setup
[03/12/2020 13:35:39.0306] [1] Setup is stopping now because of one or more critical errors.
[03/12/2020 13:35:39.0306] [1] Finished executing component tasks.
[03/12/2020 13:35:39.0327] [1] Ending processing Start-PostFileCopy

Copper Contributor

Hi all,

 

Please let me where can I download Exchange Calculator 10.3?  Thanks.

Copper Contributor

@stennukas were you able to resolve the issue "Maintenance workitem "OlsQuery.Maintenance.Workitem" (ID: 2045954113) has failed..."? We also got the same error today. Hope someone can help us. Thanks.

 

Copper Contributor

Unfortunately, no, I do not know what part to troubleshoot or what does this error indicates. Servers and all systems running normal as before but I assume if everything is okay there should be no errors or indications to "unhealthy" status that’s why it is a bug or needs more explanation what should I be looking.

 

Version history
Last update:
‎Dec 16 2019 11:38 AM
Updated by: