PC's join domain to remote site DC's

[Guest]

When joining a pc to the domain at the host site, the accepting DC ends up
being a DC at a remote-site.

I have 3 DC's at my host site, and only 1 at each remote.

I'm using Sites and Services, and have setup all my locations with Subnets.

I also checked the DNS in Active Directory at the host site.

Any ideas?

 

[Ryan Hanisco]

When joining workstations to a domain, the workstation needs to be able to
access domain resources that are not being hosted by your remote DCs. These
would be things like the PDC Emulator and RID Master. This behavior is to
be expected.

For that join, they will need to talk to the domain masters, after that,
they should be able to authenticate locally. Take a look at your FSMO Role
placement and see if that makes sense. Otherwise post back and we can look
at other things.

Ryan Hanisco
MCSE, MCDBA
Flagship Integration Services

 

[Guest]

Ryan,

Sorry. I guess I didn't do a good job of explaining the issue.

The new pc's at the host site are currently joining the domain to a remote
site DC.

They should be joining the domain to one of the available host site DC's.

I don't know why this is happening. So far, I've checked my sites and
services/subnetting, and DNS.

Sorry for the confusion.

 

[Glenn L]

conundrum,

When a computer joins the domain, it does not know which site it is in.
It sends a query for the following record in DNS.
_LDAP._TCP.DS._MSDCS.domainname.com

Every domain controller registers this record and the DNS query result will
supply the client with a list of all DCs.
This list will be randomized since all the records have the same weight and
priority by default.

The client uses the first entry in the list and connects to that DC to join
the domain.

The only way to control this behavior is to tweak the weight and/or priority
of these DNS records.
You could increase the priority and weight of a the record for the DC in
your host site.
This way the DNS query result will order the reply with the desired DC at
the top of the list.


Regards,

 

[Glenn L]

When a computer joins the domain, it does not know which site it belongs to.
It queries for _LDAP._TCP.DS._MSDCS.domainname.com

Every DC registers this record, and the DNS server will reply with a
randomized list of all the DCs in the domain.
The client then picks the first one in the list to connect to and join the
domain.
This DC could conceivably be on the other side of the planet.
The only way to control this behavior is to use the priority and weight
fields on the LDAP records.
You would increase the priority and weight for the DC you want computers to
use when joining the domain.

Then when the client qeries the LDAP record, the DNS server will order the
reply based on priority and weight.
The record with the highest priority will then be used when joining the
domain.

 

[ptwilliams]

Enabling net mask ordering (subnet prioritisation) can help with this too;
then the returned DC isn't random.

--

Paul Williams

http://www.msresource.net
http://forums.msresource.net


When a computer joins the domain, it does not know which site it belongs to.
It queries for _LDAP._TCP.DS._MSDCS.domainname.com

Every DC registers this record, and the DNS server will reply with a
randomized list of all the DCs in the domain.
The client then picks the first one in the list to connect to and join the
domain.
This DC could conceivably be on the other side of the planet.
The only way to control this behavior is to use the priority and weight
fields on the LDAP records.
You would increase the priority and weight for the DC you want computers to
use when joining the domain.

Then when the client qeries the LDAP record, the DNS server will order the
reply based on priority and weight.
The record with the highest priority will then be used when joining the
domain.

 

[Glenn L]

I think netmask ordering is enabled by default.
Also, I don't believe subnet prioritization will work in this instance.
This advanced feature is useful when the client is querying a HOST record.
HOST records contain the IP addresses of the hosts which "subnet
prioritization" can order based on the subnet of the client.
During the domain join, the client is quering an SRV record. The values of
these SRV records have no IP addresses, therefore the subnet prioritization
feature would not play a role in ordering the list of names in the reply.

 

[ptwilliams]

Hmmm, not sure either. Even though the SRV returns a name, that name has to
be resolved. Net Mask ordering certainly comes into play with site-less
workstations...so I would have thought that it is used here too...



--

Paul Williams

http://www.msresource.net
http://forums.msresource.net


I think netmask ordering is enabled by default.
Also, I don't believe subnet prioritization will work in this instance.
This advanced feature is useful when the client is querying a HOST record.
HOST records contain the IP addresses of the hosts which "subnet
prioritization" can order based on the subnet of the client.
During the domain join, the client is quering an SRV record. The values of
these SRV records have no IP addresses, therefore the subnet prioritization
feature would not play a role in ordering the list of names in the reply.

 

[Guest]

Wouldn't changing the weight on a DC in one site replicate to all sites if
you're using Active Directory Integrated Zones?

 

[Ryan Hanisco]

When joining a workstation, the FSMO role holder must be involved. Just as
their name implies, they are Single Master -- there is only one in the
domain.

Changing the weight would make it preferred when a client is requesting
services against like services by SRV record. Remember though, that a lot
of things are divided by site and that clients are site aware.

I am giving you the solution based on my experience and best practices in
the industry. There are other ways to effect a similar behavior, but this
is quirky and manipulating the tools to do this rather than relying on the
AD infrastructure components and their "normal" behaviors.