The first of my (hopefully!) many posts on Active Directory, based on the WorkshopPLUS sessions I attended last month. Progress is slow as I don’t have much time, plus I am going through the slides and my notes and adding more information from the Internet and such.

This one’s on the services that are critical for Domain Controllers to function properly.

DHCP Client

In Server 2003 and before the DHCP Client service registers A, AAAA, and PTR records for the DC with DNS

In Server 2008 and above this is done by the DNS Client

Note that only the A and PTR records are registered. Other records are by the Netlogon service.

File Replication Services (FRS)

Replicates SVSVOL amongst DCs.

Starting with Server 2008 it is now in maintenance mode. DFSR replaces it.

To check whether your domain is still using FRS for SYSVOL replication, open the DFS Management console and see whether the “Domain System Volume” entry is present under “Replication” (if it is not, see whether it is available for adding to the display). If it is present then your domain is using DFSR for SYSVOL replication.

Alternatively, type the following command on your DC. If the output says “Eliminated” as below, your domain is using DFSR for SYSVOL. (Note this only works with domain functional level 2008 and above).

1

2

3

4

C:\>dfsrmig/getglobalstate

CurrentDFSRglobalstate:'Eliminated'

Succeeded.

Stopping FRS for long periods can result in Group Policy distribution errors as SYSVOL isn’t replicated. Event ID 13568 in FRS log.

Apart from the dfsrmig command mentioned in the FRS section, the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalStateregistry key can also be checked to see if DFSR is in use (a value of 3 means it is in use).

If a DC is offline/ disconnected from its peers for a long time and Content Freshness Protection is turned on, when the DC is online/ reconnected DFSR might block SYSVOL replications to & from this DC – resuling in Group Policy distribution errors.

Content Freshness Protection is off by default. It needs to be manually turned on for each server.

Content Freshness Protection exists because of the way deletions work.

DFSR is multi-master, like AD, which means changes can be made on any server.

When you delete an item on one server, it can’t simply be deleted because then the item won’t exist any more and there’s no way for other servers to know if that’s the case because the item was deleted or because it wasn’t replicated to that server in the first place.

So what happens is that a deleted item is “tombstoned“. The item is removed from disk but a record for it remains the in DFSR database for 60 days (this period is called the “tombstone lifetime”) indicating this item as being deleted.

During these 60 days other DFSR servers can learn that the item is marked as deleted and thus act upon their copy of the item. After 60 days the record is removed from the database too.

In such a context, say we have DC that is offline for more than 60 days and say we have other DCs where files were removed from SYSVOL (replicated via DFSR). All the other DCs no longer have a copy of the file nor a record that it is deleted as 60 days has past and the file is removed for good.

When the previously offline DC replicates, it still has a copy of the file and it will pass this on to the other DCs. The other DCs don’t remember that this file was deleted (because they don’t have a record of its deletion any more as as 60 days has past) and so will happily replicate this file to their folders – resulting in a deleted file now appearing and causing corruption.

It is to avoid such situations that Content Freshness Protection was invented and is recommended to be turned on.

Here’s a good blog post from the Directory Services team explaining Content Freshness Protection.

DNS Client

For Server 2008 and above registers the A, AAAA, and PTR records for the DC with DNS (notice that when you change the DC IP address you do not have to update DNS manually – it is updated automatically. This is because of the DNS Client service).

Note that only the A, AAAA, and PTR records are registered. Other records are by the Netlogon service.

DNS Server

The glue for Active Directory. DNS is what domain controllers use to locate each other. DNS is what client computers use to find domain controllers. If this service is down both these functions fail.

Kerberos Distribution Center (KDC)

Required for Kerberos 5.0 authentication. AD domains use Kerberos for authentication. If the KDC service is stopped Kerberos authentication fails.

NTLM is not affected by this service.

Netlogon

Maintains the secure channel between DCs and domain members (including other DCs). This secure channel is used for authentication (NTLS and Kerberos) and DC replication.

Writes the SRV and other records to DNS. These records are what domain members use to find DCs.

The records are also written to a file %systemroot%\system32\config\Netlogon.DNS. If the DNS server doesn’t support dynamic updates then the records in this text file must be manually created on the DNS server.

The Windows Time service on every domain member looks to the DC that authenticates them for time time updates.

DCs in the domain look to the domain PDC for time updates.

Domain PDCs look to the domain PDC of the domain above/ sibling to them. Except the forest root domain PDC who gets time from an external source (hardware source, Internet, etc).

From this link: there are two registry keys HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\MaxPosPhaseCorrection and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\MaxNegPhaseCorrection that restrict the time updates accepted by the Windows Time service to the number of seconds defined by these values (the maximum and minimum range). This can be set directly in the registry or via a GPO. The recommended value is 172800 (i.e. 48 hours).

w32tm

The w32tm command can be used to manage time. For instance:

To get an idea of the time situation in the domain (who is the master time keeper, what is the offset of each of the DCs from this time keeper):

1

w32tm/monitor

To ask the Windows Time service to resync as soon as possible (the command can target a remote computer too via the /computer: switch)

1

w32tm/resync

Same as above but before resyncing redetect any network configuration changes and rediscover the sources:

1

w32tm/resync/rediscover

To get the status of the local computer (use the /computer: switch to target a different computer)

1

w32tm/query/status

To show what time sources are being used:

1

w32tm/query/source

To show who the peers are:

1

w32tm/query/peers

To show the current time zone:

1

w32tm/tz

You can’t change the time zone using this command; you have to do:

1

tzutil/s"Time Zone Name"

On the PDC in the forest root domain you would typically run a command like this if you want it to get time from an NTP pool on the Internet:

specify a list of peers to sync time from (in this example the NTP Pool servers on the Internet);

the /update switch tells w32tm to update the Windows Time service with this configuration change;

the /syncfromflags:MANUAL tells the Windows Time service that it must only sync from these sources (other options such as “DOMHIER” tells it to sync from the domain peers only, “NO” tells it sync from none, “ALL” tells it to sync from both the domain peers and this manual list);

the /reliable:YES switch marksthis machine as special in that it is a reliable source of time for the domain (read this link on what gets set when you set a machine as RELIABLE).

Note: You must manually configure the time source on the PDC in the forest root domain and mark it as reliable. If that server were to fail and you transfer the role to another DC, be sure to repeat the step.

On other machines in the domain you would run a command like this:

1

w32tm/config/update/syncfromflags:DOMHIER/reliable:NO

This tells those DCs to follow the domain hierarchy (and only the domain hierarchy) and that they are not reliable time sources (this switch is not really needed if these other DCs are not PDCs).

Active Directory Domain Services (AD DS)

Provides the DC services. If this service is stopped the DC stops acting as a DC.

Pre-Server 2008 this service could not be stopped while the OS was online. But since Server 2008 it can be stopped and started.

The Active Directory Database Mounting Tool was new to me so here’s a link to what it does. It’s a pretty cool tool. Starting from Server 2008 you can take AD DS and AD LDS snapshots via the Volume Snapshots Service (VSS) (I am writing a post on VSS side by side so expect to see one soon). This makes use of the NTDS VSS writer which ensures that consistent snapshots of the AD databases can be taken. The AD snapshots can be taken manually via the ntdsutil snapshot command or via backup software or even via images of the whole system. Either ways, once you have such snapshots you can mount the one(s) you want via ntdsutil and point Active Directory Database Mounting Tool to it. As the tool name says it “mounts” the AD database in the snapshot and exposes it as an LDAP server. You can then use tools such as ldp.exe of the AD Users and Computers to go through this instance of the AD database. More info on this tool can be found at this and this link.

AD WS is what the PowerShell Active Directory module connects to.

It is also what the new Active Directory Administrative Center (which in turn uses PowerShell) too connects to.

AD WS is installed automatically when the AD DS or AD LDS roles are installed. It is only activated once the server is promoted to a DC or if and AD LDS instance is created on it.