Technical posts about IT

Posts tagged Windows Server

DNSLint: DNS Troubleshooter

Feb12
2012 Leave a Comment Written by Sean Metcalf

One of the best DNS tools a Windows admin can use is DNSLint.
While nslookup is ok for quick DNS lookups, DNSLint is like the swiss army knife of DNS troubleshooting.

DNSLint popular command options:

  • Test domain DNS records:  dnslint /d domain.com
  • Test Active Directory records:  dnslint /ad <DC_IP_ADDRESS> /s <DNS_SERVER>
Note: Add /v for verbose output & /test_tcp to test DNS servers via TCP port 53.
References:

DNSLint Command Options:

DNSLint
Verifies domain name registration and DNS records
usage:
C:\dnslint\dnslint.exe /d domain_name | /ad [LDAP_IP_address] | /ql input_file
[/c [smtp,pop,imap]] [/no_open] [/r report_name]
[/t] [/s DNS_IP_address] [/v] [/y]
Required parameters:
/d used to request domain name tests
– must specify domain name to test
– cannot be used in conjunction with /ad
/ad used to request Active Directory tests
– resolves DNS records used for AD forest replication
– default is to use local system’s LDAP service
– can specify remote LDAP server IP address (optional)
– only valid IP addresses accepted – names not accepted
– typically this is an Active Directory Domain Controller
– must be used with /s option where /s specifies the
IP address of a DNS server that is authoritative for
the _msdcs subdomain in the root domain of the AD forest
– cannot be used in conjunction with /d or /c
/ql used to request DNS query tests from a list
– sends the DNS queries specified in a text input file
– must specify the path and name of the input file
– A, PTR, CNAME, SRV and MX record queries supported
– create a sample input file by running:
dnslint /ql autocreate
– cannot be used in conjunction with /d, /ad, or /c
notes:
– /d /ad /ql cannot be used together
– /c cannot be used together with /ad or /ql
– when using /ad, /s must also be specified
Optional parameters:
/c used to request connectivity tests on e-mail servers
– tests SMTP, POP, and IMAP ports on e-mail servers found
– default is to check all three, can specify one or combination
– use comma seperated list: /c pop,imap,smtp
/no_open used to prevent report from automatically opening
– useful in scripts
/r used to specify the name of the report file created
– .htm extension is automatically added to report names
– report is created in HTML format – default name is dnslint.htm
– default location is the current directory
/t used to request output to a text file
– shares same name as .htm report but with a .txt extension
– created in the same directory as the .htm report file
/test_tcp used to request that TCP port 53 be tested
– by default only UDP port 53 is tested
– this option checks if TCP port 53 is responding to queries
– cannot be used with /ql
/s used by-pass InterNIC whois lookup
– specify tested domain’s authoritative DNS server’s IP address
– does not query InterNIC for registered name servers
– starts checking DNS records using supplied IP address
– only valid IP addresses accepted – names not accepted
– use to check domain names not supported by InterNIC
– when /ad is used, /s must be used to specify a DNS server
that is authoritative for the subdomain called:
_msdcs.<root of the AD forest>
– when /ad is used, /s localhost can be run to determine if
the local system can resolve records used for AD replication
/v used to request verbose output to screen
/y used to overwrite existing report file without being prompted
– useful in scripts
Press Ctrl-c to terminate prematurely
examples:
dnslint /d myserver.com
dnslint /v /y /d reskit.com
dnslint /v /y /r ms_report /d microsoft.com
dnslint /v /y /no_open /s 169.254.1.10 /d msn.com
dnslint /v /y /c /t /d reskit.com
dnslint /d reskit.com /c smtp,pop
dnslint /ad 169.254.10.22 /s 169.254.44.1 /v
dnslint /ad /s localhost /v
dnslint /ql mylist.txt /v
dnslint /ql autocreate

 

Google+FacebookEmailPrintShare
Posted in Deployment, Microsoft Products, Tech, Technical Reference, Troubleshooting - Tagged , , , , ,

Powershell Code: Finding Orphaned Group Policy Objects

Feb04
2012 Leave a Comment Written by Sean Metcalf

Group Policy is an interesting thing when it comes to Active Directory components. One part of the Group Policy (GPO) is stored in Active Directory, specifically in the CN=Policies,CN=System,DC=domain,DC=tld (for example: CN=Policies,CN=System,DC=metcorp,DC=org) which is replicated via AD replication. The other part is stored in SYSVOL which is replicated by File Replication Services (FRS).

Here’s the PowerShell code to find Group Policy Objects where one half of the GPO piece is missing:

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#####################
# Orphaned GPO List #  20120201-15
#####################
Import-Module activedirectory
$DomainDNS = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name #Get AD Domain (lightweight & fast method)

Write-Output "Reading GPO information from AD (CN=Policies,CN=System,$ADDomainDistinguishedName)... `r "
$GPOPoliciesDN = "CN=Policies,CN=System,$ADDomainDistinguishedName"
[array]$GPOPolicies = Get-ChildItem AD:$GPOPoliciesDN
ForEach ($GPO in $GPOPolicies) { [array]$DomainGPOList += $GPO.Name }
$DomainGPOList = $DomainGPOList -replace("{","") ; $DomainGPOList = $DomainGPOList -replace("}","")
$DomainGPOList = $DomainGPOList | sort-object
[int]$DomainGPOListCount = $DomainGPOList.Count
Write-Output "Discovered $DomainGPOListCount GPOs in Active Directory ($GPOPoliciesDN) `r "
Write-Output " `r "

Write-Output "Reading GPO information from AD (CN=Policies,CN=System,$ADDomainDistinguishedName)... `r "
$GPOPoliciesSYSVOLUNC = "\\$DomainDNS\SYSVOL\$DomainDNS\Policies"
[array]$GPOPoliciesSYSVOL = Get-ChildItem $GPOPoliciesSYSVOLUNC
ForEach ($GPO in $GPOPoliciesSYSVOL) { [array]$SYSVOLGPOList += $GPO.Name }
$SYSVOLGPOList = $SYSVOLGPOList -replace("{","") ; $SYSVOLGPOList = $SYSVOLGPOList -replace("}","")
$SYSVOLGPOList = $SYSVOLGPOList | sort-object
[int]$SYSVOLGPOListCount = $SYSVOLGPOList.Count
Write-Output "Discovered $SYSVOLGPOListCount GPOs in SYSVOL ($GPOPoliciesSYSVOLUNC) `r "

## COMPARE-OBJECT cmdlet note:
## The => sign indicates that the item in question was found in the property set of the second object but not found in the property set for the first object.
## The <= sign indicates that the item in question was found in the property set of the first object but not found in the property set for the second object.

# Check for GPO template objects in SYSVOL that don't exist in AD
[array]$MissingADGPOs = Compare-Object $SYSVOLGPOList $GPOList -passThru | Where-Object { $_.SideIndicator -eq '<=' }
[int]$MissingADGPOsCount = $MissingADGPOs.Count
Write-Output "There are $MissingADGPOsCount GPO template objects in SYSVOL that don't exist in AD  `r "
Write-Output "These are: `r "
$MissingADGPOs
Write-Output " `r "

# Check for GPO policy objects in AD that don't exist in SYSVOL
[array]$MissingSYSVOLGPOs = Compare-Object $GPOList $SYSVOLGPOList -passThru | Where-Object { $_.SideIndicator -eq '<=' }
[int]$MissingSYSVOLGPOsCount = $MissingSYSVOLGPOs.Count
$MissingSYSVOLGPOsPCTofTotal = $MissingSYSVOLGPOsCount / $DomainGPOListCount
$MissingSYSVOLGPOsPCTofTotal = "{0:p2}"                      -f $MissingSYSVOLGPOsPCTofTotal  
Write-Output "There are $MissingSYSVOLGPOsCount GPO policy objects in AD that don't exist in SYSVOL ($MissingSYSVOLGPOsPCTofTotal of total) `r "
Write-Output "These are: `r "
$MissingSYSVOLGPOs
Write-Output " `r "
Google+FacebookEmailPrintShare
Posted in Microsoft Products, Powershell Code, Tech - Tagged , , , , , ,

Powershell Code: Using Powershell to get Active Directory Creation Date & Domain Instantiation

Feb02
2012 Leave a Comment Written by Sean Metcalf

One thing that has been bouncing around my head for a while is a method to identify the date Active Directory was installed. Thankfully, now I don’t have to.

A recent Scripting Guy blog post describes exactly how to do this and also list the last dates when Schema Updates occurred.

Here’s the code that I used in my script (from the Scripting Guy blog post):

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Import-Module ActiveDirectory

#############################
# Get AD Instantiation Date #
#############################
# Code from: http://blogs.technet.com/b/heyscriptingguy/archive/2012/01/05/how-to-find-active-directory-schema-update-history-by-using-powershell.aspx
write-output "Checking Active Directory Creation Date... " `r
write-output "Displaying AD partition creation information " `r

Get-ADObject -SearchBase (Get-ADForest).PartitionsContainer `
-LDAPFilter "(&(objectClass=crossRef)(systemFlags=3))" `
-Property dnsRoot, nETBIOSName, whenCreated | Sort-Object whenCreated | Format-Table dnsRoot, nETBIOSName, whenCreated -AutoSize

###########################
# Get Schema Update Dates #
###########################
# Code from: http://blogs.technet.com/b/heyscriptingguy/archive/2012/01/05/how-to-find-active-directory-schema-update-history-by-using-powershell.aspx
write-output "Reading all schema data... " `r
$schema = Get-ADObject -SearchBase ((Get-ADRootDSE).schemaNamingContext) `
-SearchScope OneLevel -Filter * -Property objectClass, name, whenChanged,`
whenCreated | Select-Object objectClass, name, whenCreated, whenChanged, `
@{name="event";expression={($_.whenCreated).Date.ToShortDateString()}} | `
Sort-Object whenCreated

#"`nDetails of schema objects changed by date:"
#$schema | Format-Table objectClass, name, whenCreated, whenChanged `
#-GroupBy event -AutoSize

write-output "`nCount of schema objects changed by date:" `r
Write-output "This displays the approximate date each each schema update was performed." `r
$schema | Group-Object event | Format-Table Count, Name, Group –AutoSize

 

Note: The Get-ADObject command that gets the schema data is an “expensive” query and may timeout. Be careful with this one.

Google+FacebookEmailPrintShare
Posted in Deployment, Microsoft Products, Powershell Code, Tech, Technical Reference - Tagged , , , , ,

Kerberos, Active Directory’s Secret Decoder Ring

Jan30
2012 Leave a Comment Written by Sean Metcalf

Kerberos Overview

Kerberos is a protocol with roots in MIT named after the three-headed dog, Cerberus. Named because there are 3 parties: the client, the resource server, and a 3rd party (the Key Distribution Center, KDC).

Kerberos can be a difficult authentication protocol to describe, so I will attempt to simplify it as best as possible.

Kerberos authentication leverages long-term asymmetric keys (public key) and short-term symmetric keys (session keys).

Asymmetric key cryptography uses two mathematically connected keys where one key is used to encrypt and the other is used to decrypt data. This is most commonly used in Public Key encryption (PKI) where one of the keys is kept secret by the user or service (Private Key) and the other key is available to anyone who wants it (Public Key). In this manner a user can sign (encrypt a hash with the private key) data to ensure it originated from that user without modification (the receiver decrypts the hash with the public key). Also a person can use the user’s public key to encrypt data so that only the user can decrypt it with the user’s private key.

Symmetric key cryptography uses one key to encrypt and the same to decrypt the data. This is also referred to as a shared secret.

Since asymmetric key cryptography is more processor intensive, it is typically only used to encrypt session keys which use symmetric keys (shared secret).

Active Directory implements Kerberos version 5 in two components: the Authentication service and the Ticket-granting service.

The Authentication Service (AS) is the first contact the client has with Kerberos and is used to lookup the user’s password and create the Ticket Granting Ticket (TGT). The AS also creates the session key the user will use for future communication with Kerberos.

The Ticket Granting Ticket (TGT) is the Kerberos ticket for the Ticket Granting Service (runs on the KDC) and is encrypted using the KDC key, meaning that only a KDC can decrypt and read the ticket. While the user’s ticket ,the TGT, is set to expire after 10 hours (AD default), it can be renewed as often as needed during the TGT renewable lifetime which is 7 days (AD default). Once the authenticating user has a TGT, it presents the TGT to the KDC to get a Service Ticket for the Ticket Granting Service (TGS) on the KDC.

Confused yet?
Keep reading, it gets easier…

Every service that is Kerberos enabled has an entry point called a Service Principal Name (SPN) and each Kerberos user has a User Principal Name (UPN). For example, a user named Joe User in the METCORP.ORG Kerberos realm aka AD domain (the Kerberos realm is always all Caps) has a UPN of JoeUser@metcorp.org. If Joe User initiates a connection to the share path \\server1.metcorp.org\Shared then Joe’s workstation will lookup the computer server1.metcorp.org in Active Directory and read its SPN attribute (cifs/server1.metcorp.org). The computer SPN is used to identify the application server in the Kerberos TGS ticket request. Furthermore, when Joe opens Outlook, his workstation performs similar actions looking up the Exchange server’s SPN.
Exchange 2010 has a number of registered SPNs; here are a few of them used as part of a client connection (using Outlook 2010):

  • exchangeMDB
  • exchangeRFR
  • exchangeAB
  • HTTP

KERBEROS METAPHOR

As mentioned earlier, Kerberos has 3 components, the client, the server, and the KDC (trusted 3rd party). The process is similar to when you travel to a foreign country.

  1. You visit the local passport office with a birth certificate
    (get the Ticket Granting Ticket ticket from the KDC)
  2. You request an entrance Visa for your passport in order to enter the country
    (get the Ticket Granting Service ticket from the KDC – ok, so you would get the Visa from the country’s embassy, but you still need the passport and something authoritative the country’s immigration guard will accept).
  3. You travel to the country with the passport and the country’s entrance Visa
    (present authoritative documentation to gain access to the resource server).

THE PROCESS

Here’s my example scenario to explain what occurs when a user logs on and opens Outlook to view his Exchange email. The bold text is the simple overview version while the detail follows.

  1. A user logs onto the domain metcorp.org on the workstation MetcorpPC.
  2. The user requests authentication by sending a timestamp encrypted with the users password encryption key.
    The workstation creates an encryption key derived from the user’s password (the user’s password is hashed using a one way function such as MD5 = (A) key) to encrypt a timestamp (date/time) as an authenticator (pre-authentication is required by AD in its default configuration, so the client must send an authenticator) . The authenticator is simply a method the client uses to prove to the KDC that the user is who he claims to be (since only the user & the KDC knows his password) and protects against replay attacks. This information is sent to the KDC in an AS-REQ (Authentication Service Request) packet. This request includes the client supported encryption algorithms.
     
    Keys used:
    (A)User’s password derived keyPacket Data:
    User account (user@metcorp.org) requests Kerberos service ticket (TGT) with PREAUTH data    KRB5: Kerberos AS-REQ
    1 Forwardable: FORWARDABLE tickets are allowed/requested
    1 Renewable: This ticket is RENEWABLE
    1 Canonicalize: This is a request for a CANONICALIZED ticket
    1 Renewable OK: We accept RENEWED ticketsClient Name (Principal): admin
    Realm: METCORP.ORG
    Service: krbtgt/metcorp.org
    till: 2037-09-12 02:48:05 (UTC)
    rtime: 2037-09-12 02:48:05 (UTC)
    Nonce: 1976014234
    Principal Name: user
    HostAddress: METCORPORGDC02<20>
    PAC_Request: True
    Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac rc4-hmac-exp rc4-hmac-old-exp des-cbc-md5KRB5: Kerberos AS-REP
    Client Name (Principal): user
    Tkt-vno: 5
  3. The Kerberos server (KDC) receives the authentication request, validates the data, and replies with a TGT.
    The KDC receives the AS-REQ, decrypts the authenticator (encrypted with key (A)), and validates the timestamp is within the time skew limits set by the domain (5 minutes by default). If the KDC is satisfied the request is a valid user request, the KDC responds with an AS-REP packet which includes the TGT. The TGT can only be decrypted by a KDC (using the (B) key) and is used to authenticate the user to the Kerberos server so it doesn’t have to look up the user’s password (long-term key) again. The KDC also includes a session key ((C)key) for use in future communication with the KC.
     
    Keys used:
    (B) Kerberos account’s password derived key
    (C)    User’s Kerberos service (KDC) session key NOTE: The TGT is encrypted with the krbtgt account password so only a valid Kerberos server can decrypt it. In an environment with RODCs, each RODC has its own krbtgt account with a unique password. This means that if a user presents a TGT received from a RODC to a writable DC, the DC dumps the TGT and generates a new one.Packet Data:
    The KDC replies with the TGT and session key
    KRB5: Kerberos AS-REP
    Client Name (Principal): User
    Ticket (Tkt-vno): 5
    Realm: METCORP.ORG
    Server Name: krbtgt/metcorp.org
    enc-part aes256-cts-hmac-sha1-96
    [Encrypted Key]
    enc-part rc4-hmac
    [Encrypted Key]
  4. The user opens Outlook which locates the user’s mailbox server and requests a TGS ticket for access.
    The workstation locates the Exchange mailbox server containing the user’s mailbox (MetcorpEXMB02.metcorp.org) and reads the ServicePrincipalName attribute on the computer account in AD (ExchangeMDB/MetcorpEXMB02.metcorp.org – there are a bunch, so I will just use this one for the example).
    The client then sends a TGS-REQ to the KDC requesting a TGS for access to the Exchange service running on the MetcorpEXMB02 Exchange server. The TGS request includes the target server SPN, the user’s TGT (encrypted with the (B) key), and an authenticator (encrypted with the (C)key). 
     
    Keys used:


    (B)     Kerberos account’s password derived key
    (C)    User’s Kerberos service (KDC) session keyPacket Data:
    User account requests service ticket (TGS) for MetcorpEXMB02 Exchange service access
    KRB5: Kerberos TGS-REQ
    1 Forwardable: FORWARDABLE tickets are allowed/requested
    1 Renewable: This ticket is RENEWABLE
    1 Canonicalize: This is a request for a CANONICALIZED ticket
    Realm: METCORP.ORG
    Server Name: ExchangeMDB/MetcorpEXMB02.metcorp.org
    till: 2037-09-12 02:48:05 (UTC)
    Nonce: 1976014234
    Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac rc4-hmac-exp rc4-hmac-old-exp des-cbc-md5KRB5: Kerberos AS-REP

  5. The KDC validates the TGS request and replies with the TGS.
    The KDC replies with a TGS-REP packet to the client which includes 2 session tickets (TGS) (2?). One of the session tickets is encrypted with the user’s (KDC) session key ((C) key) and the second one is encrypted with the target server’s (KDC) session key ((D) key). The second TGS also includes the user’s group membership & associated SIDs which provides the server information used to determine authorization and help the server determine: Is the user allowed to access the server’s resource?
    Both session tickets include a new session key ((E)key) for exclusive use in communication between the Exchange server and the user.
     
    Keys used:
    (C)     User’s Kerberos service (KDC) session key
    (D)     Server’s Kerberos service (KDC) session key
    (E)    User-Exchange service session keyPacket Data:
    The KDC replies with the service ticket (TGS) for MetcorpEXMB02 Exchange service access
    KRB5: Kerberos TGS-REP
    Client Name (Principal): User
    Ticket (Tkt-vno): 5
    Realm: METCORP.ORG
    Server Name: krbtgt/metcorp.org
    enc-part aes256-cts-hmac-sha1-96
    [Encrypted Key]
    enc-part rc4-hmac
    [Encrypted Key]
  6. The client authenticates to the Exchange server with the session ticket.
    The client sends the target server (MetcorpEXMB02.metcorp.org) an AP-REQ packet containing the TGS it received from the KDC encrypted with the server’s session key ((D) key) and an authenticator encrypted with the user-Exchange server session key ((E) key) . This lets the Exchange server know that the user was authenticated to the Kerberos domain (realm) and that the TGS is valid (assuming the Exchange server is able to decrypt it). The client also sends the server an authenticator (timestamp) encrypted with the session key ((E)key) it received from the KDC in Step 5. The Exchange server decrypts the TGS, extracts the user’s group information, extracts the session key, and uses the session key to decrypt the authenticator. This provides the server enough information to make an authorization decision. If the user is authorized to connect to the server, it sends a reply.
     
    Keys used:
    (C)     User’s Kerberos service (KDC) session key
    (D)     Server’s Kerberos service (KDC) session key
    (E)     User-Exchange service session key
  7. The Exchange server replies that authorization to the service is granted.
    The Exchange server sends the client an AP-REP packet which includes its own authenticator encrypted with the user-Exchange service session key ((E) key). This assumes the client requested mutual authentication which is the default configuration.
     
    Keys used:
    (E)    User-Exchange service session key

Note:
This is a simplified explanation of Kerberos and doesn’t cover everything involved in this process.

Kerberos Key Storage Locatons

Workstation Keys:

  • User Key
  • Ticket-Granting Ticket
  • Ticket-Granting Service Session Key
  • Service Ticket
  • Session Key

Domain Controller:

  • User Key
  • Ticket-Granting Service Key
  • Service Key

Server:

  • Service Key
  • Session Key

TICKETING

There are different “tickets” that are used to authenticate a client to a server’s resource. The client can be a user or a computer.

The Ticket Granting Ticket (TGT) is the first ticket given to the requester (user or computer.

The TGT is comprised of the following fields:

  • Ticket Version Number
  • Realm: The AD domain name in CAPITAL LETTERS
  • Server Name: The KDC
  • Flags: Kerberos Flag options
  • Key
  • Client Realm: The client’s AD domain name in CAPITAL LETTERS
  • Client Name: The user name
  • Transited: If the user is in a different domain than the resource, Kerberos tickets have transited.
  • Authentication
  • Time
  • Start Time
  • End Time
  • Renew Till
  • Client Address
  • Authorization Data

Ticket Flags:

  • FORWARDABLE
  • FORWARDED
  • PROXIABLE
  • PROXY
  • MAY-POSTDATE
  • POSTDATED
  • INVALID
  • RENEWABLE
  • INITIAL
  • PRE-AUTHENT
  • HW-AUTHENT

Supported Encryption Algorithms & Key Lengths:

DEFAULT AD KERBEROS POLICY SETTINGS

  • Enforce user logon restrictions: Enabled
  • Maximum lifetime for service ticket: 600 minutes (10 hours)
  • Maximum lifetime for user ticket: 600 minutes (10 hours)
  • Maximum lifetime for user ticket renewal : 7 days
  • Maximum tolerance for computer clock synchronization: 5 minutes

References:

Google+FacebookEmailPrintShare
Posted in Career, Deployment, Microsoft Products, Tech, Technical Reference - Tagged , , , , , ,

Active Directory Replication Overview & USN Rollback: What It Is & How It Happens

Jan25
2012 Leave a Comment Written by Sean Metcalf

If you have experienced event id #2095, then you understand how a USN Rollback can negatively affect AD consistency.

What is a USN?

The USN (Update Sequence Number) is an Active Directory database instance counter that increments every time a single change is committed to the AD database on a Domain Controller. The USN is unique to each DC and has no correlation to a USN on another DC (and that doesn’t matter, as you will see why later on in this article).  Active Directory replication keeps track of every Domain Controller’s USN and uses this information to determine when replication is required. Active Directory has two basic types of writes to the AD database, a replicated write (where the change is performed on another DC) and an originating write (where the change is performed on the local DC). AD Replicates and leverages the information about what changes were performed on which DCs and then replicated out.

Every Domain Controller has a server object in the site container stored within the Configuration partition. This object has a child object called “NTDS Settings” which has a GUID (Globally Unique IDentifier) attribute which is replicated as part of replication metadata and used by the KCC to build the replication topology. Each DC has its own copy of the Active Directory database stored in the ntds.dit file and this unique database instance on a DC is identified with its own GUID-type identifier called the “Invocation ID”. The Invocation ID is created when the DC is promoted and only changes when the AD database is restored using a supported method or an application partition is added or removed.  The reason for this is so that when an AD database is restored to an earlier point in time, the USN is also restored to that point in time. This means that any change from the restored USN value until the original, pre-restored USN value would be ignored by other DCs pulling replication from the restored DC (since they track other DCs USNs that they replicate with and only pull updates when the destination DC’s USN increments above the last stored update value USN the DC has for it – more on this later). In order to avoid this situation, the DC’s AD database generates a new Invocation ID and stores the old Invocation ID is stored in an attribute on the server’s NTDS Settings object called retiredReplDSASignatures. In this manner, the DCs will treat a new Invocation ID as a new database and ensure it gets updates from it moving forward. You can see a DC’s Invocation ID and Server GUID by running repadmin /showrepl.

Much of the DC information is visible when running the Get-ADDomainController PowerShell commandlet:

PS C:\> import-module activedirectory ;
get-addomaincontroller -identity “MetcorpORGDC01.metcorp.org”

ComputerObjectDN           : CN=METCORPORGDC01,OU=Domain Controllers,DC=metcorp,DC=org
DefaultPartition           : DC=metcorp,DC=org
Domain                     : metcorp.org
Enabled                    : True
Forest                     : metcorp.org
HostName                   : MetcorpORGDC01.metcorp.org
InvocationId               : f2e96b87-bb2a-4572-a911-0c79721e7b4f
IPv4Address                : 10.10.10.11
IPv6Address                :
IsGlobalCatalog            : True
IsReadOnly                 : False
LdapPort                   : 389
Name                       : METCORPORGDC01
NTDSSettingsObjectDN       : CN=NTDS Settings,CN=METCORPORGDC01,CN=Servers,CN=WashingtonDC,CN=Sites,CN=Configuration,DC
                             =metcorp,DC=org
OperatingSystem            : Windows Server 2008 R2 Enterprise
OperatingSystemHotfix      :
OperatingSystemServicePack : Service Pack 1
OperatingSystemVersion     : 6.1 (7601)
OperationMasterRoles       : {SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster…}
Partitions                 : {DC=ForestDnsZones,DC=metcorp,DC=org, DC=DomainDnsZones,DC=metcorp,DC=org, CN=Schema,CN=Co
nfiguration,DC=metcorp,DC=org, CN=Configuration,DC=metcorp,DC=org…}
ServerObjectDN             : CN=METCORPORGDC01,CN=Servers,CN=WashingtonDC,CN=Sites,CN=Configuration,DC=metcorp,DC=org
ServerObjectGuid           : 214c2f5d-f9eb-4b0c-b1fa-4829fc8be2fc
Site                       : WashingtonDC
SslPort                    : 636

Notice in the Get-ADDomainController ouput above, there is a Computer Object DN and a Server Object DN?

  • The Computer Object DN is where the Domain Controller’s computer object is stored in the domain partition (DC=metcorp,DC=org in the example) and represents the DC in the domain.
  • The Server Object DN is representation of the DC as a replication object and is stored in the configuration partition under the site object (…,CN=Sites,CN=Configuration,DC=metcorp,DC=org in the example).

Every replicated change includes the following pieces of information:

  • The Replication Source DC’s GUID replicating the change (originating or replicated write)
  • The Replication Source DC’s USN
  • The Originating DC’s GUID (the DC where the AD update was first performed)
  • The Originating DC’s USN

NOTE: If the Originating Source DC’s GUID & the Originating DC’s GUID are the same, then this is an originating write. If they are different, then the change operation is a replicated write and the replication system uses the Up-To-Dateness Vector. The DCs use all of this information inlcuding the Up-To-Dateness Vector & the High Water Mark as part of “Propagation Dampening” to ensure that replication doesn’t get stuck in a loop.

There are two primary mechanism that leverage a DC’s USN to track replication updates:

  1. The Up-to-Dateness-Vector(UTDV) is a method by which DC replication partners can quickly identify when data needs to be replicated.  Each DC has a UDV that keeps track of the USN for every DC hosting a replicated partition. Every DC in the AD forest hosts the same base partitions and replicates these partitions separately: Configuration & Schema and frequently the Domain DNS & Forest DNS application partitions. All of the DCs in the same domain host the same domain partition. Each partition has an associated UDV with all DCs hosting the partition and their associated USN.Simply put, the UTDV is a table of all the DCs for a replicated partition and their replicated USNs and date/time when the DC last replicated. The UTDV is sent to the Source DC by the requesting Destination DC (replicating data is always a pull even though the notification may be a push action) to filter out updates the Destination DC already has. At the end of the replication cycle the Source DC sends the Destination DC its UTDV.Here’s an example of what it looks like:Repadmin: running command /showutdvec against full DC METCORPORGDC02.metcorp.org
    Caching GUIDs.
    ..
    WashingtonDC\METCORPORGDC02 (retired) @ USN 65593 @ Time 2012-01-21 12:29:38
    WashingtonDC\METCORPORGDC02 @ USN 62096 @ Time 2012-01-23 21:47:00
    ae7a0f8e-e7bd-4d4f-83df-1c731cdd8e47 @ USN 46734 @ Time 2012-01-21 14:17:26
    WashingtonDC\METCORPORGDC01 @ USN 59160 @ Time 2012-01-23 21:46:33Notice how DC02 has 2 different entries, one with a USN of 65593 (marked Retired) and one with a USN of 62096. AD replication ignores the (Retired) Invocation ID’s USN and uses the current one for replication decisions, though it does keep it in the UTDV to ensure the USNs are kept separate.
  2.  The High Water Mark (HWM) on a DC tracks the highest USN replicated from each DC and uses that to identify when replication is required.Simply put, the HWM tracks the last USN replicated by one of the local DC’s replication partner. The HWM is used to track the most recent changes (objects and attributes) a Destination DC has received from Source DCs for a specific partition.For example, we have DC01 and DC02:DC01′s USN: 3300
    DC02′s USN: 2200DC01 has a HWM of 2000 for DC02 and DC02 has a HWM of 3300 for DC01. When a change is performed on DC01, the USN is incremented to 3301 and when DC02  requests updates, it requests any changes since USN 3300. DC01 sends DC02 change #3301 and DC02 performs a replicated write to its AD database incrementing its local USN to 2201. What’s interesting about this is that at this point, DC01 has a HWM of 200 still and DC02 now has a  USN of 2201. Since the DCs have the information about the originating DC and the originating DC’s USN, they know that this change has already been replicated so they update their HWM and wait for the next change.

What is USN Rollback?

Since updates are replicated when the USN on the source DC is larger than the destination DC has for the source DC (according to the UTDV & HWM), a USN Rollback scenario on a DC prevents replication of AD updates on that DC to any other.  Typically when a USN goes backwards, it is due to a supported restore from backup. When this process occurs, the invocation ID changes. Since all replica partners track replication based on DC GUID, Invocation ID, and USNs, a supported restore method keeps the previous invocation ID as “retired” and effectively ignores it. The new database Invocation ID & associated USN are used to get AD changes from the DC… except when the USN rolls back with NO change in Invocation ID. This means that when a DC is in a state of USN Rollback, AD updates can be performed on that DC with NONE of the changes replicated to its replication partners. That’s bad news.

Examples help clarify concepts, so I’ll use one here.

DC01, DC02 & DC03 are Domain Controllers for the Active Directory domain metcorp.org.
DC01 is running on physical hardware and DC02 & DC03 are virtual DCs running on VMWare ESX.

The AD admin copies the DC02 virtual files on Monday and on Wednesday, DC02 fails.
The admin uses the DC02 VM files from Monday to get DC02 up and running on Thursday (ASAP, right?).

During the next replication cycle, DC01 & DC03 send DC02 the last update USN they have for DC02 (USN #31,131). DC02 checks its local USN and notes that the local USN (USN #29,000) is less than the ones sent (USN #31,131), so no update is replicated to DC01 or DC03. As changes to Active Directory are performed on DC02, they are not replicated to the other metcorp.org DCs until DC02′s USN increments past the USN the other DCs have for DC02. This means that 2,131 modifications occur on DC02 before the other DCs receive a single update – and then only changes from USN 31,132 on.

Note that in this situation, any change performed on DC02 is NOT replicated to any other DC. This means that modifications to AD on DC02 only exist on DC02 while other DCs may have different versions of the same objects, including passwords and group membership.  See, bad news.

Day 01 – Sunday:
DC01′s USN #34,951
DC02′s USN #28,539
DC03′s USN #22,360

Day 02 – Monday:
DC01′s USN #35,123
DC02′s USN #29,000 (VM copied)
DC03′s USN #23,101

Day 03 – Tuesday:
DC01′s USN #36,432
DC02′s USN #31,131 – FAILS
DC03′s USN #24,555

Day 04 – Wednesday:
DC01′s USN #38,012
DC02 OFFLINE
DC03′s USN #25,010

Day 05 – Thursday:
DC01′s USN #39,951
DC02 Back online with USN #29,000
DC03′s USN #27,360

What causes USN Rollback to occur?

There are several scenarios that Microsoft has identified that can cause USN Rollback on a DC (i.e. unsupported configurations). All of these include the same common theme and that is taking an earlier state of a DC (backup or copy) and running it.

  •  Starting an Active Directory domain controller whose Active Directory database file was restored (copied) into place by using an imaging program such as Norton Ghost.
  • Starting a previously saved virtual hard disk image of a domain controller. The following scenario can cause a USN rollback:
    1. Promote a domain controller in a virtual hosting environment.
    2. Create a snapshot or alternative version of the virtual hosting environment.
    3. Let the domain controller continue to inbound replicate and to outbound replicate.
    4. Start the domain controller image file that you created in step 2.
  • Starting an Active Directory domain controller that is located on a volume where the disk subsystem loads by using previously saved images of the operating system without requiring a system state restoration of Active Directory.

These scenarios pretty much always involve a virtual environment, so if you have virtual DCs you may want to ensure backups are done on the physical DCs (you can never go wrong with performing backups on the FSMOs to start) and/or ensure that the Windows Backup tool is used to backup the AD database (SUPPORTED backup method is key).

Detecting USN Rollback

Detecting USN Rollback is extremely difficult since DCs running Windows 2000 or Windows 2003 RTM didn’t check for repeating USNs for the same Invocation ID. There are no errors in the NTDS Replication event log or when using the replication utility Repadmin. There is a manual method for detecting a USN Rollback using Repadmin and Microsoft KB 875495 describes this process:

One way to detect a USN rollback is to use the Windows Server version of Repadmin.exe to run the repadmin /showutdvec command. This version of Repadmin.exe displays the up-to-dateness vector USN for all domain controllers that replicate a common naming context. To detect a USN rollback, compare the output of the repadmin /showutdvec command on the domain controller with the output of the same command on the domain controller’s replication partners. If the direct replication partners have a higher USN number for the domain controller than the domain controller has for itself, and the repadmin /showreps command does not report replication errors between direct replication partners, you have compelling evidence of a USN rollback.

C:\>Repadmin /showutdvec dc1 dc=contoso,dc=com
Caching GUIDs…
Site1\DC1 @ USN 10 @ Time 2004-08-04 15:07:15
Site2\DC2 @ USN 24805 @ Time 2004-08-04 15:06:59
C:\>Repadmin /showutdvec dc2 dc=contoso,dc=com
Caching GUIDs…
Site1\DC1 @ USN 50 @ Time 2004-08-04 15:07:15
Site2\DC2 @ USN 24805 @ Time 2004-08-04 15:06:59

Note in the example repadmin output above, DC2 has a USN of 50 for DC1 while DC1 has a USN of 10 for itself.

Starting with Windows 2003 Sp1 or newer (or earlier with the KB  875495 hotfix), DCs track and flag when another DC (source DC) sends a USN that was previously acknowledged with the same invocation id.

When a USN Rollback is identified on a Windows 2003 Sp1 or newer (or earlier with the KB  875495 hotfix), the following actions are performed on that DC:

  • The DC write event 2095 to the DC’s Directory Services event log.
  • The DC disables inbound and outbound replication.
  • The DC recognizes the USN Rollback and pauses its Netlogon service. This prevents any changes from being performed on the DC.

Windows 2003 SP 1 and newer Domain Controllers that detect a USN Rollback state on a replication source DC, log the following event:

Event Type: Error
Event Source: NTDS Replication
Event Category: Replication
Event ID: 2095
Date: 3/10/2005
Time: 4:26:51 PM
User: USN\2B25VB$
Computer: 2B9A
Description: During an Active Directory replication request, the local domain controller (DC) identified a remote DC which has received replication data from the local DC using already-acknowledged USN tracking numbers. Because the remote DC believes it is has a more up-to-date Active Directory database than the local DC, the remote DC will not apply future changes to its copy of the Active Directory database or replicate them to its direct and transitive replication partners that originate from this local DC. If not resolved immediately, this scenario will result in inconsistencies in the Active Directory databases of this source DC and one or more direct and transitive replication partners. Specifically the consistency of users, computers and trust relationships, their passwords, security groups, security group memberships and other Active Directory configuration data may vary, affecting the ability to log on, find objects of interest and perform other critical operations. To determine if this misconfiguration exists, query this event ID using http://support.microsoft.com or contact your Microsoft product support. The most probable cause of this situation is the improper restore of Active Directory on the local domain controller. User Actions: If this situation occurred because of an improper or unintended restore, forcibly demote the DC. Remote DC: b55ee67f-ed73-4970-b2d4-7dc6f571439f Partition: CN=Configuration,DC=usn,DC=loc USN reported by Remote DC: 24707 USN reported by Local DC: 20485 For more information, see Help and Support Center at http://support.microsoft.com.

On the DC with USN Rollback the following events are logged:

Event Type: Warning
Event Source: NTDS General
Event Category: Replication
Event ID: 1113
Date: 3/10/2005
Time: 4:26:51 PM
User: USN\2B25VB$
Computer: 2B9A
Description: Inbound replication has been disabled by the user. For more information, see Help and Support Center at http://support.microsoft.com.

Event Type: Warning
Event Source: NTDS General
Event Category: Replication
Event ID: 1115
Date: 3/10/2005
Time: 4:26:51 PM
User: USN\2B25VB$
Computer: 2B9A
Description: Outbound replication has been disabled by the user. For more information, see Help and Support Center at http://support.microsoft.com

Event Type: Error
Event Source: NTDS General
Event Category: Service Control
Event ID: 2103
Date: 3/10/2005
Time: 4:26:51 PM
User: USN\2B25VB$
Computer: 2B9A
Description: The Active Directory database has been restored using an unsupported restoration procedure. Active Directory will be unable to log on users while this condition persists. As a result, the Net Logon service has paused. User Action See previous event logs for details. For more information, see Help and Support Center at http://support.microsoft.com.

Resolving USN Rollback on a DC

Microsoft recommends two methods to resolve a USN Rollback state:

  1. Demote & re-promote the DC – this resets the Invocation ID & the USN.
  2. Restore the DC from a supported backup (preferably using Microsoft’s Backup utility).

I recommend performing resolution step #1. Since the typical scenarios that bring about a USN Rollback involve imaging or performing an un-supported restoration, having a USN Rollback in the environment typically points to process issues. Often this is related to improper restore procedures.

In this situation, it is best to demote the Domain Controller by running dcpromo /forceremoval and perform a metadata cleanup of that DC. If the demoted DC was hosting any of the FSMO roles, they must be seized to another DC.

Only run DCPromo on the server to re-promote it after the metadata cleanup is successful (and any FSMOs are transferred).

References:

 

Google+FacebookEmailPrintShare
Posted in Favorite, Microsoft Products, Tech, Technical Reference - Tagged , , , , , , ,

Powershell Code: Create System State Backup

Jan25
2012 Leave a Comment Written by Sean Metcalf

A common process for Active Directory Admins is to perform a System State Backup to ensure that AD is properly backed up. This backup can be restored when needed in the future.

KB944530 describes how to modify the registry so you can backup a server to a volume that contains system files:

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

To enable the system state backup files to be targeted to critical volumes, you must set the value of the AllowSSBToAnyVolume registry entry under the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\

Set the value of this entry as follows:
Name: AllowSSBToAnyVolume
Data type: DWORD
Value data: 1
Note When this value is set to 1, system state backups to any volume are enabled. To revert to the default behavior, set the value to 0.

Here’s the Powershell Code to enable backups to a local drive (such as C:)

1
2
3
4
5
Write-Verbose "Configuring Server for Local System State Backup to drive C: `r "
IF (Test-Path 'HKLM:\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup')
 { "Registry key HKLM:\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup already exists." }
 ELSE { MD HKLM:\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup }
New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\" -Name "AllowSSBToAnyVolume" -Value 1 -PropertyType "DWORD"

Create a system state backup by using Wbadmin:

  1. Open a command prompt window as Administrator
  2. wbadmin start systemstatebackup -backupTarget:<VolumeName> [-quiet]

Example:
   wbadmin start systemstatebackup -backupTarget:F: -quiet

Powershell Method schedules a system state backup using PowerShell:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
write-host "Checking that backup prerequisites are are installed... " `r
import-module servermanager
$BackupFeatures = get-windowsfeature -name Backup-Features
$BackupTools = get-windowsfeature -name Backup-Tools

IF ($BackupFeatures.Installed -eq $False) {add-windowsfeature Backup-Features}
Else {write-host "Backup Features are installed. Continuing... " `r}

IF ($BackupTools.Installed -eq $False) {add-windowsfeature Backup-Tools}
Else {write-host "Backup Tools are installed. Continuing... " `r}

write-host "Configuring the Powershell session for Backup..." `r
$PSSnapInCheck = get-pssnapin | where-object {$_.name -like "*Backup*"}

IF ($PSSnapInCheck -notlike "ServerBackup")
{ ## OPEN IF Bracket - PS Snap In is not already installed
add-pssnapin Windows.ServerBackup
write-host "Updated"
} ## CLOSE IF Bracket - PS Snap In is not already installed

Else {write-host "The Powershell session is configured for Backup..." `r}

Write-Host "Set Backup Volume"
$BackupTargetVolume = "f:"

$BackupTarget = New-WBBackupTarget -VolumePath $BackupTargetVolume

# Create a new backup policy object and store it in the variable $policy.
write-host "Creating the Backup Policy..." `r
$BackupPolicy = New-WBPolicy

# Set the backup location in the policy
Add-WBBackupTarget –Policy $BackupPolicy –Target $BackupTarget

# Configures the backup policy to include the System State
IF ($BackupSystemState -eq $True)
{ ## OPEN IF Bracket - System State should be backed up
write-host "Setting the Backup Policy to backup the System State to $BackupTarget..." `r
Add-WBSystemState –Policy $BackupPolicy
} ## CLOSE IF Bracket - System State should be backed up

# Schedule the backup policy
## Will handle multiple times, for example: 6:00, 18:00
IF ($Computer -like "*1*")
{Set-WBSchedule –Policy $BackupPolicy –Schedule 6:00 }
IF ($Computer -like "*2*")
{Set-WBSchedule –Policy $BackupPolicy –Schedule 18:00 }

# Set the backup policy
Set-WBPolicy –Policy $BackupPolicy
write-host "The Backup Policy is now configured &amp; scheduled..." `r
$BackupPolicy

# Perform the backup
write-host "Backing up System State on $computer" -foregroundcolor Green `r
$Result = Start-WBBackup -Policy $BackupPolicy

[string] $PolicyBackupTargets = $BackupPolicy.BackupTargets
[string] $PolicySystemStateBackup = $BackupPolicy.SystemState
[string] $PolicySchedule1 = $BackupPolicy.Schedule[0]
[string] $PolicySchedule2 = $BackupPolicy.Schedule[1]

$Result

IF ($Result -match $Success)
{ ## OPEN IF Bracket - Backup was successful
$ElSourceCheck = get-eventlog -logname system -source $ELSource
IF (!($ElSourceCheck)) {New-EventLog -LogName System -Source $ELSource}
Write-EventLog -LogName System -Source $ELSource -EventID $EventNumber `
-Message "The DC Backup Script completed successfully. The log file is named $ResultsFile. The backup policy is configured with the following: `
Backup Target: $PolicyBackupTargets
Backup System State: $PolicySystemStateBackup
Backup Daily Schedule starting:
$PolicySchedule1
$PolicySchedule2" `r
Write-Host "The DC Backup Script completed successfully. The log file is named $ResultsFile. Event ID # $EventNumber was logged in the System Log. " `r
} ## CLOSE IF Bracket - Backup was successful

Else {write-host "Backup was not successful. Please review the log file named $ResultsFile." `r}

References:

Google+FacebookEmailPrintShare
Posted in Deployment, Microsoft Products, Powershell Code, Tech - Tagged , , , , , , , ,

Active Directory Replication Site Link Schedules and Time Zones

Jan20
2012 Leave a Comment Written by Sean Metcalf

Here’s an interesting question regarding AD site schedules:

QUESTION:
If there is a DC in Los Angeles & a DC in Washington DC with an AD site schedule of 12pm – 5pm, when does replication actually occur?
Note: There is a 3 hour time difference between LA & DC.

ANSWER:
The Washington DC Domain Controller pulls replication from the Los AngelesDomain Controller from 12pm through 5pm Eastern Time (UTC-5)  which is 5pm – 10pm UTC.

The LA Domain Controller pulls replication from the WashingtonDC Domain Controller from 9am through 2pm Pacific Time (UTC-8) which is 5pm – 10pm UTC.

Remember that a site link only provides the replication path, the InterSite Topology Generator (ISTG) creates the inbound replication connection from connected sites. The replication connection objects are always inbound (one-way) to the DC that creates the connection object. This means there are two one-way replication connection objects representing 2 servers that pull replication from each other (RODCs only perform inbound replication and never replicate out changes).

One caveat to this answer is that the Site Link schedule is stored in UTC time (remember Windows stores time as UTC which is also called GMT) based on the adjusted time at the server where the Site Link schedule is configured. In other words, if a Site Link schedule is configured on a Washington DC server, the schedule will be based on the local time. So, if the Site Link schedule is created on a Washington DC server (as in the example above) for 12:00 – 17:00 (Eastern Time) it is stored as 17:00 – 22:00 (UTC). However, if the Site Link schedule is created on a LA server and AD Sites & Services is pointed to a Washington DC server, the schedule is based on the time of the LA server which would be 12:00 – 17:00 (Pacific Time) and stored as 18:00 – 01:00 (UTC) which means the Washington DC Domain Controller(s) pulls replication from LA at 15:00 – 20:00 (Eastern Time).

Each server determines when it is allowed to replicate based on schedule based on UTC time. If the Site Link is configured for replciation to occur once per hour (the default), and the replication schedule is from 17:00 – 22:00 UTC, replication will likely to occur (start) during the following 5 times:

  • 17:00 -17:15
  • 18:00 -18:15
  • 19:00 -19:15
  • 20:00 -20:15
  • 21:00 -21:15

From TechNet:

Specifically, a replication event is queued at time t + n, where t is the replication interval that is applied across the schedule and n is a pseudo-random number from 1 minute through 15 minutes. For example, if the site link indicates that replication can occur from 02:00 hours through 07:00 hours, and the replication interval is 2 hours (120 minutes), t is 02:00 hours, 04:00 hours, and 06:00 hours. A replication event is queued on the destination domain controller between 02:00 hours and 02:14:59 hours, and another replication event is queued between 04:00 hours and 04:14:59 hours. Assuming that the first replication event that was queued is complete, another replication event is queued between 06:00 hours and 06:14:59 hours. If the synchronization took longer than two hours, the second synchronization would be ignored because an event is already in the queue.

Replication can extend beyond the end of the schedule. A period of replication latency that starts before the end of the schedule runs until completion, even if the period is still running when the schedule no longer allows replication to be available.

References:

 

Google+FacebookEmailPrintShare
Posted in Deployment, Microsoft Products, Tech, Technical Reference, Troubleshooting - Tagged , , , , , ,

Active Directory Replication Packet Capture

Jan18
2012 Leave a Comment Written by Sean Metcalf

I was interested in what happens behind the scenes when a Domain Controller replicates to another, so I ran a packet capture to see what happens behind the scenes.

My test environment for this packet capture is a single forest, single domain environment with two DCs, both of which running Windows Server 2008 R2. On one DC, I created a new OU and several groups. The following packet data is from the replication from MetcorpOrgDC01.metcorp.org to MetcorpOrgDC02.metcorp.org (the new objects were created on DC01), so Dc02 makes requests of Dc01 and DC01 responds to Dc01.

Here are the main packets from the Active Directory replication traffic flow (minus TCP data):

  1. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.      A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Request: call_id 54 Fragment: Single opnum: 2 ctx_id: 1
    DCERPC: Response: call_id 54 Fragment: Single ctx_id: 1
    DCERPC: Alter_context: call_id: 55 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context: call_id: 55 Fragment: Single accept max_xmit: 5840 max_recv: 5840
  2. Directory Replication Service: DsGetNCChanges
    The DsReplicaSync function synchronizes a destination naming context (NC) with one of its sources.
    DRSUAPI: DsGetNCChanges request
  3. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Request: call_id 55 Fragment: Single opnum: 2 ctx_id: 1
    DCERPC: Response: call_id 55 Fragment: 1st ctx_id: 1
    DCERPC: Alter_context: call_id: 56 Fragment: Single
    DRSUAPI V4.0
    DCERPC: Alter_context: call_id: 56 Fragment: Single accept max_xmit: 5840 max_recv: 5840
  4. Directory Replication Service: DsGetNCChanges
    The DsReplicaSync function synchronizes a destination naming context (NC) with one of its sources.
    DRSUAPI: DsGetNCChanges response
  5. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Bind: call_id 57 Fragment: Single, 2 context items, 1st DRSUAPI 4.0
    DCERPC: Bind_ack: Call_id: 57 Fragment: Single accept max_xmit: 5840 max_recv: 5840
    DCERPC: Alter_context: call_id: 57 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context: call_id: 57 Fragment: Single accept max_xmit: 5840 max_recv: 5840
  6. Directory Replication Service: DsReplicaSync
    When a DC receives a DSReplicaSync Request, then for each DC that it replicates from (stored in RepsFrom data structure) it performs a replication cycle, where it behaves like a client and makes DSGetNCChanges requests to that DC. So it gets up-to-date AD objects from each of the DC’s which it replicates from. This function implements a changes propagation mechanism.
    DRSUAPI: DsReplicaSync request
    DRSUAPI: DsReplicaSync response
  7. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Bind: call_id 56 Fragment: Single, 2 context items, 1st DRSUAPI 4.0
    DCERPC: Bind_ack: Call_id: 56 Fragment: Single accept max_xmit: 5840 max_recv: 5840
    DCERPC: Alter_context: call_id: 56 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 56 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context: call_id: 56 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 56 Fragment: Single DRSUAPI V4.0
  8. Directory Replication Service: DsGetNCChanges
    The DsReplicaSync function synchronizes a destination naming context (NC) with one of its sources.
    DRSUAPI: DsGetNCChanges request
    DRSUAPI: DsGetNCChanges response
  9. NTP Time Synchronization
    Although the Windows Time service is not an exact implementation of the Network Time Protocol (NTP), it uses the complex suite of algorithms that is defined in the NTP specifications to ensure that clocks on computers throughout a network are as accurate as possible. Ideally, all computer clocks in an AD DS domain are synchronized with the time of an authoritative computer.
    NTP: NTP Version 3, Symmetric active
    NTP: NTP Version 3, server (Peer Clock Stratum, Peer Polling Interval, Peer Clock Precision, Root Delay,Root Dispersion, Reference ID, Reference Timestamp, Origin Timestamp, Receive Timestamp, TransmitTimestamp, Key ID, Message Authentication Code)
  10. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Bind: call_id 58 Fragment: Single, 2 context items, 1st DRSUAPI 4.0
    DCERPC: Bind_ack: Call_id: 58 Fragment: Single accept max_xmit: 5840 max_recv: 5840
    DCERPC: Alter_context: call_id: 58 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 58 Fragment: Single DRSUAPI V4.0
    DRSUAPI: DsReplicaSync request
    DRSUAPI: DsReplicaSync response
    DCERPC: Alter_context: call_id: 57 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 57 Fragment: Single
    DRSUAPI V4.0
  11. Directory Replication Service: DsGetNCChanges
    The DsReplicaSync function synchronizes a destination naming context (NC) with one of its sources.
    DRSUAPI: DsGetNCChanges request
    DRSUAPI: DsGetNCChanges response
  12. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Bind: call_id 58 Fragment: Single, 2 context items, 1st DRSUAPI 4.0
    DCERPC: Bind_ack: Call_id: 58 Fragment: Single accept max_xmit: 5840 max_recv: 5840
    DCERPC: Alter_context: call_id: 58 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 58 Fragment: Single DRSUAPI V4.0
  13. Directory Replication Service: DsReplicaSync
    When a DC receives a DSReplicaSync Request, then for each DC that it replicates from (stored in RepsFrom data structure) it performs a replication cycle, where it behaves like a client and makes DSGetNCChanges requests to that DC. So it gets up-to-date AD objects from each of the DC’s which it replicates from. This function implements a changes propagation mechanism.
    DRSUAPI: DsReplicaSync request
    DRSUAPI: DsReplicaSync response
  14. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Bind: call_id 59 Fragment: Single, 2 context items, 1st DRSUAPI 4.0
    DCERPC: Bind_ack: Call_id: 59 Fragment: Single accept max_xmit: 5840 max_recv: 5840
    DCERPC: Alter_context: call_id: 59 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 59 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context: call_id: 59 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 59 Fragment: Single DRSUAPI V4.0
  15. Directory Replication Service: DsGetNCChanges
    The DsReplicaSync function synchronizes a destination naming context (NC) with one of its sources.
    DRSUAPI: DsGetNCChanges request
    DRSUAPI: DsGetNCChanges response
  16. NTP Time Synchronization
    Although the Windows Time service is not an exact implementation of the Network Time Protocol (NTP), it uses the complex suite of algorithms that is defined in the NTP specifications to ensure that clocks on computers throughout a network are as accurate as possible. Ideally, all computer clocks in an AD DS domain are synchronized with the time of an authoritative computer.
    NTP: NTP Version 3, Symmetric active
    NTP: NTP Version 3, server (Peer Clock Stratum, Peer Polling Interval, Peer Clock Precision, Root Delay, Root Dispersion, Reference ID, Reference Timestamp, Origin Timestamp, Receive Timestamp, Transmit Timestamp, Key ID, Message Authentication Code)
  17. Directory Replication Service: DsReplicaSync
    When a DC receives a DSReplicaSync Request, then for each DC that it replicates from (stored in RepsFrom data structure) it performs a replication cycle, where it behaves like a client and makes DSGetNCChanges requests to that DC. So it gets up-to-date AD objects from each of the DC’s which it replicates from. This function implements a changes propagation mechanism.
    DRSUAPI: DsReplicaSync request
    DRSUAPI: DsReplicaSync response
  18. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Alter_context: call_id: 60 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 60 Fragment: Single DRSUAPI V4.0
  19. Directory Replication Service: DsGetNCChanges
    The DsReplicaSync function synchronizes a destination naming context (NC) with one of its sources.
    DRSUAPI: DsGetNCChanges request
    DRSUAPI: DsGetNCChanges response
  20. NTP Time Synchronization
    Although the Windows Time service is not an exact implementation of the Network Time Protocol (NTP), it uses the complex suite of algorithms that is defined in the NTP specifications to ensure that clocks on computers throughout a network are as accurate as possible. Ideally, all computer clocks in an AD DS domain are synchronized with the time of an authoritative computer.
    NTP: NTP Version 3, Symmetric active
    NTP: NTP Version 3, server (Peer Clock Stratum, Peer Polling Interval, Peer Clock Precision, Root Delay, Root Dispersion, Reference ID, Reference Timestamp, Origin Timestamp, Receive Timestamp, Transmit Timestamp, Key ID, Message Authentication Code)

References:

Google+FacebookEmailPrintShare
Posted in Microsoft Products, Packet Capture, Tech, Technical Reference, Troubleshooting - Tagged , , , , , , ,

Microsoft Key Management Server (KMS) Details

Jan13
2012 Leave a Comment Written by Sean Metcalf

KMS Introduction

The Microsoft Key Management Server (KMS) is part of the Microsoft Volume Activation 2.0 solution managing Windows OS activation keys and performs activation for supported clients automatically. Starting with Windows Server 2008 & Windows Vista, Microsoft switched to an online activation system where every Windows OS requires activation.  KMS shifts the activation requirement to a single machine which is activated with a special KMS Host (server) key.  Every KMS supported Windows version automatically communicates with the KMS server to activate Windows and manage the activation key (configuring the Windows OS with a KMS key forces it to find a KMS Host and get activation from it).
KMS supported clients include Windows Server 2008, Windows Server 2008 R2, Windows Vista, & Windows 7.

The KMS client discovers the KMS server by performing a DNS query for the KMS SRV record in DNS.

DNS: Standard query SRV  _vlmcs._tcp.metcorp.org
DNS: standard query response SRV  0 100 1688 kms.metcorp.org (addr 10.10.10.11)

The DNS query response includes the KMS server hostname and port number (1688).
The KMS client then initializes a connection to port 1688 on the KMS server.

By default, a Windows installation’s license is configured with a grace period of 30 days plus 2 “rearms” (slmgr.vbs /rearm) for a total of  90 days to activate. Once activated by KMS, the KMS client communicates with the KMS server every 7 days to renew its activation as well as resetting the license counter to 0.

If the Windows license isn’t re-activated by a KMS server within 180 days (6 months), it shifts into a 30 day grace period after which it enters reduced functionality mode (retail only) or notification mode (where the user is notified regularly to re-activate) and continues to attempt a KMS connection every 2 hours until activated.

NOTE:

  • KMS doesn’t activate Windows workstations until at least 25 different Windows workstations have connected to KMS.
  • Also, KMS doesn’t activate Windows servers until at least 5 different Windows servers have connected to KMS.
  • Running slmgr.vbs /dli on the KMS Host provides the KMS activation count (a count of -1 means no clients have been activated).
  • Microsoft Office products are activated with a special KMS version & license key specific to Office.
  • Apparently the KMS Host in Windows 2008 prior to SP2 (and Windows 2008 R2) didn’t update the activated client count when activating virtual machines. Windows 2008 SP2 (and later) now updates the KMS count regardless of machine type, virtual or physical.

KMS Server Installation

Installing the KMS Host (Server) on a machine is simply a product key that gets activated on the computer which initializes the Software Protection Service to listen on port 1688 for license activation requests.  A multi-purpose enterprise server is the best candidate for KMS Host since the service is relatively lightweight. I don’t recommend configuring a Domain Controller as the KMS Server since a DC should only be providing Active Directory services (and DNS in most cases). This mitigates additional impact should a DC be taken down or reinstalled. The KMS Server can be installed on the same server as the DFS root name server and can also be virtualized (which may be ideal since High Availability can be easily enabled using VMWare HA).

A single KMS Server can handle the load of a large enterprise and it is not likely necessary to install a second (or more) KMS Server.  Many organizations choose to install 2 KMS Hosts to ensure license activations continue with the loss of a single server. However, going through the KMS Host activation process on an isolated network (not directly connected to the internet) is a time-consuming process. For this reason, it is recommended to use a server for KMS that can be easily restored from backup without affecting other services (this way the KMS Host key is restored on the same hardware).

Installing a KMS sever on the network is relatively straight forward.

  1. Identify a server on the network and install the appropriate KMS key by running slmgr.vbs /ipk <KmsKey> a Windows 2008 R2 server.
  2. Activate the KMS key on the KMS host by running slmgr.vbs /ato to activate online or run slui.exe 4 to activate by phone (for networks not connected to the internet).
  3. Restart the Software Protection Service by running restart-service sppsvc in an elevated PowerShell console (or net stop sppsvc && net start sppsvc if PowerShell is unavailable).
  4. Run slmgr.vbs /dli to get the KMS activated client count.

KMS Host installation performs a dynamic DNS update for a new SRV record (_VLMCS._TCP ) on port 1688. If the DNS server does not support dynamic DNS, the SRV record has to be manually created.

KMS SRV record:

Service: _VLMCS
Protocol: _tcp
Port: 1688
Priority: 10 (default is 0)
Weight:   0 (default is 0)
Host offering the service: kms.metcorp.org.
(enter FQDN with trailing “.”)

NOTE:
When configuring a second KMS server on the network, it is necessary to manually create the 2nd KMS SRV record in DNS. This is due to the original KMS sever owning the KMS SRV record that it dynamically created in DNS. Since the original KMS server owns the KMS SRV record, no other computer can update it. This is also why when replacing a KMS server, the new KMS server can’t update the existing KMS SRV DNS record.

KMS automatic DNS publishing can be disabled by running Slmgr.vbs /cdns.

The KMS Server only creates a KMS SRV record for its domain (Primary DNS Suffix). In order to configure the KMS Server to publish its KMS SRV DNS record to multiple domains:

To automatically publish KMS in multiple DNS domains, add each DNS domain suffix to whichever KMS should publish to the multi-string registry value DnsDomainPublishList in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform. After changing the value, restart the Software Licensing Service to create the SRV RRs.

KMS Host Key Types

The KMS Host key is directly related to the highest level OS used on the network, and there is a different KMS key series for Windows 2008 versus Windows 2008 R2.

A KMS key is used to activate only the KMS host with a Microsoft activation server. A KMS key can activate up to six KMS hosts with 10 activations per host. Each host can activate an unlimited number of computers. If you need to activate more than six KMS hosts, contact your Volume Licensing Service Center (http://go.microsoft.com/fwlink/p/?LinkId=184280), and state why you must increase the activation limit.

Windows Server 2008 R2 Standard edition is currently the highest product being deployed in the product grouping hierarchy (with Windows Server 2008 being below it and unable to activate Windows 2008 R2 servers). The associated KMS key for that product is the Windows Server 2008R2 _____ KMS _ key (where  _________ is the Server edition type and _ is “A”, “B”, or “C” ).

  • KMS C Key: Server Group C for Windows Server 2008 R2 (Editions: Datacenter & Itanium-based systems)
  • KMS B Key: Server Group B for Windows Server 2008 R2 (Editions: Standard & Enterprise)
  • KMS A Key: Server Group A for Windows Server 2008 R2 (Editions: Web Server & HPC Server)
  • Win 7 KMS Key: Client VL for Windows 7 (Editions: Professional & Enterprise)

The KMS license groups are configured so that a KMS key can activate all products in its group as well as all groups below it.

  • Server Group C can activate Groups C, B, A, and Client VL
  • Server Group B can activate Groups, B, A, and Client VL
  • Server Group A can activate Group A, and Client VL


KMS Client Configuration

On the client, run cscript slmgr.vbs –dlv to get the current Windows OS license status. By default, a KMS Client performs a DNS SRV query to locate a KMS server. If auto-discovery is disabled, run slmgr.vbs /ckms to re-enable. Activated clients need to communicate within 180 days (6 months) after which they enter a grace period.

Change a client’s activation key to a KMS client key by running slmgr.vbs /ipk <KmsSetupKey> and activate by running cscript slmgr.vbs /ato.

A DNS query for the SRV record identifies the KMS Server on a network:

nslookup -type=srv  _vlmcs._tcp.metcorp.org
(where metcorp.org is the domain name)


KMS Client Setup Keys

Windows 7
Windows 7 Professional FJ82H-XT6CR-J8D7P-XQJJ2-GPDD4
Windows 7 Professional N MRPKT-YTG23-K7D7T-X2JMM-QY7MG
Windows 7 Enterprise 33PXH-7Y6KF-2VJC9-XBBR8-HVTHH
Windows 7 Enterprise N YDRBP-3D83W-TY26F-D46B2-XCKRJ
Windows 7 Enterprise E C29WB-22CC8-VJ326-GHFJW-H9DH4
Windows Server 2008 R2
Windows Server 2008 R2 HPC Edition FKJQ8-TMCVP-FRMR7-4WR42-3JCD7
Windows Server 2008 R2 Datacenter 74YFP-3QFB3-KQT8W-PMXWJ-7M648
Windows Server 2008 R2 Enterprise 489J6-VHDMP-X63PK-3K798-CPX3Y
Windows Server 2008 R2 for Itanium-Based Systems GT63C-RJFQ3-4GMB6-BRFB9-CB83V
Windows Server 2008 R2 Standard YC6KT-GKW9T-YTKYR-T4X34-R7VHC
Windows Web Server 2008 R2 6TPJF-RBVHG-WBW2R-86QPH-6RTM4

 

Slmgr.vbs Parameters

Parameter Description
/sprt PortNumber Sets the TCP communications port on a KMS host. Replace PortNumber with the TCP port number to use. The default setting is 1688.
/cdns Disables automatic DNS publishing by a KMS host.
/sdns Enables automatic DNS publishing by the KMS host.
/cpri Lowers the priority of KMS host processes.
/spri Sets the priority of KMS host processes to Normal.
/sai ActivationInterval Changes how often a KMS client attempts to activate itself when it cannot find a KMS host. Replace ActivationInterval with a number of minutes. The default setting is 120.
/sri RenewalInterval Changes how often a KMS client attempts to renew its activation by contacting a KMS host. Replace RenewalInterval with a number of minutes. The default setting is 10080 (7 days). This setting overrides the local KMS client settings.
/dli Retrieves the current KMS activation count from the KMS host

Slmgr.vbs can be rum against a remote computer by using these additional parameters (omit username and password to use current credentials):

slmgr.vbs TargetComputerName [username] [password] /parameter [options]

 

References:

Google+FacebookEmailPrintShare
Posted in Deployment, Microsoft Products, Tech, Technical Reference - Tagged , , , , , ,

Windows 7 DNS Client Requests

Jan12
2012 Leave a Comment Written by Sean Metcalf

I decided I would install WireShark on my Windows 7 laptop and watch some traffic. After running Wireshark, I discovered some interesting traffic as a result of a simple DNS query…

The example I use here is a simple nslookup for google.com against the DNS server 10.10.10.11 (ns1.metcorp.org).

nslookup google.com

That simple command initiated the following activities.

When a Windows 7 workstation sends a DNS query to a DNS server, it performs the following queries (DNS client queries in Blue & responses in Orange):

  1.  Standard Query PTR 11.10.10.10.in-addr.arpa
    (reverse lookup for the PTR record associated with the primary DNS server in order to get the DNS server’s hostname).
  2. Standard Query response PTR ns1.metcorp.org
    (the DNS server responds with the hostname)
  3. Standard Query A google.com.metcorp.org
    (The DNS client appends its local domain suffix to perform single-label name resolution. The DNS client requests an A (host) record.)
  4. Standard Query response, No such name
    (The DNS server could not find  an A (host) record matching google.com.metcorp.org)
  5. Standard Query AAAA google.com.metcorp.org
    (The DNS client appends its local domain suffix to perform single-label name resolution. The DNS client requests an AAAA (IPv6 host) record which is the IPv6 version of an A record.)
  6. Standard Query response, No such name
    (The DNS server could not find  an AAAA (IPv6 host) record matching google.com.metcorp.org)
  7. Standard Query A google.com
    (The DNS client sends the original queried hostname. The DNS client requests an A (host) record.)
  8. Standard Query response, A 74.125.113.105 A 74.125.113.99  A 74.125.113.104 A 74.125.113.103 A 74.125.113.147 A 74.125.113.106
    (The DNS server locates an existing A record matching google.com. In this example, there are multiple IP addresses associated with google.com and these are provided in the response.)
  9. Standard Query AAAA google.com
    (The DNS client sends the original queried hostname. The DNS client requests an AAAA (IPv6 host) record.)
  10. Standard Query response
    (includes SOA record information for the domain)
  • Authoritative nameservers
  • google.com: type SOA, class IN, mname ns1.google.com (the mname record identifies the primary name server)
  • name: google.com
  • Type: SOA (Start of zone authority)
  • Class: IN (0×0001)
  • Time to live: 5 minutes
  • Data length: 38
  • Primary name server: ns1.google.com
  • Responsible authority’s mailbox: dns-admin.google.com
  • Serial number: 1473701 (at the time I ran it)
  • Refresh interval: 2 hours
  • Retry interval: 30 minutes
  • Expiration limit: 14 days
  • Minimum TTL: 5 minutes

NOTE:
This process doesn’t include the traffic from the local DNS server (ns1.metcorp.org) to get the A record information from the google.com DNS server.

The Windows DNS client will append its primary DNS suffix:

Note that when using Active Directory, by default, the primary DNS suffix portion of a computer’s full computer name must be the same as the name of the Active Directory domain where the computer is located. To allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is created and managed by the domain administrator using Active Directory Service Interfaces (ADSI) or the Lightweight Directory Access Protocol (LDAP).

Furthermore, the Windows DNS client will check its cache first, then send the DNS query to the first DNS server listed in the NIC settings (primary DNS) and after not receiving a response within 1 second, will send the same query to the first DNS configured server (on all network adapters) – whichever one replies first is used for subsequent queries. If there is no response from this query to all DNS servers on the preferred network adapter:

  • It waits 2 seconds for a response from the primary DNS servers configured on all other adapters.
  • After this second try with no response, the DNS client sends the query to all DNS servers on all adapters (still under consideration) waiting 2 seconds for a response.
  • After this third try with no response, the DNS client sends the query to all other DNS servers still under consideration (on all adapters) waiting 4 seconds for a response.
  • After this fourth try with no response, the DNS client sends the query to all other DNS servers still under consideration (on all adapters) waiting 8 seconds for a response.
  • At this point the DNS client returns a time-out.

Once a response is received, querying stops.
If the response is a positive one, the response is added to the client’s cache, and the query is fulfilled.
If the response is a negative one, all alternate DNS servers are removed from consideration for this query and the negative response is cached.

For example, if someone queries for portal.metcorp.org before the admin creates the A record, the user’s computer will cache this negative response from the DNS sever – the record doesn’t exist so it is cached as such on that computer until the cache expires. The admin creates the A record for portal.metcorp.org 1 minute later and asks the user to try again. The user attempts to connect to portal.metcorp.org and it fails again because this time the DNS query is satisfied by the DNS client cache on the user’s workstation.  Running ipconfig /flushdns will clear the DNS client cache on the computer including negative responses. After performing this action on the user’s computer (or restarting the DNS Client service), the user is able to receive the configured IP address for portal.metcorp.org.

The Windows DNS client performs Subnet Prioritization which means that if there are multiple IP addresses for a hostname, the response is then ordered in priority order with the hostname associated IP Addresses that are local to the client listed first. The use of Subnet Prioritization overrides DNS Round Robin behavior.

The Windows Server 2003 DNS Client service performs the following tasks:

  • Registers its names in DNS.
  • Name resolution.
  • Caching responses to name resolution queries.
  • Removes previously resolved names from the cache when it receives a negative response for the name.
  • Negative caching.
  • Keeps track of transitory (Plug and Play) network connections and the DNS server lists based on their IP configurations.
  • Maintains connection-specific domain name suffixes.
  • Prioritizes which DNS servers it uses according to whether they respond to a query if multiple DNS server are configured on the client.
  • Prioritizes the multiple A resource records it receives from a DNS server based on their IP address.
  • Initiates a network failure timeout when all DNS Client service queries time out, and does not submit any queries for 30 seconds. This feature applies to every adapter separately.
    From “How DNS Works“

References:

Google+FacebookEmailPrintShare
Posted in Deployment, Microsoft Products, Tech, Technical Reference - Tagged , , , , ,
« Older Entries
Content Disclaimer: This blog and its contents are provided "AS IS" with no warranties, and they confer no rights. Script samples are provided for informational purposes only and no guarantee is provided as to functionality or suitability. The views shared on this blog do not represent the views of Metcorp Consulting, LLC or its partners. Content Ownership: All content posted here is intellectual work and under the current law, the poster owns the copyright of the article. Terms of Use Copyright © 2011 - 2012