I use two Windows 2003 R2 Enterprise servers with 1.5 TB of disk space as file servers using the Distributed File System (DFS) and DFS Replication, which lets you synchronize files on two servers at all times. In this way we increase the performance and fault tolerance: if one server fails, traffic is redirected to the surviving server.

In addition to this I use the Snapshots Snapshots (Shadow Copies) to save twice daily changed data on each server. This keeps up to 64 versions of a file.

The problem I encountered is that the Shadow Copies disappearing every 2-3 days, keeping only the latest backup. In the System event log I got an error:

Event Type: Error
Event Source: VolSnap
Event Category: None
Event ID: 25
Date: 9/24/2007
Time: 7:01:53 PM
User: N / A
Computer: Filer01
Description:
The shadow copies of volume C: were deleted Because The shadow copy storage "could not grow in time. Consider Reducing the IO load on the system or choose a shadow copy storage volume shadow That Is Not Being Windows clipboard.

To correct this problem, add a key in the registry of each server with these symptoms: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ VolSnap \ MinDiffAreaFileSize and assign a value that is a multiple of 300 in the limit of 3000. This increases the buffer zone used for creating shadow copies, which defaults to 300 MB for my part I used a size of 1800 and since then I have no loss of Shadow Copies.

In one area it is important that the clocks of all machines are synchronized. Indeed, the Kerberos authentication protocol requires a default of 5 minutes maximum difference between clocks in order to prevent attacks.

If authentication is based solely on a username and the password it is theoretically possible for a malicious person to record network traffic, extract data and replay them on a server. The Kerberos session keys are unique and are based on the time of the client, which avoids these attacks if the maximum permissible difference is relatively small.

To be certain that all clocks are synchronized between them, it is necessary to define an authoritative time source. It is possible to configure the domain controller operation master PDC so that it becomes a time source for synchronizing on stratum 2 time source of Stratum 1 (usually a time server based on an atomic clock) .

Continue reading "Configuring an Authoritative Time Server in Windows 2003"

I recently installed two new domain controllers in Windows 2003 R2 to replace an old domain controller in Windows 2000 which showed some signs of weakness. Problem, after the usual phase dcpromo the SYSVOL and NETLOGON did not automatically created on two new CDs. The transfer FSMO roles have passed them without problem and Active Directory (users, computers) and the DNS replicate perfectly.

This problem is very critical because if the domain controller to Windows 2000 were to die it would be possible to authenticate on the field or on the SQL servers using Windows authentication. A very regular backup system state with ntbackup of DC is crucial as the situation is not stabilized. On the other hand, the group policies are not replicated servers are fully considered as DCs SYSVOL and NETLOGON shares have not been created.

Continue reading "Problem replication of SYSVOL and NETLOGON"