Sorry for such a long response, but thought to let you know of all the
possibilites...
So the answers are inline and below your post...
In
jallen said:
The network admin prior to myself migrated the NT4.0 PDC
to Active Directory. It's functioning just fine and sees
the other two BDC's in our domain.
If you are referring to your NT4 BDCs, then that is normal without DNS since
the NT4 BDCs use NetBIOS for communication and not DNS queries to "find" the
domain by querying for the SRV location records.
The problem is that we
use a Unix based DNS solution (not BIND), and when I try
to promote a member server to Active Directory, the
installation fails because of DNS problems.
That is due to either using the wrong DNS in IP properties (ISP addresses
MUST be removed) and/or the SRV records are missing in the zone.
Here's where
it gets complicated: our office domain (I'll call it
OFFICE for anonymity reasons)is a separate domain from our
other domain, OFFICESOURCE (again, a fictional name).
There is a 2-way, non-transitive trust between the
domains.
All of our clients on the OFFICE domain have been
configured to use the DNS suffix OFFICESOURCE.COM for
their connections. My W2K domain controller has DNS
running on it, but it only has entries pointing to itself.
All machines in your domain MUST use this server. If using the Unix DNS (the
non-BIND server), then I can see why you're having major problems since this
guy, not being a BIND server, cannot support SRVs unless it's MetaIP or QIP.
The Unix admin has already delegated the recommended sub-
domains (_msdcs, _sites, _tcp, _udp) for the
OFFICESOURCE.COM domain. How can I get authoritative DNS
servers for my OFFICE domain to install a second domain
controller?
.
What did the Unix admins delegate those records to? They are actually not
really "subdomains" (they look like it) but rather are SRV records. They
contain domain service records and their locations. The DNS server hosting
them MUST support SRVs. So an SRV record cannot be delegated, but rather is
a valid record under the zone name following the RFCs for service location
records, whether they exist under the second level name (office.com) or a
under a child name (child.office.com).
Does that make sense?
NT4 doesn't use this, so probably why everything is working right now. Once
you go to all AD, then clients, such as W2k and newer will requrie the
internal DNS on the W2k server exclusively. Otherwise you'll experience long
logon times, GPOs do not apply, printers cannot authenticate, same with
mapped drives, and many other anomalies, such as what you're currently
experiencing.
AD and DNS follow simple rules to make it work. Veering away from them
causes issues since those SRV records (you called subdomains) is what it's
looking for when a client logs on, dcpromo to add another DC, GPOs to apply
to clients, etc.
1. Point all AD members (DCs and clients) to just the DNS server that hosts
the domain name for AD. If you point to anyother DNS server that is not
hosting the AD zone, then numerous errors WILL occur.
2. The DNS servers being used *MUST* support SRV records. This goes a step
beyond just creating those subdomain (as you call it) in any DNS server.
They only DNS servers out there I know that support SRV records are W2k,
W2k3, and Bind 4.9.7 or newer (actually 8.2.3 or neweris recommended). Not
sure what DNS server you are using, but that can be a major issue.
3. Dynamic Registration is an optional feature (but HIGHLY recommended) for
the DC to register it's records. I know of a few universities that keep this
tightly wrapped and request that the system32\config folder is made
available to the BIND admins so they can create the SRV for you. The data is
taken out of the netlogon.dns file. That is the file that the netlogon
service creates prior to attempting to register that data into the DNS zone.
4. You mentioned DNS Sufffixes. Is that the Primary DNS Suffix? That setting
is what the clients and the netlogon service uses to register into DNS under
that same zone name. What is recommended is that this suffix be set to the
domain that the machines are joined to. On a DC this is actually a must and
not just a recommendation.
I hope that helped a little in trying to figure out why you can;t join it.
If you can just point the DNS address to the same that the current server
uses, then it may work. By rights, all machines in that domain need to only
use the internal DNS, which in your case is the W2k DNS server. A good
practice is to use only the W2k DNS for the AD name and forward everything
else to the Unix machine for outside resolution, unless they are tight about
this either for political or security reasons.
Here's some links to read up on:
Frequently Asked Questions About Windows 2000 DNS and Windows Server 2003
DNS
http://support.microsoft.com/?id=291382
DNS Requirements for Deploying Active Directory:
http://www.microsoft.com/technet/tr...prodtechnol/windows2000serv/deploy/dnsreq.asp
How to setup a forwarder, delete the Root zone, and configure Internet
resolution in general in W2k or W2k3:
http://support.microsoft.com/?id=300202
178169 DNS Records Registered by Windows 2000 Domain Controllers :
http://support.microsoft.com/?id=178169
237675 Setting Up the Domain Name System for Active Directory :
http://suport.microsoft.com/?id=237675
241505 SRV Records Missing After Implementing Active Directory and DNS :
http://support.microsoft.com/default.aspx?scid=kb;EN-US;241505
241515 How to Verify the Creation of SRV Records for a Domain Controller :
http://support.microsoft.com/default.aspx?scid=kb;EN-US;241515
--
Regards,
Ace
Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.
Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
