How do I manually create the _msdcs DNS zone for a domain that was created pre S2K3?
I have a forest, lets call it contoso.com. I also have 3 subdomains, a.contoso.com, b.contoso.com, and c.contoso.com. The original forest, contoso.com, was created before server 2003, and may have been a Windows NT domain at some point, but I havent been here that long. Anyway, because it was created pre server 2003, I do not have an _msdcs.contoso.com zone in DNS.
In other forests that I have worked in that were created with server 2003, there is a seperate zone for _msdcs. I followed KB article 817470 to manually create the _msdcs zone for contoso.com and once I did a repadmin /syncall, it got populated. If you look in this KB under case 2 (which I believe describes me) step 4 is "Delete the old _msdcs subdomain." Does this mean that I should delet the folder _msdcs that is under caontoso.com now that i have a zone called _msdcs.contoso.com? Also, the 3 subdomains that I created using Server 2008 also do not have _msdcs zones. Should I repeat this process for each subdomain?
If the "folder" you see under the domain zone is grey, and not looking like the others, then its not a separate instance of the _msdcs zone. It is a zone delegation, meaning that "everything under this sub domain is managed as a zone itself".
Don't delete anything.
Everything is just as its supposed to be if you've followed the How-to article up until this step, given that "_msdcs.contoso.com" did not previously exist.
Be sure to restart the Netlogon services on all DC's when the zone has been replicated to them. This forces the DC's to register their SRV records in the _msdcs zone
First I'd like to be sure you understand what you are doing and why. You dont need to have a dedicated _msdcs.contoso.com zone for AD to work correctly. If you have a zone called contoso.com and it has a _msdcs sub domain with all required records, then that's all you need. The important thing is to ensure when a DNS client issues queries for the records that they get answered correctly.
The dedicated _msdcs.contoso.com zone along with the application partition it is hosted on offers an administrator the ability to ensure there is one zone containing AD specific DNS records and that it is replicated where he chooses (e.g. either forestwide or domain wide or any other custom chosen list of DCs). so having a _msdcs.contoso.com zone for your contoso.com in the forestdnszones application partition would ensure all DCs running DNS host the forest specific DNS records in addition to the domain specific DNS records on themselves. All DCs running DNS in the forest would be authoritative for the zone and would serve queries from the zone without the need to forward elsewhere.
Within a forest consisting of multiple domains, you will have some records that are registered in the forest domain related _msdcs and others that are domain specific. So for example each DC registers records for its own domain's _msdcs with some others in the forest specific _msdcs. E.g. GC specific SRV records (regardless whether DC is in root or child domain) is registered in forest specific _msdcs. Another example is the unique CNAME based DC identifiers in the format of {guid}._msdcs.contoso.com for all DCs in contoso.com forest regardless of whether they are in a root or child domain.
Yes you should "Delete the old _msdcs subdomain..." (but not a delegation with NS records) because this ensures DNS is aware that there is a dedicated zone for all records intended for _msdcs.contoso.com and no longer uses the subdomain it used to.
And as for the other child domain specific zones, they will have a _msdcs subdomain for domain specific records. So there is nothing required to be done there.
The default setup for DNS zones representing domains in the forest is to have each domain specific zone (e.g. a.contoso.com, b.contoso.com, contoso.com etc) in the domaindnszones partition with a _msdcs.contoso.com zone for forest specific records in forestdnszones application partition. You could move to that model if you want. But you don't have to.