>>>> aware once the client discovers there is no DC on its own subnet the >>>> dsgetsite api sends an dns query for the SRV >>>> _LDAP._tcp.dc._msdcsdomainname, i.e give me a DC that is responsible for >>>> the X domain. DC should then inform the client, based upon the IP >>>> information that the client belongs to x Site and for this site are X and >>>> X DC's are repsonbile. DsGetDcName finds a DC but in this case a DC in the >>>> core location, not its closest.
True when the client is joined to the domain. When it is not joined to the
domain the client does not issue a "give me a DC in site X" query. It issues a
"give me a DC in domain XYZ" query. It receives a response from DNS with ALL
the DCs listed that registered the domain wide service resource records. By
default all the DCs register the domain wide service resource records and the
site wide service resource records. To prevent, where a client in branch office
site X is serviced by a DC in branch office site Y after issuing a query for
"give me a DC in domain XYZ", it is a best practice to disable registration of
the domain wide service resource records by the branch office DCs and only
allow the HUB (main) office DCs to that. Most probably you have configured that
as you are saying the object creation is always done in the HUB. If you want to
target the computer account creation to the nearest DC, either:
· You use NETDOM manually
· You create some script/tool that:
o Checks IP of client
o Matches that to a subnet in AD
o Retrieves the AD site that has that subnet
o Query DNS for a DC in that site and use that in NETDOM
Example: NETDOM JOIN /DOMAIN:<domain>\<DC> /userD: <domain>\<user>
/PasswordD:<password> /OU:<DN of OU> /REboot
-----------
NETDOM JOIN Joins a workstation or member server to the domain.
machine is the name of the workstation or member server to be joined
/Domain Specifies the domain which the machine should join. You
can specify a particular domain controller by entering
/Domain:domain\dc. If you specify a domain controller, you
must also include the user's domain. For
example: /UserD:domain\user
/UserD User account used to make the connection with the domain
specified by the /Domain argument
/PasswordD Password of the user account specified by /UserD. A * means
to prompt for the password
/UserO User account used to make the connection with the machine to
be joined
/PasswordO Password of the user account specified by /UserO. A * means
to prompt for the password
/OU Organizational unit under which to create the machine account.
This must be a fully qualified RFC 1779 DN for the OU.
If not specified, the account will be created under the default
organization unit for machine objects for that domain.
/REBoot Specifies that the machine should be shutdown and automatically
rebooted after the Join has completed. The number of seconds
before automatic shutdown can also be provided. Default is
30 seconds
-----------
Met vriendelijke groeten / Kind regards,
__________________________________________________________________________________
MVP Profile à
https://mvp.support.microsoft.com/profile=f8c04f4a-bff2-453e-9aed-7dfedab0be10
MVP Home Site à https://mvp.support.microsoft.com/
MVP Overview à https://mvp.support.microsoft.com/mvpexecsum
BLOG à http://blogs.dirteam.com/blogs/jorge/default.aspx
__________________________________________________________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Holt, Will
Sent: Friday, January 12, 2007 12:43
To: 'activedir@mail.activedir.org'
Subject: [ActiveDir] DC Locator process\Site Topology
Hi All,
# W2K3 DFM - Windows Server 2003
# FFM - Windows Sever Interim.
I have the following site topology. Network: Two Core locations(MAN Gbps), on
to which are attached 9 backbone locations(155Mbps). Access2 locations are
attached to one backbone with a VPN(ISDN\DSL) fallback back to one of the Core
locations. DC's are placed only on the core and backbone locations (this is
domestic, i.e Germany). There are a total of 872 locations world wide. For the
site (objects of type siteLink, subnet and site) information I have a scripted
solution.
Every network location has a site, and the subnets are allocated at this level
enabling us to offer "service location" for DFS and print, i.e I have
serverless sites which are "covered" by the relevant DC's on the core and
backbone levels. I qualify the clients "site awareness" with nltest
/server:XXXXXX /dsgetsite - no problems. I then qualify with nltest
/server:DCNAME / dsgetsitecov that the server is "covering" the site with the
value from the last query - no problems.
These changes have been made before Christmas after a major network project was
finished. Before the subnets were allocated at the backbone\core.
The first clients since a "frozen zone" are being set up in locations outside
of the core but the installation is cutting during the joindomain. The
computer account is being created on a DC in one of the core sites, client
reboots and tries to establishes a secure channel to its closest DC, as it
should but because the repl isn't through no computer account( XP SP2), no
ticket -goodbye!
To help the client guys and in order to qualify whether or not this is an AD
problem I have checked the netsetup.log on the client. Account that is
carrying out the joindomain has not been changed and has enough permissions.
The joindomain uses the NetBIOS name of the domain but obviously DNS is being
used for the joindomain. As far as I am aware once the client discovers there
is no DC on its own subnet the dsgetsite api sends an dns query for the SRV
_LDAP._tcp.dc._msdcsdomainname, i.e give me a DC that is responsible for the X
domain. DC should then inform the client, based upon the IP information that
the client belongs to x Site and for this site are X and X DC's are
repsonbile. DsGetDcName finds a DC but in this case a DC in the core location,
not its closest. Clients already rolled out and belonging to the same site are
authenticated by a DC in the correct site. This is puzzling me.
I checked the metadata for the computer object which confirmed that whenCreated
is beind stamped on a DC which is covering one of the core sites. I don't have
any problems on the DC's with regards to overload etc.
According to the client guys\rollout team the DHCP scope options have not been
changed for the clients. If anyone has any ideas on this one I would
appreciate it. Prestaging was my first suggestion but apparently a no no!
Mit freundlichen Grüßen
Will Holt
ZIT P 5.31 Directory Services
C O M M E R Z B A N K A G
Mainzer Landstr. 151
D-60261 Frankfurt am Main
Tel.: + 49 (0) 69 136 - 41996
Mobile: + 49 (0) 172 6176344
E-mail: [EMAIL PROTECTED]
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an intended
recipient then please promptly delete this e-mail and any attachment and all
copies and inform the sender. Thank you.
<<attachment: image002.jpg>>
