Latest Entries »

PowerShell code for adding Domain Controller

 #
 # Windows PowerShell script for AD DS Deployment
 #
Import-Module ADDSDeployment
 Install-ADDSDomainController `
 -NoGlobalCatalog:$false `
 -CreateDnsDelegation:$false `
 -Credential (Get-Credential) `
 -CriticalReplicationOnly:$false `
 -DatabasePath “C:\Windows\NTDS” `
 -DomainName “test.local” `
 -InstallDns:$true `
 -LogPath “C:\Windows\NTDS” `
 -NoRebootOnCompletion:$false `
 -SiteName “Default-First-Site-Name” `
 -SysvolPath “C:\Windows\NTDS” `
 -Force:$true

Advertisements

Introducing Hyper-V 3.0 Microsoft added some new features which allows for better virtualization management for Domain Controllers. From now, you don’t have to affraid USN Rollback when you restore your DC from snapshot or when you use DC’s clone in your environment. New Hyper-V 3.0 is “smarter” and it secures your environment. Thanks to that, you may use new feature for rapid DC deployment from the existing Domain Controller. You need to only allow cloning DC, adding it into appropriate domain group and prepare some XML config file with PowerShell v3.0 cmd-let. Then you can safely clone new DCs from the existing one(s).

In virtualized domain environments, this feature is also really good for disaster forest/domain recovery.

Important! To be able to use the new feature, you need at least one Windows Server 2012 Domain Controller on which you hold PDC Emulator operation master role.

More about Domain Controller virtualization process, you will read on Microsoft Technet at
http://technet.microsoft.com/en-us/library/hh831734.aspx

Active Directory Based Authentication

With Windows Server 2012, Microsoft presented new Windows activation method. This method is called Active Directory Based Authentication. That is available in Volume Activation Services role when you run Server Manager.

P1

Volume Activation Services – Active DIrectory Based Authentication

When you use Windows 8 in your environment, you can simply activate it when client is being joined to the domain. It happens automatically, you don’t need to put an activation key and there is no need to access the Internet.

This much more secures your environment in comparison to KMS server. When KMS was present in the environment, you need to only know server name on which it was running (there is also other method for that but I would not describe it here  and you can simply activate your Windows copy. Now, with AD BA you need to add client to the domain to allow for OS activation. It is also important to limit users in your environment with permission for joining computers into domain.

Of course, you can still use KMS server for that. It is suported by AD BA. However, it is required for previous Windows OSes. AD BA may be only used for Windows 8 activation!

Important! To be able to use AD BA option, you need to extend Active Directory schema to Windows Server 2012 but you don’t need to have Windows Server 2012 Domain Controller

RID Operation Master

Microsoft improved RID FSMO role in Windows Server 2012. The most know improvement in this role is its RID pool incrementation. Previously we had 2^30 available RIDs and now we have one bit more 2^31. This bit incremented pool  from one billion to two billions of RIDs. Thanks to that improvement we have doubled RID’s pool. But we need to know one important thing. If we want to use that, we need to have Windows Server 2012 Domain Controllers or Windows Server 2008R2 with appropriate hotfix installed. Other Windows versions do not support extended RID pool.

Remember! Extended RID pool may be used only by Windows Server 2012 and Windows Server 2008R2 with appropriate hotfix installed. Additionally, you need to have RID Operation Master role on Windows Server 2012 Domain Controller!

Another great thing introduced with Windows Server 2012 is RID Pool re-use feature! Microsoft did not fix RID leak issue which happens mostly when you are creating new users in a script mode. When password set up by script does not meet domain password criteria, object cannot be created successfully and RID is lost. In case that your script was prepared to create many user objects, you are loosing many RIDs. With Windows Server 2012 on which RID Operation Master is held, those RIDs are going to RID Pool re-use. This pool catches all those RIDs and uses them for the next objects which are created. If pool is empty then standard RID is used from global DC’s pool.

Important! RID Pool  re-use is only available until you will restart Domain Controller. After server reboot that pool is empty!

In Windows Server 2012 Microsoft introduced also event logging for used RIDs. The first entry will appear when RID consumes 100.000.000 (10% of pool). Another entry will be recorded when 10% of remaining pool will be used (in this case 1.000.000.000 – 100.000.000 = 900.000.000 and 10% from remaining pool is 90.000.000).

Events are recorded every 10% consumption of remaining pool. Smaller RIDs pool more frequent logs in Event log.

Microsoft changed also, possibility to issue large pool of RIDs from RID Master to other Domain Controllers. By default RIDs are delivered in 500 in a pool for each Domain Controller. Administrator is able to change that value in registry but when he/she sets up too high value, RIDs may be exhausted in short time. In Windows Server 2012 Microsoft limited maximum amount of RIDs to issue. The maximum pool allowed for distribution is 15.000 (decimal). When you set up higher value in the registry, it won’t be issued to Domain Controller(s) because new mechanism will issue maximum 15.000 RIDs in a pool.

One more interesting thing introduced in new RID Mater FSMO role is RID Manager artificial ceiling protection mechanism. Microsoft knows that administrators do not read event log frequently and even if they read it, they do not react too fast to solve the issue recorded in Event log. They implemented new mechanism which blocks RID distribution when its pool exceeds 90%. From that point, RID Master does not issue any pool to other Domain Controllers. Administrator must manually unlock this. That mechanism informs administrator about pool exhaustion (90% RIDs in general pool are used) and informs that additional activity may be required to prevent complete exhausting RID pool.

Other new Active Directory features

  • Kerberos enhancements
  • Active Directory Replication and Topology Management
  • Off-Premises Domain Join
  • Group Managed Service Accounts (GMSA)
  • Deferred Index Creation

Refer:  http://technet.microsoft.com/en-us/library/hh831477.aspx.

New features in Active Directory in Windows Server 2012

Some new features or improvements in Windows server 2012 Active directory.

  • New Domain Controller promotion process
  • Improved Active Directory Administrative Center console
  • New Domain Controller virtualization features
  • Dynamic Access Control
  • Active Directory Based Authentication
  • RID Operation Master improvements

For more features and advancement, Refer: http://technet.microsoft.com/en-us/library/hh831477.aspx

New Domain Controller promotion process

Microsoft simplified Domain Controller promotion process as much as they can. In Windows Server 2012 they do a real great improvement. Domain Controller promotion process allows much more simple introduction of the first Windows Server 2012 DC in your existing domain environment.

You don’t have to extend your schema and prepare domain environment for the first Windows Server 2012 Domain Controller. Previously, you had to extend schema and prepare domain using adprep manually with appropriate switches before you were able to promote DC based on newer operating system. Also dcpromo known from previous Windows v    ersions is no longer used for server promotion. That command is integrated with new Windows Server Manager. Whole process for Windows Server 2012 Domain Controller introduction in the existing environment is based on GUI wizard in Server Manager.

You need to only be logged on with appropriate permissions and you can start the process very quickly. Just add Active Directory: Domain Services role from the new manager and after all, follow post-installation steps in notification area. When you are promoting new DC, you are informed that wizard extends schema and prepares domain for the new Domain Controller.

P1

Automatic forest and domain preparation

P2

Automatic forest and domain preparation

P3

As I mentioned above, dcpromo cannot be used for DC promotion as it was in the previous versions of Windows. It is integrated with Server Manager and if you try to run it from command-line, you will see that it is not possible and you have to run the process from new manager.

P4

There is No dcpromo

However, you can still use dcpromo in command-line to:

  • forcefully decommission DC (/forceremoval switch)
  • install from media DC (/adv switch)

Note! You need to know that everything you will do in Server Manager is translated to PowerShell v3.0 code and run in the background.

New Active Directory Administrative Center

Microsoft introduced for the first time ADAC in Windows Server 2008R2. We were able to use this console for:

  • User management
  • Computer management
  • Group management
  • OU management
  • Domain Functional Level management
  • Forest Functional Level management
  • LDAP queries

Now, new Active Directory Administrative Center console allows for more. Of course, all the previous features are still suported but some new are available:

You don’t have to use complicated PowerShell cmd-lets to restore deleted object(s) or create/modify Fine-Grained Password policy. From now, you can simply use GUI for that. Just run new ADAC (it is available in tools or execute dsac.exe in run box) and go to Deleted Objects container to restore deleted object(s)

P5

GUI for AD Recycle Bin

The same situation is for Fine-Grained Password Policy, you don’t have to use ADSI Edit or PowerShell to create new PSO. This is also available over GUI method in ADAC console.

P6

GUI for Fine-Grained Password Policy

Everything what you do in Active Directory Administrative Center is also translated into PowerShell v3.0 code and run in the background. In this case, ADAC has implemented new feature called PowerShell History viewer which allows you to see cmd-lets used for action and whole syntax. You can copy it into notepad and modify to run it later. This is really good method to learn PowerShell.

PowerShell History viewer is available at the bottom of Active Directory Administrative Center console

PowerShell History viewer

Completely new feature in Windows Server 2012 is Dynamic Access Controll. It is responsible for simplified management of claims in AD and allows to extend FileServer permissions out of standard ACL method. User does not need to be a member of many groups in Active Directory, You can allow him/her access to resources over claims in combination with DAC. This option reduces Kerberos token size which is really important in large domain environments where user is a member of many groups.

Lingering Objects

When some object is deleted on a DC it is changed into a tombstone. When an object is transformed into a tombstone ALL almost attributes values, except those mandatory and additionally manually configured, are stripped from the deleted object.

NOTE:

  • The values of the following attributes are preserved during a deletion:
    • objectGUID, objectSid, nTSecurityDescriptor and uSNChanged.
    • Additionally on W2K3 SP1 DCs: sIDHistory
  • Additional attributes can be configured to be preserved by:
    • Using ADSIEDIT.MSC and connecting to the schema partition
    • Configure the “searchFlags” property of the attribute which consists of bits, each with a certain meaning! Don’t just change this without knowing what you are doing!!!
    • Enabling the FOURTH bit on the “searchFlags” property preserves the attribute value in the tombstone of the deleted objects.
      • 1st bit: 2^0=1
      • 2nd bit: 2^1=2
      • 3rd bit: 2^2=4
      • 4th bit: 2^3=8 <——this one!

 

After that the new object form (the tombstone) replicates (at least… it should!) to all DCs/GCs. The lifetime of the tombstone within the directory service depends on the “tombstone lifetime period”, which is a forest-wide configuration. The value for the “tombstone lifetime period” can be seen on:

  • Object: “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<domain>,DC=<tld>”
  • Attribute: “tombstoneLifetime”
  • Value:
    • Fresh install of AD with W2K DCs (all SPs): 60 days
    • Upgrading AD with W2K DCs to W2K3 DCs: 60 days
    • Upgrading AD with W2K DCs to W2K3 SP1 DCs: 60 days
    • Fresh install of AD with W2K3 DCs (all SPs): 60 days
    • Upgrading AD with W2K3 DCs to W2K3 SP1 DCs: 60 days
    • Fresh install of AD with W2K3 SP1 DCs (all SPs): 180 days
    • <not set> means: 60 days

 

A process on each DC called the “Garbage Collection Process” runs each 12 hours and checks, amongst other activities, if tombstones are older than the configured “tombstone lifetime period” they are removed from the directory forever! (nothing to worry as this is a normal process and it should work this ways!) That removal does not replicate to others DCs, but each DC on its own does this check.

 

So now let’s look at HOW lingering objects occur!

Lingering objects occur when a DC/GC is not available (e.g. due to network connectivity issues or DNS issues or it has been shutdown or whatever) for more than the “tombstone lifetime period”.

 

Because of that, that particular DC/GC is not able to replicate at least once within the “tombstone lifetime period” to receive the tombstones. If the unavailable/disconnected DC/GC becomes available again after the “tombstone lifetime period” has passed, inconsistencies (may… but probable will) exist between DCs/GCs, which might cause security related issues, replication issues and even loss of functionality.

Whether or not the lingering objects replicate back to the other DCs/GCs depends on how the two defense mechanisms (for W2K3 and later) against lingering objects are configured. W2K DCs only have one defense mechanism, being option 2.

  1. Replication time between DCs exceeds the “tombstone lifetime period”
  2. Strict and loose replication

 

(1): Replication time between DCs exceeds the “tombstone lifetime period”

When a DC/GC does not replicate at least once within the “tombstone lifetime period” with other DCs/GCs, replication is halted with that DC.

This defense is NOT in place when the following registry name is available and set to a value of 1 (one).

This defense is in place when the following registry name is set to a value of 0 (zero) or is not available:

  • Registry Key: HKLMSystemCurrentContro
    lSetServicesNTDSParameters
  • Registry Name: Allow Replication With Divergent and Corrupt Partner
  • Registry Type: REG_DWORD

 

(2): Strict and loose replication

When strict replication is enabled on a DC/GC the inbound replication of lingering objects is halted and reported (event ID 1988 in the Directory Service event log) for the partition that contains the lingering object. When loose replication is enabled on a DC/GC the inbound replication of lingering objects is NOT halted but it is reported (event ID 1388 in the Directory Service event log). Lingering objects can be detected on DCs by either looking for event ID 1388 or event ID 1988 on DCs/GCs using, amogst others, the EventCombMT tool (Resource Kit).

This defense is NOT in place when the following registry name is NOT available or it is set to a value of 0 (zero).

This defense is in place when the following registry name is available AND set to a value of 1 (one):

  • Registry Key: HKLMSystemCurrentControlSetServicesNTDSParameters
  • Registry Name: Strict Replication Consistency
  • Registry Type: REG_DWORD

 

When STRICT replication is ENABLED:

  • Event ID 1988 is registered in the Directory Service event log of the DC NOT containing the lingering (while replication of the lingering object was prevented), which specifies:
    • The transport-specific network address of the “source DC” (the DC containing the lingering object)
      • Example: ed0c6501-28c1-47e9-b3db-5dcf281e9e31._msdcs.ADCORP.LAN)
    • The “distinguishedName” of the “lingering object”
      • Example: CN=JORGE DE ALMEIDA PINTO,OU=Users,OU=ORG,DC=ADCORP,DC=LAN
    • The “objectGUID”  of the “lingering object”
      • Example: r84ssk2a-92kj-938r-n49a-b3xxc7912423
  • This event ID will only be logged on the DC when an attempt is made to inbound replicate the lingering object from the DC containing the lingering object. That attempt will be triggered when a changed is made on the lingering object on the DC containing the lingering object.

 

When LOOSE replication is ENABLED:

  • Event ID 1388 is registered in the Directory Service event log of the DC which previoudly did NOT contain the lingering (while replication of the lingering object was NOT prevented), which specifies:
    • The transport-specific network address of the “source DC” (the DC containing the lingering object)
      • Example: ed0c6501-28c1-47e9-b3db-5dcf281e9e31._msdcs.ADCORP.LAN)
    • The “distinguishedName” of the “lingering object”
      • Example: CN=JORGE DE ALMEIDA PINTO,OU=Users,OU=ORG,DC=ADCORP,DC=LAN
    • The “objectGUID”  of the “lingering object”
      • Example: r84ssk2a-92kj-938r-n49a-b3xxc7912423
    • The “Directory partition” containing the lingering object(s)
      • Example: DC=ADCORP,DC=LAN
    • The “Destination highest property USN” (the highest commited USN on the DC NOT containing the lingering object)
      • Example: USN: 14221
  • This event ID will only be logged on the DC when an attempt is made to inbound replicate the lingering object from the DC containing the lingering object. That attempt will be triggered when a changed is made on the lingering object on the DC containing the lingering object.

To DETECT lingering objects (but not remove):

  • STRICT replication consistency MUST be enabled for the following to work.
  • Will NOT work with LOOSE replication consistency as the data between the “DC with lingering objects” and “DC with correct data” is the same
  • REPADMIN /REMOVELINGERINGOBJECTS <FQDN of DC with lingering objects> <objectGUID of DC with correct data> <DN of partition containing lingering objects> /ADVISORY_MODE
    • Example:
      • repadmin /removelingeringobjects BAD-DC.ADCORP.LAN ed0c6601-28c1-47e9-b3db-5dcf291d9e31 DC=ADCORP,DC=LAN /advisory_mode
  • On the DC/GC containing the lingering objects the event IDs 1938 (starting detection summary), 1946 (for each lingering object detected) and 1942 (final detection summary) are registered in the Directory Service event log.

To DETECT and REMOVE lingering objects:

  • STRICT replication consistency MUST be enabled for the following to work.
  • Will NOT work with LOOSE replication consistency as the data between the “DC with lingering objects” and “DC with correct data” is the same
  • REPADMIN /REMOVELINGERINGOBJECTS <FQDN of DC with lingering objects> <objectGUID of DC with correct data> <DN of partition containing lingering objects>
    • Example:
      • repadmin /removelingeringobjects BAD-DC.ADCORP.LAN ed0c6601-28c1-47e9-b3db-5dcf291d9e31 DC=ADCORP,DC=LAN
  • On the DC containing the lingering objects the event IDs 1937 (starting removal summary), 1945 (for each lingering object detected and removed) and 1939 (final removal summary) are registered in the Directory Service event log.

So if STRICT replication is ENABLED, possible ways to detect lingering objects:

  • REPADMIN /REMOVELINGERINGOBJECTS with the /ADVISORY_MODE option
  • Scan DCs for event ID 1988 which contain information about the lingering objects (e.g. with EVENTCOMBMT)
  • For global catalogs use can ALSO use GCCHK from joeware.net (http://www.joeware.net/win/free/tools/gcchk.htm)

So if LOOSE replication is ENABLED, possible ways to detect lingering objects:

  • Scan DCs for event ID 1388 which contain information about the lingering objects (e.g. with EVENTCOMBMT)

 
MY €0.02:

  • Don’t enable LOOSE replication (because of security issues with re-introduced objects that should have been deleted) as this really does not solve the real problem. It only extends it!
  • Be carefull using a mixture of loose replication and strict replic
    ation as that may lead to inconsistencies and/or security issues
  • Enable STRICT replication (=default on W2KSP4 and W2K3)
  • Detect and cleanup lingering objects if applicable
  • Make sure you MONITOR end-to-end AD and SYSVOL replication between DCs!!!
    • Should be a MUST on your priority list!!!
  • Make sure you MONITOR DC/BH/GC/FSMO availability and detect disconnected DCs ASAP!!!
    • Should be a MUST on your priority list!!!
  • Monitoring is a preventive measure that helps you NOT getting the headaches you may have now concerning lingering objects!

To make things a bit easier for those that experience lingering objects on W2K3 DCs:

I have created some scripts (see the zip file at the end of the post where it says ‘attachments’) that automate this a bit more. Use them as you wish and at your own risk!!! Get there scripts from HERE.

The logic works as follows:

  • For EACH domain in the forest specify in ‘DC-LIST-FQDN-HEALTHY.TXT’ ONE DC that is considered HEALTHY
  • Specify in ‘DC-LIST-FQDN-UNHEALTHY.TXT’ ALL DCs/GCs that are considered UNHEALTHY and may contain lingering objects
  • Execute ‘GET-GUID-NCs-FROM-FQDN.CMD’ to generate:
    • ‘DC-LIST-GUID-FQDN-HEALTHY.TXT’
      • –> contains the GUID and FQDN of the HEALTHY DCs
    • ‘<FQDN UNHEALTHY DC>-NCs.TXT’
      • –> For each unhealthy DC contains ALL writable and read-only NCs (partitions)
  • Execute ‘CLEAN-LINGERING-OBJECTS-ON-UNHEALTHY-DCs.CMD’
    • In detect mode (first argument = DETECT) (argument = case sensitive)
    • In clean mode (first argument = CLEAN) (argument = case sensitive)
    • ‘CLEAN-LINGERING-OBJECTS-ON-UNHEALTHY-DCs_DETECT.TXT’
      • –> contains ALL detected lingering objects
    • ‘CLEAN-LINGERING-OBJECTS-ON-UNHEALTHY-DCs_CLEAN.TXT’
      • –> contains ALL detected AND cleaned lingering objects

Were these scripts useful? Just say: Thanks!

Let me know what you think by leaving comments behind

Enjoy!

### DISCLAIMER ###

  • These scripts are freeware. Use it as you wish at your own risk.
  • I do not warrant these scripts to be fit for any purpose or use
  • I do not guarantee that it will not damage or destroy your system
  • Make sure you test these scripts FIRST in a test environment!
  • If you don’t know how to use the scripts DON’T USE them!

 

More and additional information about lingering objects can be found in the following Microsoft articles:

The following has been copied from the URL below, for those who are interested to know how the “/removelingeringobjects” works.

http://technet2.microsoft.com/WindowsServer/en/Library/1465d773-b763-45ec-b971-c23cdc27400e1033.mspx

 

RemoveLingeringObjects Implementation

When you run repadmin /removelingeringobjects, the tool performs the following steps to compare the directories of the source and destination domain controllers and log (or remove) any found lingering objects:

  1. Check to ensure that the directory partition and the source domain controller are valid.
  2. Verify that the user has the DS-Replication-Manage-Topology extended right on the directory partition container object specified in <NC>. This extended right is required to verify object state between two domain controllers. Members of the Domain Admins group have this right by default.
  3. Ensure that both source and destination use the same objects for comparison by merging the up-to-dateness vectors to filter out any objects that have not replicated from the source to the destination or from the destination to the source. This check rules out a lingering object on the destination if the destination has not received the tombstone from the source, and vice versa. Any such nonreplicated objects are removed from the comparison.
  4. Create the list of object GUIDs for each domain controller to be compared. Examine the metadata of each object and use the merged up-to-dateness vector to determine whether the object should be present on both source and destination.
  5. For each GUID that is in the list for the destination, determine if it is in the list of GUIDs for the source.
  6. If a GUID is not found on the source, the object is identified to be outdated on the destination and is either displayed or deleted on the destination server. If advisory mode has been specified, the GUID is displayed only.

Loopback processing in GPO

What is loopback processing? 

Group Policy loopback is a computer configuration setting that enables different Group Policy user settings to apply based upon the computer from which logon occurs. 

Breaking this down a little more:

  1. It is a computer configuration setting. (Remember this for later)
  2. When enabled, user settings from GPOs applied to the computer apply to the logged on user.
  3. Loopback processing changes the list of applicable GPOs and the order in which they apply to a user. 

 Why would I use loopback processing?

Administrators use loopback processing in kiosk, lab, and Terminal Server environments to provide a consistent user experience across all computers regardless of the GPOs linked to user’s OU. 

Our recommendation for loopback is similar to our recommendations for WMI filters, Block Inheritance and policy Enforcement; use them sparingly.  All of these configuration options modify the default processing of policy and thus make your environment more complex to troubleshoot and maintain, whenever possible, keep your designs as simple as possible.

 How to configure loopback processing

The loopback setting is located under Computer Configuration/Administrative Templates/System/Group Policy in the Group Policy Management Editor (GPME). 

 Use the policy setting Configure user Group Policy loopback processing mode to configure loopback in Windows 8 and Windows Server 2012Earlier versions of Windows have the same policy setting under the name User Group Policy loopback processing mode. 

loop1

 When you enable loopback processing, you also have to select the desired mode.  There are two modes for loopback processing:  Merge or Replace.

loop2

 Loopback Merge vs. Replace

Prior to the start of user policy processing, the Group Policy engine checks to see if loopback is enabled and, if so, in which mode.

Loopback Merge

During loopback processing in merge mode, user GPOs process first (exactly as they do during normal policy processing), but with an additional step.  Following normal user policy processing the Group Policy engine applies user settings from GPOs linked to the computer’s OU.  The result– the user receives all user settings from GPOs applied to the user and all user settings from GPOs applied to the computer. The user settings from the computer’s GPOs win any conflicts since they apply last.

 To illustrate loopback merge processing and conflict resolution, let’s use a simple chart.  The chart shows us the “winning” configuration in each of three scenarios:

  1. The same user policy setting is configured in GPOs linked to the user and the computer
  2. The user policy setting is only configured in a GPO linked to the user’s OU
  3. The user policy setting is only configured in a GPO linked to the computer’s OU

loop3

 Now, going back to our original example, loopback processing in Merge mode applies user settings from GPOs linked to the user’s OU followed by user settings from GPOs linked to the computer’s OU.

loop4

 GPOs for the user in OU ”E” apply in the following order (the first part is identical to normal user policy processing from our original example):

Local Group Policy

  1. Group Policy objects linked to the Site
  2. Group Policy objects linked to the Domain
  3. Group Policy objects linked to OU “A”
  4. Group Policy objects linked to OU “B”
  5. Group Policy objects linked to OU “E”
  6. Group Policy objects linked to the Site
  7. Group Policy objects linked to the Domain
  8. Group Policy objects linked to OU “A”
  9. Group Policy objects linked to OU “C”
  10. Group Policy objects linked to OU “G”

 Loopback Replace

 Loopback replace is much easier. During loopback processing in replace mode, the user settings applied to the computer “replace” those applied to the user.  In actuality, the Group Policy service skips the GPOs linked to the user’s OU. Group Policy effectively processes as if user object was in the OU of the computer rather than its current OU. 

 The chart for loopback processing in replace mode shows that settings “1” and “2” do not apply since all user settings linked to the user’s OU are skipped when loopback is configured in replace mode.

loop5

 Returning to our example of the user in the “E” OU, loopback processing in replace mode skips normal user policy processing and only applies user settings from GPOs linked to the computer.

loop4

 The resulting processing order is: 

  1. Local Group Policy
  2. Group Policy objects linked to the Site
  3. Group Policy objects linked to the Domain
  4. Group Policy objects linked to OU “A”
  5. Group Policy objects linked to OU “C”
  6. Group Policy objects linked to OU “G”

 Recap

  1. User Group Policy loopback processing is a computer configuration setting.
    • Loopback processing is not specific to the GPO in which it is configured. If we think back to what an Administrative Template policy is, we know it is just configuring a registry value.  In the case of the loopback policy processing setting, once this registry setting is configured, the order and scope of user group policy processing for all users logging on to the computer is modified per the mode chosen: Merge or Replace.
  2. Merge mode applies GPOs linked to the user object first, followed by GPOs with user settings linked to the computer object. 
    • The order of processing determines the precedence. GPOs with users settings linked to the computer object apply last and therefore have a higher precedence than those linked to the user object.
    • Use merge mode in scenarios where you need users to receive the settings they normally receive, but you want to customize or make changes to those settings when they logon to specific computers.
  3. Replace mode completely skips Group Policy objects linked in the path of the user and only applies user settings in GPOs linked in the path of the computer.  Use replace mode when you need to disregard all GPOs that are linked in the path of the user object.

Those are the basics of user group policy loopback processing. For more updates and troubleshooting series , please refer  http://cbfive.com/blog/post/Loopback-Policy-Processing-Debug-Series-Replace-Mode.aspx

Strict Replication Consistency is a registry value that prevents destination domain controllers (DC) from replicating in lingering objects. Lingering objects are objects that have been deleted on one DC but replication failures prevent a partner DC learning of the deletion. The result is those deleted objects remain “live” on the replication partners. If the replication failure persists for longer than tombstone lifetime but is later corrected, the DC that failed to inbound replicate the deletions will continue to have “live”/lingering objects in its copy of the AD database. When one or more attributes are modified on these “live” objects, that object must replicate outbound. DCs that don’t have Strict Replication Consistency enforced will replicate in these formerly deleted objects, re-animating them.

Note: for the sake of readability, when I say “Windows Server 2003” in the document, I mean Windows Server 2003 or later. Windows Server 2008 and Windows Server 2008 R2 behave the same in this respect.

A Windows Server 2003 server can automatically configure Strict Replication Consistency during the domain controller promotion process certain conditions have to be true. There are some myths and badly worded documents out there that imply Windows Server 2003 DC’s always configure themselves for strict replication , so this blog post aims to set the record straight.

Forests originally created on Windows 2000 Server – but later upgraded to Windows Server 2003 require an additional step to automatically enable strict replication consistency on newly promoted domain controllers. While Windows Server 2003 DCs tend to quarantine themselves if they have not replicated for greater than Tombstone Lifetime, failure to implement this step will leave all newly promoted Windows Server 2003 DCs configured for Loose Replication Consistency; leaving them at risk of re-animating lingering objects from Windows 2000 replica DCs or Windows Server 2003 DCs that have had Allow Replication With Divergent and Corrupt Partner set but have not been cleaned of lingering objects first.

If to the you want new domain controllers added forest to have strict replication consistency automatically enabled, you can import the Operational GUID cited below to the Configuration directory partition using Ldifde.exe. The presence of this object in the Configuration partition causes dcpromo.exe to enable Strict Replication Consistency on any Windows Server 2003 domain controller that is promoted into the forest.

1. Start notepad.exe and copy in the sample LDF text below. Edit both lines containing DC=<domain>,DC=<com> to match your forest root domain.

Example: If your forest root domain were contoso.com the DN would be DC=contoso,DC=com

dn: CN=94fdebc6-8eeb-4640-80de-ec52b9ca17fa,CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<domain>,DC=<com>
changetype: add
objectClass: container
showInAdvancedViewOnly: TRUE
name: 94fdebc6-8eeb-4640-80de-ec52b9ca17fa
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=<domain>,DC=<com>

2. Once the DN has been modified correctly save the file as StrictRepl.ldf.

3. Open a command prompt with Enterprise Administrator credentials and issue this command:

      Ldifde.exe -i -f StrictRepl.ldf

It’s important to note that just adding this object to the CN=Operations container will not cause existing Windows Server 2003 DCs to configure themselves for Strict Replication Consistency. For existing DCs you must add the Strict Replication Consistency registry value and set it to 1 before they will enforce strict replication. The good news is this can be done remotely using repadmin.exe from a command prompt opened with Enterprise Admin credentials. The command to run is:

repadmin.exe /regkey <dcname> +strict

If you want to make certain this is configured on all DCs in the forest you can pass a wildcard to repadmin.exe like this,:

repadmin.exe /regkey * +strict

If you are running this against all DCs in the forest you should pipe this out to a text file and verify all DCs have been contacted and the value has been set correctly.

Warning: Before you implement this change forest-wide it is important to understand that all replication between the source DC and the destination DC will stop for any partition that has a lingering object in it. Replication will only be restored once the lingering object is removed. This could cause forest-wide authentication issues until replication is restored.

For more information about this operational GUID see Technet.

Hopefully this will clear up the common misconception that all Windows Server 2003 domain controllers will always enforce strict replication consistency and will lead to closer examination of current configurations before lingering objects start causing issues.

The process of location is to use DNS to identify a set of candidate domain controllers from a list, based on SRV records.

 When you login what happens in the background is à

1.)    Check for the primary /secondary DNS in your workstation

2.)    Hit the DNS to have the corresponding Srv records of Domain controller(It will happened depends on the subnet/site where you resides on)

3.)    Dns will provide the list of SRV records of the Domain controllers, with that list workstation will try to reach any of the alive domain controller.

DC locator process

The client is initialized with DomainName. FQDN being set to the Domain Name System (DNS) name of the domain to locate, for example server1.test.com

The general process is shown in the following diagram:

The first step is to perform the DNS discovery.
The client issues a DNS request for _ldap._tcp.dc._msdcs.server1.test.com
The DNS server returns a list of SRV records that match this request. If no records are available, then the domain location fails.
If target hosts have the same priority, the client select a return SRV record according to weighted pseudorandom order.

The client then resolves the SRV record to an address, again as specified in the DNS protocols.

Once the address is known, the client sends an LDAP “Ping,” as a way of detecting that the domain. controller is in fact handling requests and determining the characteristics of this domain controller The LDAP “Ping” also known as connectionless LDAP is sent over UDP

After each packet is sent, the client waits for a response, and if no response is received, it sends a packet to the next domain controller. The client continues this process until it receives a valid response that specifies the requested services or has tried all of the domain controllers.

When a client tries to locate a domain controller after it has received the IP address from DNS, it varies the time it waits for a response based on the number of domain controllers it has already pinged. For the first five domain controllers, it waits for 0.4 seconds, and for next five domain controllers, it waits for 0.2 seconds. After 10 domain controllers have been pinged, the client uses a 0.1 second wait for the remaining requests.

The LDAP “Ping” is an LDAP rootDSE search to the domain controller, looking for an attribute called “NetLogon.”

The domain controller server inspects the query and returns the NetLogon result.
The response is typically returned in a NETLOGON_SAM_LOGON_RESPONSE_EX.

Upon receipt of the LDAP SearchResultEntry, the client validates the capabilities returned by the domain controller.

If the capabilities returned by the domain controller are incompatible with the requirements specified by the invoker of the locator algorithm on entry, the client must select another candidate domain controller from the list of domain controller SRV records returned above.

Incompatibility in this case can arise because the client requested a Kerberos KDC, but the domain controller did not indicate that a KDC was present, or the client requested a domain controller that could accept writes, but this domain controller is read-only.

These sorts of negative results are cached by the client. However, they are purged promptly (on the order of minutes).

Because the LDAP “Ping” returns a snapshot of the current state of the domain controller at the moment of the query, services such as a time server, may not be running at the moment, but may be available once the server has completely started.

If all the responses in the SRV records have been checked, and each SRV record points to a server that is either not available or does not match the requirements, then the location operation has failed.

Upon successful response from the domain controller, the location portion completes.

===================================================================================

For additional information,

DC Locator Process in W2K, W2K3(R2) and W2K8

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>

 snap

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_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters
  • 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 ConfigurationAdministrative TemplatesSystemNet LogonDC 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 ConfigurationAdministrative TemplatesSystemNet LogonDC 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_MACHINESystemCurrentControlSetServicesDfsParameters
  • 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_MACHINESYSTEMCurrentControlSetServicesDfsDriver
  • Registry value name: DfsEnableSmartClient
  • Registry value type: REG_DWORD
  • Registry value data: 1

For W2K3(R2) DCs and later:

  • Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDfsParameters
  • 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_MACHINESYSTEMCurrentControlSetServicesDfsParameters
  • Registry value name: SysvolNetlogonTargetFailback
  • Registry value type: REG_DWORD
  • Registry value data: 1

1.We already have a Windows 2003 DC and we promote another Windows 2008 DC. In this situation, Sysvol will use FRS to replicate the data and not DFSR

2. We are installing a Windows 2008 DC in a new domain/forest. This is the first DC of this forest. But while running dcpromo you select 2003 domain functional level instead of 2008. Even though the DC is running on Windows 2008, since the domain functional level is 2003, SYSVOL will still use FRS to replicate the content instead of DFSR

In the scenario 2, we can although later on change the way SYSVOL will replicate the content. This is where we do Migration of the replicating engine from FRS to DFSR

 3. We are installing a Windows 2008 DC in a new domain/forest. This is the first DC of this forest. But while running dcpromo you select 2008 domain functional level.

In this scenario 3, SYSVOL will use DFSR to replicate the content

 

In the environment where the sites are located in different geographical locations, most of the administrators have confused with time services and how it’s works.

 Let me explain how the Time and Time sync works.

Active directory uses the Kerberos for authenticating users and computers in a domain
I am not going to explain the Kerberos authentication process, just how the Kerberos uses the time for authentication.

When the server receives request for authentication (the ticket), it check for client’s clock time. The server then checks the client’s time to make sure that it falls within the server’s time and the allowable skew and client time should be unique not the same as or earlier than the time of another authenticator

If the client’s time falls within the allowable skew and its timestamp is unique, the server then slightly modifies the contents of the original authenticator and re-encrypts it with the client’s secret key, establishing mutual authentication. The server then acknowledges the client by sending the modified authenticator with the client’s original timestamp back to the client for identification. Client’s clock time should sync with the server (Domain controllers) clock time in order to get successful authentication

Time synchronization in an Active Directory
In Active Directory environment PDC emulator is acting as a time server, PDC emulator is located in the forest root domain and is connected to an external time source. The external time source holds the position of greatest accuracy, or stratum one. The PDC emulator is at stratum two. The forest root domain can also be called the parent domain, and each domain under the parent or forest root can be called a child domain. Any domain controller that accesses time directly from the PDC emulator of the forest root domain is designated as stratum.

 

Understanding the time zone configuration in windows

Difference between time
Before describing the time zone configuration you should know what is time zone and how and why it’s used, relation between time and time zone, and difference between time

Due to time difference between the countries, like time in UK is not the same in US, to differentiate the time between the different parts of the world we use the time zone, I call it difference between time

Computers and servers store time in Coordinated Universal Time (UTC), when viewed through any application (or) viewing system time it’s displayed according to the local time zone of the computer, UTC is equal to GMT

Current system time (UTC) + Time zone (UTC +5.30) = Display time

5 + 5.30 = 10.30

So on the whole,  all the systems are uses UTC time, while displaying the system time it will be converted according to the time zone configuration.

The W32Time service starts automatically on computers that are joined to a domain. For computers that are not joined to a domain, you can start the time service manually. On computers that are joined to a domain, time synchronization takes place when the W32Time service turns on during system startup. The Net Logon service looks for a domain controller that can authenticate and synchronize time with the client. When a domain controller is found, the client sends a request for time and waits for a reply from the domain controller. This communication is an exchange of SNTP packets intended to calculate the time offset and roundtrip delay between the two computers.

Time passed to any client in the domain is unadjusted UTC time, which is adjusted to local time based on the time zone configuration of the workstation. Adjusting the time on the domain controllers will not change the time for the workstations. They have to be updated with the new time zone information as well.

Time zone information will not sync to client from Domain controller, we have to do the time zone change manually, for bulk change we can users the Microsoft hot fix

W32Time uses coordinated universal time (UTC), which is based on an atomic time scale and is the correct term to use when talking about time and time synchronization. UTC is the name for time that is independent of time zone. Time zone information is stored in the computer’s registry and is added to the system time just before it is displayed to the user.

How to change time zone configuration in windows

In Control Panel -> Date/Time -> Time Zone

The process to change the DST is as follows:

Or Use the utility TZEDIT.EXE

Start->Run->TZEDIT.EXE

Then select your time and time zone.

We got issue that user could not access their shares in Domain controller.

When we check we found that all services are running (domain service, server,dfs)

 Tried to ping the server ip for the server itself , got the below error

c:\>ping xx.xx.xx.xx

Unable to contact IP driver. General failure.

 Tried to ping the loop back ip

c:\>ping 127.0.0.1

Unable to contact IP driver. General failure.

 To solve the about issue we had done the below.

As we can’t even ping the loopback address, it seems that the TCP/IP stack may be corrupted.

Logged into the server via admin account , turned off the UAC then taking the following steps to reinstall and reset TCP/IP heap to its original state:

 1)Run the cmd as administrator (operation requires elevation (Run as administrator).

2)Type  netsh int ip reset in the Command Prompt shell, and then press the Enter key.

3)Restart your computer.

 Eventually pleasedownload and update the network driver to the latest version. If you server is VM, then goahead and update you VM tools.

 Hope this might help!!!