Keith B. Rosenberg <(E-Mail Removed)> wrote:
> Thanks for the reply. It is flaky in that it goes down more often
> than DSLs here in the states. When it is up, it works fine. The DSL
> we are having problems with is from Bell Canada and I am not at all
> impressed with its reliability or pricing structure (they charge if
> you go over the outbound quota).
Are they your only option?
>
> It supposedly is a business class DSL, but we have had problems with
> keeping a DC replicating over some DSL links (AT&T links actually).
SDSL? Don't use ADSL. Get a
>
> Keith
I'd see about investing in a T1 or a point to point link. The bandwidth
required for your DCs to replicate shouldn't be that great, esp compared to
that required for your users to authenticate & access data. Why have a
member server that regularly has no contact with the domain? Seems like a
bad setup to me.
Or just toss out the local server idea, and use a TS box in the main office.
That's a better use of bandwidth anyway.
>
>
>
>
> "Lanwench [MVP - Exchange]"
> <(E-Mail Removed) hoo.com> wrote in
> message news:(E-Mail Removed)...
>> Keith B. Rosenberg <(E-Mail Removed)> wrote:
>>> Hi! We have a remote office on a VPN WAN using a DSL link. The link
>>> went down the other night and was still not up when the users came
>>> in the next morning. They could logon to their computers, but could
>>> not access the local server. The server at the remote office is a
>>> member of the domain, but is not a Domain Controller. Making it a
>>> DC is not an option since the DSL link is pretty flaky.
>>
>> That doesn't make a lot of sense. So instead, you want your users
>> authenticating to a remote DC over a flaky WAN link? That sounds
>> like a far worse option to me. Since you've got AD and this server
>> belongs to the domain, I'd promote it to be a DC, put it in a
>> separate AD site/subnet, and join all computers to the domain. Don't
>> set up local user accounts for them at all. Users will always be
>> able to log into the domain - even if there's no connection between
>> the sites - and access local resources. You should also investigate the
>> flaky DSL situation. DSL isn't
>> usually the best choice for this sort of thing, especially if it
>> isn't fast business-class SDSL. A full T1 shouldn't run you that
>> much any longer, if you still want to use VPN - or a point to point
>> connection, although that may not be optimal.
>>
>>> As a work-around they
>>> put the a user account for each user on the server, but that is not
>>> really a good solution.
>>
>> Definitely not.
>>>
>>> Is there a way to tell the server in the remote office to allow
>>> access if it cannot connect to the DCs?
>>
>> Hope the above helps.
>>>
>>> Thanks!!!!
|