Re: Satellite Branch Office Woes
- From: "Danny Sanders" <DSanders@xxxxxxxxxxxxxxx>
- Date: Fri, 12 Jan 2007 16:58:48 -0700
I would suggest putting a domain controller with DNS in the site. AD client
use DNS to "find" *anything*. You are probably sending all that info along
the "DSL" (not a T1?)
Look around the MS site for info on setting up and AD site. Setting up an AD
site will allow your client in that site to use the DC in that site for
logons and DNS
hth
DDS
"Slandrum" <Slandrum@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:EA7C3AAC-E839-41CF-BFFB-9151B5A5C546@xxxxxxxxxxxxxxxx
We are currently testing a traditional satellite branch office solution
(no
servers in the SBO) for several small locations that will be coming online
this year. I've been through several different sources now, including the
WSSRA, but either I've missed something completely, or I am stuck with an
(unacknowledged) WAN configuration issue. Hopefully you folks can help me
decide which.
To elaborate, we have the traditional setup where we have a WAN guy who
handles all the telecom stuff, and then we have a Windows server guy (me)
who
handles all the Windows/AD stuff, etc. Although we work well together, the
WAN guy is pretty anti-MS, which means that anytime I suspect something
amiss
on his end, I have to really jump through the hoops to get him to
double-check configuration settings on his side of the fence. Otherwise
his
answer is always "Must be a Microsoft issue". And he may be right, this
time,
or at least a "Windows Admin issue". ;-)
At any rate, he has setup a DSL connected VPN IPSEC tunnel that is
entirely
hardware based. At one end of the tunnel he has a Cisco router, and at the
other end a Cisco VPN Concentrator. I'm not sure of the actual model
numbers,
but for the sake of this discussion it shouldn't really matter. There are
a
few other hardware devices in between, a VLAN, etc, but still pretty
standard
from what I've reviewed thus far. He is handling the IPSEC via an internal
Cisco certificate solution, so right now I view this connection as being a
straight through, clean pipe, just like it was one of our WAN circuits.
It passes pings just fine, and I have done some portqry testing to verify
that LDAP, Kerberos, NTLM, SMB and various other TCP/UDP traffic types go
through okay, so right now I don't think it's a port blocking issue. I
tested
in both directions, so all should be fine, but the behavior I am seeing
makes
me wonder if there is a port filtering issue, or a bounce issue, etc.
Since as I said I view the connection as operating just like one of our
WAN
links, the only AD side change I made was to create a subnet to match the
SBO
site and assigned it to the Central AD Site. Based on experience and
subsequent re-checking, I see no other required AD changes at this time.
However, I could be wrong in this.
We have a client PC in the SBO running WinXPsp2. At first "the WAN guy"
was
providing DHCP from the Cisco router endpoint on the SBO side, but just to
make it cleaner I have since given the PC a manual IP address, with two
DNS
entries, a WINS entry and so on. I will eventually provide DHCP from the
Central Site as well, but not until I can get past the current issue.
Also, due to SPNEGO errors in the Event Log of the client PC that match KB
article numbers 891559 and 885887, I have applied the kereberos.dll sp2
hotfix as described in KB 885887 in an attempt to correct the below
described
problems. It didn't help any.
The PC itself does have a workstation account in the domain, and I have
placed this account in its own OU and have checked on "Block Policy
Inheritance" to ensure that it's not receiving any of our GPOs. And its
Host
entry does appear in the AD-integrated DNS Zone for the Domain. I have
also
configured a reverse lookup zone for the SBO subnet.
The primary problem that I am seeing is that the PC will not log into the
domain. It accepts the domain user name and password, albeit rather
slowly,
then goes to the "Loading Your Personal settings" screen and stays there .
forever. This occurs whether I am attaching via Remote Desktop, or if he
is
actually logging in at the console. We have left it at this stage for as
much
as 24 hours at one point, and it never completes the login.
I can attach to the PC with Remote Desktop (through the VPN IPSEC Tunnel)
but I receive the standard "user domain/username is currently logged in ."
message that requires me to do a forced Remote Logoff. This often will
take
several tries, but eventually the incomplete domain login session will
end.
Once it does I can attach to the PC with Remote Desktop by logging onto
the
local machine Administrator account. I can then attach to domain resources
on
our file servers by providing a domain/username and password when prompted
to
do so. However, these operations are also very slow; much slower than the
ping times would lead me to expect.
I'm sorry this is sooo long, but I've tried to paint as complete a picture
as possible to eliminate the "did you check this and this" stuff, but will
watch for and happily answer any additional configuration or environment
questions you may have.
What do you think I've missed, or barring that, what should I have "the
WAN
guy" check?
.
- References:
- Satellite Branch Office Woes
- From: Slandrum
- Satellite Branch Office Woes
- Prev by Date: Re: Removing child domain
- Next by Date: Re: Auditing - User add / remove from Group
- Previous by thread: Satellite Branch Office Woes
- Next by thread: Re: Satellite Branch Office Woes
- Index(es):
Relevant Pages
|
