How to identify the replication technology in use by Active Directory FRS Or DFSR

Since Windows Server 2003 the SYSVOL replication which includes Group Policies, Scripts, and so forth has been done through FRS (File Replication Services), however starting on Windows Server 2008 the focus shifted to use DFS (Distributed File Service).

If your current domain was created before Windows Server 2008, then you environment probably is using FRS, however if your current domain was created on Windows Server 2008 or later then it most likely that you are using DFS.

In the upcoming Windows Server 2016 the FRS is being deprecated, which makes a good time to move from FRS to DFS. We are going to cover this process in a future article, for now we are going to use this Tutorial to check it out which technology is being used to replicate SYSVOL on your network.


By default, the SYSVOL data can be found on the C:\Windows\SYSVOL folder. An easy way to check is to use ADSIEdit.msc, expand Default naming context, expand the domain, and then click expand CN=System, and then get properties of CN=DFSR-GlobalSettings.

1In the new window, look for the msDFSR-Flags attribute, and if the value is 48 then the DFS is being in use. If the value is one of these (null/empty, 0, 16 or 32), then you are in a transition or FRS mode.





What is the use of lastLogontimeStamp attributes?


It is important to note that the intended purpose of the lastLogontimeStamp attribute to help identify inactive computer and user accounts. The lastLogon attribute is not designed to provide real time logon information. With default settings in place the lastLogontimeStamp will be 9-14 days behind the current date.

The lastLogontimeStamp attribute is not updated with all logon types or at every logon. The good news is that the logon types that admins usually care about will update the attribute and often enough to accomplish its task of identifying inactive accounts.

Interactive, Network, and Service logons will update the lastLogontimeStamp. So if a user logs on interactively, browses a network share, access the email server, runs an LDAP query etc… the lastLogontimeStamp attribute will updated if the right condition is met.

Update and Replication of lastLogontimeStamp

First become acquainted with the ms-DS-Logon-Time-Sync-Interval attribute. It is an attribute of the domain NC and controls the granularity (in days) with which the lastLogontimeStamp attribute is updated. The default value is 14 and is set in code. Meaning that if you look at this attribute in ADSIEDIT.MSC and you see it as “Not Set” don’t be alarmed. This just means the system is using the default value of 14.

The lastLogontimeStamp attribute is not updated every time a user or computer logs on to the domain. The decision to update the value is based on the current date minus the value of the (ms-DS-Logon-Time-Sync-Interval attribute minus a random percentage of 5). If the result is equal to or greater than lastLogontimeStamp the attribute is updated. There are no special considerations for replication of lastLogontimeStamp. If the attribute is updated it is replicated like any other attribute update. This is not urgent replication

Walkthrough of a lastLogontimeStampUpdate update

  1. (Assuming the value of the ms-DS-Logon-Time-Sync-Intervalis at the default of 14)
  2. User logs on to the domain
  3. The lastLogontimeStampattribute value of the user is retrieved
  4. 14 – (Random percentage of 5) = X
  5. Current date – value of lastLogontimeStamp= Y
  6. X ≤ Y – update lastLognTimeStamp
  7. X > Y – do not update lastLogontimeStamp

Why the Randomization?

This randomization is done to prevent an update of the lastLogontimeStamp attribute from many accounts at the same time causing a high replication load on the DC’s. Remember the purpose of the lastLogontimeStamp attribute is locate inactive accounts not provide real-time logon information.

Controlling the update frequency of lastLogontimeStamp.

It is possible to change the frequency of updates to the lastLogonTime stamp or turn it off completely if desired. If you need a different time interval you will need to adjust the value of the msDS-LogonTimeSyncInterval attribute to a value between 5-100,000. Yes that’s right: the max value is 100,000 days… Or if you prefer ~280 years… And the max value was set in code not in the schema. (I guess the dev was counting on medical science to solve that pesky aging problem.)

In my experience the default settings can accommodate almost anyone and there is no need to change the update interval. Most customers I have talked to start considering accounts potentially inactive at the 30 day or higher mark of inactivity.

Note: If the msDS-LogonTimeSyncInterval is less than 5 days, the randomization is not put into effect.

Clearing up the confusion – Verifying that LastLogontimeStamp is in sync across all DCs in the domain.

Many times customers will be concerned about what their tools are displaying to them (usually a very old date) as the lastLogontimeStamp of a user compared to what they know to be a more accurate date. This is almost always due to the admin using a tool that queries the lastLogonattribute instead of the lastLogontimeStamp attribute.

For example acctinfo.dll that is included with the Account Lockout tools will display the lastLogon attribute data not the lastLogontimeStampdata. In some cases the date the tool reports may be months or years out of date or display nothing at all. This is because they are querying the lastLogon attribute and the user they are looking up has either never been authenticated by the reference DC (in the case of null) or has not been authenticated by the reference DC in a very long time.

How to tell if lastLogontimeStamp is in sync

To verify if the lastLogonTime stamp is being updated and replicated as expected you can use repadmin.exe with the showattr switch. Some examples are given below. These examples are intended to demonstrate that lastLogontimeStamp is being updated within the window of 9-14 days and replicated to all DC’s in the domain. They are not an example of how to manage stale accounts.

  1. Using repadmin to check the value of lastLogontimeStampon all DC’s in a domain for one user:

repadmin /showattr * (DN of the target user) /attrs:lastLogontimeStamp >lastLogontimeStamp.txt


repadmin /showattr * CN=user1,OU=accounting,DC=domain,dc=com /attrs:lastLogontimeStamp >lastLogontimeStamp.txt

  1. Using repadmin to dump the lastLogontimeStampfor all users in a domain including users that have no data in the lastLogontimeStampattribute:

repadmin /showattr * /subtree /filter:”(&(objectCategory=Person)(objectClass=user))” /attrs:lastLogontimeStamp >lastLogontimeStamp.txt

  1. Dump lastLogonTime stamp for users but only ones that have the attribute populated

repadmin /showattr * dc=domain,dc=com /subtree /filter:”((&(lastLogontimeStamp=*)(objectCategory=Person)(objectClass=user)))” /attrs:lastLogontimeStamp >lastLogontimeStamp-2-22-2009.txt

Reference Copied from : –

Hide disable user, service account, and generic account from outlook organization chart direct reports.

There may be an requirement in organization to set each account manager attributes, so that it can be tracked who is the owner of each accounts (service accounts, generic accounts & which user reports to whom). But for user’s reports to manager looks good in outlook organization chart.


  1. Problem is service accounts & generic accounts as they will be also listed in outlook organization chart, so we still want to keep them manager assigned but should not be visible in outlook organization chart.
  2. The issue is that newly disabled people are not removed from the org chart. For instance we mark an employee as disabled, remove their licensing and ensure access is blocked. Even with this done, a departed employee will display on the org chart. How Microsoft support suggested to fix it – by clearing the ManagerID, but due to organization policies we cannot remove manager id. Delete the user from AD – We cannot also immediately delete that disabled users from AD.

We would like the org chart to have the ability to recognize disabled users and or hidden users should not be displayed on the org chart. This would allow our org chart to be correct all of the time.


  1. Service accounts / generic accounts without mail enabled: – By default below attribute is not configured & if it is not configured means it is False & show up is address book, so we have to make it true.12
  2. Service accounts / generic accounts with mail enabled ( very rare case) : We have to see if these service account needs to be hide or not & if not then we can leave them as it & should be only execute in case basis.
  3. Disabled users account: when the account is getting disabled additionally configure this attributes with “True”, so that it will not show up in address book. You can also schedule a script to updated only disabled user attribute “msExchHideFromAddressLists” to True. But if in future if any of the disable user getting enable then we have to define the process that msExchHideFromAddressLists configure with <Not set>.


Active Directory Domain Discovery Checklist

During an AD DS migration or health checks, system engineers and auditors always need a checklist to keep up with what should be discovered.  This checklist is a working checklist, one that has been created here for peer review and peer additions.  This checklist should try and take into account all the high level items one needs to look for during an AD DS discovery/audit.

This checklist is not meant to be a step-by-step guide but a high level overview to keep track of what needs to be discovered.

SR.NO Category Sub-Catagories Status
1 Domain(s) discovery – Forest Information
1.1 All trust
1.2 Stale or broken trust
1.3 Forest Functional Level
1.4 Domains/Sites/DC/GC/Exchange/Other
1.5 Forest Features
1.6 Tombstone lifetime
1.7 SID filter info
2 Sites and Services
2.1 Summary
2.2 Site names
2.3 Locations
2.4 Domains
2.5 DCs
2.6 Subnets
2.7 Site connections
2.8 Site links
2.9 Replication Interval
2.10 GPOs
2.11 Site mirroring between domains and other domains/forest
3 Domain Controllers
3.1 IP addresses
3.2 Names
3.3 Disk space report
3.4 Server up time
3.5 Physical Locations
3.6 Sites and Services
3.7 Subnets
3.8 Missing Subnets
3.9 Sites
3.10 Journal Wrap (if FRS)
3.11 Is DFS used in the environment
3.12 Schema Extensions
3.13 AD FS
3.14 Azure connections
4 Security
4.1 Security Patch report
4.2 What is the patching process
4.3 What patches are missing
4.4 Vulnerability scan
4.5 Is ATA implemented
4.6 Is LAPS implemented
4.7 Are authentication policies and authentication policy silos implemented
4.8 Have default ACLs been changed
5.1 AD integrated zones
5.2 Forest replicated zones
5.3 Domain replicated zones
5.4 Conditional forwarding
5.5 Domain level auditing
6 Infrastructure Services
6.1 Authorized DHCP server discovery
6.2 WINS server discovery
6.3 Exchange server discovery
6.4 SCCM server discovery
6.5 WSUS
6.6 Other
7 Applications in the environment
7.1 Manager per App
7.2 Owner per App
7.3 Tier or SLA (how critical is the app)
7.4 Authentication method
7.5 Local
7.6 Active Directory
7.7 Other
8 Networking
8.1 Physical site list
8.2 Subnets at each site
8.3 Site link speed and utilization level (how saturated is the link)
8.4 Network Topology
8.5 Firewall locations
8.6 VLAN restrictions
8.7 Router ACLs
9 Users
9.1 All
9.2 Detailed information
9.3 Initial count
9.4 Ongoing count for growth projections
9.5 Disabled
9.6 Count
9.7 Password no expire
9.8 Count
9.9 Token size report
9.10 Locked users
9.11 Dial-in enabled
9.12 Delegation
9.13 Password not required
9.14 Password must change
9.15 Services accounts (accounts running as a service on computers in domain)
10 Computers
10.1 Detailed report – plus the following
10.2 With OS attribute populated
10.3 Without OS attribute populated
10.4 Are cluster accounts documented
10.5 Total computer objects
10.6 Disabled
10.7 Grouped by function
10.8 Workstations
10.9 Initial count
10.10 Ongoing count for growth projections
10.11 Stale
10.12 Disabled
10.13 Servers
10.14 Initial count
10.15 Ongoing count for growth projections
10.16 Stale
10.17 Disabled
11 Contacts
11.1 Count
11.2 Logical location
12 Groups
12.1 Initial count
12.2 Ongoing count for growth projections
12.3 Empty
12.4 Similar
12.5 Nested
12.6 Global groups
12.7 Global distribution groups
12.8 Domain local security
12.9 Domain local distribution
12.10 Admin built-in groups
12.11 Enterprise Admin
12.12 Schema Admins
12.13 Domain Admins
12.14 DNS Admins
12.15 Administrators
12.16 Account Operators
12.17 Cert Publishers
12.18 Backup Operators
12.19 Print Operators
12.2 Server Operators
12.21 Membership details
12.22 Membership counts
13 Group Policy
13.1 Backup all GPOs
13.2 Not linked
13.3 Empty
13.4 Disabled
13.5 No Settings
13.6 Passwords in Group Policy
13.7 Scripts/applications in GPOs
13.8 Bat files
13.9 Exe files
13.10 VBScripts
13.11 KixScripts
13.12 PowerShell scripts
13.13 Images in GPOs
13.14 Default Domain Policy – Standard or modified?
13.15 Default Domain Controllers – Standard or modified?
13.16 Who can join computers to the domain
14 Sysvol/Netlogon (What items are stored in Sysvol/Netlogon)
14.1 Bat files
14.2 Exe files
14.3 VBScripts
14.4 KixScripts
14.5 PowerShell scripts
14.6 Images
14.7 Shortcuts



How to hide the data in Active Directory on existing attribute with confidential flag.

There may be many reasons to hide few of the information in active directory which can be only view by authorized person & not everyone able to read it. By default what all information stored in AD can be view/ready by any domain user. In some company there may be a requirement to update few information in each user attribute which should not be publicly visible , but only domain admin or delegated groups/user should be able to read/modify/update it.

Below is the best way to implement the confidential attribute without extending the schema & nor tampering the default permission in active directory.

  • Extending the Schema (which often has company-political implications)
  • Using an existing attribute and editing the permissions (which results in AD/ACL bloat that increases your DIT and subsequent replication size)

The best way is to take an existing attribute and flag it as Confidential.

The default permissions in Active Directory are such that Authenticated Users have blanket read access to all attributes. This makes it difficult to introduce a new attribute that should be protected from being read by everyone.

To mitigate this, Windows 2003 SP1 introduces a way to mark an attribute as CONFIDENTIAL. This feature achieved by modifying the searchFlags value on the attribute in the schema. SearchFlags contains multiple bits representing various properties of an attribute. E.g. bit 1 means that the attribute is indexed. The new bit 128 (7th bit) designates the attribute as confidential.

Note: you cannot set this flag on base-schema attributes (those derived from “top” such as common-name). You can determine if an object is a base schema object by using LDP to view the object and checking the systemFlags attribute of the object. If is the 10th bit is set it is a base schema object.

When the Directory Service performs a read access check, it checks for confidential attributes. If there are, then in addition to READ_PROPERTY access, the Directory Service will also require CONTROL_ACCESS access on the attribute or its property set.

By default, only Administrators have CONTROL_ACCESS access to all objects. Thus, only Administrators will be able to read confidential attributes. Users are free to delegate this right to any specific group they want. This can be done with DSACLs tool, scripting, or the R2 ADAM version of LDP. As of this writing is not possible to use ACL UI Editor to assign these permissions.

The process of marking an attribute Confidential and adding the users that need to view the attribute has 3 Steps

  1. Determining what attribute to mark Confidential, or adding an attribute to mark Confidential.
  2. Marking it confidential
  3. Granting the correct users the Control Access right so they can view the attribute.

For more details and step-by-step instructions, please refer to the following article:

922836 How to mark an attribute as confidential in Windows Server 2003 Service Pack 1;EN-US;922836

Before configure as confidential  attribute 

pic1                         After configuring it to confidential attribute


Access the user via domain admin account



Access the user via normal user account


How do we set the CONTROL_ACCESS permission for a hidden attribute? This should actually be an easy thing, but Microsoft didn’t supply any command-line tools with Windows Server 2003 SP1 that could set this access at the attribute level. However, Windows Server 2008 and later versions have an updated Dsacls version that fully supports this capability, as tested on a Windows Server 2012 DC.

The correct syntax to add the CONTROL_ACCESS permission via Dsacls is as follows:


When you assign CONTROL_ACCESS permissions at the property level to a user or group, you must specify the display name of the property—in our case, employeeNumber:

DSACLS "CN=Root-User1,OU=UserAccounts,DC=root,DC=net"
  /G root\HR-users:employeeNumber

Unfortunately, ever since the CONTROL_ACCESS permission was introduced, there hasn’t been a really useful UI to manage or view this permission. This is still true in Windows Server 2012. But since Windows Server 2003 R2, the LDP.exe editor does include a powerful security editor that allows you to view and set the CONTROL_ACCESS flag on a specific object attribute.

Navigate to the object on which you want to change the permissions. Right-click the object and choose Advanced, Security Descriptor. LDP then pops up a dialog box, which you can use to set the options for displaying the Security Descriptor. Don’t choose the Text dump, which dumps the descriptor to the output window. Using the default settings starts the new

How to let non-administrative users see the attribute data

Note the following procedures require that you use the Ldp.exe tool that is included with Windows Server 2003 R2 Active Directory Application Mode (ADAM). Other versions of the Ldp.exe tool cannot set permissions.

How to manually set Control_Access permissions on a user/group account

  1. Open the Ldp.exe tool that is included with Windows Server 2003 R2 ADAM.
  2. Connect and bind to the directory.
  3. Select a user account, right-click the account, click
    Advanced, click Security Descriptor, and then click OK.
  4. In the DACL box, click Add ACE.
  5. In the Trustee box, type the group name or the user name to which you want to grant permissions.
  6. In the Control Access box, verify the changes that you made in step 5.



How to use inheritance to assign Control_Access permissions

To use inheritance, create an access control entry that grants Control_Access permissions to the desired users or groups that are higher in the container hierarchy than the objects that have confidential attributes. You can set this access control entry at the domain level or at any point in the container hierarchy that works well for an enterprise. The child objects that have confidential attributes must have inheritance enabled.

To assign Control_Access permissions, follow these steps:

  1. Open the Ldp.exe file that is included in Windows Server 2003 R2 ADAM.
  2. Connect and bind to a directory.
  3. Select an OU or a container that is the higher in the container hierarchy than the objects that have confidential attributes, right-click the OU or the container, click Advanced, click
    Security Descriptor, and then click OK.
  4. In the DACL box, click
    Add ACE.
  5. In the Trustee box, type the group name or the user name to which you want to grant permissions.
  6. In the Control Access box, verify the changes that you made in step 5.
  7. In the Object Type box, click the confidential attribute that you added.
  8. Make sure that inheritance is enabled on the target objects.

In below screen you have to provide the delegation if only read then only select “Control access” if need modify rights then select”Write permission” alomg with Control access.

pic 5

How to determine the systemFlags attribute value when you use an existing attribute

If you use an existing object, you must verify what the current searchFlags attribute value is. If you add an object, you can define the value when you add the object. There are many ways to obtain the searchFlags attribute value. Use the method that works best for you.

To use the Ldp.exe tool to obtain the searchFlags attribute value, follow these steps:

  1. Click Start, click Run, type LDP, and then click OK.
  2. Click Connection, and then click
  3. Bind as the Administrator of the root domain, or bind as an account that is an Enterprise Administrator.
  4. Click View, and then click
  5. Click
    CN=schema,cn=configuration,dc=rootdomain, and then click OK.
  6. In the left pane, expand
  7. Locate the domain name of the attribute that you want to mark as confidential, and then expand it.
  8. In the list of attributes that are populated for the object, find searchFlags to determine the current searchFlags attribute value for that object.

Note To determine the new searchFlags attribute value, use the following formula:

128 + current searchFlags attribute value =
new searchFlags attribute value

How to determine whether an attribute is a base schema attribute

To determine whether an attribute is a base schema attribute, use the Ldp.exe tool to examine the systemFlags attribute value.

LDP output of Employee-ID – systemFlags: 0x10 = (FLAG_SCHEMA_BASE_OBJECT) 


                                                                                                   Read More »

Find CNF objects in Active Directory

When two or more objects with the same name are created in the same container on different domain controllers before replication occurs the conflict is resolved by renaming the object with the older timestamp.  The object will be renamed so that it includes “\0ACNF:[GUID]” in its DN.  These objects are referred to as conflict or CNF objects.  A domain controller will generate Event ID 12292 whenever a CNF object is created.

To find CNF objects and open the created file, run the following commands:

dsquery * forestroot -gc -attr distinguishedName -scope subtree -filter “(|(cn=*\0ACNF:*)(ou=*OACNF:*))”  >   cnfobjects.txt

start cnfobjects.txt

It is safe to delete CNF objects, but it’s always recommended to validate it.

Cleanup of content of ConflictAndDeleted folder under SYSVOL on domain controller.

DFSR uses a set of conflict-handling algorithms during initial sync and ongoing replication to ensure that the appropriate files replicate between servers.

  • During non-authoritative initial sync, cloning, or ongoing replication: files with the same name and path modified on multiple servers move to the following folder on the losing server:<rf>\Dfsrprivate\ConflictAndDeleted
  • Initial sync or cloning: files with the same name and path that exist only on the downstream server go to<rf>\Dfsrprivate\PreExisting
  • During ongoing replication: files deleted on a server move to the following folder on all other servers:<rf>\Dfsrprivate\ConflictAndDeleted

The ConflictAndDeleted folder has a 4GB first in/first out quota in Windows Server 2012 R2 (660MB in older operating systems). The PreExisting folder has no quota. When content moves to these folders, DFSR tracks it in theConflictAndDeletedManifest.xml and PreExistingManifest.xml. DFSR deliberately mangles all files and folders in the ConflictAndDeleted folder with version vector information to preserve uniqueness. DFSR deliberately mangles the top-level files and folders in the PreExisting folder with version vector information to preserve uniqueness.

One should perform the routine maintenance to do the cleanup of contents under \Dfsrprivate\ConflictAndDeleted which will free up the disk space where the SYSVOL is resides.

Note: Don’t delete the main folder & only delete the content inside the folder.

Replacing an Active Directory Forest NTP server

There should only be one time source in your forest and by default it would be on the first Domain Controller you bring up.  At some point you will need to replace that server with newer hardware.  Just make sure you remember to add the authoritative time source to the new server or another Domain Controller in your forest.  A best practice is to keep the NTP server on a PDC emulator (or if you have a multi domain forest the root domain on the PDC emulator) .

The following MS article (kb816042) explains the proces ->

To check which server is PDC role holder run netdom query fsmo.

Make sure that below parameters are set correctly on PDC Server.

  1. Change the server type to NTP
    HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type (default is NT5DS) should be changed to NTP
  2. Specify the time,0x1
    HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer (default is,0x1) should be set to a time source you trust the default should be fine.
  3. Set AnnounceFlags to 5
    HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags (default is 10) should be changed to 5
  4. Enable NTPServer
    HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer\Enabled (default is 0) should be changed to 1
  5. Restart the windows time service.
    net stop w32time && net start w32time
  6. Run w32tm /resync /rediscover command, which should complete successfully.

Once again please remember there should only be one server in the forest which is marked as a reliable time source.  Please make sure only one Domain Controller has there w32time type set to NTP.

Server 2012 – Add Additional Domain Controller to a 2008 R2 Domain

When you try and run DCPromo from the explorer shell on Windows Server 2012, you will receive the following message “The Active Directory Domain Services Installation Wizard is relocated in Server Manager. For more information, see”


No DCPromo, what now?! DCPromo is deprecated in Windows Server 2012, so adding an additional Domain Controller is slightly different than in earlier versions. The new process is still straight forward, and the wizard will even extend the schema (to version 56) for you- meaning it’s a one-stop process. Adding a Windows Server 2012 Domain Controller requires a Windows Server 2003 forest functional level or higher on your existing forest.

Promoting a Server 2012 to a Domain Controller

1. Open Server Manager, select Local Server on the left hand side then choose Manager -> Add roles and Features.


2. Next.


3. Next.


4. Select the server you wish to promote.


5. Tick Active Directory Domain Services.


6. Click Add Features.


7. Next.


8. Next.


9. Install.


10. In Progress.


11. Close.


12. You’ll now notice you have a notification, prompting you to promote this server to a domain controller.


13. We are adding a domain controller to an existing domain, specify the domain and domain administrator credentials.


14. It will make the additional DC a DNS and GC by default, we do not want to make this a Read Only Domain Controller. You have the option to add the DC to a particular Site. Enter your DSRM password (as usual, keep this safe!).


15. You can typically ignore the warning about DNS delegation, a more detailed explanation can be found here:


16. You can install from Media, which is useful if you are promoting a DC in a branch office with a poor connection- it will significantly reduce the initial Active Directory replication. You can specify a particular DC for the initial replication.


17. Default locations.


18. This screen tells us it will prepare the Forest, Schema and domain for us (Server 2012 uses Schema Version 56).


19. Review screen and option to view the Powershell script.


20. Click Install.


21. The install will tick over and when it has finished the server will be restarted.



The server will now reboot and the promotion is complete.

Windows Server 2008 ADMT 3.1 PES Password Issue

When installing the Password Export Server on a Server 2008 Domain Controller in the destination forest, the following error was encountered entering the password for the .pes file security key that was generated in the source forest:

The supplied password does not match this encryption key’s password. ADMT’s Password Migration Filter DLL will not install without a valid encryption key.

The error that was being generated “the password does not match this encryption key” is bogus, as the password did match. This error was actually being generated by a permission problem to the SAM database caused by UAC (user account control).

To get around this run a command prompt as administrator and launch pwdmig.msi from there. Ensure the command prompt is running as administrator!