Uninstalling AD with DNS still working

Mishra

We dcpromoed an AD server here because it could not handle the load when clients failed over to it. We wanted DNS and WINS to still work on the machine but after the dcpromo, the forward and reverse zones did not show up. Can anyone explain what is happening?

BTW: is there a good way to see what domain controller a system has authenticated against?

royal

Give it 5-10 minutes and DNS will show up on the new DC. This is the method I always use to get a 2nd DC up and running.

1. Your first and only DC (DNS IP configured to point to itself)
2. A new DC (point DNS IP to point to your original DNS)
3. DCPromo new DC
4. Install DNS on new DC and don't try to create any DNS zones, just leave it alone
5. Come back in 15 minutes and you'll notice that during replication, the replication process will see that DNS is installed on the new DC and the replication process will automatically register the new DC as a Nameserver and create the NS records accordingly. This process will also populate the DNS server with zones.

So just give it 10-15 minutes and you'll notice DNS will be fully functional all by itself after some time. It's magic!

Also, after everything has synced up and both servers are now fully functional, I would optimize your DNS IP configuration.

I would point the primary DNS IP of your 1st DC to point to the 2nd DC and then point the secondary DNS IP to point to itself. On the 2nd DC, since the primary IP is already pointed to the 1st DC, I would configure the secondary IP to point to itself.

In the following thread, I talk more about why you'd want this DNS configuration:
http://www.techexams.net/forums/viewtopic.php?t=23644

I just wanted to add some more information on why you would want to do this. In 2000 Server, there was an issue called Island DNS. Basically, if a DC would point to itself for DNS, then it would register the Domain Controlller locator CNAME record for DsaGuid._msdcs.ForestDnsName in its own zone. This would cause other Domain Controllers not having a copy of this. Becuase of this, a DC would essentially be on an "island." In Server 2003, there were several things behind the scenes that were done to prevent this. One of them was by creating an application partition called ForestDNSZones. The msdcs zone is now a forest replicated dns zone and a delegation within your domain's dns zone has been created to point to this forest replicated msdcs zone. This msdcs forest wide dns zone will contain all the Domain Controller locator CNAME records. Now all Domain Controllers in a forest will contain that forest replicated dns zone so they will all know about all the Domain Controllers in the entire forest.

Even in Server 2003, it's still advised to configure another server as its primary dns server. I can think of 2 reasons. 1 is reassurance that no bizzare case of island dns reoccurs. Another is because if a DC is configured to use itself as a DNS server, you will notice that it will take forever at Network Connections to start up. This is because Active Directory requires DNS to function. Since it's a DC, it has to wait for DNS to full start up and become functional. Then other functions for AD can begin and then the box eventually comes up. If you have the primary dns server pointed to the other DC, it will most likely be booted up already. Now when you're booting up a DC, it'll be able to pull DNS information immediately due to its primary dns being pointed to an already booted up DC.

sprkymrk

Mishra wrote:

BTW: is there a good way to see what domain controller a system has authenticated against?

You can either run the "set" command or "gpresult".

royal

Also, you can go to a command prompt and type set to see what DC a system is authenticating against.

Edit: Mark beat me! although I didn't know you can use gpresult!

Mishra

royal wrote:

Give it 5-10 minutes and DNS will show up on the new DC. This is the method I always use to get a 2nd DC up and running.

1. Your first and only DC (DNS IP configured to point to itself)
2. A new DC (point DNS IP to point to your original DNS)
3. DCPromo new DC
4. Install DNS on new DC and don't try to create any DNS zones, just leave it alone
5. Come back in 15 minutes and you'll notice that during replication, the replication process will see that DNS is installed on the new DC and the replication process will automatically register the new DC as a Nameserver and create the NS records accordingly. This process will also populate the DNS server with zones.

So just give it 10-15 minutes and you'll notice DNS will be fully functional all by itself after some time. It's magic!

Also, after everything has synced up and both servers are now fully functional, I would optimize your DNS IP configuration.

I would point the primary DNS IP of your 1st DC to point to the 2nd DC and then point the secondary DNS IP to point to itself. On the 2nd DC, since the primary IP is already pointed to the 1st DC, I would configure the secondary IP to point to itself.

In the following thread, I talk more about why you'd want this DNS configuration:
http://www.techexams.net/forums/viewtopic.php?t=23644

I just wanted to add some more information on why you would want to do this. In 2000 Server, there was an issue called Island DNS. Basically, if a DC would point to itself for DNS, then it would register the Domain Controlller locator CNAME record for DsaGuid._msdcs.ForestDnsName in its own zone. This would cause other Domain Controllers not having a copy of this. Becuase of this, a DC would essentially be on an "island." In Server 2003, there were several things behind the scenes that were done to prevent this. One of them was by creating an application partition called ForestDNSZones. The msdcs zone is now a forest replicated dns zone and a delegation within your domain's dns zone has been created to point to this forest replicated msdcs zone. This msdcs forest wide dns zone will contain all the Domain Controller locator CNAME records. Now all Domain Controllers in a forest will contain that forest replicated dns zone so they will all know about all the Domain Controllers in the entire forest.

Even in Server 2003, it's still advised to configure another server as its primary dns server. I can think of 2 reasons. 1 is reassurance that no bizzare case of island dns reoccurs. Another is because if a DC is configured to use itself as a DNS server, you will notice that it will take forever at Network Connections to start up. This is because Active Directory requires DNS to function. Since it's a DC, it has to wait for DNS to full start up and become functional. Then other functions for AD can begin and then the box eventually comes up. If you have the primary dns server pointed to the other DC, it will most likely be booted up already. Now when you're booting up a DC, it'll be able to pull DNS information immediately due to its primary dns being pointed to an already booted up DC.

oh no Royal.... I forgot to say DCpromoed DOWN a domain controller. Meaning we uninstalled it. sorrrrrrry

royal

Pretty sure you can configure a regular member server to be a secondary off of an AD-integrated Primary Zone. Not entirely sure though as I haven't done it, but have read about it. I think it's the same way as having a BIND server containing information from an AD-integrated zone.

theseman

Sounds like the zones are AD-integrated zones, which would have required almost no configuration to show up on a new DC.

To have your DNS zones show up on a member server you will have to enable zone transfers on a server with the zones and set up secondary zones on the member server for DNS to function.

Mishra

ahh... you can't have direct AD-integrated zones on a DNS server without it being a domain controller. Well that is sad but I can take it for what it is.

Thanks for the help!