Home disk management it system administration windows server

Reclaim Disk Space: Efficiently Manage SYSVOL by Pruning Administrative Templates in Windows Server

Updated: • 0 • min read
Table of Contents

Reclaim Disk Space: Efficiently Manage SYSVOL by Pruning Administrative Templates

Managing the SYSVOL share in a Windows Server domain is crucial for the efficient operation of Group Policy. Over time, the size of the SYSVOL can grow substantially, primarily due to the replication of Administrative Templates (.adm files). This excessive growth can lead to significant delays and performance issues, particularly in environments with numerous Group Policies or slow Wide Area Network (WAN) links.

This article details a robust three-step process for effectively minimizing SYSVOL size by strategically removing these administrative template files. By implementing these measures, administrators can drastically improve replication speeds, streamline domain controller promotions, and enhance the overall health of their Active Directory infrastructure. Understanding the impact of .adm files and applying the correct filtration techniques will ensure a leaner, more responsive SYSVOL.

The Challenge of SYSVOL Bloat

The SYSVOL share is a critical component for Active Directory, housing Group Policy Objects (GPOs), logon scripts, and other essential data that must be replicated across all domain controllers. In domains with a high number of Group Policies, the replication of this share can become a bottleneck. This problem is particularly noticeable during the promotion of new domain controllers in remote locations or during non-authoritative restores of SYSVOL, where large data transfers over slow links can consume considerable time and bandwidth.

Administrative Templates, commonly known as .adm files, are a primary contributor to this SYSVOL bloat. These files define the registry-based policy settings available in Group Policy Object Editor and are stored within each GPO’s folder in SYSVOL. Each policy’s folder contains a complete set of these templates, leading to redundant storage and unnecessary replication of identical files across numerous GPOs.

Why Administrative Templates Increase SYSVOL Size

Administrative Templates (.adm files) are legacy components that contain the definitions for registry-based Group Policy settings. When a new Group Policy Object (GPO) is created, a copy of these default .adm files is typically stored within the GPO’s folder in SYSVOL. Consequently, if a domain has hundreds or thousands of policies, each with its own set of these administrative templates, the cumulative disk space consumed can become enormous.

For instance, with the default Administrative Templates, each policy can occupy approximately 870 kilobytes (KB) of disk space. If a domain possesses 1,300 policies, the SYSVOL size dedicated to these templates alone can reach a staggering 1,100 megabytes (MB). By removing these redundant files, the same SYSVOL share could be reduced to a mere 35 MB, translating to just 27 KB per policy. This dramatic reduction significantly lightens the load on replication systems.

The Three-Step Process for SYSVOL Management

To efficiently manage SYSVOL and reclaim disk space, the removal of .adm files is a methodical three-step procedure. This approach ensures that the files are first cleared from existing policies, then prevented from replicating again, and finally, selectively restored where necessary. Each step requires careful execution to maintain the integrity of Group Policy functionality while achieving the desired space reduction. It is paramount to back up your SYSVOL content before initiating any changes to the file structure to prevent data loss.

Step 1: Remove the ADM Files from Policies

The initial phase involves systematically removing the .adm files from all Group Policy Objects within the SYSVOL share. This action will free up the disk space currently occupied by these files within each policy’s folder. The process varies slightly depending on whether you have only default Administrative Templates or if you have incorporated custom templates into your environment.

If your environment utilizes only the default Administrative Templates and no custom ones, the simplest approach is to search for *.adm files on the Primary Domain Controller (PDC) emulator. Sort the search results by name to easily identify the administrative template folders, then proceed to delete them from within the respective policy directories. After performing these deletions, it is critical to allow sufficient time for these changes to replicate successfully to all other domain controllers across the domain. This ensures a consistent state before proceeding to the next step.

For domains that incorporate custom Administrative Templates, a more cautious approach is required. Before deleting, these custom templates must be copied to a separate, secure directory structure for safekeeping. The Robust File Copy utility, Robocopy.exe, available from the Resource Kit, is an excellent tool for this task due to its reliability and advanced features. The general command syntax for this operation is:

robocopy <PDC_SYSVOL_Path> <backup_directory_path> *.adm /s /mov

An illustrative example of copying custom Administrative Templates to a backup location and simultaneously moving them out of the SYSVOL policies could be:

robocopy \\mydom-pdc\sysvol\mydom.com\policies c:\sysvol-adm-backup\ *.adm /s /mov

This command will recursively move all .adm files from the SYSVOL policies directory on the PDC emulator to your specified backup directory. After executing this command, you must wait for the file replication services to complete the propagation of these deletions to all other domain controllers in the domain. Verifying replication status is a crucial step before moving forward to setting the replication filters in Step 2.

Important Note: Always perform a full backup of your SYSVOL directory before making any structural changes to its content. This precaution ensures that you can revert to a previous state if any unforeseen issues arise during the process.

Step 2: Set Replication Filter for ADM Files

Once the .adm files have been removed from the policy folders and these changes have replicated throughout the domain, the next critical step is to configure the replication service to prevent these files from being replicated again. This is achieved by setting a file filter within the File Replication System (FRS) or Distributed File System Replication (DFSR), depending on which service your domain uses for SYSVOL replication. It is essential to determine your domain’s replication method to apply the correct procedure.

Steps for File Replication System (FRS)

For domains still utilizing the File Replication System (FRS) for SYSVOL replication, you need to modify the fRSFileFilter attribute within the FRS object. This modification is best performed using Adsiedit.msc, a powerful tool included in the Support Tools. By default, this attribute contains filters for temporary and backup files, such as *.tmp, *.bak, ~*. We will add *.adm to this list.

To edit this attribute:

  1. Open ADSIEDIT.MSC on a domain controller.
  2. Navigate to and locate the following object in the console tree:
    CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=your_domain
    (Replace your_domain with your actual domain name, e.g., DC=contoso,DC=com).
  3. Right-click on the Domain System Volume (SYSVOL share) object and select Properties.
  4. In the properties dialog box, locate and select fRSFileFilter from the Select a property to view dropdown list. The current value(s) of the attribute will appear in the Value line.
  5. Click Clear to bring the current attribute value to the Edit Attribute line, allowing for modification.
  6. Modify the line to include *.adm. The new value should be *.tmp, *.bak, *.adm, ~*. Ensure proper comma separation.
  7. Click Set to apply the change to the attribute.
  8. Finally, click OK to close the properties dialog box and commit the changes.

Steps for Distributed File System Replication (DFSR)

For domains leveraging Distributed File System Replication (DFSR) for SYSVOL, the process involves modifying the msDFSR-FileFiler attribute. Similar to FRS, this is done through ADSIEDIT.MSC. DFSR is the default replication method for SYSVOL in Windows Server 2008 and later functional levels.

To edit this attribute:

  1. Launch ADSIEDIT.MSC on a domain controller.
  2. Navigate through the console tree to the following path:
    DC=<DominanName>,CN=System,CN=DFSR GlobalSettings, CN=Domain System Volume,CN=Content
    (Replace <DominanName> with your actual domain components, e.g., DC=contoso,DC=com).
  3. Right-click on the CN=Sysvol Share object and choose Properties.
  4. In the properties window, locate the msDFSR-FileFiler attribute.
  5. Select this attribute and click Edit to modify its value.
  6. Append ,*.ADM to the existing string of file filters. For example, if the current value is ~*, it would become ~*,*.ADM.
  7. Click Apply and then OK to save the changes and close the dialog box.

After applying these replication filters, the FRS or DFSR service will no longer replicate any files ending with the .adm extension. This ensures that even if .adm files are reintroduced to the PDC emulator (as discussed in the next step), they will not propagate throughout the SYSVOL share, thus preserving the disk space savings.

Step 3: Copy the ADM Files Back to the PDC’s SYSVOL (Conditional)

The final step involves deciding whether to copy the Administrative Template files back to the PDC emulator’s SYSVOL, specifically into the GUID-named policy folders. This step is conditional and depends on your specific operational requirements and whether you have custom Administrative Templates. The replication filters set in Step 2 ensure that even if these files are placed back on the PDC emulator, they will not be replicated to other domain controllers.

If your environment did not contain any custom Administrative Templates, you technically do not need to copy them back to the PDC emulator’s SYSVOL. The Group Policy Object Editor, whenever used to edit a GPO, will automatically regenerate the necessary Administrative Template files using its locally stored templates. This means GPO editing functionality remains intact without the need to explicitly restore the .adm files to SYSVOL.

However, if you previously had custom Administrative Templates and backed them up in Step 1, or if you prefer to have a complete set of templates on your PDC emulator for specific administrative practices, you can copy them back. You can use the Robust File Copy utility (robocopy) for this purpose. The general command syntax to copy them back from your backup directory is:

robocopy <backup_directory_path> <PDC_SYSVOL_Path> /s

An example of this command, using our previous backup directory and target SYSVOL path, would be:

robocopy c:\sysvol-adm-backup\ \\mydom-pdc\sysvol\mydom.com\policies /s

This command will recursively copy all files from your sysvol-adm-backup directory back into the corresponding policy folders within the PDC’s SYSVOL. Remember, these files will only reside on the PDC emulator due to the replication filter you established earlier.

Moving Administrative Templates During a PDC Emulator Role Transfer

If the PDC emulator Flexible Single Master Operation (FSMO) role is transferred to a different domain controller, and you wish to maintain custom Administrative Templates on the new PDC emulator, you may also need to move these files. This ensures that the new PDC emulator has the complete set of custom templates available locally for GPO editing purposes. Again, robocopy is the recommended tool for this task. The command syntax for moving templates during a PDC role transfer is:

robocopy <old_PDC_SYSVOL_Path> <new_PDC_SYSVOL_Path> *.adm /s /mov

For instance, if your old PDC was mydom-pdc and the new one is mydom-res-pdc, the command would look like this:

robocopy \\mydom-pdc\sysvol\mydom.com\policies \\mydom-res-pdc\sysvol\mydom.com\policies *.adm /s /mov

This command will move the .adm files from the old PDC’s SYSVOL to the new PDC’s SYSVOL. The replication filter will ensure these files remain local to the new PDC emulator.

Distributing Custom Administrative Templates

For organizations with unique Administrative Template requirements, where custom templates are crucial for managing specific policies, it is a good practice to ensure these templates have unique file names across all policies. Furthermore, if administrators need to edit GPOs from machines other than the PDC emulator (e.g., administrative workstations), these custom Administrative Template files should be distributed to those computers. They should be copied to the NT\Inf folder (typically C:\Windows\inf or %windir%\inf) on the administrative workstations. This ensures that the Group Policy Object Editor on these machines can access and display the settings defined by the custom templates when editing GPOs.

In essence, while the primary goal is to minimize SYSVOL replication, maintaining local access to relevant Administrative Templates on GPO editing machines is crucial for uninterrupted management functionality. Combining these approaches ensures both an optimized SYSVOL and a fully functional Group Policy management environment.

Visualizing the Process

To further clarify the steps involved in pruning Administrative Templates from SYSVOL, consider the following process flow diagram. This visual representation outlines the sequential actions and decision points required to effectively manage your SYSVOL size.

mermaid graph TD A[Start: Identify Problem (Large SYSVOL)] --> B{Backup SYSVOL?}; B -- Yes --> C[Backup SYSVOL Content]; B -- No --> C; C --> D[Step 1: Remove ADM Files from Policies]; D --> D1{Custom ADM Files?}; D1 -- Yes --> D2[Copy Custom ADM to Backup Dir (robocopy /mov)]; D1 -- No --> D3[Delete ADM folders on PDC Emulator]; D2 --> E[Wait for SYSVOL Replication]; D3 --> E; E --> F[Step 2: Set Replication Filter for ADM Files]; F --> F1{SYSVOL uses FRS?}; F1 -- Yes --> F2[Edit fRSFileFilter in ADSIEDIT.MSC to include *.adm]; F1 -- No (DFSR) --> F3[Edit msDFSR-FileFiler in ADSIEDIT.MSC to include *.adm]; F2 --> G[Step 3: Copy ADM Files Back to PDC's SYSVOL (Conditional)]; F3 --> G; G --> G1{Need Custom ADM on PDC or for GPO Editing?}; G1 -- Yes --> G2[Copy Custom ADM from Backup to PDC SYSVOL (robocopy)]; G1 -- No --> H[Optional: Distribute Custom ADM to GPO Editor Workstations]; G2 --> H; H --> I[End: Optimized SYSVOL];

This diagram illustrates the logical flow, from initial backup and removal of files, through setting replication filters, to the optional step of restoring custom templates. Each node represents a key action or decision point in the comprehensive management strategy for SYSVOL.

Understanding the Impact on Group Policy Editor

When .adm files are removed from the SYSVOL and filtered from replication, it’s important to understand how this affects the Group Policy Object Editor (GPOE). GPOE uses administrative templates to display and configure registry-based policy settings.

If the .adm files are not present in the GPO’s folder within SYSVOL on the domain controller or administrative workstation where GPOE is being run, the editor will default to using the .adm files found locally in the C:\Windows\inf directory. For default Administrative Templates, this process is seamless, as Windows installations typically contain these files. However, for custom Administrative Templates, it becomes crucial to ensure these files are present on any machine used for GPO editing.

This approach effectively decouples the storage and replication of .adm files within SYSVOL from their functionality in the GPO Editor. It allows for a significantly smaller SYSVOL while maintaining full administrative control over Group Policies. Administrators should consider creating a centralized repository for custom .adm files and a distribution mechanism for administrative workstations to ensure consistency and availability.

Conclusion

Efficiently managing SYSVOL by pruning Administrative Templates is a critical task for maintaining a healthy and responsive Windows Server environment. The presence of numerous .adm files significantly increases SYSVOL size, leading to sluggish replication, prolonged domain controller promotions, and increased network traffic. By following the detailed three-step process—removing files, setting replication filters, and conditionally restoring custom templates—administrators can achieve substantial disk space savings and dramatically improve replication performance.

This strategy ensures that the essential functionality of Group Policy remains intact while eliminating redundant data. Remember to always back up your SYSVOL before making any structural changes and to thoroughly verify replication status after each step. By proactively managing your SYSVOL, you contribute to a more robust, efficient, and scalable Active Directory infrastructure.

We hope this comprehensive guide assists you in optimizing your Windows Server environment. Do you have experience with SYSVOL management or specific challenges you’ve faced? Share your thoughts, questions, or best practices in the comments section below!

Post a Comment