The Netlogon service sends a datagram to the computers that registered the name. TCP is a connection-oriented transport protocol. Each available domain controller responds to the datagram to indicate that it's currently operational and returns the information to DsGetDcName.
UDP allows a program on one computer to send a datagram to a program on another computer. UDP includes a protocol port number, which allows the sender to distinguish among multiple destinations programs on the remote computer. When a client logs on or joins the network, it must be able to locate a domain controller. So clients find a domain controller by querying DNS for a record of the form:. After the client locates a domain controller, it establishes communication by using LDAP to gain access to Active Directory.
As part of that negotiation, the domain controller identifies which site the client is in based on the IP subnet of that client.
If the client is communicating with a domain controller that isn't in the closest most optimal site, the domain controller returns the name of the client's site. If the client has already tried to find domain controllers in that site, the client uses the domain controller that isn't optimal. Otherwise, the client does a site-specific DNS lookup again with the new optimal site name. The domain controller uses some of the directory service information for identifying sites and subnets.
After the client locates a domain controller, the domain controller entry is cached. If the domain controller isn't in the optimal site, the client flushes the cache after 15 minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client.
After the client has established a communications path to the domain controller, it can establish the logon and authentication credentials. And if necessary for Windows-based computers, it can set up a secure channel. The client then is ready to perform normal queries and search for information against the directory. The client establishes an LDAP connection to a domain controller to log on.
The logon process uses Security Accounts Manager. If the client attempts to contact a DC that's offline, it will try to contact the next one in the list until all results are exhausted. Here is a screenshot from a member server showing how the server is preferring the DC in its local site. As you can see by the above process, this is not the case. The member server will query its configured DNS server to retrieve a list of DCs and then intelligently choose the correct DC based on the site information.
This should return all of the DCs in the domain. How do you ensure that all of this happens smoothly? You should review and confirm the following points:. If you run the first command again you should see that domain controller has changed.
This is a temporary thing as after some time the cleint will fallback to the original domain controller. Tags: change domain controller , nltest , Setprfdc. This entry was posted on Monday, May 16th, at and is filed under Microsoft. You can follow any responses to this entry through the RSS 2. You can leave a response , or trackback from your own site. I have 4 domain controllers and I want the people that are at a certin location to log into that DC, if that DC goes down I want the users to to be able to log into one of the other 3 DC.
All of the DC are mirrored and have the same information on them. Any suggestions on how to complete this task? I do not think that this post is what you looking for. Read some articles about intersite management and how to have multiple sites for your AD. This will allow clients in one site connect to the DC in the same site.
Also there is a way to enable client to locate next closest site DC.
0コメント