I was just made aware of a HP specific setting which has a huge impact on performance. But before you start panic, have a look at the conditions:
- you’re running Proliant Gen9 Servers
- these servers are equipped with Intel Xeon E5 2600v3 and higher processors
- you have the default setting for NUMA Group Size Optimization
If you’re not matching these conditions, you can stop reading and relax. If not….you might want to continue reading.
As mentioned before it affects not only Exchange. Credit goes to Nicholas, who highlighted the following KB for Lync/SfB:
Bug Check 0x133 DPC_WATCHDOG_VIOLATION error on Lync/Skype for Business Edge server
Another PFE made me aware that the script HealthChecker.ps1 is checking the setting by comparing the values EnvProcessorCount and NumberOfLogicalProcessors
With Exchange 2016 a huge improvement in regards of document collaboration with OneDrive for Business was introduced when you have a Hybrid configured.
You can read more about it here:
When I introduced Exchange 2016, I was more than happy to configure and make this feature available to my end-users. But after I run through the prerequisites and steps, I wasn’t able to get the option in OWA and with Outlook I received the following error:
The same happened when I was using Outlook for Mac. As different clients, protocols and servers where affected, I assumed a general issue and started troubleshooting.
Over the last months a lot of changes needed to be addressed. The script was intended to extract data from the IIS logs. With PowerShell in combination with LogParser it did a great job. But different versions of Exchange, changed infrastructure and multiple versions of Exchange ActiveSync protocol demanded an update to fulfill these needs.
The latest version focused on code improvement and added support for the new version of Exchange ActiveSync protocol v16.1 .
In a previous post here, I wrote about a few basic commands, which are useful to quickly gather information about transport component of an Exchange server.
In this post I want to give you a deep dive about it and how you can explore what the CmdLet can do for you as it evolves in each Exchange version and can be very useful.
Lately I installed my first DAG with Exchange 2016 CU3 in productive environment. In the beginning it went really smoothly. But after all databases have been created, I realized that databases got bounced around the nodes and a lot of errors in the Event Log like these:
Log Name: Application
Date: 12/14/2016 9:53:07 AM
Event ID: 1001
Task Category: General
Microsoft Exchange Server Information Store has encountered an internal logic error. Internal error text is (ProcessId perf counter does not match actual process id.) with a call stack of ( at Microsoft.Exchange.Server.Storage.Common.ErrorHelper.AssertRetail(Boolean assertCondition, String message)
at Microsoft.Exchange.Server.Storage.Common.Globals.AssertRetail(Boolean assertCondition, String message)
The store worker processes kept constantly crashing.
When it comes to the point to troubleshoot Exchange Web Services related issues, where do you start? When it’s related to F/B requests of Outlook there used to be some client-side logs available. Since Office 2013 not anymore, as these data are all moved into ETL files, which are encrypted. It can be also hard to troubleshoot a Mac client or even cross-org or Hybrid scenarios.
So how can you start troubleshooting?
Starting with Exchange 2010 you will find EWS related logs on the servers and you can easily parse them. The newer the Exchange version is the more information is logged.
A while ago I wrote the post Troubleshooting Exchange with LogParser:RCA logs, which describes how you can parse RCA logs using PowerShell and LogParser.
With the new protocol MAPI over HTTP also new kinds of logs were introduced. When it comes to connectivity or performance issues, those logs might help you to find the root cause.