DNS won't start until all servers running?

[Cache]

Hi, not really sure where to put this and whether I'm worrying unnecisarily but it has me a little concerned with reagrds to what I had planned.

Our power has been off all day today so yesterday I went in and shut all the servers down. Came in late on this afternoon to power everything back up but DNS failed to start until all servers were up and running which had me puzzled.

The Forest is currently in Windows 2000 Mode, the Domain in Windows 2003.

There are 3 DC's at present, 2 2003 and 1 2008 R2, the 2008 R2 being the one which holds all FSMO roles (or should do!) and all servers hold the GC. I started up the 2008 R2 server and even 10 minutes after starting DNS was still waiting for the Initial Syncronisation of AD before it would start.

Started up another DC, which also wouldn't start DNS, then started the 3rd DC at which point the DNS zones could be loaded.

I thought that DNS should be able to load from the 2008 R2 server if all the other servers were down.

Is it likely there is something held by the 3rd DC I started that AD is dependant upon to do it's initial syncronisation, or does AD require all DC's running before an initial syncronisation can occur? If it does require all DC's for the initial synchronisation what happens if a DC fails while it's shut down?

The only reason I'm slightly worried is that I was planning to remove this DC over the next half term to rebuild it with a bigger C Drive, but now I'm concerned that if I remove it and then at some point in the future have to shut all the servers down again I won't be able to bring AD back up.

Any ideas where I should be looking or am I worrying unnecessarily?

[Cache]

Ok, now I've taken a break and had another look, this seems to suggest it's normal behaviour: Initial synchronization requirements for Windows 2000 Server and Windows Server 2003 operations master role holders

Please point out if I'm wrong.

[pete]

Where are your DCs pointing to for their primary and secondary nameservers in their network settings?

The primary should be $other_dc, not themselves,

So:
DC1 has DC2 as primary nameserver
DC2 has DC3 as primary nameserver
DC3 has DC1 as primary nameserver

or similar.

[Cache]

DC1 points to DC1,DC2,DC3
DC2 points to DC2,DC3,DC1
DC3 points to DC3,DC1,DC2

Which was the way I came up with after asking on here (previously it had the ISP's DNS in there as well which guickly got removed) The main reason being that if the other servers were offline that they should boot up happily in the knowledge that the DNS server is available. Didn't really happen in this case though

[tmcd35]

Where are your DCs pointing to for their primary and secondary nameservers in their network settings?

The primary should be $other_dc, not themselves,

Interesting, I always thought that a DNS server should point to itself as the primary source and using Forwarders if it cannot resolve an I.P.

I've always set up so all DC's are also DNS and GC servers as a matter of course. I usually I assign 1 DNS server as the networks root DNS server. This would have LEA/ISP DNS hosts as Forwarders for addresses that cannot be resolved/have not been cached by the local DNS servers. I'd also set an external DNS as secondary on this server. The other servers would point to themselves and then the root DNS.

So:

DC1 = DC1 then external DNS
DC2 = DC2 then DC1
DC3 = DC3 then DC1

Clients are then set to DC2 and DC3 as primary/secondary DNS, alternating which is primary (usually 1 way round for DHCP and the other for manual IP's).

Ok, now I've taken a break and had another look, this seems to suggest it's normal behaviour: Initial synchronization requirements for Windows 2000 Server and Windows Server 2003 operations master role holders

Admittedly I've not read the link, but based on the title - what are the FSMO roles for the severs? Maybe the issues is not with DNS at all but the allocation of the FSMO roles across the servers? (think out loud).

[pete]

Interesting, I always thought that a DNS server should point to itself as the primary source and using Forwarders if it cannot resolve an I.P.

There are arguments for and against. See here: Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003

Also here, which argues it's unnecessary since 2003: DNS Client Configuration for Windows DNS Servers - Notes From The Field - Site Home - TechNet Blogs

I do it because I've found that a DC pointing to itself as primary can delay the start of services that rely on DNS (because the server hasn't started it's DNS yet) and occasionally require manual intervention to restart services. The flipside is you have to note down and remember which servers depend on which nameservers.

[Psymon]

My DNS Servers are set up as follows

DC1 points to 127.0.0.1 and DC2
DC2 points to 127.0.0.1 and DC3
DC3 points to 127.0.0.1 and DC1

If you use 127.0.0.1 instead of pointing to its own IP address it knows its local.

Forwarders are set to external DNS servers (in my case 2 by the schools ISP, and 2 OpenDNS servers) for resolution that cannot be dealt with locally by internal DC's.

You can add more than the 2 DNS servers on the NIC config by going to advanced, i deploy all 3 to my clients with DHCP options, and they all show with an IPConfig /all

As for the problem that you are mentioning (Not firing up untill all 3 DC \ DNS servers were alive) i have seen a problem quite recently (when we had power down for a day due to electrical maintanence) that the FSMO holder doesnt consider itself valid until it has another DC up to confirm it holds the FSMO roles after it was powered off for an extended amount of time.

The solution previously has been for the FSMO holder to sieze the roles to itself, or fire up a 2nd DC (we have a Hyper-V Virtual enviroment, and the Hyper-V Hosts have to see the PDC before the cluster goes live and fires up the virtual servers)

Simon

[Cache]

As for the problem that you are mentioning (Not firing up untill all 3 DC \ DNS servers were alive) i have seen a problem quite recently (when we had power down for a day due to electrical maintanence) that the FSMO holder doesnt consider itself valid until it has another DC up to confirm it holds the FSMO roles after it was powered off for an extended amount of time.

The solution previously has been for the FSMO holder to sieze the roles to itself, or fire up a 2nd DC (we have a Hyper-V Virtual enviroment, and the Hyper-V Hosts have to see the PDC before the cluster goes live and fires up the virtual servers)

Simon

That could explain the issue then, they were off for over 24 hours and it could just be the DC it tried to pick to validate it's self again was the last one I fired up. I had a phone call yesterday morning to say they were going to knock the power off again over the weekend so I dashed back in and shut the whole lot down again. I'll try putting one of the other servers up before the server that holds the FSMO roles this time and see if it will validate with just 2 DC's.

All the FSMO roles are held by the 2008 R2 DC which was added arround May Half Term.

Once I've brought them all up, I'll maybe try changing them to use 127.0.0.1 as primary.

Thanks all, I'll see what happens on Tuesday when I'm back in to power them up and thanks @Psymon, seems like it is normal behaviour to an extent.

[Cache]

Ok, panic over

Just brought up 2 Servers today to see what would happen, leaving the one which started everything last time shut down. After 5 minutes or so everything kicked into life, so replication is required with only one server before AD will start. *phew*

Now I can go back to planning the rebuild of the server with peace in my mind.