Archived from groups: microsoft.public.win2000.active_directory (
More info?)
"jokes54321" <jokes54321@nospam.com> wrote in message
news:OhgdV50$EHA.2180@TK2MSFTNGP10.phx.gbl...
> Thank you so much. I will attempt to join one of our New York computers to
> our domain tomorrow.
>
If you have problems on an open connection (no firewalls
stopping you) where you can ping, then it is almost certainly
a DNS error.
You are probably good on this stuff but the CLIENT part is
also crticial....
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
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.
--
Herb Martin
>
> Thank you again,
>
> Denny
>
>
> "Herb Martin" <news@LearnQuick.com> wrote in message
> news:utDqSv0$EHA.2600@TK2MSFTNGP09.phx.gbl...
> >> I agree a server at each location would be ideal. Here in town we have
> > three
> >> AD servers in the Phoenix office and one AD server in our Scottsdale
> > office,
> >> which is connected via a point to point T1. The one AD server in the
> >> Scottsdale office hosts DHCP and File server services. This is the
office
> > my
> >> boss works out of. I explained it wouldn't be any different than his
> >> location but still got shot down.
> >>
> >> I've noticed a couple of you suggested the remote DC GC should run DNS.
> > I'm
> >> curious as to why? In our Phoenix/Scottsdale scenario we only run DNS
at
> > the
> >> Phoenix location, but we do run WINS on one AD at each site.
> >
> > Because it is likely that if authentication is critical (e.g.,
> > access to domain resources is critical) then likely so
> > is name resolution in general, and DNS in particular
> > (which interfere directly with authentication as well as
> > with just finding the resource by name.)
> >
> > If DNS is critical (as it is in such cases) then you don't
> > won't to lose it when the WAN goes down -- were that
> > acceptable you probably wouldn't need the DC either.
> >
> > One note, it is POSSIBLE to do without the WINS servers
> > locally MORE EASILY than the DNS servers -- especially
> > when the site only has one subnet.
> >
> > WINS clients can be set to M-node -- broadcast for all local
> > resources on the same (local) subnet, use WINS across the
> > WAN only for the remote resources, which will themselves
> > be unreachable any time a lost WAN removes access to the
> > WINS server.
> >
> > Not really an issue for you, but for those with 2000 subnets
> > (especially single subnet per location) getting rid of all
> > those WINS servers is a BIG DEAL.
> >
> >> How do I go about joining a remote machine to our domain over the WAN?
Do
> > I
> >> just type in the fully qualified domain name like I would do locally?
> >
> > Yes. As long as the WAN supports the traffic and the
> > Name Resolution (DNS) is setup it should just work.
> >
> > --
> > Herb Martin
> >
> >
> > "jokes54321" <jokes54321@nospam.com> wrote in message
> > news:OKpAVlz$EHA.3592@TK2MSFTNGP09.phx.gbl...
> >> Thank you all for your feedback. My boss shot down the servers at each
> >> location because he feels it's not needed. His thinking is we've been
> >> running fine for 10 years in a workgroup environment, why change now. I
> >> explained the centralized management of user accounts, managing the
> > machines
> >> via group policies, file server services, DHCP instead of static IP
> >> addresses. For every one of those he said that's what he pays me for.
> >>
> >> We utilize Terminal Services heavily to central our custom written, in
> >> house, applications. Since we depend on the private frame relay cloud
to
> > run
> >> every aspect of our business (being everything is run over Terminal
> >> Services), we do have 128K ISDN backup lines. The only program that is
> >> not
> >> centralized is the Office suite, which is on a few workstations at each
> >> location. Each user saves their files to their local computer and
> >> manually
> >> backs them up to floppies or USB flash drives, so the only real WAN
> > traffic
> >> should be the group policies and logon validations.
> >>
> >> I agree a server at each location would be ideal. Here in town we have
> > three
> >> AD servers in the Phoenix office and one AD server in our Scottsdale
> > office,
> >> which is connected via a point to point T1. The one AD server in the
> >> Scottsdale office hosts DHCP and File server services. This is the
office
> > my
> >> boss works out of. I explained it wouldn't be any different than his
> >> location but still got shot down.
> >>
> >> I've noticed a couple of you suggested the remote DC GC should run DNS.
> > I'm
> >> curious as to why? In our Phoenix/Scottsdale scenario we only run DNS
at
> > the
> >> Phoenix location, but we do run WINS on one AD at each site.
> >>
> >> How do I go about joining a remote machine to our domain over the WAN?
Do
> > I
> >> just type in the fully qualified domain name like I would do locally?
> >>
> >> Thank you,
> >>
> >> Denny
> >>
> >>
> >>
> >> "Cary Shultz [A.D. MVP]" <cwshultz@mvps.org> wrote in message
> >> news:OW$Xdhq$EHA.3428@TK2MSFTNGP10.phx.gbl...
> >> > Yes, it is very possible and done all the time. The thing to
consider
> > is
> >> > that you will most likely want to set up some sort of Site-to-Site
VPN
> >> > (
> >> > aka Firewall-to-Firewall VPN ). That is, unless you have a private
> >> > link
> >> > ( read: T1 ) between the physical locations.
> >> >
> >> > How you would normally ( okay, poor choice of terms...... ) set
things
> > up
> >> > when you have several physical locations is that you have at least
two
> >> > Domain Controllers in the HQ and one Domain Controller in each
'Branch
> >> > Office'. Now, this depends on how many users are in each remote
> >> > office!
> >> > If you have three users then you probably would not need a DC. In
> >> > fact,
> >> > you would probably make user of Terminal Server!
> >> >
> >> > So, let's assume that you have something like 35 users in each remote
> >> > office. You would probably have one Domain Controller in each of the
> > two
> >> > remote offices. You would need to make sure that you set up the
Sites
> >> > correctly ( done in the Active Directory Sites and Services MMC ) and
> > that
> >> > you create a Subnet for each location ( so, 192.168.1.x for the HQ,
> >> > 192.168.2.x for one remote office and 192.168.3.x for the other
remote
> >> > office ) and then associate the Subnet with the correct Site. You
> >> > would
> >> > then make sure that each DC is also a Global Catalog Server and that
> >> > DNS
> >> > and DHCP was running on at least one DC in each location.
> >> >
> >> > This accomplished two things: it allows you to speed up users log on
(
> > as
> >> > they are authenticating against a local Domain Controller - meaning
one
> > in
> >> > the Site in which the are locating ) and you control Active Directory
> >> > Replication.
> >> >
> >> > You would need to create the Site Links ( so, probably HQ-Site1 and
> >> > HQ-Site2 ). Stick with the defaults for the cost. The interval is,
by
> >> > default, 180 minutes ( 3 hours ). Depending on how you do things
would
> >> > determine if that was okay or not ( I would probably keep it there
but
> > you
> >> > might want to change it either way to 90 minutes or to 240 minutes ).
> >> >
> >> > The server in each remote location would also be the File
Server....you
> >> > really do not want to be saving things across a WAN. I used to work
in
> > an
> >> > environment where there were two Sites connected by a private T1.
> > Really
> >> > small files were okay ( and I mean really small ) but when things got
a
> >> > bit bigger ( like 256kb ) you would notice delays.
> >> >
> >> > If you do not mind why was your suggestion denied?
> >> >
> >> > Naturally, I am assuming that you have WIN2000 Active Directory with
> >> > WIN2000 or WINXP Clients. If you really want to manage everything
> >> > centrally have you looked into Terminal Server. maybe with Citrix?
> >> > WIN2003 Terminal Server is really nice. That might be what you want.
> > But
> >> > we would need some more details!
> >> >
> >> >
> >> > --
> >> > Cary W. Shultz
> >> > Roanoke, VA 24014
> >> > Microsoft Active Directory MVP
> >> >
> >> >
http://www.activedirectory-win2000.com
> >> >
http://www.grouppolicy-win2000.com
> >> >
> >> >
> >> >
> >> > "jokes54321" <jokes54321@nospam.com> wrote in message
> >> > news:uNQygNq$EHA.3472@TK2MSFTNGP14.phx.gbl...
> >> >> Is it possible to bridge AD services across a WAN. We run an AD
domain
> > in
> >> >> our central office but each of our remote sites are workgroups. I've
> >> >> lobbied for a pair of cheap servers at each location but lost. I am
> >> >> wondering if it's possible to bridge those services? Our main goal
is
> > to
> >> >> centrally manage logons and security settings
> >> >>
> >> >> I don't know how chatty AD traffic is, would the traffic be to much
of
> > a
> >> >> load on 256K frame relay circuits?
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>