https://docs.microsoft.com/archive/blogs/dannypexchange/feed.xml Just another Exchange guys' site Tue, 16 Apr 2019 04:59:06 GMT en-US hourly 1 https://docs.microsoft.com/archive/blogs/dannypexchange/outbound-mail-queued-up-at-edge-server-with-451-4-4-0-dns-query-failed Thu, 05 Apr 2018 20:03:13 GMT https://blogs.msdn.microsoft.com/dannypexchange/?p=75 LastError: {LED=451 4.4.0 DNS query failed. The error was: DNS query failed with error ErrorRetry -> DnsQueryFailed This was for all external domains we got the DNS query failure.  We verified via nslookup that we were able to resolve external domains MX records just fine, so there wasn't an issue with the DNS servers we had configured.  The issue turned out to be because of one simple (advanced) setting on the NIC "Register this connection's addresses in DNS". After we checked this setting we were able to successfully resolve MX records and send outbound mail! Now you may be asking why this would be the case, when clearly we are able to resolve DNS records with our configured DNS servers?  My theory is that this is due to the Exchange 2013/2016 code design differences that we had in Exchange 2010.  For instance, in Exchange 2010, this was just a checkbox for the DAG Network in the EMC if you wanted a network to be mapi/replication enabled or not.  When managing your DAG networks in Exchange 2013/2016, Exchange sees networks as "Replication Enabled" when the same "Register this connection's addresses in DNS" option is checked on the NIC or not.  If it's checked to register in DNS, Exchange thinks "oh this is a resolvable NIC address, this must be a MAPI network", and if it's not a registered DNS address, then we are probably using this for replication traffic, and it's not a client-accessible network.  My theory is that Transport uses this same logic for when it tries to do MX lookups for external domains.  If the NIC isn't registered in DNS, then we won't do DNS lookups.   Hopefully if you're having these symptoms this will help you out! //DannyP]]> https://docs.microsoft.com/archive/blogs/dannypexchange/exchange-2016-users-unable-to-edit-distribution-group-membership-when-outlook Fri, 26 Jan 2018 19:58:33 GMT https://blogs.msdn.microsoft.com/dannypexchange/?p=25 HERE but the cases I've had and am referring to were after migrating from Exchange 2010 to 2016, the owners of Distribution Groups could not longer edit members of distribution groups from Outlook and get the error "Changes to the public group membership cannot be saved. You do not have sufficient permission to perform this operation on this object. The odd thing is that they are able to edit them fine in OWA, so that rules out permissions.  After getting some code-level tracing we could actually see that the processor on the server was being marked as 'unhealthy' before this operation, so it's denying the code execution, not denying the user permission to edit group membership which is the confusing part.  Without getting into too much detail, there are calculations in the Exchange code which can mark the processor(s) as unhealthy, and in many cases it's due to the Exchange Servers having more CPU cores than our recommendations, which you can find here in Jeff Mealiffe's blog on the Exchange Team site How Big is Too Big? In the handful of recent cases we've had, the following settings were changed to correct the CPU issues we were seeing - Disable Hyperthreading on the Exchange Servers - Set the NUMA BIOS settings to "Flat" instead of "Clustered" I'm sure everyone knows about Hyperthreading and Exchange by now. The NUMA setting is set in the BIOS and can actually throttle CPU as well and degrade Exchange performance. Both of the above items are covered in our Exchange Health checker script, so they should be addressed anyways to be in a best practice configuration.  You can download that script here if you want to be proactive about it:  Exchange Health Checker Worst case scenario and this does not resolve your issue, you're in a better configuration than previously. Hope that helps!]]> https://docs.microsoft.com/archive/blogs/dannypexchange/hello-world Wed, 17 Jan 2018 22:46:57 GMT https://blogs.msdn.microsoft.com/dannypexchange/?p=1 Developer Network. This is your first post. Edit or delete it, then start blogging!]]>