![mdaemon vs exchange 2013 mdaemon vs exchange 2013](https://www.birdiesoftware.com/img/cmd.gif)
![mdaemon vs exchange 2013 mdaemon vs exchange 2013](https://images.g2crowd.com/uploads/attachment/file/190613/Large-File.jpg)
While doing this has always caused sporadic issues with Exchange, Exchange 2013 seems to be even more sensitive in this regard. As a side note, check out the Exchange community a colleague & I moderate on reddit here. I actually did a write-up about this topic on the Sysadmin community on Reddit awhile back which you can find here. You’re see that you still get an IPv6 response. An easy way to test that your OS is still trying to use IPv6 is to ping localhost after you have unchecked IPv6 on your NIC & rebooted.
![mdaemon vs exchange 2013 mdaemon vs exchange 2013](https://docplayer.net/docs-images/49/16535326/images/page_10.jpg)
The problem with this is while the OS still thinks it can & should be using IPv6, the NIC is unable to do so which leads to communications issues. Let’s first talk about un-checking IPv6 on your NIC adapters. Properly Disabling IPv6 in the registry (Ok but not recommended by MS).Unchecking IPv6 on the NIC adapter ( BAD).So I’m going to cover two very different things here: So that right there should be a good indicator that you’re trailblazing on your own in the land of Exchange (bring a flashlight, it’s dark & scary). Let’s start off with this, The Exchange Server Product Team performs Zero testing or validation on systems with IPv6 Disabled. Then earlier today a coworker actually did this in a lab which caused the same issue. In fact I’m writing this today because earlier this week I had a customer who’s Information Store Service, as well as the Exchange Transport Services, on Exchange 2013 would not start. It seems like this sentiment has been preached widely but yet I still see customers do this.