1

What happened:

We had to reboot one of our Domain Controller (DC), located on the VLAN 1 for maintenance purpose.

We have a total of 4 DCs on 3 VLANs, so we thought that wouldn't affect our production servers as a failover would take place.

But during the reboot the websites that require authentication to our DC, and hosted on servers that are on the same VLAN as the rebooting DC, weren't accessible from outside (Internet) for 20 min.

I tend to think that IIS on the production servers on VLAN 1 lost their connection to the domain, and couldn't use any other DCs located on VLANs 2 or 3, while their DC on VLAN 1 was rebooting.

Configuration:

1st DC, running Win Svr 2K8 SP2, located on VLAN 1 2nd and 3rd DC, both running Win Svr 2003 R2, located on VLAN 2 4th DC, running Win Svr 2K8 SP2, located on VLAN 3 Affected servers, all running Win Svr 2K8 SP2, with IIS 7.0 and .Net 4.0, part of VLAN 1

DNS service is running on all 4 DCs Domain Functional Level: Windows 2000 native Network Load Balancing enabled

Steps taken:

Ran REPADMIN /SHOWREPS in an elevated Command Prompt from the 1st DC

Output of the command:

DC=ForestDnsZones,DC=WXYZ,DC=com

Site-Name2\DC2 via RPC

    DSA object GUID: 

    Last attempt @ 2013-06-19 14:50:45 was successful.

Site-Name2\DC3 via RPC

    DSA object GUID: 

    Last attempt @ 2013-06-19 14:50:45 was successful.

Site-Name2\DC2 via RPC

    DSA object GUID:

    Last attempt @ 2013-06-19 14:52:19 was successful.

So replication is taking place just fine.

I have verified and confirmed that all servers in VLAN 1 have a static IP address, a primary DNS and 2 alternate DNS configured in their NIC. All servers can ping all 3 DNS servers.

I followed the KBase "How to Verify the Creation of SRV Records for a Domain Controller" (http://support.microsoft.com/kb/241515) I used Nslookup and followed the 3 steps. The output showed that all 4 DC/DNS servers were registered and for all of them I got:

_ldap._tcp.dc._msdcs.mydomainname SRV service location:

      priority       = 0
      weight         = 100
      port           = 389
      svr hostname   = 

Questions:

Could this be a Kerberos issue? Or a failover issue?

I would appreciate if someone can provide some troubleshooting steps or tools I could use to find the issue and solve it.

Follow-up:

I have ran the following command line for each DC:

dcdiag /s:dcname /u:domain\adminusername /p: /a /v /c* and it returned the following result:

Starting test: Intersite

     Doing intersite inbound replication test on site VLAN1:
        Locating & Contacting Intersite Topology Generator (ISTG) ...
           The ISTG for site VLAN1 is: DC1.
        Checking for down bridgeheads ...
           Bridghead VLAN1\DC1 is up and replicating fine.
           Bridghead VLAN2\DC2 is up and replicating fine.
           Bridghead VLAN2\DC3 is up and replicating fine.
           Bridghead VLAN3\DC4 is up and replicating fine.
        Doing in depth site analysis ...
           All expected sites and bridgeheads are replicating into site VLAN1

Starting test: Intersite

    Doing intersite inbound replication test on site
    VLAN2:
       Locating & Contacting Intersite Topology Generator (ISTG) ...
          The ISTG for site VLAN2 is: DC2.
       Checking for down bridgeheads ...
          Bridghead VLAN1\DC1 is up and replicating fine.
          Bridghead VLAN2\DC2 is up and replicating fine.
          Bridghead VLAN2\DC3 is up and replicating fine.
          Bridghead VLAN3\DC4 is up and replicating fine.
       Doing in depth site analysis ...
          All expected sites and bridgeheads are replicating into site VLAN2

Starting test: Intersite

     Doing intersite inbound replication test on site VLAN2:
        Locating & Contacting Intersite Topology Generator (ISTG) ...
           The ISTG for site VLAN2 is: DC2.
        Checking for down bridgeheads ...
           Bridghead VLAN1\DC1 is up and replicating fine.
           Bridghead VLAN2\DC2 is up and replicating fine.
           Bridghead VLAN2\DC3 is up and replicating fine.
           Bridghead VLAN3\DC4 is up and replicating fine.
        Doing in depth site analysis ...
           All expected sites and bridgeheads are replicating into site VLAN2.

Starting test: Intersite

    Doing intersite inbound replication test on site VLAN3:
        Locating & Contacting Intersite Topology Generator (ISTG) ...
           The ISTG for site VLAN3 is: DC4.
        Checking for down bridgeheads ...
           Bridghead VLAN1\DC1 is up and replicating fine.
           Bridghead VLAN2\DC2 is up and replicating fine.
           Bridghead VLAN2\DC3 is up and replicating fine.
           Bridghead VLAN3\DC4 is up and replicating fine.
           Doing in depth site analysis ...
           All expected sites and bridgeheads are replicating into site VLAN3.

Confirming the previous command line REPADMIN /SHOWREPS.

These are 4 DCs in production and I cannot allow any downtime, therefore rebooting the DC1 to cause again the same behavior will be my last choice.

Does someone have any troubleshooting advice? Could it be useful to use Wireshark?

Thanks for your help.

  • How many of your DC's are Global Catalogs? Do you have All Ports needed for AD open on the firewall between the DC's and the clients (If there is one)? – Zypher Jun 19 '13 at 19:52
  • @Zypher Thanks for your reply. All 4 of them are Global Catalogs. There is not firewall between the DCs and the clients. – Laurent O. Jun 19 '13 at 20:17
  • Have you taken a look at the System event log on the IIS server? I would expect you to see some events indicating that the trust relationship between the IIS server and the logon server was interrupted/broken. What is the DNS server configuration on the primary network adapter on the IIS server? – Mathias R. Jessen Jun 21 '13 at 14:48
  • How are the web sites authenticating? Forms or integrated? – Greg Askew Jun 21 '13 at 16:16
  • @MathiasR.Jessen Thanks for your reply. I checked the Event Viewer at the time stamp I have and I can only see DFSR critical/warning errors. I cannot see anything about KDC or AD events. The DNS server configuration on the primary adapter of all affected IIS Servers shows the IP address of DC1, then the IP address of DC2, and at last DC3. As a reminder (it's a complex config.): all affected servers and DC1 are part of VLAN1. DC2 and DC3 are part of VLAN 2. – Laurent O. Jun 25 '13 at 20:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.