Questions

What is the precedence for dns client settings

+
0 Votes
Locked

What is the precedence for dns client settings

keith.abbott
Hi,

Quick question if you know, but slow if you're trying to find the answer.

The question pertains to NT4 domain and AD2003 domain with XP and Win2k Clients:

For settings such as dns suffix search order, who has precedence: settings configured on the local machine, or settings specified by DHCP?

And is there "overlay"? ie if the first in precedence has 2 search suffixes, and the second in precedence has those two plus a third, do you wind up with all 3 suffixes, or just the 2 specified by first precedence source?

OK I lied - not a quick question but a few questions:

Should you include the suffix listed in "use this suffix for dns registration" in the search suffix as the first search suffix, or leave it out?

and what about the 2 check boxes below that: wouldn't you always want to register the connection (at least for the primary nic) and use the configured DNS suffix?

What are best practices here?

Thanks for your input
k
  • +
    0 Votes
    CG IT

    here's how it works,

    on the workstation, in the NIC card TCP/IP properties, there are boxes for DNS server listings. First one is called the primary DNS server and any DNS queries are directed to that server. IF that server can not resolve the query, it forwards it to other DNS servers in it's fowards list or root hint list.

    The second DNS server listing is there in case the first DNS server is unavailable. Then DNS queries are sent to that server. If you list a 3rd one, if the first and second DNS servers are unavailable, queries are sent to that one. The however, is, if the first DNS server listed is available for queries, all queries are sent to it and no others.

    Registering the connection in DNS simply means that the workstation/computer registers itself in DNS with the address it has.

    If you use DHCP to get addresses, then the option for DNS servers needs to be configured in DHCP with the DNS servers to use. If that option isn't configured, then DHCP will not provide it to clients. same with routers option. The router's option provides clients with the default gateway address [router] out of the local network.

    +
    0 Votes
    keith.abbott

    right but what I am talking about is in the case where the NIC card is set to DHCP, but there are still settings in the advanced tab, for DNS suffix search order, and 'suffix for this connection'. And there are potentially different settings configured in DHCP for suffix search order and'suffix for this connection'.

    In this situation are the DHCP settings in effect, or the NIC card settings?

    +
    0 Votes
    CG IT

    configuration takes precedence. If the Nic is configured to obtain info from DHCP, that takes precedence.

    suffix is the "added at the end" part. Primary suffix = Active Directory domain name.

    So if everything was working well with the NT server listed first to answer DNS queries, and you changed to the W2003 server and everything went bad, then change it back.

    The DNS problem sounds like a zone problem.


    note: DNS server order of precedence is first always unless that becomes unavailable [server goes down] then queries go to the second DNS server listed [redundancy]. Not load balance.

    so if the computer name is xyz and you do a query lookup for xyz in dns the return will be xyz.domain name.com/net/ [or private extension].

    +
    0 Votes
    keith.abbott

    ok, to make sure my understanding is what you're communicating:

    two clients, (one on an NT domain, one on an AD domain called 'grouchy.com') nic has 'Obtain IP address automatically' checked, but if you click on the advanced button, and DNS tab,
    x.x.x.48 is listed as the primary server
    x.x.x.30 is listed as the secondary server
    'Append these DNS suffixes' is also checked and listed is:
    frog.com
    fish.com
    lizard.com

    In 'DNS suffix for this connection' frog.com is listed

    register this connections address in dns is checked
    Use this connections DNS suffix in DNS registration is checked

    Then in DHCP, DHCP specifies DNS servers of
    x.x.x.30 as primary
    x.x.x.48 as secondary

    and a suffix list of:
    frog.com
    bird.com
    snake.com
    orange.com

    Both clients try to ping a client specified only as warthog (Ping warthog)

    According to my understanding of your message that DHCP takes precedence,

    For the NT client (call it electron):
    it will use server x.x.x.30
    it will register with x.x.x.30 as electron.frog.com (listed as 'dns suffix for this connection' and (register this connections address' and 'use this connections dns suffix'
    It will first attempt to resolve
    warthog.frog.com (listed as 'dns suffix for this connection')
    then
    warthog.frog.com again because it is the first entry in the suffix list - which suggests it shouldnt be there since its already handled by the clients suffix
    warthog.bird.com
    warthog.snake.com
    warthog.orange.com

    for the AD client (call it lepton):
    it will use server x.x.x.30
    it will register as lepton.grouchy.com - AD always wants to use the domain name

    it will try
    warthog.grouchy.com - tries its own suffix first
    warthog.frog.com
    warthog.bird.com
    warthog.snake.com
    warthog.orange.com


    also in this scenario, changing the order of the server list at the client will have no effect because the order specified by DHCP takes precedence.

    Is this a correct understanding?

    Finally,

    For the NT client, if you have 'register this connection' and 'use this connections dns suffix' checked, but 'dns suffix for this connection' is blank, what happens?

    Same question for AD - I assume it doesn't care and registers as lepton.grouchy.com

    For AD client,if you uncheck 'register this connection', does it not register it? That doesn't seem probable since DNS is so integral to AD. If it still registers, then that checkbox doesnt really matter, correct?

    For AD client, what about the next checkbox? Won't it always register as grouchy.com regardless of what you put in that checkbox and the 'dns suffix for this connection' box? If not, you will most certainly break it by putting in the wrong thing.

    For the NT client unchecking 'register this connection' truely causes it not to register.

    for the NT client what suffix will it register if 'use this connection's DNS suffix' is uncheck?

    for the AD client, I know (or at least think I do) any settings in group policy will override all of the local and DHCP settings correct? But in the case where group policy specifies some settings and not others (specifies suffix order but not server addresses for instance) I assume the client uses the suffix order specified by the group policy, but servers specified by DHCP, or NIC settings. Correct?

    Thanks for all your help! The basics I know, but the devil is in the details and I have to know the details to really see how things should work.

    k

    +
    0 Votes
    CG IT

    If you choose to configure the Nic statically, and you can do this with DNS servers or ip addressing or both static entries take precedence.

    Registering the computer in DNS does so with the Nic information. Registration in DNS is for the address to computer name records. registering the suffix is the computer name.domain name.extention. If you don't want suffix registration in DNS, then it's simply the computer name to address [basically same as a WINS regisration].

    Suffix registration really is for a multi domain environment so that computers can be found based on what domain they are in. Domains are security boundries and computers can have the same name yet be in different domains. DNS wouldn't know the difference in a multi domain environment if only the computer name is used.

    note: multi-domain environment means an enterprise environment or a domain environment with trust relationships.

    +
    0 Votes
    keith.abbott

    OK, that clears up some of the questions.
    The reason I am asking is that at one time we had a large number of statically address machines. Those have long since been changed to DHCP, but the change was made by simply checking the 'get address automatically' box and leaving all of the other settings in place. Therein creating the issue of who has precedence.

    When we only had one domain, it wasn't too much of an issue: everything was the same (just provided different ways) and everyone played nice.

    Now that we have the AD domain with trusts between the two, with additional dns servers and suffixes, these million-year-old legacy settings become a concern.

    And from what I am now understanding, it sounds like any local (NIC) settings will take precedence over DHCP on both NT and AD clients.

    (Group Policy trumps all for AD client)

    Or the succinct version is:
    Order of Precedence for AD client:
    1. Group Policy
    2. Local Settings
    3. DHCP

    Order of Precedence for NT client
    1. Local Settings
    2. DHCP

    And, that, since we are running multi-domain, we need to be sure to register suffixes so things resolve to the right domain for the client.


    Is all of that correct?
    thx again

    +
    0 Votes
    keith.abbott

    One thing that came out in the long post - that I wanted to ask:

    for the NT client,
    If the domain suffix for that client is specified in the 'dns suffix for this connection' box, should, or should not, the suffix also be specified (and listed first) in the 'append these DNS suffixes' list?

    Does doing so cause it to make the same query twice?
    warthog.frog.com because frog.com is listed as the client's suffix,
    and again warthog.frog.com because frog.com is listed in the 'append these' list?

    what about the AD client?

    thx
    k

    +
    0 Votes
    CG IT

    local machine, site, domain and OU in that order.

    but that's a whole different ball game and doesn't apply to network cards.


    network cards have two ways of being configured. static entries and dynamically assigned entries.

    if you use static entries, they are the entries the NIC uses and dont' change unless manually changed.

    Dynamic entries change if and when you want them to change via DHCP on a DHCP server.

    you can change your whole network addressing scheme including routers, DNS servers, etc via DHCP and not visit workstations.

    if workstations have static entries, the only way to change em is to visit them and change them manually.

    order of precedence is simply static never changes even if there is DHCP services running and what DHCP has is different than what is statically assigned to the network card. Static is just that, never changes.

    Nic cards do not choose which one to use. The default TCP/IP properties is obtain automatically. If they can't get one then they assign themselves an address in the IP range 169.X.X.X

    If configured statically, they use that. If the address is configured dynamically but DNS servers statically, DNS will never change but addresses will. If DNS is dynamic and IP is static, DNS servers can change.

    depends on how you want clients to get their addresses, default gateways, DNS server information.

    If you have 2 domains with a trust between them, both on 2 different physical networks, [best way to go really] they each use their respective network addressing and DNS servers. If you have two non-contigious named domains on the same network segment, then that's really more tricky. DNS servers have to lookup names in zones and if they don't have zones for a name, they will shoot the query out to root hint or specified forwarders.

    +
    0 Votes
    keith.abbott

    well I'm not sure about the group policy point. Case in point:

    one group of our users need to be able to resolve names from a different site. Their legacy software was not really written to run from multiple sites and only specifies the server name rather than the FQDN. To resolve the issue we included the remote domain in the suffix search order. But when we moved them to the AD domain, that stopped working and even though you would put the suffix in the search list, when you did an IPconfig /all, the suffix was never listed with the normal suffixes.

    Come to find out, there was a network group policy in place that specified only the normal suffixes and it had precedence over the local settings.

    As far as the domain trusts, we're in the second case you listed. Two domains on a single subnet (one AD one NT). Except both domains use the same DHCP and DNS servers.

    The PDCE on the AD domain - which of course is also Primary DNS for all clients on the domain, has a secondary zone for the NT domain.

    On another AD DC, a secondary DNS server is configured and has the NT domain configured as a Primary zone and the AD domain as 'AD integrated'

    k

    +
    0 Votes
    CG IT

    big admin headache but hey that's why you get the big bucks huh.

    if you have a NT domain, then you probably have DNS and DNS Zones running for it..[ for those security domains in NT]. If you have pre W2K workstations, god forbid, then you probably run WINS as well.

    The tricky part comes with what DNS server handles what zone for what domain.

    If you had seperate DNS servers for NT and Active Directory, life is good. NT people use theirs. AD people use their.

    if you 2 logical domain networks on the same physical subnet, things get a bit dicey. Especially if you use 1 DHCP server and 1 subnet addressing scheme. This sounds like what's going on. DHCP gives out DNS servers and those on the NT network can't find the NT domain PDCs to authenticate with but they can find the AD domain controller.

    Note: Group Policy can be used to configure network settings but what's the point if you have DHCP?

    If I were you and in this situation where I have two logical domains on a single physical network, as a last resort, I'd do superscopes in DHCP. Assign 1 range to 1 logical domain and another range to the other logical domain. But for ease of administrative work and less headaches, for the NT domain, give em static addressing.

    bottom line is the NT clients need their PDC to authenticate with and that PDC should be listed in their DNS server that hosts the NT domain [security domains] DNS zone. That DNS server will then tell clients that the NT PDC is such and such server. That DNS server is then listed in the NIC card properties or provided to the workstations by DHCP. it should be the first DNS server listed.

    For complexity sake, and to make the admins life really fun, if NT domain clients use a different DNS server than the one for their domain, and it's not an authoritative DNS server for the domain and does not hold the DNS zone for the domains and that DNS server is available on the network, that server will forward unresolved queries to either root hint or forwarders. you can configure that DNS server to forward unresolved queries to a server you specify. So for instance your AD DNS server can't resolve queries for the NT domain, you can have it forward to the NT DNS server.

    If you only have 1 DNS server, then you can configure different zones for the different domains and that 1 DNS server can resolve queries for the different domains.....

    Depends on how much complexity you want.

    +
    0 Votes
    keith.abbott

    there's always a few thousand year old applications that people feel they cant live without, that will only run on win98 or win95.... sigh....

    Here's one for you:
    As I mentioned, both DNS servers are on the AD domain - the secondary dns server built on a DC - not the PDCE - has the NT domain as a primary scope. In the NIC settings for that DC, should I list the NT domain in the search suffix so it knows that if it cant find a pc on ADdom.com it should look on NTdom.com?

    +
    0 Votes
    CG IT

    personally, get them to spring for Windows 2003 Server and CALs and upgrade the NT domain to Active Directory. You can run it in mixed mode with WINS and those really 1990s era people with W9X can still use their stuff and be a part of something that isn't so much work. Those apps don't work on W2K?

    If you have 1 DNS server than handles both domains with seperate zones, their domain affiliation can't change. It's an either or thing. Either they are on the AD domain or the NT domain. DNS can resolve the queries for both the zones.

    If you run DHCP you can still use the register DNS suffix in DNS because the workstation domain affiliation is to the NT domain. But if you use 2 different DNS servers, but you can't spring for 2 DHCP servers, best to use superscopes and configure options for both superscopes.

    +
    0 Votes
    keith.abbott

    yeah, we're already migrating the NT side to AD. But that project is on hold because we have run into a problem on the AD side where some users are having to reboot overnight.

    System (PID 4) is locking their NTuser.dat files forcing the whole temp profile thing. Understandably theyre not willing to migrate anybody else until we get it resolved.

    I tried rebuilding profiles (which is pretty successful but not universally and not forever) and installing hive cleaner (which is also pretty successful but not universally so). I'm now down to using procmon to try to figure out the problem and thats a killer!

    I've also thought about deleting the user from the domain and the pc entirely and readding them but haven't gone there yet.

    It's weird because with a few people it's almost every day: with a bunch others it's periodically: and with quite a few it's been never....

    If we could get past that, we could get everyone migrated over and the whole multi-domain thing would go away.

    Although I guess that still doesnt address the fact that we still have a bunch of formerly static assigned IP clients with incorrect search suffix lists, that are now dhcp assigned....

    some days it's hard to wake up but at least the job isn't boring...

    +
    0 Votes
    CG IT

    Is this whole problem a user profile problem from NT to Active Directory meaning users want their same desktop settings from NT to the new AD domain?

    then this is the tool to use.

    http://www.forensit.com/domain-migration.html

    seriously works, and saves untold frustration with NT domains.

    +
    0 Votes
    keith.abbott

    The profiles (and machines) were migrated from the NT domain to the AD domain using Microsoft's 'ad migration tool' and generally the migration worked fine and the users were fine after that.

    But a couple of months after we had started the migration process, we had a rash of these profile lock issues along with several that required rebuild, on a Monday morning.

    Coincidentally (I doubt it) the previous Friday. I had made some GPO changes to try to get time sync working between the dc's, and the PDCE to sync to an external source.

    When the problem occurred, I tried to back out the changes, and when that didn't work I GPOfixed the policy and installed just the basic stuff we need for our domain configuration. But we continue to have the problem.

    As a side note on the DNS, just for grins I took an available pc on the NT domain and did some playing.
    It had a static address
    1 address in the suffix list (say ADdom.com)
    and its ip domain name was listed in the 'suffix for this connection' (say NTdom.com

    I set up a packet capture to the DNS servers and had the client ping a non-existent address - ping snot (hey, I had to use something)

    The first surprise was that it did not try to ping snot.ntdom.com, it went straight to snot.ADdom.com

    Then I added the NT ip domain and a a dummy domain to the suffix list - hogwarts.com

    Redid the ping and got attempts to resolve
    snot.ntdom.com
    snot.ADdom.com
    and snot.hogwarts.com

    then I clicked the "obtain an address" button and pinged snot and got the same list
    snot.ntdom.com
    snot.ADdom.com
    and snot.hogwarts.com

    instead of the list provided by the DHCP - just as you said.

    The server list depended on whether 'obtain dns server addres automatically' was checked or not.

    When I first clicked the dhcp radio and tried it without touching anything else, it used the local list. When I clicked 'obtain dns address' it used dhcp. When I reclicked 'use these dns' it required that I re-entered them.

    k

    +
    0 Votes
    CG IT

    sounds like the GPO mucked something up. GP default refresh is 90 minutes or after log off and log on.

    Sounds like GPO applied, users log off for the weekend, log on monday and bam!

    so the DHCP problem solved? the options in DHCP are: router option 3 [default gateway] DNS option 6 domain name option 15 so you can specify what DNS servers clients are supposed to use when they get DNS server addressing as part of DHCP.

    +
    0 Votes
    keith.abbott

    My thoughts exactly on the GPO. That's why I ran the GPOfix - it was supposed to get everything back to default.

    The default gpos had been modified, so it gave me the opportunity to get those back to default and create our own adjunct policies.

    But even that didnt resolve the problem and I'm struggling for a solution.

    As far as DHCP, I at least know what's going on.

    The leftover settings from the static addr days are overriding our DHCP settings in some cases and the clients will have to be visited and corrected.

    When we use the suffix list we'll have to include the client's native domain as first in the list (at least on the nt clients). That one surprised me.

    For the NT clients we'll need to specify the DNS list at the client - for the AD clients, DHCP serves the correct list. Although I noticed that the NT test client correctly resolved clients when pointed to the other DNS server - which I would expect because the 2 servers replicate.

    Do you think it would do any good to open a thread on the client reboot issue here? I've posted threads in couple of other places and they helped me do the gpofix. But beyond some help with the sysinternals tools, that's about as far as I got.

    k

    +
    0 Votes
    CG IT

    RSOP is a great tool to find out what's happening on the clients. I suggest you run that and see what the clients config is...

    Changing the default domain group policy,.. eh.. except for password policies which apply domain wide anyways, I don't do that.

    other GPOs? in my opinion, OU level.

  • +
    0 Votes
    CG IT

    here's how it works,

    on the workstation, in the NIC card TCP/IP properties, there are boxes for DNS server listings. First one is called the primary DNS server and any DNS queries are directed to that server. IF that server can not resolve the query, it forwards it to other DNS servers in it's fowards list or root hint list.

    The second DNS server listing is there in case the first DNS server is unavailable. Then DNS queries are sent to that server. If you list a 3rd one, if the first and second DNS servers are unavailable, queries are sent to that one. The however, is, if the first DNS server listed is available for queries, all queries are sent to it and no others.

    Registering the connection in DNS simply means that the workstation/computer registers itself in DNS with the address it has.

    If you use DHCP to get addresses, then the option for DNS servers needs to be configured in DHCP with the DNS servers to use. If that option isn't configured, then DHCP will not provide it to clients. same with routers option. The router's option provides clients with the default gateway address [router] out of the local network.

    +
    0 Votes
    keith.abbott

    right but what I am talking about is in the case where the NIC card is set to DHCP, but there are still settings in the advanced tab, for DNS suffix search order, and 'suffix for this connection'. And there are potentially different settings configured in DHCP for suffix search order and'suffix for this connection'.

    In this situation are the DHCP settings in effect, or the NIC card settings?

    +
    0 Votes
    CG IT

    configuration takes precedence. If the Nic is configured to obtain info from DHCP, that takes precedence.

    suffix is the "added at the end" part. Primary suffix = Active Directory domain name.

    So if everything was working well with the NT server listed first to answer DNS queries, and you changed to the W2003 server and everything went bad, then change it back.

    The DNS problem sounds like a zone problem.


    note: DNS server order of precedence is first always unless that becomes unavailable [server goes down] then queries go to the second DNS server listed [redundancy]. Not load balance.

    so if the computer name is xyz and you do a query lookup for xyz in dns the return will be xyz.domain name.com/net/ [or private extension].

    +
    0 Votes
    keith.abbott

    ok, to make sure my understanding is what you're communicating:

    two clients, (one on an NT domain, one on an AD domain called 'grouchy.com') nic has 'Obtain IP address automatically' checked, but if you click on the advanced button, and DNS tab,
    x.x.x.48 is listed as the primary server
    x.x.x.30 is listed as the secondary server
    'Append these DNS suffixes' is also checked and listed is:
    frog.com
    fish.com
    lizard.com

    In 'DNS suffix for this connection' frog.com is listed

    register this connections address in dns is checked
    Use this connections DNS suffix in DNS registration is checked

    Then in DHCP, DHCP specifies DNS servers of
    x.x.x.30 as primary
    x.x.x.48 as secondary

    and a suffix list of:
    frog.com
    bird.com
    snake.com
    orange.com

    Both clients try to ping a client specified only as warthog (Ping warthog)

    According to my understanding of your message that DHCP takes precedence,

    For the NT client (call it electron):
    it will use server x.x.x.30
    it will register with x.x.x.30 as electron.frog.com (listed as 'dns suffix for this connection' and (register this connections address' and 'use this connections dns suffix'
    It will first attempt to resolve
    warthog.frog.com (listed as 'dns suffix for this connection')
    then
    warthog.frog.com again because it is the first entry in the suffix list - which suggests it shouldnt be there since its already handled by the clients suffix
    warthog.bird.com
    warthog.snake.com
    warthog.orange.com

    for the AD client (call it lepton):
    it will use server x.x.x.30
    it will register as lepton.grouchy.com - AD always wants to use the domain name

    it will try
    warthog.grouchy.com - tries its own suffix first
    warthog.frog.com
    warthog.bird.com
    warthog.snake.com
    warthog.orange.com


    also in this scenario, changing the order of the server list at the client will have no effect because the order specified by DHCP takes precedence.

    Is this a correct understanding?

    Finally,

    For the NT client, if you have 'register this connection' and 'use this connections dns suffix' checked, but 'dns suffix for this connection' is blank, what happens?

    Same question for AD - I assume it doesn't care and registers as lepton.grouchy.com

    For AD client,if you uncheck 'register this connection', does it not register it? That doesn't seem probable since DNS is so integral to AD. If it still registers, then that checkbox doesnt really matter, correct?

    For AD client, what about the next checkbox? Won't it always register as grouchy.com regardless of what you put in that checkbox and the 'dns suffix for this connection' box? If not, you will most certainly break it by putting in the wrong thing.

    For the NT client unchecking 'register this connection' truely causes it not to register.

    for the NT client what suffix will it register if 'use this connection's DNS suffix' is uncheck?

    for the AD client, I know (or at least think I do) any settings in group policy will override all of the local and DHCP settings correct? But in the case where group policy specifies some settings and not others (specifies suffix order but not server addresses for instance) I assume the client uses the suffix order specified by the group policy, but servers specified by DHCP, or NIC settings. Correct?

    Thanks for all your help! The basics I know, but the devil is in the details and I have to know the details to really see how things should work.

    k

    +
    0 Votes
    CG IT

    If you choose to configure the Nic statically, and you can do this with DNS servers or ip addressing or both static entries take precedence.

    Registering the computer in DNS does so with the Nic information. Registration in DNS is for the address to computer name records. registering the suffix is the computer name.domain name.extention. If you don't want suffix registration in DNS, then it's simply the computer name to address [basically same as a WINS regisration].

    Suffix registration really is for a multi domain environment so that computers can be found based on what domain they are in. Domains are security boundries and computers can have the same name yet be in different domains. DNS wouldn't know the difference in a multi domain environment if only the computer name is used.

    note: multi-domain environment means an enterprise environment or a domain environment with trust relationships.

    +
    0 Votes
    keith.abbott

    OK, that clears up some of the questions.
    The reason I am asking is that at one time we had a large number of statically address machines. Those have long since been changed to DHCP, but the change was made by simply checking the 'get address automatically' box and leaving all of the other settings in place. Therein creating the issue of who has precedence.

    When we only had one domain, it wasn't too much of an issue: everything was the same (just provided different ways) and everyone played nice.

    Now that we have the AD domain with trusts between the two, with additional dns servers and suffixes, these million-year-old legacy settings become a concern.

    And from what I am now understanding, it sounds like any local (NIC) settings will take precedence over DHCP on both NT and AD clients.

    (Group Policy trumps all for AD client)

    Or the succinct version is:
    Order of Precedence for AD client:
    1. Group Policy
    2. Local Settings
    3. DHCP

    Order of Precedence for NT client
    1. Local Settings
    2. DHCP

    And, that, since we are running multi-domain, we need to be sure to register suffixes so things resolve to the right domain for the client.


    Is all of that correct?
    thx again

    +
    0 Votes
    keith.abbott

    One thing that came out in the long post - that I wanted to ask:

    for the NT client,
    If the domain suffix for that client is specified in the 'dns suffix for this connection' box, should, or should not, the suffix also be specified (and listed first) in the 'append these DNS suffixes' list?

    Does doing so cause it to make the same query twice?
    warthog.frog.com because frog.com is listed as the client's suffix,
    and again warthog.frog.com because frog.com is listed in the 'append these' list?

    what about the AD client?

    thx
    k

    +
    0 Votes
    CG IT

    local machine, site, domain and OU in that order.

    but that's a whole different ball game and doesn't apply to network cards.


    network cards have two ways of being configured. static entries and dynamically assigned entries.

    if you use static entries, they are the entries the NIC uses and dont' change unless manually changed.

    Dynamic entries change if and when you want them to change via DHCP on a DHCP server.

    you can change your whole network addressing scheme including routers, DNS servers, etc via DHCP and not visit workstations.

    if workstations have static entries, the only way to change em is to visit them and change them manually.

    order of precedence is simply static never changes even if there is DHCP services running and what DHCP has is different than what is statically assigned to the network card. Static is just that, never changes.

    Nic cards do not choose which one to use. The default TCP/IP properties is obtain automatically. If they can't get one then they assign themselves an address in the IP range 169.X.X.X

    If configured statically, they use that. If the address is configured dynamically but DNS servers statically, DNS will never change but addresses will. If DNS is dynamic and IP is static, DNS servers can change.

    depends on how you want clients to get their addresses, default gateways, DNS server information.

    If you have 2 domains with a trust between them, both on 2 different physical networks, [best way to go really] they each use their respective network addressing and DNS servers. If you have two non-contigious named domains on the same network segment, then that's really more tricky. DNS servers have to lookup names in zones and if they don't have zones for a name, they will shoot the query out to root hint or specified forwarders.

    +
    0 Votes
    keith.abbott

    well I'm not sure about the group policy point. Case in point:

    one group of our users need to be able to resolve names from a different site. Their legacy software was not really written to run from multiple sites and only specifies the server name rather than the FQDN. To resolve the issue we included the remote domain in the suffix search order. But when we moved them to the AD domain, that stopped working and even though you would put the suffix in the search list, when you did an IPconfig /all, the suffix was never listed with the normal suffixes.

    Come to find out, there was a network group policy in place that specified only the normal suffixes and it had precedence over the local settings.

    As far as the domain trusts, we're in the second case you listed. Two domains on a single subnet (one AD one NT). Except both domains use the same DHCP and DNS servers.

    The PDCE on the AD domain - which of course is also Primary DNS for all clients on the domain, has a secondary zone for the NT domain.

    On another AD DC, a secondary DNS server is configured and has the NT domain configured as a Primary zone and the AD domain as 'AD integrated'

    k

    +
    0 Votes
    CG IT

    big admin headache but hey that's why you get the big bucks huh.

    if you have a NT domain, then you probably have DNS and DNS Zones running for it..[ for those security domains in NT]. If you have pre W2K workstations, god forbid, then you probably run WINS as well.

    The tricky part comes with what DNS server handles what zone for what domain.

    If you had seperate DNS servers for NT and Active Directory, life is good. NT people use theirs. AD people use their.

    if you 2 logical domain networks on the same physical subnet, things get a bit dicey. Especially if you use 1 DHCP server and 1 subnet addressing scheme. This sounds like what's going on. DHCP gives out DNS servers and those on the NT network can't find the NT domain PDCs to authenticate with but they can find the AD domain controller.

    Note: Group Policy can be used to configure network settings but what's the point if you have DHCP?

    If I were you and in this situation where I have two logical domains on a single physical network, as a last resort, I'd do superscopes in DHCP. Assign 1 range to 1 logical domain and another range to the other logical domain. But for ease of administrative work and less headaches, for the NT domain, give em static addressing.

    bottom line is the NT clients need their PDC to authenticate with and that PDC should be listed in their DNS server that hosts the NT domain [security domains] DNS zone. That DNS server will then tell clients that the NT PDC is such and such server. That DNS server is then listed in the NIC card properties or provided to the workstations by DHCP. it should be the first DNS server listed.

    For complexity sake, and to make the admins life really fun, if NT domain clients use a different DNS server than the one for their domain, and it's not an authoritative DNS server for the domain and does not hold the DNS zone for the domains and that DNS server is available on the network, that server will forward unresolved queries to either root hint or forwarders. you can configure that DNS server to forward unresolved queries to a server you specify. So for instance your AD DNS server can't resolve queries for the NT domain, you can have it forward to the NT DNS server.

    If you only have 1 DNS server, then you can configure different zones for the different domains and that 1 DNS server can resolve queries for the different domains.....

    Depends on how much complexity you want.

    +
    0 Votes
    keith.abbott

    there's always a few thousand year old applications that people feel they cant live without, that will only run on win98 or win95.... sigh....

    Here's one for you:
    As I mentioned, both DNS servers are on the AD domain - the secondary dns server built on a DC - not the PDCE - has the NT domain as a primary scope. In the NIC settings for that DC, should I list the NT domain in the search suffix so it knows that if it cant find a pc on ADdom.com it should look on NTdom.com?

    +
    0 Votes
    CG IT

    personally, get them to spring for Windows 2003 Server and CALs and upgrade the NT domain to Active Directory. You can run it in mixed mode with WINS and those really 1990s era people with W9X can still use their stuff and be a part of something that isn't so much work. Those apps don't work on W2K?

    If you have 1 DNS server than handles both domains with seperate zones, their domain affiliation can't change. It's an either or thing. Either they are on the AD domain or the NT domain. DNS can resolve the queries for both the zones.

    If you run DHCP you can still use the register DNS suffix in DNS because the workstation domain affiliation is to the NT domain. But if you use 2 different DNS servers, but you can't spring for 2 DHCP servers, best to use superscopes and configure options for both superscopes.

    +
    0 Votes
    keith.abbott

    yeah, we're already migrating the NT side to AD. But that project is on hold because we have run into a problem on the AD side where some users are having to reboot overnight.

    System (PID 4) is locking their NTuser.dat files forcing the whole temp profile thing. Understandably theyre not willing to migrate anybody else until we get it resolved.

    I tried rebuilding profiles (which is pretty successful but not universally and not forever) and installing hive cleaner (which is also pretty successful but not universally so). I'm now down to using procmon to try to figure out the problem and thats a killer!

    I've also thought about deleting the user from the domain and the pc entirely and readding them but haven't gone there yet.

    It's weird because with a few people it's almost every day: with a bunch others it's periodically: and with quite a few it's been never....

    If we could get past that, we could get everyone migrated over and the whole multi-domain thing would go away.

    Although I guess that still doesnt address the fact that we still have a bunch of formerly static assigned IP clients with incorrect search suffix lists, that are now dhcp assigned....

    some days it's hard to wake up but at least the job isn't boring...

    +
    0 Votes
    CG IT

    Is this whole problem a user profile problem from NT to Active Directory meaning users want their same desktop settings from NT to the new AD domain?

    then this is the tool to use.

    http://www.forensit.com/domain-migration.html

    seriously works, and saves untold frustration with NT domains.

    +
    0 Votes
    keith.abbott

    The profiles (and machines) were migrated from the NT domain to the AD domain using Microsoft's 'ad migration tool' and generally the migration worked fine and the users were fine after that.

    But a couple of months after we had started the migration process, we had a rash of these profile lock issues along with several that required rebuild, on a Monday morning.

    Coincidentally (I doubt it) the previous Friday. I had made some GPO changes to try to get time sync working between the dc's, and the PDCE to sync to an external source.

    When the problem occurred, I tried to back out the changes, and when that didn't work I GPOfixed the policy and installed just the basic stuff we need for our domain configuration. But we continue to have the problem.

    As a side note on the DNS, just for grins I took an available pc on the NT domain and did some playing.
    It had a static address
    1 address in the suffix list (say ADdom.com)
    and its ip domain name was listed in the 'suffix for this connection' (say NTdom.com

    I set up a packet capture to the DNS servers and had the client ping a non-existent address - ping snot (hey, I had to use something)

    The first surprise was that it did not try to ping snot.ntdom.com, it went straight to snot.ADdom.com

    Then I added the NT ip domain and a a dummy domain to the suffix list - hogwarts.com

    Redid the ping and got attempts to resolve
    snot.ntdom.com
    snot.ADdom.com
    and snot.hogwarts.com

    then I clicked the "obtain an address" button and pinged snot and got the same list
    snot.ntdom.com
    snot.ADdom.com
    and snot.hogwarts.com

    instead of the list provided by the DHCP - just as you said.

    The server list depended on whether 'obtain dns server addres automatically' was checked or not.

    When I first clicked the dhcp radio and tried it without touching anything else, it used the local list. When I clicked 'obtain dns address' it used dhcp. When I reclicked 'use these dns' it required that I re-entered them.

    k

    +
    0 Votes
    CG IT

    sounds like the GPO mucked something up. GP default refresh is 90 minutes or after log off and log on.

    Sounds like GPO applied, users log off for the weekend, log on monday and bam!

    so the DHCP problem solved? the options in DHCP are: router option 3 [default gateway] DNS option 6 domain name option 15 so you can specify what DNS servers clients are supposed to use when they get DNS server addressing as part of DHCP.

    +
    0 Votes
    keith.abbott

    My thoughts exactly on the GPO. That's why I ran the GPOfix - it was supposed to get everything back to default.

    The default gpos had been modified, so it gave me the opportunity to get those back to default and create our own adjunct policies.

    But even that didnt resolve the problem and I'm struggling for a solution.

    As far as DHCP, I at least know what's going on.

    The leftover settings from the static addr days are overriding our DHCP settings in some cases and the clients will have to be visited and corrected.

    When we use the suffix list we'll have to include the client's native domain as first in the list (at least on the nt clients). That one surprised me.

    For the NT clients we'll need to specify the DNS list at the client - for the AD clients, DHCP serves the correct list. Although I noticed that the NT test client correctly resolved clients when pointed to the other DNS server - which I would expect because the 2 servers replicate.

    Do you think it would do any good to open a thread on the client reboot issue here? I've posted threads in couple of other places and they helped me do the gpofix. But beyond some help with the sysinternals tools, that's about as far as I got.

    k

    +
    0 Votes
    CG IT

    RSOP is a great tool to find out what's happening on the clients. I suggest you run that and see what the clients config is...

    Changing the default domain group policy,.. eh.. except for password policies which apply domain wide anyways, I don't do that.

    other GPOs? in my opinion, OU level.