How to Find from which Server a GPO Created

If you didn’t change the domain controller it will automatically point to PDC in all GPMC by default.

But in case if you are using Different servers for GPMC and created by different Admins and you want to find from where and which server  the GPO created use the below command.

repadmin /showmeta . “CN={insertgpoguid},CN=policies,CN=system,dc=domain,dc=com”

Check when created and originating DSA  for that.

Image

AD,Exchange,Lync Schema Versions

Version of the Active Directory Forest Schema Version

To discover Active Directory Forest Schema Version for the domain home. intranet.

1. Using ADSIEdit

 Plug in the Naming Context in Schema

“CN = Schema, CN = Configuration, DC = home, DC = intranet”

and find the following entry:

“objectVersion”

2. Using the DSQuery command prompt:

dsquery * cn = schema, cn = configuration, dc = home, dc = intranet-scope base-attr objectVersion

Map of the objectVersion: version history

 

Windows Server

The objectVersion value

Windows 2000 Server

13

Windows Server 2003 RTM, Windows 2003 Service Pack 1, Windows 2003 Service Pack 2

30

Windows Server 2003 R2

31

Windows Server 2008 RTM, Windows 2008 Service Pack 1, Windows 2008 Service Pack 2

44

Windows Server 2008 R2, Windows Server 2008 R2 Service Pack 1

47

Windows 8 Beta

52

Windows Server 2012

56

Windows Server 2012 R2 Preview

69

Active Directory Exchange version Schema Version

To discover the Exchange Active Directory Schema Version for the domain home. intranet.

1. Using ADSIEdit

Plug in the Naming Context in Schema

“CN = ms-Exch-Schema-Version-Pt, CN = Schema, CN = Configuration, DC = home, DC = intranet”

and find the following entry:

“rangeUpper”


    2. Using the DSQuery

at the command prompt:

 
 dsquery * CN = ms-Exch-Schema-Version-Pt, cn = schema, cn = configurationration, dc = home, dc = com-scope base-attr intranet rangeUpper

Map of versions of rangeUpper:

Exchange

Value of rangeUpper

2000 RTM

4397

2000 SP3

4406

2003 RTM

6870

2003 SP1

6870

2003 SP2

6870

2003 SP3

6936

2007 RTM

10637

2007 SP1

11116

2007 SP2

14622

2007 SP3

14625

2010 RTM

14622

2010 SP1

14726

2010 SP2

14732

2013 RTM

15137

2013 RTM CU1

15254

 

Active Directory version Lync (OCS) Schema Version

To discover Active Directory Lync (OCS) Schema Version for the domain home. intranet.

1. Using ADSIEdit

 

Plug in the Naming Context in Schema

 

“CN = ms-RTC-SIP-SchemaVersion, CN = Schema, CN = Configuration, DC = home, DC = intranet”

and find the following entry:

 

“rangeUpper”

    2. Using the DSQuery

 

at the command prompt:

 

dsquery * CN = ms-RTC-SIP-SchemaVersion, cn = schema, cn = configurationration, dc = home, dc = com-scope base-attr intranet rangeUpper

Map of versions of rangeUpper:

 

Communicator

rangeUpper

LCS 2005 1006

OCS 2007

1007

OCS 2007 R2

1008

Lync 2010

1100

Lync 2013 1150
 

References

Active Directory Site Design

1. When ever you create a new site  in AD consider the design of your network and replication topology.

2. Add the related sub nets associated with the physical site to AD site. It will help the clients to locate the nearest DC

3. Create Site links accordingly to manage the replication between sites.

4. Add only 2 sites in a site link not more than it will reduce the bandwidth consumptions and avoiding unnecessary connections created by KCC.

5.Intra site replication will occur with in the same site server. KCC will generate automatic connection object

6.Inter site replication will occur between the 2 sites based on the physical connectivity between the 2 sites and WAN configuration.

 

The DC Locator Process

The DC Locator Process, The Logon Process, Controlling Which DC Responds in an AD Site, and SRV Records:

By default a client that knows in what AD site it is in, will ask for a DC in that same site by querying DNS with:

  • _ldap._tcp.<SITE>._sites.dc._msdcs.<DOMAIN>.<TLD>

image001

By default all DCs in AD site <SITE> will register that DNS SRV record. If no DCs are in that AD Site, the DCs in the nearest AD site will cover that AD site by registering their records in the DC-less AD site. The DCs in the site list are in a random order and provided by the DNS round robin mechanism.

If a client does not know in what site it is in, it will ask for a DC in that same domain by querying DNS with:

  • _ldap._tcp.dc._msdcs. <DOMAIN>.<TLD>

By default all writable DCs in AD domain <DOMAIN> will register that DNS SRV record. The writable DCs in the domain list are in a random order and provided by the DNS round robin mechanism. Read-Only DCs (RODCs) in Windows Server 2008 will not register domain-wide SRV records. RODCs only register SRV records for the AD site they are in.

To determine the AD site of a client:

  • NLTEST /DSGETSITE

To determine a DC within a set of DC of DCs in the client’s AD site that could authenticate/service the client:

  • NLTEST /DSGETDC:<FQDN DOMAIN>

So if you look at the situation where a client queries for a DC in the domain because it does not know in what AD site it is in, it can be somewhat interesting when you find out the client is communicating with some DC on the other side of the world. Not really efficient! In HUB and SPOKE environments this can be a problem. It can be really annoying when some client in branch office X is authenticating to a DC in branch office Y, while then WAN links between both branch offices (SPOKES) and the datacenter (HUB) are not that fast. To prevent that situation, it is a best practice to allow the DCs in the datacenters (HUB) register whatever SRV record and allowing the DCs in the branch offices (SPOKES) to register only their site specific SRV records. That way when a client queries for a DC in the domain it will be serviced by one of the DCs in the datacenter (HUB) and NOT in some branch office far far way!

This same situation occurs when a client is joined to the domain using the GUI. At that moment the client does not know its site and it will thus query for A DC in the domain to create its computer account. Guess what, after the clients reboots you might experience authentication problems because the computer account was created at a DC in branch office X while the client is in branch office Y. The issues will go away as soon as the computer account replicates from branch office X to the datacenter and from the datacenter to branch office Y. How long that takes depends on your AD site and replication topology. By using the configuration explained above, the computer account will be created on a DC in the datacenter. That way it only needs to replicate from the datacenter to the branch office. To target the correct AD site where the client will based it is better to use the command-line tool NETDOM. Using that command-line tool you can specify a DC in the AD site where the client will based AND you can specify in what OU the computer account should be placed. The syntax is:

  • NETDOM JOIN %COMPUTERNAME% /DOMAIN:<DOMAIN>\<DC> /OU:<distinguished name of OU> /USERD:<DOMAIN>\<USER> /PASSWORDD:<PASSWORD>
    • REMARK: I specify %COMPUTERNAME% instead of the computername because this command needs to be executed locally on the client/server that needs to be joined to a domain

Because DCs by default register all SRV records, you need to configure the branch office NOT to register certain records. W2K DCs do not have a GPO setting to do the configuration, so you need to configure the registry locally. To prevent that you can still create your own ADM file. W2K3 DCs do have a special GPO setting to make the configuration.

To Configure Domain Controllers or global catalogs to Not Register Generic (domain wide) Records

  • For W2K DCs
    • Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
    • Registry value name: DnsAvoidRegisterRecords
    • Registry value type: REG_MULTI_SZ
    • Registry value data: <list of ENTER-delimited mnemonics>
  • For W2K3(R2)/W2K8 DCs and later:
    • GPO setting path: “Computer Configuration\Administrative Templates\System\Net Logon\DC Locator DNS Records”
    • GPO setting: “DC Locator DNS records not registered by the DCs”
    • GPO setting mode: Enabled
    • GPO setting value: <list of SPACE-delimited mnemonics>

List of “mnemonics” that should not be registered by branch office DCs:

  • Dc
  • DcByGuid
  • Gc
  • GcIpAddress
  • GenericGc
  • Kdc
  • Ldap
  • LdapIpAddress
  • Rfc1510Kdc
  • Rfc1510Kpwd
  • Rfc1510UdpKdc
  • Rfc1510UdpKpwd

UPDATE:

If you have configured your branch office DCs to not register domain-wide specific records, the clients will use those DCs and fail over to the datacenter if the local DC becomes unavailable. However if the local DC comes back online the client keeps using the datacenter DC until the client is restarted or the datacenter DCs become unavailable for some reason. Apparently it does not rediscover its local DC is available again. MS-KBQ939252 provides a hotfix and registry configuration for Windows XP (SP1 & SP2) and Windows Server 2003 (SP1 & SP2). The registry configuration is the ability to configure a discovery interval for the locator process.

Make sure you also see MS-KBQ247811, as there it mentions: “After the client locates a domain controller, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after fifteen minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client.”

Looking at this all, the DC locator process as explained above still applies to Windows Vista and to Windows Server 2008 and later. Are there any differences or additions? Yes, there are!

Basically the client either queries for a DC in the AD site it is in or it queries for a DC in the AD domain it is in. I have always asked myself why the DC locator process did not support following the site topology based on the site cost to find the next closest DC for authentication. The answer to that is unknown to me, but both Windows Vista and Windows Server 2008 provide an additional possibility that exists between “a DC in the AD site” (the closest end) and “a DC in the AD domain” (the far end). The new possibility is “a DC in the next closest site”. 😉

Both Windows Vista and Windows Server 2008 still use the default behavior W2K, WXP, W2K3(R2) have. For both Windows Vista and Windows Server 2008 to locate a DC in the next closest site, it needs to be enabled explicitly. That can be done by using the following:

  • For WVT/W2K8 and later:
    • GPO setting path: “Computer Configuration\Administrative Templates\System\Net Logon\DC Locator DNS Records”
    • GPO setting: “Try next closest site”
    • GPO setting mode: Enabled

To determine a DC within a set of DC of DCs in the client’s AD site that could authenticate the client:

  • NLTEST /DSGETDC:<FQDN DOMAIN>

To determine a writable DC within a set of DCs in the next closed AD site from the client’s perspective that could authenticate the client:

  • NLTEST /DSGETDC: <FQDN DOMAIN> /WRITABLE /TRY_NEXT_CLOSEST_SITE

Until now I talked about locating a DC for authentication. What I did not talk about yet is locating the SYSVOL to apply GPOs and to use the legacy NETLOGON share. Let’s see how that works.

Each AD domain contains one system domain DFS that allows access to the SYSVOL and NETLOGON share. After a computer or user has been authenticated a referral is requested at the authenticating DC for \\<Domain Name>\<SYSVOL or NETLOGON>. The authenticating DC creates two lists being one list with random referrals IN the same AD site as the computer/user and one list with random referrals OUTside the AD site of the computer/user. As you can see the authenticating DC is not by default (it can be however) also the DC that provides access to the SYSVOL or NETLOGON shares. It can thus be another DC in the same AD site as the computer/user that will provide access to the SYSVOL or NETLOGON shares. To make sure the authenticating DC in the same AD site as the computer/user is at the top of the DFS referrals in-site list an update needs to be installed on the DCs and a registry configuration needs to be made on the same DCs. For more information see MS-KBQ831201.

In addition to installing the update on the DCs the following configuration needs to be made on the DCs to put the authenticating DC on top of the DFS referrals list:

  • Registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Dfs\Parameters
  • Registry value name: PreferLogonDC
  • Registry value type: REG_DWORD
  • Registry value data: 1

NOTE: This works on W2K and W2K3 and at this moment I’m not sure if it is still needed for W2K8.

It gets even worse if a computer/user is authenticated outside its AD site because its DC is not available or because it is a DC-less AD site. In that situation it will use ANY DC to gain access to the SYSVOL or NETLOGON shares and in the worst case it will use some DC on the other side of the world with the tiniest WAN link you can imagine. That kinda sucks!

For both W2K and W2K3 a solution exist so that the referral process uses the nearest referral based upon site link costs. To achieve this the following is needed:

  • For W2K SP4 (!) DCs
    • Install update as mentioned in MS-KBQ823362
    • Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DfsDriver
    • Registry value name: DfsEnableSmartClient
    • Registry value type: REG_DWORD
    • Registry value data: 1
  • For W2K3(R2) DCs and later:
    • Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters
    • Registry value name: SiteCostedReferrals
    • Registry value type: REG_DWORD
    • Registry value data: 1

To determine DFS referral information:

  • DFSUTIL /SPCINFO
  • DFSUTIL /PKTINFO

NOTE: This works on W2K and W2K3 and at this moment I’m not sure if it is still needed for W2K8. If it is the most probably you need to use the W2K3 configuration

Now imagine the client used a DFS referral for the SYSVOL or NETLOGON outside of its AD site because its local DC was not available for some reason. Of course you want the client to fallback to its local DC in the AD site as soon as it becomes available to either access the SYSVOL or NETLOGON share. But will it do that? No! It will use the DFS referral outside its AD site until it is rebooted or its cached is reset. W2K3 SP1 allows a client to fallback to its local DFS referral target as soon as it becomes available again and it needs to access the SYSVOL or NETLOGON share.

On W2K3 SP1 DCs and later:

  • Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters
  • Registry value name: SysvolNetlogonTargetFailback
  • Registry value type: REG_DWORD
  • Registry value data: 1

On WXP SP2 clients and W2K3 SP1 servers:

Controlling which DC responds in a Site

This section is to understand how to change the Netlogon Registry Data to control SRV weights and priorities, that are referenced in the links above. Be careful when implementing these changes. It MUST be documented so if another DC in the site were to go down, users may experience a delay or worse, an inability to logon, and if the changes made were forgotten, it will be extremely difficult to troubleshoot.

To find out which DC logged you in:
echo %logonserver%

You can also test which DCs are nearest to your workstation in your site (copy nltest.exe from the DC to the workstation’s system32 folder):
nltest /sc_query:YourDomainName.com

To find the GC your workstation used (copy nltest.exe from the DC to the workstation’s system32 folder):
nltest /dgsgetdc:your_domain_name.com /GC

This is performed altering the default weight and/or priority settings that get registered in the SRV records. The changes are made in the specific DC’s netlogon registry entry. I would suggest to change all your DCs in a Site for more finite control. The reason is it controlled in the netlogon registry entry, is because the netlogon service is the component that registers a DC’s data into their respective SRV folders.

When changing them, keep in mind a client will attempt to contact a server with the lowest priority first. If there are more than one server with the same priority, DNS load balancing is used when selecting the target server. If the weights are changed with the same priority, then a server is chosen based a percentage by dividing the weigth by the sum of all weights of all DCs in an AD Site.

Let’s say you have 3 DCs: DC01, DC02 and DC03. Weights are assigned as follows:
DC01 = 10
DC02 = 20
DC03 = 30

In this example:
DC01 will be contacted 1 out of every 6 times (10/(30+20+10))
DC02 will be contacted 2 out of every 6 times (10/30(20/(30+20+10)))
DC03 will be contacted 3 out of every 6 times (10/20(30/(30+20+10)))

You can use nslookup to find the SRV weights:
nslookup
q=srv
_ldap._tcp.dc01._msdcs.domain.com

The CSEs (client side extensions) is what chooses a DC in this order:

1.A DC in its own AD Site based on the client’s IP address and subnet its in.
2.If more than one DC in the same Site to choose from in the same IP subnet, Round Robin prevails
3.If more than one DC in the same AD Site but one of the DCs are in the same subnet and the other is not, then Subnet Priortization prevails to choose the DC in its own subnet.
4.If more than one DC in the same AD Site but both of the DCs are in different IP subnets than the client, and the two DCs are in the same subnet, then Round Robin will prevail to choose one of the DCs in that same subnet.
5.If more than one DC in the same AD Site but both of the DCs are in different IP subnets than the client, then Subnet Priortization will prevail to choose one of the subnets that a closest match based on the network bits (see this for more info on subnet priortization and bit selection: Technet Thread – DNS issue : DHCP relay + VLANs + multiple AD Sites (Heavily discusses subnet priortization and subnet bits)

The SRV record is used to map the name of a service (in this case, the LDAP service) to the DNS computer name of a server that offers that service. In a Windows 2000 network, an LDAP resource record locates a domain controller.

A workstation that is logging on to a Windows 2000 domain queries DNS for SRV records in the general form:
_Service._Protocol.DnsDomainName

Active Directory servers offer the LDAP service over the TCP protocol; therefore, clients find an LDAP server by querying DNS for a record of the form:
_ldap._tcp.DnsDomainName
Note:
The service and protocol strings require an underscore (_) prefix to prevent potential collisions with existing names in the namespace.

_msdcs Subdomain
There are possible implementations of LDAP servers other than Windows 2000–based domain controllers. There are also possible implementations of LDAP directory services that employ Global Catalog servers but are not servers that are running Windows 2000. To facilitate locating Windows 2000–based domain controllers, in addition to the standard _Service._Protocol.DnsDomainName format, the Net Logon service registers SRV records that identify the well-known server-type pseudonyms “dc” (domain controller), “gc” (Global Catalog), “pdc” (primary domain controller), and “domains” (globally unique identifier, or GUID) as prefixes in the _msdcs subdomain. This Microsoft-specific subdomain allows location of domain controllers that have Windows 2000–specific roles in the domain or forest, as well as the location by GUID when a domain has been renamed. To accommodate locating domain controllers by server type or by GUID (abbreviated “dctype”), Windows 2000–based domain controllers register SRV records in the following form:
_Service._Protocol.DcType._msdcs.DnsDomainName

The addition of the _msdcs subdomain means that two sets of DNS names can be used to find an LDAP server: DnsDomainName is used to find an LDAP server or Kerberos server that is running TCP (or, in the case of a Kerberos server, either TCP or the User Datagram Protocol [UDP]), and the subdomain _msdcs.DnsDomainName is used to find an LDAP server that is running TCP and also functioning in a particular Windows 2000 role. The name “_msdcs” is reserved for locating domain controllers. The single keyword “_msdcs” was chosen to avoid cluttering the DNS namespace unnecessarily. Other constant, well-known names (pdc, dc, and gc) were kept short to avoid exceeding the maximum length of DnsDomainName.

Windows 2008 R2 DC Locator improvements:

“The DC Locator Service has been re-designed in Windows Server 2008 to include a new mechanism. When a client computer finds a preferred domain controller, it sticks to this domain controller unless that domain controller stops responding or the client computer is restarted. This is generally called Domain Controller Stickiness. If you take this domain controller offline for maintenance purpose or it goes down, the clients that were connected to it will look for another domain controller to shift their connections to new domain controller. But when the domain controller comes online again, these connections are not shifted back because client computers do not refresh themselves to check to see if domain controller is back again. This can cause load-balancing issues because client computers remain connected to same domain controller.

Windows Server 2008 includes a new Group Policy setting for client computers. If a domain controller goes down and whenever the DC Locator Service invokes itself to execute the DcGetDCName API call, it retrieves a domain controller name from its cache. It checks to see if this cached entry is expired. If it is expired, it discards this domain controller and tries to search a new domain controller for the client.”

The domain controller locator cannot find an appropriate domain controller on a computer that is running Windows XP or Windows Server 2003

The DNS locator client tries to rediscover a suitable domain controller. The life cycle of a cached entry is controlled by the value of the ForceRediscoveryInterval registry entry.”

Workaround:
Method 1
Some client computers periodically retrieve the domain controller name by using the DS_FORCE_REDISCOVERY flag to call the DsGetDcName function. Determine which client computers do this. Then, deploy a script to these client computers.

Method 2
Update the cache on each client. To do this, run the following command at a command prompt:
nltest /dsgetdc:DomainName /force

The domain controller locator cannot find an appropriate domain controller on a computer that is running Windows XP or Windows Server 2003
http://support.microsoft.com/kb/939252

For additional information, make sure to have a look at:

http://blogs.technet.com/b/arnaud_jumelet/archive/2010/07/11/domain-controller-locator-in-depth.aspx

DC Locator Process in W2K, W2K3(R2) and W2K8 – PART 1
http://blogs.dirteam.com/blogs/jorge/archive/2007/06/30/dc-locator-process-in-w2k-w2k3-r2-and-w2k8-part-1.aspx

DC Locator Process in W2K, W2K3(R2) and W2K8 – PART 2
http://blogs.dirteam.com/blogs/jorge/archive/2007/07/02/dc-locator-process-in-w2k-w2k3-r2-and-w2k8-part-2.aspx

DC Locator Process in W2K, W2K3(R2) and W2K8 – PART 3
http://blogs.dirteam.com/blogs/jorge/archive/2007/07/02/dc-locator-process-in-w2k-w2k3-r2-and-w2k8-part-3.aspx

New DNS Features in Windows Server 2008

 New DNS Features in Windows Server 2008

1.       DNS Server Role – DNS server service is now implemented as a Server Role using Server Manager. Which mean DNS is no longer installed via Add/Remove Windows Components.

2.       Background Zone Loading – Microsoft has changed the way DNS loads zone data from Active Directory. Sometimes the DNS server can take an hour or more to load the data with extremely large zone data. The result is that the DNS server is unable to serve the client’s requests for entire time it takes to load AD based zones.

A DNS server running Windows Server 2008 now loads zone data from AD in the back ground while it restarts so that it can respond to requests for data from other zones. Example – If you have 10 zones and data for first 3 zones data already loaded properly while it is loading other zone data, the DNS server can respond to the client’s request as expected for first 3 zones.

Because the task of loading zones is performed by separate threads, the DNS server is able to respond to queries while zone loading is in progress.

Another advantage of storing data in AD rather than in a file -namely that the DNS Server service has the ability to respond to requests immediately. When the zone is stored in files, the service must sequentially read through the file until the data is found.

3.       Support for IPv6 – DNS Servers running on Windows Server 2008 now support IPv6 as fully as they support IPv4 addresses.  Which mean IPv6 support is available with DNS MMC as well as with tools. Example, IPv6 address can be displayed in Server Forwarder list or DNSCMD.exe tool accepts addresses in either format.

4.       Support for Read Only Domain Controllers (RODC) – To Support RODC, DNS server running Windows Server 2008 support a new zone type called the Primary Read-Only Zone.  When computer becomes RODC, it will get read only copy of all the application partitions that DNS uses. The Administrator of RODC can view contents of DNS but will unable to change it from RODC machine.

5.       GlobalNames Zone – Organization deploy WINS as secondary name resolution protocol along with DNS as they rely on global names which are unique & single-label. WINS requires NetBIOS over TCPIP and it do not support IPv6.

To assist organization to move to all-DNS environment, DNS server in Windows Server 2008 now supports a new zone called GlobalNames. Typically the replication scope for this zone is entire forest, which ensures that zone has the desired effect of providing unique, single-label names across forest.

DNS SRV Records, Purpose and Functionality

DNS SRV Records, Purpose and Functionality

We all know that DNS provides hostname resolution and that this service is critical to Active Directory. It allows domain controllers as well as domain members to locate services in the domain. One of those services is Client / User authentication; and as we all know – Active Directory is a distributed database, one domain controller needs to find another in order to replicate the changes it makes to its local copy of AD Database (NTDS.DIT). DNS provides specific types of records for such services; these records are called SRV or Service Resource Records. SRV records map the name of a service to the server offering this service. Clients and domain controllers use these SRV records to find the IP addresses of authenticating domain controllers and replicating partners. I don’t need to remind you that a DNS Server must allow dynamic updates to the zone where SRV records are to be created by domain controllers in a domain. DNS maintains zones and these zones allow Secure dynamic updates by default. If a DNS Server does not or is configured to NOT allow any dynamic updates, these SRV records will not be registered by domain controllers automatically. We will discuss this some other time.

Once you promote a server to a domain controller using DCPROMO, a text file containing all the appropriate records the domain controller will register in DNS gets created. This text file is in the %systemroot%\system32\config and is called NETLOGON.DNS. Whenever a domain controller starts, the NETLOGON service registers these records or refreshes these records in the primary zone held by the DNS. This way, you will always have the SRV records registered dynamically with the DNS Server. There are other means to do the same, for instance, you can stop and start the NETLOGON service manually or nltest /dsregdns etc.

So now, let’s see what these records are and their function.

  • _ldap._tcp.<DNSDomainName> – Allows a client to locate a domain controller in the domain named by <DNSDomainName>. A client searching for a domain controller in the domain contoso.com would query the DNS server for _ldap._tcp.contoso.com
  • _ldap._tcp.<SiteName>._sites.<DNSDomainName> – Allows a client to find a domain controller in the domain and site specified (e.g., _ldap._tcp.lab._sites.contoso.com for a domain controller in the Lab site of contoso.com).
  • _ldap._tcp.pdc._ms-dcs.<DNSDomainName> – Allows a client to find the PDC emulator (FSMO) role holder of a domain. Only the PDC of the domain registers this record.
  • _ldap._tcp.gc._msdcs.<DNSForestName> – Allows a client to find a Global Catalog (GC) server. Only domain controllers serving as GC servers for the forest will register this name. If a server ceases to be a GC server, the server will deregister this record.
  • _ldap._tcp. ._sites.gc._msdcs.<DNSForestName> – Allows a client to find a GC server in the specified site (e.g., _ldap._tcp.lab._sites.gc._msdcs.contoso.com).
  • _ldap._tcp.<DomainGuid>.domains._msdcs.<DNSForestName> – Allows a client to find a domain controller in a domain based on the domain controller’s globally unique ID. A GUID is a 128-bit (8 byte) number that generates automatically for referencing Active Directory objects.
  • <DNSDomainName> – Enables a client to find a domain controller through a normal Host record.

You can also use the NETLOGON.DNS file to import the records to non-Microsoft DNS Servers that support SRV records but do not allow dynamic updates. At this point we will not discuss weights, priority or port numbers for these services. Another qUICK explanation is required for that 😉

And a picture is worth a 1000 words

image001

 

SRV Records Registered by Net Logon

The list that follows provides the definitions of the names associated with registered SRV records. It also describes the lookup criteria supported by each record and the checks performed by Netlogon as each record is registered. Text in bold type denotes constant record components; text in italic type denotes variable names.

In the descriptions of registered SRV records, DnsDomainName refers to the DNS domain name that is used during creation of the domain controller when the domain tree is joined or created (that is, while the computer is running the Active Directory Installation Wizard). DnsForestName refers to the DNS domain name of the forest root domain.

The following is a list of the owner names of the SRV records that are registered by Net Logon. An owner name is the name of the DNS node to which the resource record pertains.

_ldap._tcp.DnsDomainName.
Allows a client to locate a server that is running the LDAP service in the domain named by DnsDomainName. The server is not necessarily a domain controller — that is, the only assumption that can be made about the server is that it supports the LDAP application programming interface (API). All Windows 2000 Server–based domain controllers register this SRV record (for example, _ldap._tcp.reskit.com.).
_ldap._tcp.SiteName._sites.DnsDomainName.

Allows a client to locate a server that is running the LDAP service in the domain named in DnsDomainName in the site named by SiteName. SiteName is the relative distinguished name of the site object that is stored in the Configuration container in Active Directory. The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers register this SRV record (for example, _ldap._tcp.charlotte._sites.reskit.com.).

_ldap._tcp.dc._msdcs.DnsDomainName.
Allows a client to locate a domain controller (dc) of the domain named by DnsDomainName. All Windows 2000 Server–based domain controllers register this SRV record.

_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName.
Allows a client to locate a domain controller for the domain named by DnsDomainName and in the site named by SiteName. All Windows 2000 Server–based domain controllers register this SRV record.

_ldap._tcp.pdc._msdcs.DnsDomainName.
Allows a client to locate the server that is acting as the primary domain controller (also known as a “PDC”) in the mixed-mode domain named in DnsDomainName. Only the PDC emulator master of the domain (the Windows 2000–based domain controller that advertises itself as the primary domain controller to computers that need a primary domain controller) registers this SRV record.

_ldap._tcp.gc._msdcs.DnsForestName.
Allows a client to locate a Global Catalog (gc) server for this forest. Only domain controllers that are functioning as Global Catalog servers for the forest named in DnsForestName register this SRV record (for example, _ldap._tcp.gc._msdcs.reskit.com.).

_ldap._tcp.SiteName._sites.gc._msdcs.DnsForestName.
Allows a client to locate a Global Catalog (gc) server for this forest in the site named in SiteName. Only domain controllers that are serving as Global Catalog servers for the forest named in DnsForestName register this SRV record (for example, _ldap._tcp.charlotte._sites.gc._msdcs.reskit.com.).

_gc._tcp.DnsForestName.
Allows a client to locate a Global Catalog (gc) server for this domain. The server is not necessarily a domain controller. Only a server that is running the LDAP service and functioning as the Global Catalog server for the forest named in DnsForestName registers this SRV record (for example, _gc._tcp.reskit.com.).
Note:
In Windows 2000, a Global Catalog server is a domain controller. Other non-Windows 2000 implementations of directory services can also register servers as Global Catalog servers.

_gc._tcp.SiteName._sites.DnsForestName.
Allows a client to locate a Global Catalog (gc) server for this forest in the site named in SiteName. The server is not necessarily a domain controller. Only a server that is running the LDAP service and functioning as the Global Catalog server for the forest named in DnsForestName registers this SRV record (for example, _gc._tcp.charlotte._sites.reskit.com.).

_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName.
Allows a client to locate a domain controller in a domain on the basis of its GUID. A GUID is a 128-bit number that is automatically generated for referencing objects in Active Directory — in this case, the domain object. This operation is expected to be infrequent; it occurs only when the DnsDomainName of the domain has changed, the DnsForestName is known, and DnsForestName has not also been renamed (for example, _ldap._tcp.4f904480-7c78-11cf-b057-00aa006b4f8f.domains._msdcs.reskit.com.). All domain controllers register this SRV record.

_kerberos._tcp.DnsDomainName.
Allows a client to locate a server that is running the Kerberos KDC service for the domain that is named in DnsDomainName. The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

_kerberos._udp.DnsDomainName.
Same as _kerberos._tcp.DnsDomainName, except that UDP is implied.

_kerberos._tcp.SiteName._sites.DnsDomainName.
Allows a client to locate a server that is running the Kerberos KDC service for the domain that is named in DnsDomainName and is also in the site named in SiteName. The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

_kerberos._tcp.dc._msdcs.DnsDomainName.
Allows a client to locate a domain controller that is running the Windows 2000 implementation of the Kerberos KDC service for the domain named in DnsDomainName. All Windows 2000 Server–based domain controllers that are running the KDC service (that is, that implement a public key extension to the Kerberos v5 protocol Authentication Service Exchange subprotocol) register this SRV record.

_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName.
Allows a client to locate a domain controller that is running the Windows 2000 implementation of the Kerberos KDC service for the domain that is named in DnsDomainName and that is also in the site named in SiteName. All Windows 2000 Server–based domain controllers that are running the KDC service (that is, that implement a public key extension to the Kerberos protocol Authentication Service Exchange subprotocol) register this SRV record.

_kpasswd._tcp.DnsDomainName.
Allows a client to locate a Kerberos Password Change server for the domain. All servers that provide the Kerberos Password Change service (which includes all Windows 2000–based domain controllers) register this name. This server at least conforms to “Kerberos Change Password Protocol.” (For more information about this draft, see the Microsoft Platform SDK link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Use a keyword search to locate the draft.) The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

_kpasswd._udp.DnsDomainName.
Same as _kpasswd._tcp.DnsDomainName, except that UDP is implied.
If multiple domain controllers have the same criteria, multiple records exist with the same owner name. A client that is looking for a domain controller with specific criteria would receive all the applicable records from the DNS server. The client would pick one of the returned records to select a domain controller, as described in “A DNS RR for specifying the location of services (DNS SRV).” For more information about this draft, see the Internet Engineering Task Force (IETF) link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Follow the links to Internet Drafts, and then use a keyword search.
For information about the Kerberos v5 authentication protocol and Kerberos subprotocol extensions, see “Authentication” in this book.

Host Records for Non-SRV-Aware Clients
Net Logon registers the following DNS A records for the use of LDAP clients that do not support DNS SRV records (that is, that are “non-SRV-aware”). The Locator does not use these records.

The following owner names of A (host) records are registered by Net Logon:

DnsDomainName.
Allows a non-SRV-aware client to locate any domain controller in the domain by looking up an A record. A name in this form is returned to the LDAP client through an LDAP referral. (For more information about LDAP referrals, see “LDAP Referrals” later in this chapter.) A non-SRV-aware client looks up the name; an SRV-aware client looks up the appropriate SRV resource record.

gc._msdcs.DnsForestName.
Allows a non-SRV-aware client to locate any Global Catalog server in the forest by looking up an A record. A name in this form is returned to the LDAP client through an LDAP referral. A non-SRV-aware client looks up this name; an SRV-aware client looks up the appropriate SRV resource record.
Netlogon also registers a DNS CNAME (alias) record for use by Active Directory replication. The Locator does not use this record.

The owner name of the CNAME record is:
DsaGuid._msdcs.DnsForestName.
Allows a client to locate any domain controller in the forest by looking up an A record. The only information that is known about the domain controller is the GUID of the directory system agent (also known as the “DSA”) object for the domain controller and the name of the forest in which the domain controller is located. This record is used to facilitate renaming a domain controller.

Other SRV Record Content

The following information is also included in an SRV record:
Priority   The priority of the server. Clients attempt to contact the server with the lowest priority.
Weight   A load-balancing mechanism that is used when selecting a target host from those that have the same priority. Clients randomly choose SRV records that specify target hosts to be contacted, with probability proportional to the weight.

Port Number
The port where the server is listening for this service.

Target
The fully qualified domain name of the host computer.

The following example illustrates the combined information that is contained in A resource records and SRV resource records. A domain controller named Phoenix in the domain reskit.com has an IP address of 157.55.81.157. It registers the following A records and SRV records with DNS:
phoenix.reskit.com   A   157.55.81.157
_ldap._tcp.reskit.com    SRV  0 0 389 phoenix.reskit.com
_kerberos._tcp.reskit.com   SRV  0 0 88 phoenix.reskit.com
_ldap._tcp.dc._msdcs.reskit.com  SRV  0 0 389 phoenix.reskit.com
_kerberos._tcp.dc._msdcs.reskit.com  SRV  0 0 88 phoenix.reskit.com.

When the appropriate SRV records and A records are in place, a DNS lookup of _ldap._tcp.dc._msdcs.reskit.com returns the names and addresses of all domain controllers in the domain.
For more information about A records, SRV records, DNS, and dynamic updates, see “Introduction to DNS” and “Windows 2000 DNS” in the TCP/IP Core Networking Guide.

If the DCs are in a truly configured “Site”, then to change the priority and weights, you must change the registry entries under the Netlogon key. Once changed, then it will register that info into DNS.

 

 

DNS

DNS: The Domain Name System consists of a hierarchical set of DNS servers. Each domain or subdomain has one or more authoritative DNS servers that publish information about that domain and the nameservers of any domains “beneath” it. The hierarchy of authoritative DNS servers matches the hierarchy of domains. At the top of the hierarchy stand the root nameservers: the servers to query when looking up (resolving) a top-level domain name (TLD). Iterative and recursive queries:

  • An iterative query is one where the DNS server may provide a partial answer to the query (or give an error). DNS servers must support non-recursive queries.
  • A recursive query is one where the DNS server will fully answer the query (or give an error). DNS servers are not required to support recursive queries and both the resolver (or another DNS acting recursively on behalf of another resolver) negotiate use of recursive service using bits in the query headers.

DNS Propagation

DNS Propagation refers to the time for any DNS changes to transmit across the Internet. Please remember that DNS changes in general can take up to 24-48 hours to fully propagate.

DNS Records

CNAME or “Canonical Name”

(CNAME) Record is used to define an alias hostname. A “CNAME” record takes this format:

alias.domain.name      IN     CNAME   otherhost.domain.name.

This defines alias.domain.name as an alias for the host whose canonical (standard) name is otherhost.domain.name.

“A” Record

An A record gives you the IP address of a domain. That way, users that try to go to www.example.com will get to the right IP address. An A record or “Address Record” maps a hostname to a 32-bit IPv4 address. An “A” Record takes this format (example):

Name             TTL     TYPE    DATA

ftp.domain.com   43200   A       IP Address

(mt) Media Temple DNS Zone files are written with a “wildcard” entry, that looks like this:

*.domain.com   IN   A   xxx.xxx.xxx.xxx

The x’s represnt your particular IP address. The star takes “anything” .domain.com and points it to your server’s IP address. This way, if someone mistakenly types too many or too few w’s, they’ll still see your website. This is also useful for setting up subdomains on your server, relieving you of the duty of adding an additional “A” record for the subdomain.

MX Record

Mail Exchange Record: Maps a domain name to a list of mail exchange servers for that domain. A zone can have one or more Mail Exchange (MX) records. These records point to hosts that accept mail messages on behalf of the host. A host can be an ‘MX’ for itself. MX records need not point to a host in the same zone. An ‘MX’ record takes this format:

host.domain.name       IN     MX      10 otherhost.domain.name.

IN     MX      20 otherhost2.domain.name.

The ‘MX’ preference numbers nn (value 0 to 65535) signify the order in which mailers select ‘MX’ records when they attempt mail delivery to the host. The lower the ‘MX’ number, the higher the host is in priority.

PTR Record / Pointer Record

Maps an IPv4 address to the canonical name for that host. Setting up a PTR record for a hostname in the in-addr.arpa. domain that corresponds to an IP address implements reverse DNS lookup for that address. For example, at the time of writing, www.icann.net has the IP address 192.0.34.164, but a PTR record maps 164.34.0.192.in-addr.arpa to its canonical name.

NS Record or “Name Server Record”

Maps a domain name to a list of DNS servers authoritative for that domain. In this case, for (mt) Media Temple purposes would be:

ns1.mediatemple.net

ns2.mediatemple.net

SOA Record or “Start of Authority Record”

Specifies the DNS server providing authoritative information about an Internet domain, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone.

TXT Record

The TXT Record allows an administrator to insert arbitrary text into a DNS record. For example, this record is used to implement the Sender Policy Framework and DomainKeys specifications.