Can I Bridge AD across a frame relay network??

  • Thread starter Thread starter jokes54321
  • Start date Start date
J

jokes54321

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?
 
jokes54321 said:
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
Click to expand...

Bridging the WAN or routing it is not a function of AD.

If you mean can you run an AD domain across such WANS,
then yes.
I don't know how chatty AD traffic is, would the traffic be to much of a
load on 256K frame relay circuits?
Click to expand...

Probably not since you likely have a small domain even with
those extra sites but you didn't really tell us.

You can also set the replication schedule to avoid any time
period in which reduced traffic is necessary.

You CAN run such without DCs at the locations but it
will mean that access to resources may be limited if
the WAN is down.

Even a single DC at each location would be better.

DCs are cheap. A few hundred dollars for hardware and
buy the cheaper Standard Server product (on eBay if you
must) for a few hundred more.
[/QUOTE]
 
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
 
I forgot to add, most sites only have 10 computers at most. We have two
larger sites that are around 40-50.
Each remote site is 256K, the two larger sites are 512K and the host site is
a full T1.
 
jokes54321 said:
I forgot to add, most sites only have 10 computers at most. We have two
larger sites that are around 40-50.
Each remote site is 256K, the two larger sites are 512K and the host site is
a full T1.
Click to expand...

The key questions to ask yourself about a local DC
is this:

Are there local domain resources?

Would loss of access to these resources be unacceptable
(when the WAN is down)?

If the answer to both is "yes" then you need a DC (perhaps
two) in that site.

Without local domain resources the WAN will disconnect
the stations from any resources anyway so authentication is
not critical when the WAN is down.

With access to local domain resources being critical,
you cannot afford to lose that when the WAN is down,
the DC must be local.

There is also the minor reason of performance and WAN
usage but for only a few stations and only a small domain
it probably doesn't matter much.

IF you put a DC there, you almost certainly make it a DNS
server too.
 
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
 
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.
Click to expand...

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?
Click to expand...

Yes. As long as the WAN supports the traffic and the
Name Resolution (DNS) is setup it should just work.
 
Thank you so much. I will attempt to join one of our New York computers to
our domain tomorrow.


Thank you again,

Denny
 
jokes54321 said:
Thank you so much. I will attempt to join one of our New York computers to
our domain tomorrow.
Click to expand...

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: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.
 
jokes54321 said:
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?
Click to expand...

We have one client with 8 offices in various parts of the country - each
office has 2 computers. The two computers connect with the home office
through a VPN router across either a T1, Business Class Cable modem, or
a wireless internet connection. With the VPN's they are part of the
domain as much as any other node, but they are slower.

Logon takes 3~5 times as long as being part of the home office LAN.
Storage of files in the My Documents folder makes logon longer. No files
are stored on the local computers (business documents), and users have 6
~12 mapped drives to the main server - clicking on a document takes
seconds to respond (and users often click many times before the first
item opens, leading to many instances of the same document). Outlook
2003 is setup for all users, not in cached mode, and users experience
slowness anytime they have attachments (most never have attachments).
For the users that have large email boxes we did implement cached mode,
but it's still slow for the new mail.

One big thing is when the VPN's go down, even with many instances of
telling them to check to see if they can get to GOOGLE.COM or MSN.COM,
they still don't understand that they have to be able to get to the
INTERNET for the VPN's to work....

A 256k line, for files/email, would be very slow in my experience - our
Cable connections are 3mbps downstream and 1mbps upstream and I still
think it's slow when I'm at the remote offices.
 
Back
Top