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
C-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
C-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
>
>