Late last night we became aware of an issue with MS13-061 security update for Exchange Server 2013. Specifically, after the installation of the security update, the Content Index for mailbox databa...
Updated Jul 01, 2019
Version 2.0
Blog Post
Everything I am setting up I always make sure that both IPv4 and IPv6 are enabled. I understand those are now both required as the Windows team does not support turning them off even if ipv6 isn't used. If you turn off ipv6 things like direct access, DAG, and others will break. I understand that is Microsofts official recommendation to leave ipv6 on.
That said, it makes zero sense to have ipv6 enabled. Putting IPv6 in the client, business, and data layers was absolutely the WRONG way to go. You should have stuck with the tried and true OSI and/or TCPIP models taht separated the IP stack from the session, presentation, and app layers. If you'd stuck to the standard models for application design I could definitively understand and verify if IPv6 was causing an issue. Unfortunately the way you've now coded the new Exchange applications, it makes it impossible to really track down IP issues. I'm not here to berate you for the architecture, just saying - it's a pain now to troubleshoot IP issues and it wasn't before in Exchange. I think a number of issues have been caused due to this new architecture.
That was just a guess though as to what the issue "may" be...but back to the real issue, yes, with a brand new fresh Exchange 2013 install it would not send back to Exchange 2007 until we added/modified the default connectors. I'm just throwing out guesses as to what was the actual problem.
My bigger concern was the certificate that wasn't correctly handed out to the client even when specifically assigned to the service and the massively delayed migration process due to the wrong config data being present in the latest update. Those really caused a LOT of pain and the customer was very, very unhappy with the process.