Here’s a nice feature of the Active Directory Administrative Centre – the PowerShell History Viewer. Simply undertake your daily tasks as usual and the PowerShell History Viewer will capture what you do and allow you to see the commands it used to perform those tasks. You’ve then taken the first steps needed to automate your most common tasks as you will:
Know which tasks you carry out most regularly and
Know the PowerShell commands to perform those tasks.
To expose the PowerShell History Viewer in the Active Directory Administrative Centre, click on the up arrow at the bottom right of the Admin Centre.
You can now perform your usual tasks and the PowerShell for those tasks will be captured there.
The PowerShell used is displayed below – checking the “Show All” box will show all PowerShell commands issued to run the Admin Centre, not just those related to you entering instructions.
For the “full” command, right click it and select “Copy”
You can then paste it into your favourite editor such as the PowerShell Integrated Scripting Engine (ISE). If you would prefer to just read the string in the GUI then clicking the + sign to the left of the command renders it readable.
Shutting down the Admin Centre will clear the history so do take a note of any commands you need first.
I’ve been hunting around the web for a powershell script that will list the members of multiple groups and haven’t been able to write one so I’ve written my own.
This script isn’t intended to be perfect but it will give you the bare bones of how to write your script. For example, this script work on the basis of entering all or part of a group name and then reporting on that group. If you enter a blank or * from the group name then it will export user membership in all groups as direct members (add a recursive switch if you need membership of nested groups). This is useful if you have a group naming convention as you can easily drill down into the groups you want.
It also doesn’t filter out computer accounts so it depends if that’s an issue for you and it reports against the whole AD but you can always filter the Get-ADGroup command to scope it to an individual OU or area of AD.
In any event, like I said I wasn’t able to find anything around to do this so hopefully, if you need to do this, this script will give you a good head start on exporting these values from your directory.
Here’s the script – if copying and pasting into notepad remember to correct some characters such as ‘ and “.
Import-Module ActiveDirectory
Write-Host “********************************************************”
Write-Host “* This script will dump out users in named groups, all *”
Write-host “* groups or a range of groups. You will be guided *”
Write-host “* through the process *”
Write-Host “* *”
Write-Host “* All output will be saved to C:SupportScriptOutput *”
Write-Host “********************************************************”
write-host
$strFileName = $(
$selection = read-host ‘Enter the name of file to save results to. Include an extention. (Default = Groupmembership.csv)’
if ($selection) {$selection} else {‘GroupMembership.csv’}
)
Write-Host
Write-Host ‘Enter name of group you would like to export’
Write-Host ‘The script will look for matching groups’
Write-Host
Write-Host ‘Entering the first part of the group name will return all matching groups’
Write-Host ‘For example, Entering “LG-APP-” without the quotation marks will return all application groups’
Write-Host
Write-Host ‘Pressing return will list membership of ALL groups’
Write-host
Write-Host ‘***** WARNING *****’
Write-Host
Write-Host ‘Exporting all group memberships will take some time as it will’
Write-Host ‘include all built in groups and distribution lists – use with caution’
Write-Host
$strGroupNames = $(
$selection = Read-Host ‘Enter name of group you would like to export (no value will return all groups)’
if ($selection) {$selection + ‘*’} else {‘*’}
)
Write-Host
Write-Host ‘Exporting teams with names like ‘ $strGroupNames ‘ to ‘ $strFilename
$data= ‘Group,UserName,UserID’
Write-Output $data | out-file -FilePath $strFileName -Append
$groups = Get-ADGroup -filter {name -like $strGroupNames}
foreach ($Group in $Groups)
{
$usernames = Get-ADGroupMember $($group.name)
We all know that there is a simple way to document GPOs, just right click the GPO and select “Save Report” which will create an HTML file but those can be a little hard to understand and don’t include all of the data such as what individual settings do. An alternative is to use the Microsoft Security Compliance Manager (SCM). Version 3.0 is now available for download from http://technet.microsoft.com/en-gb/solutionaccelerators/cc835245.aspx.
By default, SCM imports baselines for the following products:
Hopefully Microsoft will release the baseline packs for 2012 R2, Windows 8.1, Exchange 2013 and SQL at some point but that doesn’t necessarily prevent the tool being used for documenting most standard settings.
To document the settings, backup your GPO in the usual way and then use the “Import a Group Policy Backup” link in the “Get Information” section.
Browse to where you have your backup GPO
Select a name for the “baseline” or GPO settings and click on OK
Your settings will now be shown as an imported GPO
You can click on the Excel link to export the settings to Excel
Choose to enable the content in the excel spreadsheet created
You will now have your settings in Excel format together with an explanation of each setting and, where covered by the built in security baseline information, details of any vulnerabilities that the setting may address, counter measures that can be deployed to overcome that vulnerability and any impact that setting of the GPO value may cause.
NOTE: Click on the image below to see the level of detail provided for each setting.
Obviously this is a bit more long winded than simply exporting a report but I hope that you can also see how this does provide far more information around what has been configured and, as it is in Excel, enables you to add a further column with an explanation as to why each setting has been configured.
When setting up a Disaster Recovery site its reasonably standard to deploy Active Directory in that site and let AD replicate as usual to ensure that you have a copy of the directory available.
However, replication between sites (using site links0 can only occur as often as once every 15 minutes, longer if you don’t change the defaults. This means that, if the disaster occurs in that time period, any changes that you make may well be lost.
To overcome this you can set up change based notifications for the site link. This makes updates between sites work as though they are within the same AD site. that is, pretty much as soon as a change occurs, it will replicate across the link. of course, this will generate more traffic between links especially for larger sites but you tend to ind that a DR replication link is usually fairly fast and low latency to allow replication of the virtual machines and data.
To enable notification driven replication between active directory sites, access the site link properties page and update the “options” value.
The options attribute uses a bitmap. Its possible values are:
Decimal Value
Binary Value
Explanation
1
1
USE_NOTIFY
2
10
TWOWAY_SYNC
4
100
DISABLE_COMPRESSION
If you want to enable notification without compression (as you are on a LAN like connection, for example, between firewalled segments of the LAN) you can enter the value 5 to enable notification without compression.
New in Windows 2008 R2 active directory is the concept of Active Directory Optional Features and the first of these which have been made available is the Recycle Bin feature. Ever since Active Directory was launched you have been able to recover individual deleted items by undertaking an authoritative restore of sections of the database, even down to an individual object. From 2003 onwards deleted objects have been tombstoned and you have been able to use the ADRestore tool (available to download from http://technet.microsoft.com/en-us/sysinternals/bb963906.aspx). However, the issue with these methods has always been with back links or, to put it another way, restoring these items with any group membership they had and, yes, it has been possible to do that with multiple authoritative restores of the database but that is at best tiresome and at worse can be dangerous. What the Recycle Bin feature does for you is restore with these back links / group memberships in place.
However, to use this feature the first thing you need to do is have your Forest at the Windows 2008 R2 level. Whilst your schema may be at the R2 level (meaning your forest can play host to 2008 R2 Domain Controllers) your domains and forest may still be running Domain Controllers with previous operating systems such as 2008 RTM or 2003 R2. The easy way to check your domain level in Windows 2008 R2 is to start the new Active Directory Administrative Centre. If you select the domain node on the left hand side (the netbios name of my domain is philipflint) then you will be able to check and raise the domain / forest functional levels in the action pane on the right hand side.
Click to Enlarge
If your forest level is not at Windows 2008 R2 you can raise it.
Click to Enlarge
We can now install the Recycle Bin feature. Care should be taken before undertaking the next procedure. Enabling the Recycle Bin feature for a domain / forest is a one way process with no way back. In a typical environment the recycle bin feature will grow the Active Directory database by 10 – 20% which may have an affect on performance especially in larger environments which many thousands of users where servers have been sized to run the complete database in RAM.
You should also note that, even though the Recycle Bin is an optional feature, it cannot be added as a Role Service nor as a Feature.
Click to Enlarge
Instead the role is enabled by running a command in PowerShell. PowerShell is installed by default Windows 2008 R2 servers. However, PowerShell itself has no knowledge of Active Directory. Instead we need to load up the scripts and Verbs that PowerShell needs to be aware of to connect and control Active Directory. There are two ways to do this. The first, and simplest, is to click on Start | All Programs | Administrative Tools | Active Directory Module for Windows PowerShell.
Click to Enlarge
The other alternative is to start PowerShell by clicking on the below icon on the taskbar and then running the command below to import the Active Directory modules.
Import-Module ActiveDirectory
Click to Enlarge
We can now enable the Recycle Bin Feature. Below is a piece of code that you can change to use in your environment.
I’ve highlighted in Red the three pieces of information you have to change. If you have a two tier domain name (such as .co.uk) then you will have to add another DC= section. An example is given below for a domain called philipflint.co.uk.
After amendment for the appropriate domain name variables this command is simply cut and paste into the PowerShell window.
Click to Enlarge
I was not given a chance to back out of the addition of the feature as I used the PowerShell switch –confirm:$false which provides any confirmation when asked. If you do not include this switch then you will be asked to confirm the action.
NOTE: This command needs to be run for each domain in your forest for which the Recycle Bin should be installed.
After synchronising the domain the Recycle Bin will be active on all Domain Controllers and you can now test it out by creating test OU’s and test users and deleting them and restoring them. I have created two users called ‘William Shakespeare‘ and ‘Enid Blyton’ in an OU called ‘Authors‘.
They are both members of the Global Group ‘Famous‘ and the Domain Local group ‘Published‘.
Click to Enlarge
We can now delete the William Shakespeare account.
Click to Enlarge
To restore a user that has been deleted I have provided a script for you below.
As before, simply change the section in Red with the display name of the user you want to restore. I use the logon name as its something that you can ask the user that they are likely to know but if they don’t know this (‘Its always there, I just enter my password’) then you can use another field which uniquely identifies them, their email address for example.
The user account is now restored along with all group memberships.
Click to Enlarge
Memberships below.
Click to Enlarge
Now, of course, its possible that a user may be deleted who is in an OU that has also been deleted. It is not possible to restore the user without first restoring the OU of which they were a member or, in extreme cases, the whole OU tree if multiple OU’s have been deleted.
Unless your records are up-to-date there is a chance that you may not know what your exact OU structure was and so you need a method of finding out what was the parent object of a deleted user. The code to do this is below.
As can be seen from the output, we can see that the last know parent (i.e. the containing OU for this user) was the Authors OU directly under the domain node. Note that the Authors OU has not been deleted and so the user object may be directly restored. Below is a screenshot with the same command but where the Authors OU has been deleted.
Click to Enlarge
In this case we can query the Authors OU to find its last known good parent until we find a containing object which has not been deleted.
Once we know which is the first object to be restored we can begin the restoration process. Previously I have given you the code to restore a user. The command to restore an OU is slightly different and I show it below.
Sometimes you need to have your Schema at a certain level of Windows or may even want to check that a Schema upgrade is successful. One way to do this is to use ADSI Edit and connect to the Schema contect. Looking at the properties of the Schema node we can see the objectVersion attribute of the Schema. For Windows 2008 R2 this is 47.
Click to Enlarge
The objectVersion attribute has the values below for different levels of Schema upgrades.
Schema Version
Release of Windows
13
Windows 2000
30
Windows 2003
31
Windows 2003 R2
44
Windows 2008
47
Windows 2008 R2
Of course, there may be a level of risk in accessing objects with ADSI Edit so you want to query the schema version from a command prompt. To do so you can download the free AdFind tool from http://www.joeware.net/freetools/tools/adfind/index.htm and open up an administrative level command prompt (right click cmd.exe ad select “Run As Administrator”), change your path to where you have saved AdFind.exe to and then run the command
A standard configuration I see is organisations redirecting users “My Documents” to their “Home Drive”. When I ask them why I’m usually told that they don’t know why, because they’ve always done it or because they believe users “need” to see a drive letter in My Computer. Of course, you don’t HAVE to have a home drive to redirect the My Documents folder as the My Documents folder can be redirected to an UNC path (typically \servershare%username%) but you may still want to redirect them to a home drive as explained below. So, what is a home drive and why would you want to use one ?
Well, a home drive, or more correctly a home directory, is a special type of mapped drive that contains a users folders and can contain application data. It allows programmatic access to the home drive by assigning values to the variables:
HOMEDRIVE
HOMEPATH
HOMESHARE
For example, these three environment variables could contain the following:
The home drive can then be accessed in a standard logon script. Below are some parameters that can be used and their meanings.
Parameter
Description
%HOMEDRIVE%
The user’s local workstation drive letter connected to the user’s home directory
%HOMEPATH%
The full path of the user’s home directory
%HOMESHARE%
The share name containing the user’s home directory
So, we can assign a home drive rather than a standard “mapped” drive to enable us to reference the drive in scripts. But, is that all that using a home drive gives us ? The answer is “no”. If you have not assigned a home drive to a user in their Active Directory object then Windows (on clients) uses a default location, the users profile in Documents and Settings / Users directory for files and for user-specific application files such as .ini files it uses the users Windows directory which, be default, is the Windows directory on the client. Therefore one thing extra that using a home drive gives us (over a standard mapped drive) is a place to store user-specific application settings which will follow the user from machine to machine – note that this is distinct from roaming user profiles as these files are not stored in the users profile by default. Also, as the default home location is the users My Documents folder in their profile if we map a home directory we change the home location. This doesn’t mean that the users My Documents location is changed but it does mean that the default location for Open, Save As and command prompt start points is the users Home Directory.
From the above you can see that if we set a users home directory (Home Drive) to be H: then when they try to save a file in Microsoft Word, for example, it will offer to save the file to H: by default. It is for this reason that you often see My Documents redirected to the home drive location….. so that users will save to their My Documents location by default.
As you can see from the above a Home Drive is not just another mapped drive but has a real affect on the end user experience and where files are saved.
Now that’s a difficult question. If you asked me “Can I virtualise my Domain Controllers” then that’s a different question to which the answer is “Of course, its fully supported depending on your virtualisation platform and the version of Windows being used but if you’re on the latest Hyper-V and the latest Windows then its fine”. The question “Should I virtualise my Domain Controllers ?” recognises that you can but that you have a choice as to whether you do or not and, as with any IT decision, you should research, size and plan. What I’d like to talk about today is two items to consider when thinking of virtualising domain controllers.
The first is around synchronisation of system clocks. As mentioned in a previous article windows Servers use time synchronisation to ensure against replay attacks and thus increase the security of Kerberos authentication within an Active Directory environment. However, virtual platforms such as VMWare or Hyper-V also allow you to synchronise a virtual machines clock with the physical host. What this means though is that, if the server host is showing a different time from the root PDC Emulator then any virtualised domain member server or domain controller will set its clock against the domain and then set its clock against the physical host and then against the domain and then against the physical host and so on ad nauseum. This can cause five issues:
If there is more than the amount of “difference” between the DC clock and other domain controller clocks then the server will not be able to synchronise
Similarly, as the DC clock will different from those of clients, clients will fail authentication against this domain controller.
This constant re-synchronisation will cause clock “flapping” so that any events or logs written will have events recorded in an incorrect order. This is an issue not only for domain controllers but also for other servers such as SQL or Exchange where they record the time of records being changed or messages arriving.
If you run an environment where accurate times are important then this will into be possible with “flapping” clocks. For example, if you require staff to “clock in” and penalise them for late arrival then your solution will be at risk if your clock cannot keep accurate time.
So, by all means virtualise your domain controllers but don’t allow them to synchronise their clocks with the physical host. In Hyper-V this behaviour can be disabled by opening the Hyper-V Manager Console. selecting the virtual machine and clicking on Settings in the Actions pane for that virtual machine. Under the Management node select Integration Services and clear the Time Synchronization check box.
Click to enlarge
Click on Apply and that virtual machine will now synchronise its clock solely based on the settings within its operating system.
The second item to consider before virtualising your domain controllers concerns “snapshotting”. Snapshots allow you to take a point in time view of a server and then record differences to the virtual disk of that server over time. In this way you can “roll back” a virtual machine to the point the snap shot was taken by removing the changes made. However, this gives an issue when we consider domain controllers.
When a change is made on a Domain Controller it updates its own Update Sequence Number (USN) and, when a synchronisation is due with other domain controllers, issue the update to them. These USN’s are maintained per Domain Controller and a certain change may register on DC1 as 12345 and hold the USN of 7657622 on the far older DC2. You can see the USN on a particular Domain Controller by looking at the highestCommittedUSN value using ADSIEdit to connect to the RootDSE default naming context.
Click to enlarge
DC1 would look like above and DC2 would have the USN below, for example.
Click to enlarge
Now, it’s a basic premise that the USN on a domain controller should only ever get bigger, and not smaller. After all, transactions can’t just disappear. Indeed, domain controllers use this USN to keep track of the updates they have received from each other. The last USN received from each replicating partner is stored in a High Watermark Vector Table on each DC. In this way, the receiving domain controller knows which was the last change it received form a replicating partner. When it next wants to replicate it sends its high watermark value to the DC it wants to replicate from (the source domain controller). The source DC then uses the information in the high watermark value to determine which objects to replicate back to the target Domain Controller. This can be represented by the following table:
Step
DC
USN
High Watermark Value
Action
1
DC1
100
200
Initial Value
DC2
200
100
2
DC1
108
200
Changes made on DC1 (New user created for example)
DC2
200
100
3
DC1
108
200
DC2 requests changes, synchronises and updates it high watermark value for DC1
DC2
200
108
4
DC1
127
200
Further changes are made on DC1
DC2
200
108
5
DC1
127
200
Only changes 109 to 127 are synchronised to DC2
DC2
200
127
So far so good. So, what’s the issue. The issue is that if we had taken a snapshot of DC1 at, say, step 3 and rolled back then the following would happen.
Step
DC
USN
High Watermark Value
Action
1
DC1
100
200
Initial Value
DC2
200
100
2
DC1
108
200
Changes made on DC1 (New user created for example)
DC2
200
100
3
DC1
108
200
DC2 requests changes, synchronises and updates it high watermark value for DC1
DC2
200
108
4
DC1
127
200
Further changes are made on DC1
DC2
200
108
5
DC1
127
200
Only changes 109 to 127 are synchronised to DC2
DC2
200
127
6
DC1
108
200
Active Directory database “restored” on DC1
DC2
200
127
7
DC1
119
200
Further updates made on DC1 raising its USN past the old value of 127
DC2
200
127
8
DC1
147
200
DC2 requests changes past 127 – DC1 send changes 128 to 147 – the “new” changes in the range 109 to 127 are lost and never synchronised
DC2
200
127
So, by restoring Active Directory from a snapshot we would run the risk of losing updates IF Active Directory allowed us to do this. Fortunately the clever guys at Microsoft have worked this out and from Windows 2003 SP1 this is not likely to happen because AD will recognise that the USN’s have become out of sequence and will refuse to allow DC1 to synchronise. You will know if this has happened to you not only because your domain will not synchronise properly but you will see an event similar to the below logged in the event viewer on the “restored” Domain Controller.
Click to enlarge
As you can see, the only solution for this is to forcibly demote the domain controller and start again. Of course, the situation is even worse if ALL domain controllers are snapshotted and then restored. It’s perfectly possible that you can end up without an operating Active Directory environment ! So, the original question was “Should I virtualise my Domain Controllers ?” and I say that this is a decision that you have to make yourself and the risk you want to assume. However, I would suggest that a best practice is to:
Never synchronise Domain Controller clocks with the virtualisation host
Never snapshot domain controllers
Always have at least one (and preferably two) physical domain controllers in case you have to force demote all virtualised domain controllers
If you follow the above advice I believe the risks in virutalising DC’s are relatively low.
Windows Servers use time synchronisation to ensure against replay attacks and thus increase the security of Kerberos authentication within an Active Directory environment. Kerberos tickets are presented to domain controllers by clients and the authenticating domain controller checks that the time stamp on the ticket is within a certain amount of time of the clock on the domain controller, generally 5 minutes although this can be set by group policy. To ensure that the clocks between clients and domain controllers are reasonably in synch at all times, Windows operating systems use the windows time service (W32Time) to synchronise clocks within the forest. They do this by following a synchronisation hierarchy which can be described as below.
All client desktop computers nominate the authenticating domain controller as their in-bound time partner.
All member servers also nominate the authenticating domain controller as their in-bound time partner.
All domain controllers in a domain nominate the primary domain controller (PDC) operations master as their in-bound time partner.
All PDC operations masters follow the hierarchy of domains in the selection of their in-bound time partner and synchronise with the server holding the PDC operations master role in the forest root domain.
In this hierarchy, the PDC operations master at the root of the forest becomes authoritative for the organization and should be set to synchronise with an external atomic time source or will use its own CMOS clock to set its internal time.
When deploying domain controllers, the server holding the PDC operations master role must then be granted access to the internet to synchronise its time with an atomic clock using the NTP protocol (UDP port 123). This is fine when a data centre is first deployed but what happens when the PDC emulator operations master role is moved to another server ? Synchronisation will still occur within the forest with the new server holding this role other than for the original server hosting the role which will still synchronise with its external source.
This can raise two issues.
One of the servers, over time, could drift in terms of its clock and so the original PDC emulator may not be in sync with the rest of the forest and therefore reject authentication attempts.
If an application is Active Directory integrated and using the AD servers for its time source then that application or service may not be accurately recording its time in the application or any logs. This can be an issue, for example, for systems “clocking in” staff where staff are fined for late arrival or, perhaps, when accurate recording of access times for network assets is important for security reasons. If the time recorded is out by a few minutes then this may be an issue.
This raises the question then “how do I set my clocks accurately for all machines if I move my PDC Emulator role”. There are three solutions.
Set all domain controllers to synchronise to the same external atomic clock. Whilst this should certainly keep all clocks within a reasonable skew time the same issue can occur as described above if one server should, for some reason, not have external access. It is likely to eventually drift from the other server clocks and create issues.
Set two domain controllers to synchronise externally and only move the PDC emulator role between those two servers. This is a standard answer to this conundrum and can work well. It has the advantage that administrators are likely to know where the FSMO roles are for the domain and reduces the amount of setup time. However, there is still a small risk of drift if one server loses its external access for any reason. There is also the possibility that the PDC Emulator role will be moved to a server other than those nominated.
Use a GPO to set domain controllers to follow the hierarchy above and be compliant with RFC 1305 unless they are the PDC Emulator in which case they go to an external source. While all domain controllers still need to be provided access to the internet over UDP port 123, should a mistake be made then all servers will at least have the same clock time and so, using this method, the likelihood of failed authentication attempts are very much minimised.
The preferred method then is option C above. To configure this is relatively simplistic. A GPO is created and applied at the “Domain Controllers” OU level. The GPO itself is scoped by way of a WMI script to affect just the server holding the PDC Emulator operations master role. This GPO configures the W32Time service on that server with the external clocks to synchronise to.
To create the GPO, open Group Policy Management Console and create a new GOP linked to the Domain Controllers OU (I have called mine PDC Time Sync). Access the Scope tab of the GPO.
Note that WMI Filtering is net to <none>. You can only apply a WMI filter if one exists and so, next, we right click the WMI Filters node above and select “New…“. We give the WMI filter a name and description as below.
We then click Add to add a query to the filter. The WMI query will be as below:
Select * from Win32_ComputerSystem where DomainRole = 5
We then click on OK and “Save“.
The WMI script selects computers whose DomainRole method of the Win32_ComputerSystem class (i.e. DomainRole value) is set to 5. The allowed values for this method are as below.
Value
Meaning
0
Standalone Workstation
1
Member Workstation
2
Standalone Server
3
Member Server
4
Backup Domain Controller
5
Primary Domain Controller
Active Directory follows the multi-master method of replication whereby each domain controller “owns” a copy of the Active Directory database and can update values in that database and replicate changes to all other domain controllers. This is as opposed to the NT4 methodology where a primary domain controller existed and all other domain controllers were backup domain controllers. However, Active Directory maintains the PDC Emulator role for those times when a PDC is still required for down level clients, password replication and time synchronisation. The server hosting this role has DomainRole 5 and all other domain controllers hold domain role 4, even though they are not backup domain controllers in the traditional meaning of that term.
As the WMI filter now exists it can be assigned to the GPO as a filter. Access the scope tab of the GPO created earlier and set the WMI filter to the one just created.
The GPO can now be edited and values set to control the W32Time service on the server holding the PDC Emulator role. If the role is moved between servers then the GPO ceases to apply and the W32Time settings are reverted to their original values forcing the server to sync to the new server holding the PDC Emulator role. The appropriate policy to set is the “Configure Windows NTP Client” policy found at “Computer Configuration | Policies | Administrative Templates | System | Windows Time Service | Time Providers” in Windows Server 2008 R2. The default values for these settings are shown below.
The meaning of each value is as follows:
Policy Setting
Effect of Setting
NtpServer
Establishes a space-delimited list of peers from which a computer obtains time stamps, consisting of one or more DNS names or IP addresses per line. Computers connected to a domain must synchronize with a more reliable time source, such as the official U.S. time clock. This setting is used only when Type is set to NTP or AllSync.
0x01 SpecialInterval
0x02 UseAsFallbackOnly
0x04 SymmetricActive
0x08 NTP request in Client mode
Type
Indicates which peers to accept synchronization from:
NoSync. The time service does not synchronize with other sources.
NTP. The time service synchronizes from the servers specified in the NtpServer registry entry.
NT5DS. The time service synchronizes from the domain hierarchy.
AllSync. The time service uses all the available synchronization mechanisms.
CrossSiteSyncFlags
Determines whether the service chooses synchronization partners outside the domain of the computer.
None 0
PdcOnly 1
All 2
This value is ignored if the NT5DS value is not set.
ResolvePeerBackoffMinutes
Specifies the initial interval to wait, in minutes, before attempting to locate a peer to synchronize with. If the Windows Time Service cannot successfully synchronize with a time source, it will keep retrying, using the settings specified in ResolvePeerBackOffMinutes and ResolvePeerBackoffMaxTimes.
ResolvePeerBackoffMaxTimes
Specifies the maximum number of times to double the wait interval when repeated attempts fail to locate a peer to synchronize with. A value of zero means that the wait interval is always the initial interval in ResolvePeerBackoffMinutes.
SpecialPollInterval
Specifies the special poll interval in seconds for peers that have been configured manually. When a special poll is enabled, Windows Time Service will use this poll interval instead of a dynamic one that is determined by synchronization algorithms built into Windows Time Service.
I use the flag 0x1 on the NtpServer setting to make the time service take note of the SpecialPollInterval setting (which is a value in seconds) which sets how often the server should poll for a new time. In this way we can, if desired, poll for a time update more or less often. The NTP type setting tells the service to go direct for its time updates to the NtpServer specified.
One the GPO is configured you can wait for it to be applied to the PDC Emulator or force its application using GPUpdate. To check that the policy is working simply note the difference between the server clock and your wristwatch or other clock and, around an hour later, check again and you should see that the difference between the two time sources has changed as the server is drawing its time from an accurate time source.
The final thing to do is to change the GPO status to disable user configuration settings within the GPO as this will lead to a slightly faster GPO processing time.
I hope this post will help remove some of the mystery surrounding how to configure time synchronisation settings within an Active Directory domain.
Philip Flint 