Monitoring Window 2012 AD - Multiple Monitoring Scripts Failing (or Why I need IPv6)

  • [アーティクル]

I recently worked a case where a client was getting irregular, but frequent alerts across all Windows 2012 Domain Controllers.  The alerts included:

  • AD Replication Monitoring : encountered a runtime error. Failed to bind to 'LDAP://[server]/RootDSE'. The error returned was: 'The server is not operational.' (0x8007203A)
  • AD General Response : While running 'AD General Response' the following consecutive errors were encountered: Failed to bind to 'LDAP://[server]/rootDSE'. This is an unexpected error. The error returned was 'LDAP://[server]/rootDSE' (0x8007203A)
  • AD Replication Partner Count : The script 'AD Replication Partner Count' failed to initialize correctly. The error returned was: 'Object required' (0x80000000)
  • AD Lost And Found Object Count : Script 'AD Lost And Found Object Count' was unable to bind to the lost and found container.

The alerts occurred on pretty much every DC, but never in predictable manner (i.e. regular intervals, etc.) This one had me confused as these monitors are hard to track down (the monitor doesn't provide much detail about what it's actually doing) and because the AD servers themselves appears healthy and were serving clients.

While researching this I came across an article that really helped - https://windorks.wordpress.com/2014/02/24/known-issues-with-disabling-or-unbinding-ipv6/. Specifically this item, "When either IP protocol version is disabled, the 2048 byte limit applies and the response is typically 2200 or more bytes. LDAP servers with IPv6 disabled will drop > than 2048 byte responses and the tool / caller issuing the query considers such DCs unreachable"

Sure enough, the client had disabled IPv6 on all Windows 2012 machines since their network didn't support it. The learning here is that all Windows 2012 servers use IPv6, even if only for internal communications.

Don't disable IPv6 on Windows 2012 and don't disable IPv4 or IPv6 on a Windows 2012 DC!

Comments

  • Anonymous
    August 01, 2018
    The comment has been removed