AD Replication: What Does "Fully Routed" Mean?

Archived from groups: microsoft.public.win2000.active_directory (More info?)

I'm having trouble with replication, and in the process of trying to fix
it, I'm breaking it worse.

Without starting at the beginning, let's jump into the middle.. I'm getting
Event ID 1311, and
that after deleting my site links and checking "Bridge All Sites".

My sites _are_ fully routable the way I'd define it: I'm using RRAS & VPN
tunnels to connect
the sites, with static routing tables on each server that allows each server
to have IP connectivity
to every other server. I've verified that I can ping all the servers from
each servers.

So, w/r/t Active Directory replication, does "fully routed" mean something
different from what
I've got?

My enterprise has three sites, three subnets, three domains, each in
one-to-one correspondance.
The southernmost site was running Windows 2000 Server, but we've
transitioned it to a Win2k3
Server. The old server has been demoted after moving it out of the southern
site and to our HQ;
I realized only after it arrived here that I should have demoted it while it
was still in place.

Still, I seem to have gotten it demoted. So now, there is one domain
controller in each site, except
here at HQ, we are adding a new domain controller.

I can supply output from dcdiag, netdiag, dnslint, etc... thanks in advance
for any & all help,

-doug q
--
-Douglas Hurst Quebbeman (dougq@iglou.com) [Call me "Doug"]
To reply, place PUNCHTHRU in square brackets in SUBJECT line
"The large print giveth, and the small print taketh away." -Tom Waits
9 answers Last reply
More about replication fully routed mean
  1. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    "Douglas H. Quebbeman" <dhquebbeman@theestopinalgroup.com> wrote in message
    news:eLEjOSa$EHA.1264@TK2MSFTNGP12.phx.gbl...
    > I'm having trouble with replication, and in the process of trying to fix
    > it, I'm breaking it worse.
    >
    > Without starting at the beginning, let's jump into the middle.. I'm
    getting
    > Event ID 1311, and
    > that after deleting my site links and checking "Bridge All Sites".

    Bridge all sites and creating site links are NOT comparable.

    You need to both create (enough) site links and (in general)
    leave the Bridge all sites checked (the default.)

    Without Site Links -- no replication (to that site.)

    > My sites _are_ fully routable the way I'd define it: I'm using RRAS & VPN
    > tunnels to connect
    > the sites, with static routing tables on each server that allows each
    server
    > to have IP connectivity
    > to every other server. I've verified that I can ping all the servers from
    > each servers.

    That's a good sign -- and of course you must pass
    the actual traffic (not just ICMP for ping.)

    Ok, put back the Site Links to (roughly) correspond to
    the WAN links. Use a cost roughly inverse to the speed
    of the line (or high if you wish to discourage that path),
    e.g.,
    T3 = 3
    T1 = 1
    ISDN = 1000
    Dial = 2000

    But note, if you had a permanent ISDN and a another demand
    dial ISDN you might well mark the second one 1500, 2000 or
    even higher.

    The idea is to DESCRIBE the underlying WAN to the KCC
    so that it will calculate the best replication partners/paths.

    > So, w/r/t Active Directory replication, does "fully routed" mean something
    > different from what
    > I've got?

    Well, technically you have to make sure the DCs can
    pass their own traffic, not just ping.

    Are you firewalling any of these (with selective port/protocol
    filters)? Or are the DCs open to each other?

    If the latter, the ping is probably good enough as a test for now.

    > My enterprise has three sites, three subnets, three domains, each in
    > one-to-one correspondance.

    Likely you biggest problem (once you create the sites)
    will be DNS (most replication issues are really DNS
    issues once the underlying infracture IP/sites etc. are
    setup.)

    > The southernmost site was running Windows 2000 Server, but we've
    > transitioned it to a Win2k3
    > Server. The old server has been demoted after moving it out of the
    southern
    > site and to our HQ;
    > I realized only after it arrived here that I should have demoted it while
    it
    > was still in place.

    Yes, and you will get errors for that until you use NTDSUtil
    to remove it (but they are generally benign errors so this can
    wait probably until you fix the other stuff), later you can Google:

    [ ntdsutil "metadata cleanup" remove domain dc ]

    > Still, I seem to have gotten it demoted. So now, there is one domain
    > controller in each site, except
    > here at HQ, we are adding a new domain controller.

    What about single master roles? The 2 Forest wide roles
    and the 3 (EACH) domain specific roles?

    What about GCs? Do you have at least one (or more) GCs
    per site?

    > I can supply output from dcdiag, netdiag, dnslint, etc... thanks in
    advance
    > for any & all help,

    Let's do the obvious, then run the DCDiag.

    DNS for AD
    1) Dynamic for the zone supporting AD
    2) All internal DNS clients NIC\IP properties must specify SOLELY
    that internal, dynamic DNS server (set.)
    3) DCs and even DNS servers are DNS clients too -- see #2

    Restart NetLogon on any DC if you change any of the above that
    affects a DC and/or use:

    nltest /dsregdns /server:DC-ServerNameGoesHere

    Ensure that DNS zones/domains are fully replicated to all DNS
    servers for that (internal) zone/domain.

    Also useful may be running DCDiag on each DC, sending the
    output to a text file, and searching for FAIL, ERROR, WARN.

    Single Lable domain zone names are a problem Google:
    [ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]

    --
    Herb Martin


    >
    > -doug q
    > --
    > -Douglas Hurst Quebbeman (dougq@iglou.com) [Call me "Doug"]
    > To reply, place PUNCHTHRU in square brackets in SUBJECT line
    > "The large print giveth, and the small print taketh away." -Tom Waits
    >
    >
  2. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    In news:%23C60%23xa$EHA.1296@TK2MSFTNGP10.phx.gbl,
    Herb Martin <news@LearnQuick.com> screib:
    > "Douglas H. Quebbeman" <dhquebbeman@theestopinalgroup.com> wrote in
    > message
    > news:eLEjOSa$EHA.1264@TK2MSFTNGP12.phx.gbl...
    >> that after deleting my site links and checking "Bridge All Sites".
    >
    > Bridge all sites and creating site links are NOT comparable.
    >
    > You need to both create (enough) site links and (in general)
    > leave the Bridge all sites checked (the default.)
    >
    > Without Site Links -- no replication (to that site.)

    Ok... in trying to solve other problems (postings coming soon), I hoped that
    simplifying the configuration (as much as possible) would be a good start.

    >> My sites _are_ fully routable the way I'd define it: I'm using RRAS & VPN
    >> tunnels to connect
    >> the sites, with static routing tables on each server that allows each
    >> server
    >> to have IP connectivity
    >> to every other server. I've verified that I can ping all the servers from
    >> each servers.
    >
    > That's a good sign -- and of course you must pass
    > the actual traffic (not just ICMP for ping.)

    I'm not doing any packet filtering on the RRAS links... all traffic should
    be passing from one site to another.

    > Ok, put back the Site Links to (roughly) correspond to
    > the WAN links. Use a cost roughly inverse to the speed
    > of the line (or high if you wish to discourage that path),
    > e.g.,
    > T3 = 3
    > T1 = 1
    > ISDN = 1000
    > Dial = 2000
    >
    > But note, if you had a permanent ISDN and a another demand
    > dial ISDN you might well mark the second one 1500, 2000 or
    > even higher.
    >
    > The idea is to DESCRIBE the underlying WAN to the KCC
    > so that it will calculate the best replication partners/paths.

    As small as we are, I'd never messed with routing costs... but it
    sounds like a good idea anyway.

    >> So, w/r/t Active Directory replication, does "fully routed" mean
    >> something
    >> different from what I've got?
    >
    > Well, technically you have to make sure the DCs can
    > pass their own traffic, not just ping.
    >
    > Are you firewalling any of these (with selective port/protocol
    > filters)? Or are the DCs open to each other?

    No filtering; the VPN/PPTP tunnels are there to move traffic
    through the firewall, all ports are open in the tunnel, but closed
    outside the tunnel (except for standard systems services like SMTP).

    > If the latter, the ping is probably good enough as a test for now.
    >
    >> My enterprise has three sites, three subnets, three domains, each in
    >> one-to-one correspondance.
    >
    > Likely you biggest problem (once you create the sites)
    > will be DNS (most replication issues are really DNS
    > issues once the underlying infracture IP/sites etc. are
    > setup.)

    My DNS logs are clean, and DNSLint doesn't list any errors when I
    run it with /ad /s localhost /v. But I *am* having WINS replication
    issues...

    >> The southernmost site was running Windows 2000 Server, but we've
    >> transitioned it to a Win2k3
    >> Server. The old server has been demoted after moving it out of the
    >> southern site and to our HQ;
    >> I realized only after it arrived here that I should have demoted it while
    >> it was still in place.
    >
    > Yes, and you will get errors for that until you use NTDSUtil
    > to remove it (but they are generally benign errors so this can
    > wait probably until you fix the other stuff), later you can Google:
    >
    > [ ntdsutil "metadata cleanup" remove domain dc ]

    Ok...

    >> Still, I seem to have gotten it demoted. So now, there is one domain
    >> controller
    >> in each site, except here at HQ, we are adding a new domain controller.
    >
    > What about single master roles? The 2 Forest wide roles
    > and the 3 (EACH) domain specific roles?
    >
    > What about GCs? Do you have at least one (or more) GCs
    > per site?

    I want GCs in each site, since the WAN links do go down from time to time.
    The southernmost site is having problems becoming a GC... that site fails
    the
    nSecDesc test...

    In the HQ, the GC is also the FSMO, and I get some complaints about that,
    and it sees the new server and suggests moving the role to it, but again, I
    think
    I can wait on this.

    >> I can supply output from dcdiag, netdiag, dnslint, etc... thanks in
    >> advance
    >> for any & all help,
    >
    > Let's do the obvious, then run the DCDiag.
    >
    > DNS for AD
    > 1) Dynamic for the zone supporting AD
    > 2) All internal DNS clients NIC\IP properties must specify SOLELY
    > that internal, dynamic DNS server (set.)
    > 3) DCs and even DNS servers are DNS clients too -- see #2
    >

    I have a NAS unit here, Windows Powered, that's acting as a secondary
    DNS server; I have it mapped to my NIC on my WS as secondary, so I
    can still browse the web when the main server is down. That seems to violate
    #2 in your list above...

    > Restart NetLogon on any DC if you change any of the above that
    > affects a DC and/or use:
    >
    > nltest /dsregdns /server:DC-ServerNameGoesHere
    >
    > Ensure that DNS zones/domains are fully replicated to all DNS
    > servers for that (internal) zone/domain.
    >
    > Also useful may be running DCDiag on each DC, sending the
    > output to a text file, and searching for FAIL, ERROR, WARN.

    Yes, we have some issues there. I've run DCDIAG with the switches

    /e /c /v /fix

    and you can see the output for all 4 servers at:

    http://members.iglou.com/dougq/MyActiveDirectoryProblems.html

    > Single Lable domain zone names are a problem Google:
    > [ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]

    Although my internal domain names are bogus (not registered), they are
    all .COMs...

    Thanks,
    -dq
  3. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    > > The idea is to DESCRIBE the underlying WAN to the KCC
    > > so that it will calculate the best replication partners/paths.
    >
    > As small as we are, I'd never messed with routing costs... but it
    > sounds like a good idea anyway.

    I was not referring to routing costs but rather SiteLink costs,
    which you cannot avoid because they default to something.
    Make them sensible (previous suggesti
    > > Likely you biggest problem (once you create the sites)
    > > will be DNS (most replication issues are really DNS
    > > issues once the underlying infracture IP/sites etc. are
    > > setup.)
    >
    > My DNS logs are clean, and DNSLint doesn't list any errors when I
    > run it with /ad /s localhost /v. But I *am* having WINS replication
    > issues...

    And can all DCs pass a DCDiag test clean?

    > >> I realized only after it arrived here that I should have demoted it
    while
    > >> it was still in place.
    > >
    > > Yes, and you will get errors for that until you use NTDSUtil
    > > to remove it (but they are generally benign errors so this can
    > > wait probably until you fix the other stuff), later you can Google:
    > >
    > > [ ntdsutil "metadata cleanup" remove domain dc ]
    >
    > Ok...
    >
    > >> Still, I seem to have gotten it demoted. So now, there is one domain
    > >> controller
    > >> in each site, except here at HQ, we are adding a new domain controller.
    > >
    > > What about single master roles? The 2 Forest wide roles
    > > and the 3 (EACH) domain specific roles?
    > >
    > > What about GCs? Do you have at least one (or more) GCs
    > > per site?
    >
    > I want GCs in each site, since the WAN links do go down from time to time.
    > The southernmost site is having problems becoming a GC... that site fails
    > the
    > nSecDesc test...

    You will have problems, especially in Native modes if you
    don't get a GC to every site.

    > In the HQ, the GC is also the FSMO, and I get some complaints about that,
    > and it sees the new server and suggests moving the role to it, but again,
    I
    > think
    > I can wait on this.

    "the FSMO" indicates a slight misunderstanding.
    There is ONE single master role that is recommended
    to not be a GC (when you have multiple domains), and
    that is the Infrstructure master. The Schema Master/
    Domain Naming Master must be a GC.

    You can have lots of GCs - at least one per site.

    > >> I can supply output from dcdiag, netdiag, dnslint, etc... thanks in
    > >> advance for any & all help,
    > >
    > > Let's do the obvious, then run the DCDiag.
    > >
    > > DNS for AD
    > > 1) Dynamic for the zone supporting AD
    > > 2) All internal DNS clients NIC\IP properties must specify SOLELY
    > > that internal, dynamic DNS server (set.)
    > > 3) DCs and even DNS servers are DNS clients too -- see #2
    > >
    >
    > I have a NAS unit here, Windows Powered, that's acting as a secondary
    > DNS server; I have it mapped to my NIC on my WS as secondary, so I
    > can still browse the web when the main server is down. That seems to
    violate
    > #2 in your list above...

    That is incorrect. DNS servers must forward to DNS servers which return
    the same answers. DNS Clients assume that ALL DNS server know
    the same stuff.

    Fix this:

    All DNS clients pointed to strictly the internal DNS server
    set -- which must resolve ALL of your internal domains.

    Remember that DCs, even DNS servers themselves are ALSO
    DNS clients.

    And then you can use Forwarding to resolve Internet names.

    You cannot reliably use two distinct DNS server sets.
    Don't try. (It may work just enough to convince you otherwise
    since it will give intermittent results.)


    > > Restart NetLogon on any DC if you change any of the above that
    > > affects a DC and/or use:
    > >
    > > nltest /dsregdns /server:DC-ServerNameGoesHere
    > >
    > > Ensure that DNS zones/domains are fully replicated to all DNS
    > > servers for that (internal) zone/domain.
    > >
    > > Also useful may be running DCDiag on each DC, sending the
    > > output to a text file, and searching for FAIL, ERROR, WARN.
    >
    > Yes, we have some issues there. I've run DCDIAG with the switches
    >
    > /e /c /v /fix
    >
    > and you can see the output for all 4 servers at:
    >
    > http://members.iglou.com/dougq/MyActiveDirectoryProblems.html
    >
    > > Single Lable domain zone names are a problem Google:
    > > [ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]
    >
    > Although my internal domain names are bogus (not registered), they are
    > all .COMs...
    >

    --
    Herb Martin


    "Douglas H. Quebbeman" <dhquebbeman@theestopinalgroup.com> wrote in message
    news:eGbGHRj$EHA.3824@TK2MSFTNGP10.phx.gbl...
    > In news:%23C60%23xa$EHA.1296@TK2MSFTNGP10.phx.gbl,
    > Herb Martin <news@LearnQuick.com> screib:
    > > "Douglas H. Quebbeman" <dhquebbeman@theestopinalgroup.com> wrote in
    > > message
    > > news:eLEjOSa$EHA.1264@TK2MSFTNGP12.phx.gbl...
    > >> that after deleting my site links and checking "Bridge All Sites".
    > >
    > > Bridge all sites and creating site links are NOT comparable.
    > >
    > > You need to both create (enough) site links and (in general)
    > > leave the Bridge all sites checked (the default.)
    > >
    > > Without Site Links -- no replication (to that site.)
    >
    > Ok... in trying to solve other problems (postings coming soon), I hoped
    that
    > simplifying the configuration (as much as possible) would be a good start.
    >
    > >> My sites _are_ fully routable the way I'd define it: I'm using RRAS &
    VPN
    > >> tunnels to connect
    > >> the sites, with static routing tables on each server that allows each
    > >> server
    > >> to have IP connectivity
    > >> to every other server. I've verified that I can ping all the servers
    from
    > >> each servers.
    > >
    > > That's a good sign -- and of course you must pass
    > > the actual traffic (not just ICMP for ping.)
    >
    > I'm not doing any packet filtering on the RRAS links... all traffic should
    > be passing from one site to another.
    >
    > > Ok, put back the Site Links to (roughly) correspond to
    > > the WAN links. Use a cost roughly inverse to the speed
    > > of the line (or high if you wish to discourage that path),
    > > e.g.,
    > > T3 = 3
    > > T1 = 1
    > > ISDN = 1000
    > > Dial = 2000
    > >
    > > But note, if you had a permanent ISDN and a another demand
    > > dial ISDN you might well mark the second one 1500, 2000 or
    > > even higher.
    > >
    > > The idea is to DESCRIBE the underlying WAN to the KCC
    > > so that it will calculate the best replication partners/paths.
    >
    > As small as we are, I'd never messed with routing costs... but it
    > sounds like a good idea anyway.
    >
    > >> So, w/r/t Active Directory replication, does "fully routed" mean
    > >> something
    > >> different from what I've got?
    > >
    > > Well, technically you have to make sure the DCs can
    > > pass their own traffic, not just ping.
    > >
    > > Are you firewalling any of these (with selective port/protocol
    > > filters)? Or are the DCs open to each other?
    >
    > No filtering; the VPN/PPTP tunnels are there to move traffic
    > through the firewall, all ports are open in the tunnel, but closed
    > outside the tunnel (except for standard systems services like SMTP).
    >
    > > If the latter, the ping is probably good enough as a test for now.
    > >
    > >> My enterprise has three sites, three subnets, three domains, each in
    > >> one-to-one correspondance.
    > >
    > > Likely you biggest problem (once you create the sites)
    > > will be DNS (most replication issues are really DNS
    > > issues once the underlying infracture IP/sites etc. are
    > > setup.)
    >
    > My DNS logs are clean, and DNSLint doesn't list any errors when I
    > run it with /ad /s localhost /v. But I *am* having WINS replication
    > issues...
    >
    > >> The southernmost site was running Windows 2000 Server, but we've
    > >> transitioned it to a Win2k3
    > >> Server. The old server has been demoted after moving it out of the
    > >> southern site and to our HQ;
    > >> I realized only after it arrived here that I should have demoted it
    while
    > >> it was still in place.
    > >
    > > Yes, and you will get errors for that until you use NTDSUtil
    > > to remove it (but they are generally benign errors so this can
    > > wait probably until you fix the other stuff), later you can Google:
    > >
    > > [ ntdsutil "metadata cleanup" remove domain dc ]
    >
    > Ok...
    >
    > >> Still, I seem to have gotten it demoted. So now, there is one domain
    > >> controller
    > >> in each site, except here at HQ, we are adding a new domain controller.
    > >
    > > What about single master roles? The 2 Forest wide roles
    > > and the 3 (EACH) domain specific roles?
    > >
    > > What about GCs? Do you have at least one (or more) GCs
    > > per site?
    >
    > I want GCs in each site, since the WAN links do go down from time to time.
    > The southernmost site is having problems becoming a GC... that site fails
    > the
    > nSecDesc test...
    >
    > In the HQ, the GC is also the FSMO, and I get some complaints about that,
    > and it sees the new server and suggests moving the role to it, but again,
    I
    > think
    > I can wait on this.
    >
    > >> I can supply output from dcdiag, netdiag, dnslint, etc... thanks in
    > >> advance
    > >> for any & all help,
    > >
    > > Let's do the obvious, then run the DCDiag.
    > >
    > > DNS for AD
    > > 1) Dynamic for the zone supporting AD
    > > 2) All internal DNS clients NIC\IP properties must specify SOLELY
    > > that internal, dynamic DNS server (set.)
    > > 3) DCs and even DNS servers are DNS clients too -- see #2
    > >
    >
    > I have a NAS unit here, Windows Powered, that's acting as a secondary
    > DNS server; I have it mapped to my NIC on my WS as secondary, so I
    > can still browse the web when the main server is down. That seems to
    violate
    > #2 in your list above...
    >
    > > Restart NetLogon on any DC if you change any of the above that
    > > affects a DC and/or use:
    > >
    > > nltest /dsregdns /server:DC-ServerNameGoesHere
    > >
    > > Ensure that DNS zones/domains are fully replicated to all DNS
    > > servers for that (internal) zone/domain.
    > >
    > > Also useful may be running DCDiag on each DC, sending the
    > > output to a text file, and searching for FAIL, ERROR, WARN.
    >
    > Yes, we have some issues there. I've run DCDIAG with the switches
    >
    > /e /c /v /fix
    >
    > and you can see the output for all 4 servers at:
    >
    > http://members.iglou.com/dougq/MyActiveDirectoryProblems.html
    >
    > > Single Lable domain zone names are a problem Google:
    > > [ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]
    >
    > Although my internal domain names are bogus (not registered), they are
    > all .COMs...
    >
    > Thanks,
    > -dq
    >
    >
  4. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    In news:%23ljYZRk$EHA.3120@TK2MSFTNGP12.phx.gbl,
    Herb Martin <news@LearnQuick.com> screib:
    >>> The idea is to DESCRIBE the underlying WAN to the KCC
    >>> so that it will calculate the best replication partners/paths.
    >>
    >> As small as we are, I'd never messed with routing costs... but it
    >> sounds like a good idea anyway.
    >
    > I was not referring to routing costs but rather SiteLink costs,
    > which you cannot avoid because they default to something.
    > Make them sensible (previous suggesti

    Since I didn't enter any cost value, I assume I get the defaults...

    >>> Likely you biggest problem (once you create the sites)
    >>> will be DNS (most replication issues are really DNS
    >>> issues once the underlying infracture IP/sites etc. are
    >>> setup.)
    >>
    >> My DNS logs are clean, and DNSLint doesn't list any errors when I
    >> run it with /ad /s localhost /v. But I *am* having WINS replication
    >> issues...
    >
    > And can all DCs pass a DCDiag test clean?

    No, as shown in those posted DCDiag logs...

    >> I want GCs in each site, since the WAN links do go down from time to
    >> time.
    >> The southernmost site is having problems becoming a GC... that site fails
    >> the
    >> nSecDesc test...
    >
    > You will have problems, especially in Native modes if you
    > don't get a GC to every site.

    I have a legacy NT machine I can't upgrade without breaking the application,
    so I've been keeping the enterprise in mixed mode.

    >> In the HQ, the GC is also the FSMO, and I get some complaints about that,
    >> and it sees the new server and suggests moving the role to it, but again,
    >> I
    >> think I can wait on this.
    >
    > "the FSMO" indicates a slight misunderstanding.
    > There is ONE single master role that is recommended
    > to not be a GC (when you have multiple domains), and
    > that is the Infrstructure master. The Schema Master/
    > Domain Naming Master must be a GC.
    >
    > You can have lots of GCs - at least one per site.

    Indeed, how is it possible for anyone who installs a server
    once every three or four years to master this MS Stuff?

    Sorry- rhetorical question...

    Once I get production moved to the new server, and get a
    chance to clean up the old production server, when I redeploy it,
    at that time, I can make it be the infrastructure master and not be a GC..

    I suppoose I could split them now, too, and just reverse roles later,
    but I don't want to make more work for myself than neeed be...

    >> I have a NAS unit here, Windows Powered, that's acting as a secondary
    >> DNS server; I have it mapped to my NIC on my WS as secondary, so I
    >> can still browse the web when the main server is down. That seems to
    >> violate
    >> #2 in your list above...
    >
    > That is incorrect. DNS servers must forward to DNS servers which return
    > the same answers. DNS Clients assume that ALL DNS server know
    > the same stuff.
    >
    > Fix this:
    >
    > All DNS clients pointed to strictly the internal DNS server
    > set -- which must resolve ALL of your internal domains.
    >
    > Remember that DCs, even DNS servers themselves are ALSO
    > DNS clients.

    None my servers point to this alternate, non-AD-integrated DNS server-
    just a couple of my workstations....

    > And then you can use Forwarding to resolve Internet names.

    Yes, the AD-integrated DNS server at each site uses forwarding to resolve
    Internet names...

    > You cannot reliably use two distinct DNS server sets.
    > Don't try. (It may work just enough to convince you otherwise
    > since it will give intermittent results.)

    Since you used the term 'set' twice, and I don't recall encountering
    the use of the term "DNS Server sets" in the resource kit books,
    could you briefly explain?

    And I'm still unclear as to what needs to be fixed...

    Thanks,
    -dq
  5. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    > > I was not referring to routing costs but rather SiteLink costs,
    > > which you cannot avoid because they default to something.
    > > Make them sensible (previous suggestion
    >
    > Since I didn't enter any cost value, I assume I get the defaults...

    Yes, and all are equal, even if that means treating
    a T3 as just as good as an ISDN.

    You are describing you WAN network to the KCC
    when you create site links and give them a cost.

    You are directing the KCC when and how often to
    replicate over that link by giving a Schedule and
    a Frequency.

    > >>> Likely you biggest problem (once you create the sites)
    > >>> will be DNS (most replication issues are really DNS
    > >>> issues once the underlying infracture IP/sites etc. are
    > >>> setup.)
    > >>
    > >> My DNS logs are clean, and DNSLint doesn't list any errors when I
    > >> run it with /ad /s localhost /v. But I *am* having WINS replication
    > >> issues...
    > >
    > > And can all DCs pass a DCDiag test clean?
    >
    > No, as shown in those posted DCDiag logs...

    I will take a look, but generally it's going to be DNS.

    > >> I want GCs in each site, since the WAN links do go down from time to
    > >> time.
    > >> The southernmost site is having problems becoming a GC... that site
    fails
    > >> the
    > >> nSecDesc test...
    > >
    > > You will have problems, especially in Native modes if you
    > > don't get a GC to every site.
    >
    > I have a legacy NT machine I can't upgrade without breaking the
    application,
    > so I've been keeping the enterprise in mixed mode.

    You probably still need the GCs per site, it just isn't
    as fatal (critical) if you don't.

    > >> In the HQ, the GC is also the FSMO, and I get some complaints about
    that,
    > >> and it sees the new server and suggests moving the role to it, but
    again,
    > >> I
    > >> think I can wait on this.
    > >
    > > "the FSMO" indicates a slight misunderstanding.
    > > There is ONE single master role that is recommended
    > > to not be a GC (when you have multiple domains), and
    > > that is the Infrstructure master. The Schema Master/
    > > Domain Naming Master must be a GC.
    > >
    > > You can have lots of GCs - at least one per site.
    >
    > Indeed, how is it possible for anyone who installs a server
    > once every three or four years to master this MS Stuff?
    >
    > Sorry- rhetorical question...
    >
    > Once I get production moved to the new server, and get a
    > chance to clean up the old production server, when I redeploy it,
    > at that time, I can make it be the infrastructure master and not be a GC..
    >
    > I suppoose I could split them now, too, and just reverse roles later,
    > but I don't want to make more work for myself than neeed be...
    >
    > >> I have a NAS unit here, Windows Powered, that's acting as a secondary
    > >> DNS server; I have it mapped to my NIC on my WS as secondary, so I
    > >> can still browse the web when the main server is down. That seems to
    > >> violate
    > >> #2 in your list above...
    > >
    > > That is incorrect. DNS servers must forward to DNS servers which return
    > > the same answers. DNS Clients assume that ALL DNS server know
    > > the same stuff.
    > >
    > > Fix this:
    > >
    > > All DNS clients pointed to strictly the internal DNS server
    > > set -- which must resolve ALL of your internal domains.
    > >
    > > Remember that DCs, even DNS servers themselves are ALSO
    > > DNS clients.
    >
    > None my servers point to this alternate, non-AD-integrated DNS server-
    > just a couple of my workstations....

    Neither should any of your clients.

    > > And then you can use Forwarding to resolve Internet names.
    >
    > Yes, the AD-integrated DNS server at each site uses forwarding to resolve
    > Internet names...

    The point being not to mix internal and external DNS servers
    in such settings.

    Internal only in the client settings, external only in the Forwarding
    settings (if you resolve the Internet and are not using the more
    flexible Win2003 conditional forwarding.)

    > > You cannot reliably use two distinct DNS server sets.
    > > Don't try. (It may work just enough to convince you otherwise
    > > since it will give intermittent results.)
    >
    > Since you used the term 'set' twice, and I don't recall encountering
    > the use of the term "DNS Server sets" in the resource kit books,
    > could you briefly explain?

    It's not commonly used because most of the books don't go
    into this level of practical advice or troubleshooting.

    It is not a technical term but purposely chosen to mean
    all those DNS servers that can fully resolve INTERNAL
    name (when we say "internal DNS server set") no matter
    which zones they hold, or even if they hold no zones.

    For many people this server set holds only the SINGLE
    internal domain/zone name but those people who have
    multiple zones will have different definitions of what is
    and is not in the "internal DNS server set."

    The point being, an internal client must use strictly (internal)
    DNS server(s) which can resolve ALL internal names.

    I refer to that set of servers as the internal "DNS server set".
    > And I'm still unclear as to what needs to be fixed...

    I don't see the DCDiag but you need to resolve all the WARN,
    ERROR, and FAIL messages.

    --
    Herb Martin


    "Douglas H. Quebbeman" <dhquebbeman@theestopinalgroup.com> wrote in message
    news:uSjcv$k$EHA.3472@TK2MSFTNGP14.phx.gbl...
    > In news:%23ljYZRk$EHA.3120@TK2MSFTNGP12.phx.gbl,
    > Herb Martin <news@LearnQuick.com> screib:
    > >>> The idea is to DESCRIBE the underlying WAN to the KCC
    > >>> so that it will calculate the best replication partners/paths.
    > >>
    > >> As small as we are, I'd never messed with routing costs... but it
    > >> sounds like a good idea anyway.
    > >
    > > I was not referring to routing costs but rather SiteLink costs,
    > > which you cannot avoid because they default to something.
    > > Make them sensible (previous suggesti
    >
    > Since I didn't enter any cost value, I assume I get the defaults...
    >
    > >>> Likely you biggest problem (once you create the sites)
    > >>> will be DNS (most replication issues are really DNS
    > >>> issues once the underlying infracture IP/sites etc. are
    > >>> setup.)
    > >>
    > >> My DNS logs are clean, and DNSLint doesn't list any errors when I
    > >> run it with /ad /s localhost /v. But I *am* having WINS replication
    > >> issues...
    > >
    > > And can all DCs pass a DCDiag test clean?
    >
    > No, as shown in those posted DCDiag logs...
    >
    > >> I want GCs in each site, since the WAN links do go down from time to
    > >> time.
    > >> The southernmost site is having problems becoming a GC... that site
    fails
    > >> the
    > >> nSecDesc test...
    > >
    > > You will have problems, especially in Native modes if you
    > > don't get a GC to every site.
    >
    > I have a legacy NT machine I can't upgrade without breaking the
    application,
    > so I've been keeping the enterprise in mixed mode.
    >
    > >> In the HQ, the GC is also the FSMO, and I get some complaints about
    that,
    > >> and it sees the new server and suggests moving the role to it, but
    again,
    > >> I
    > >> think I can wait on this.
    > >
    > > "the FSMO" indicates a slight misunderstanding.
    > > There is ONE single master role that is recommended
    > > to not be a GC (when you have multiple domains), and
    > > that is the Infrstructure master. The Schema Master/
    > > Domain Naming Master must be a GC.
    > >
    > > You can have lots of GCs - at least one per site.
    >
    > Indeed, how is it possible for anyone who installs a server
    > once every three or four years to master this MS Stuff?
    >
    > Sorry- rhetorical question...
    >
    > Once I get production moved to the new server, and get a
    > chance to clean up the old production server, when I redeploy it,
    > at that time, I can make it be the infrastructure master and not be a GC..
    >
    > I suppoose I could split them now, too, and just reverse roles later,
    > but I don't want to make more work for myself than neeed be...
    >
    > >> I have a NAS unit here, Windows Powered, that's acting as a secondary
    > >> DNS server; I have it mapped to my NIC on my WS as secondary, so I
    > >> can still browse the web when the main server is down. That seems to
    > >> violate
    > >> #2 in your list above...
    > >
    > > That is incorrect. DNS servers must forward to DNS servers which return
    > > the same answers. DNS Clients assume that ALL DNS server know
    > > the same stuff.
    > >
    > > Fix this:
    > >
    > > All DNS clients pointed to strictly the internal DNS server
    > > set -- which must resolve ALL of your internal domains.
    > >
    > > Remember that DCs, even DNS servers themselves are ALSO
    > > DNS clients.
    >
    > None my servers point to this alternate, non-AD-integrated DNS server-
    > just a couple of my workstations....
    >
    > > And then you can use Forwarding to resolve Internet names.
    >
    > Yes, the AD-integrated DNS server at each site uses forwarding to resolve
    > Internet names...
    >
    > > You cannot reliably use two distinct DNS server sets.
    > > Don't try. (It may work just enough to convince you otherwise
    > > since it will give intermittent results.)
    >
    > Since you used the term 'set' twice, and I don't recall encountering
    > the use of the term "DNS Server sets" in the resource kit books,
    > could you briefly explain?
    >
    > And I'm still unclear as to what needs to be fixed...
    >
    > Thanks,
    > -dq
    >
    >
  6. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    In news:%23fSM6Ml$EHA.2196@TK2MSFTNGP14.phx.gbl,
    Herb Martin <news@LearnQuick.com> screib:
    >>> Fix this:
    >>>
    >>> All DNS clients pointed to strictly the internal DNS server
    >>> set -- which must resolve ALL of your internal domains.
    >>>
    >>> Remember that DCs, even DNS servers themselves are ALSO
    >>> DNS clients.
    >>
    >> None my servers point to this alternate, non-AD-integrated DNS server-
    >> just a couple of my workstations....
    >
    > Neither should any of your clients.

    This is a great learning experience. I'm trying to imagine how having my
    workstation
    pointing to two DNS servers could cause problems for Active Directory.

    Or, does it only cause problems for the user (me) ? It sure solves them:
    when I
    have the server down for maintenance, as it stands now, I can't resolve
    Internet
    names without having the second DNS server in my NIC's config, UNLESS I
    make the change back and forth every time I have to take the server down.

    >>> And then you can use Forwarding to resolve Internet names.
    >>
    >> Yes, the AD-integrated DNS server at each site uses forwarding to resolve
    >> Internet names...
    >
    > The point being not to mix internal and external DNS servers
    > in such settings.

    Internal and external? The only references that exist to any external DNS
    servers
    are in the forwarders fields in the Win2k & Win2k3 DNS Server config...

    I probably said something to lead you to think I had my workstation's NIC
    pointing
    to one internal DNS server and one outside the office. No, I have a NAS
    running
    Windows Powered, the applicance version of Windows Server, and it's running
    the
    MS DNS Service, as a secondary, "caching-only" server...

    > Internal only in the client settings, external only in the Forwarding
    > settings (if you resolve the Internet and are not using the more
    > flexible Win2003 conditional forwarding.)

    To confirm, yes indeed, in each and every NIC configuration, I am pointing
    ONLY to internal DNS servers. On a few workstations, such as mine, I'm
    pointing to 2 internal servers, but most workstations point only to one.

    >>> You cannot reliably use two distinct DNS server sets.
    >>> Don't try. (It may work just enough to convince you otherwise
    >>> since it will give intermittent results.)
    >>
    >> Since you used the term 'set' twice, and I don't recall encountering
    >> the use of the term "DNS Server sets" in the resource kit books,
    >> could you briefly explain?
    >
    > It's not commonly used because most of the books don't go
    > into this level of practical advice or troubleshooting.
    >
    > It is not a technical term but purposely chosen to mean
    > all those DNS servers that can fully resolve INTERNAL
    > name (when we say "internal DNS server set") no matter
    > which zones they hold, or even if they hold no zones.
    >
    > For many people this server set holds only the SINGLE
    > internal domain/zone name but those people who have
    > multiple zones will have different definitions of what is
    > and is not in the "internal DNS server set."
    >
    > The point being, an internal client must use strictly (internal)
    > DNS server(s) which can resolve ALL internal names.
    >
    > I refer to that set of servers as the internal "DNS server set".
    >> And I'm still unclear as to what needs to be fixed...
    >
    > I don't see the DCDiag but you need to resolve all the WARN,
    > ERROR, and FAIL messages.

    I posted the output from four invocations of DCDiag in my web storage
    area; each DCDIAG.TXT file was the result of running

    DCDIAG /E /C /FIX /V

    on each of my 4 domain controllers, and the links the to four log files
    can be found on this page:

    http://members.iglou.com/dougq/MyActiveDirectoryProblems.html

    I am posting these DCDiags precisely because I require assistance in
    resolving the various warnings and errors... and I really appreciate all
    the help I can get!

    Regards,
    -doug q
  7. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    > >> None my servers point to this alternate, non-AD-integrated DNS server-
    > >> just a couple of my workstations....
    > >
    > > Neither should any of your clients.
    >
    > This is a great learning experience. I'm trying to imagine how having my
    > workstation
    > pointing to two DNS servers could cause problems for Active Directory.

    It won't (don't smoke your brain <grin>). It will cause
    problems for THAT client authenticating and for things
    like your own resource and admin access.

    Pointing it correctly will maintain all of the above
    (authentication and privileges) while STILL allowing
    you to resolve (and use) the Internet.

    > Or, does it only cause problems for the user (me) ? It sure solves them:
    > when I
    > have the server down for maintenance, as it stands now, I can't resolve
    > Internet
    > names without having the second DNS server in my NIC's config, UNLESS I
    > make the change back and forth every time I have to take the server down.

    You should have two servers and really should never bring
    them both down together.

    During such a time (if they must be down) you should consciously
    change your workstation and then change it back.

    There is no guaratee the other way and it should not
    be depended up.

    > >>> And then you can use Forwarding to resolve Internet names.
    > >>
    > >> Yes, the AD-integrated DNS server at each site uses forwarding to
    resolve
    > >> Internet names...
    > >
    > > The point being not to mix internal and external DNS servers
    > > in such settings.
    >
    > Internal and external?

    Point your clients at ONLY servers which can fully
    resolve the internal names.

    By external, I mean any DNS server than cannot resolve
    those internal names.

    > The only references that exist to any external DNS
    > servers
    > are in the forwarders fields in the Win2k & Win2k3 DNS Server config...

    And they should not reference internal (in almost all cases)
    so that is NOT a mix.

    > I probably said something to lead you to think I had my workstation's NIC
    > pointing
    > to one internal DNS server and one outside the office. No, I have a NAS
    > running
    > Windows Powered, the applicance version of Windows Server, and it's
    running
    > the
    > MS DNS Service, as a secondary, "caching-only" server...

    It is it doing (only) external name resolution then it
    is NOT a member of the internal set of DNS servers (despite
    it's physical location.)

    It's purpose sounds like EXTERNAL (i.e., Internet) resolution.
    It should only be referenced in the DNS forwarders entries.

    > > Internal only in the client settings, external only in the Forwarding
    > > settings (if you resolve the Internet and are not using the more
    > > flexible Win2003 conditional forwarding.)
    >
    > To confirm, yes indeed, in each and every NIC configuration, I am pointing
    > ONLY to internal DNS servers. On a few workstations, such as mine, I'm
    > pointing to 2 internal servers, but most workstations point only to one.

    It's unreliable. It will not always autocorrect and
    reconfigure when the internal DNS goes off line
    and returns.


    > >>> You cannot reliably use two distinct DNS server sets.
    > >>> Don't try. (It may work just enough to convince you otherwise
    > >>> since it will give intermittent results.)
    > >>
    > >> Since you used the term 'set' twice, and I don't recall encountering
    > >> the use of the term "DNS Server sets" in the resource kit books,
    > >> could you briefly explain?
    > >
    > > It's not commonly used because most of the books don't go
    > > into this level of practical advice or troubleshooting.
    > >
    > > It is not a technical term but purposely chosen to mean
    > > all those DNS servers that can fully resolve INTERNAL
    > > name (when we say "internal DNS server set") no matter
    > > which zones they hold, or even if they hold no zones.
    > >
    > > For many people this server set holds only the SINGLE
    > > internal domain/zone name but those people who have
    > > multiple zones will have different definitions of what is
    > > and is not in the "internal DNS server set."
    > >
    > > The point being, an internal client must use strictly (internal)
    > > DNS server(s) which can resolve ALL internal names.
    > >
    > > I refer to that set of servers as the internal "DNS server set".
    > >> And I'm still unclear as to what needs to be fixed...
    > >
    > > I don't see the DCDiag but you need to resolve all the WARN,
    > > ERROR, and FAIL messages.
    >
    > I posted the output from four invocations of DCDiag in my web storage
    > area; each DCDIAG.TXT file was the result of running
    >
    > DCDIAG /E /C /FIX /V

    Generally, DCDiag is fine (as long as you run it on each server.)

    Fix is nice, but it won't fix everything so I run it once, then
    run it again to see what errors remain.

    > on each of my 4 domain controllers, and the links the to four log files
    > can be found on this page:
    >
    > http://members.iglou.com/dougq/MyActiveDirectoryProblems.html
    >
    > I am posting these DCDiags precisely because I require assistance in
    > resolving the various warnings and errors... and I really appreciate all
    > the help I can get!


    Try RepAdmin and ReplMon for checking your replication.

    How do DNS servers from each domain resolve the DNS of
    the "other domain" ?

    Does each hold cross secondaries for the other or what?
    > Regards,
    > -doug q
    >


    --
    Herb Martin


    "Douglas H. Quebbeman" <dhquebbeman@theestopinalgroup.com> wrote in message
    news:u8fkvel$EHA.208@TK2MSFTNGP12.phx.gbl...
    > In news:%23fSM6Ml$EHA.2196@TK2MSFTNGP14.phx.gbl,
    > Herb Martin <news@LearnQuick.com> screib:
    > >>> Fix this:
    > >>>
    > >>> All DNS clients pointed to strictly the internal DNS server
    > >>> set -- which must resolve ALL of your internal domains.
    > >>>
    > >>> Remember that DCs, even DNS servers themselves are ALSO
    > >>> DNS clients.
    > >>
    >
  8. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    In news:u7hYs5l$EHA.2196@TK2MSFTNGP14.phx.gbl,
    Herb Martin <news@LearnQuick.com> screib:
    >> http://members.iglou.com/dougq/MyActiveDirectoryProblems.html
    >>
    >> I am posting these DCDiags precisely because I require assistance in
    >> resolving the various warnings and errors... and I really appreciate all
    >> the help I can get!
    >
    > Try RepAdmin and ReplMon for checking your replication.

    Ok...

    > How do DNS servers from each domain resolve the DNS of
    > the "other domain" ?
    >
    > Does each hold cross secondaries for the other or what?

    Each domain has a DNS server that has a forward lookup zone,
    and is authoritative for that domain. Then, each DNS server also
    has a forward lookup zone for the other two domains. And yes,
    they are 'standard secndaries'.

    Each DNS server also has a reverse lookup zone covering the
    subnet for its corresponding site. No cross-secondaries here...

    Regards,
    -dq
  9. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    In news:u7hYs5l$EHA.2196@TK2MSFTNGP14.phx.gbl,
    Herb Martin <news@LearnQuick.com> screib:
    >
    > Try RepAdmin and ReplMon for checking your replication.
    >

    Here's what I got:

    **************************************************************
    REPADMIN /showreps DC=hqdom,DC=com
    **************************************************************

    HQ_Site\old_hq_server
    DSA Options : IS_GC
    objectGuid : aeb5ba3a-9fc0-4f10-ab33-d4842fb8a2c6
    invocationID: 23d01027-ddaf-4e70-92a2-bd8a4481bae8

    ==== INBOUND NEIGHBORS ======================================

    DC=hqdom,DC=com
    HQ_Site\new_hq_server via RPC
    objectGuid: 0ca6fbde-d311-47ef-af23-d04e37da0c3f
    Last attempt @ 2005-01-19 16:52.16 was successful.

    ==== OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ============

    DC=hqdom,DC=com
    HQ_Site\new_hq_server via RPC
    objectGuid: 0ca6fbde-d311-47ef-af23-d04e37da0c3f


    **************************************************************
    REPADMIN /showreps DC=southdom,DC=com
    **************************************************************

    HQ_Site\old_hq_server
    DSA Options : IS_GC
    objectGuid : aeb5ba3a-9fc0-4f10-ab33-d4842fb8a2c6
    invocationID: 23d01027-ddaf-4e70-92a2-bd8a4481bae8

    ==== INBOUND NEIGHBORS ======================================

    DC=southdom,DC=com
    HQ_Site\OLD_SOUTH_SERVER
    DEL:ba447c07-2878-4b98-a285-b6a5ef141ade (deleted DSA) via RPC
    objectGuid: e90e38ad-ad3b-41ba-b713-bdb08722b399
    West_Site\west_server via RPC
    objectGuid: d19e0173-1d3e-4964-a003-3cbfaae9b898
    Last attempt @ 2005-01-19 16:39.03 was successful.
    South_Site\south_server2k3 via RPC
    objectGuid: ecbb97fa-2aed-4a7c-bc8f-197d6ccc7c5b
    Last attempt @ 2005-01-19 16:39.03 was successful.

    ==== OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ============


    **************************************************************
    REPADMIN /showreps DC=westdom,DC=com
    **************************************************************

    HQ_Site\old_hq_server
    DSA Options : IS_GC
    objectGuid : aeb5ba3a-9fc0-4f10-ab33-d4842fb8a2c6
    invocationID: 23d01027-ddaf-4e70-92a2-bd8a4481bae8

    DsReplicaGetInfo failed with status 8440 (0x20f8):
    The naming context specified for this replication operation is invalid.


    And I knew the problems were pointing 'westward'...

    -dq
Ask a new question

Read More

Servers Active Directory Windows