Monitor health of DFSR and SYSVOL in your Active Directory

Within an Active Directory environment, there are certain things which needs to be monitored regularly. It can be done on daily basis or weekly basis, but not monthly! One of this areas which is heavily important in your environment is ‘Distributed File System’ or as it is known DFS. If you have been using DFS name space for your “File Services” structure, that’s it! DFS is the same, but here, in this article, we are focusing on the role of DFS for synchronization of SYSVOL folder between domain controllers of an Active Directory Domain. In today’s article, we are going to present a method which can be used to monitor the health of your DFS and SYSVOL folder.

Why SYSVOL & DFS is important?

As everybody know, within an Active Directory Domain Controller, there is a folder called SYSVOL. This folder plays a key role in enforcing ‘Group Policy Objects’ to computers or users of the domain. It is better to simply say that; Group Policy will not work if your SYSVOL folder is not doing its job properly. You might be able to open GPMC, but at the end, on the clients, Group Policies will not be applied, simply because SYSVOL folder is not functioning properly. Talking about importance of DFS, it can be said that DFS errors are main reasons of a corrupted SYSVOL structure. Mostly when you have a broken DFS, they will lead to a broken SYSVOL. Consequently, when SYSVOL is heavily important as this, it is always recommended to perform health checks in order to verify that both DFS and SYSVOL are working properly.

But, you might ask yourself, ‘What can happen after all, if these two fail in my Active Directory environment?’, it is a good question though! As we said, DFS is the main procedure which is being used constantly to re-synchronize SYSVOL structure. When a new GPO is created in a domain, this GPO will need a folder in SYSVOL. So firstly, Active Directory will produce a GUID, assign that GUID to the GPO, then create a folder inside SYSVOL folder using that GUID for folder name. Right after, DFS will comes into play, and will replicate that folder to other domain controllers within the domain. By this ways, SYSVOL folder will be synchronized on all domain controllers of the domain. However, if there are some errors on DFS, there is a high chance that, GUID folder will not get replicated to SYSVOL of other domain controllers and it can cause corrupted SYSVOL.

If GUID folder exist in one domain controller but not on another domain controller, you probably will have GPO processing problems on client side. Because if a client, connect to domain controller with missing GUID folder in its SYSVOL, the corresponding GPO of that folder will not get processed on the clients. The ugly part is, you will not be able to notify that the GPO has not been applied on the clients unless someone calls you for that.

Monitoring SYSVOL and DFS

The good part is that I have written a pack of scripts, specifically for monitoring purposes of DFS and SYSVOL. This script will not however fix anything which means it does no harm to your environment. It is only a reporting tool for DFS and SYSVOL of your domain. You can use these scripts for initial troubleshooting cases of your SYSVOL. It means that, by using this script, you can get a health report of the whole DFS within your domain or forest. Then using information provided by this report, you can start doing the troubleshooting.

The very first thing that needs to be done to start doing this health report, is to download the pack of scripts which will be used in this article. This scripts can be downloaded by navigating through this TechNet gallery link. Once it is downloaded, unzip the file and you will see 2 files inside it:

  • Get-DomainSYSVOLHealth
  • Get-ForestSYSVOLHealth

These two functions are actually the same, but they can be used for different environments. If you want to have a health report of SYSVOL and DFS of entire forest (including all domains and all domain controllers), you will need to run ‘Get-ForestSYSVOLHealth’, however, if you have only one domain or you would like to run this report for your local domain, you will need to run ‘Get-DomainSYSVOLHealth’. So the choice is yours, however the procedure of running will be the same. We will focus on running ‘Get-ForestSYSVOLHealth’ for our training purposes.


Before diving into the real job, it is worth to mention, if you would like to be able to generate a report of all domains, you will need some requirement in place. Make sure your environment can meet all these requirements:

  • Network connectivity for all domain and all domain controllers from the machine where you are running the script is available.
  • Ensuring that “Remote Event Log” reading is enabled on Windows Firewalls of your domain controllers.
  • Run the script as administrator. Otherwise it will not be able to generate reports for GPO’s where you have defined ‘Security Filtering’.
  • Running the script with appropriate privileges. In my test environment it is “Enterprise Administrator”, but it is possible to create a user and add it to “Event Log Readers”, of remote domains.

Once you have all above requirements in place, copy the script on your domain controller and use it with ‘PowerShell ISE’ (Run as Administrator), however you can use ‘PowerShell’, but I always stick to “PowerShell ISE’.

Evaluating the results

The only thing, that it is needed to be done in order to have the report, is to simply ‘Dot Source’ the script. For this to work, change the directory of the PowerShell to the folder where the downloaded scripts are residing. Then start typing the name of the script, hit tab, and the name will be completed automatically. Then you need to ‘Dot Source’ the script, for that, type “. “ before the name of the script (a dot and a space). Once it is done, the script will be loaded into the memory and you can simply call the function.





Call the function and script will go through the process of finding all domains and all corresponding domain controllers and eventually processing the health check. Depending on your size of environment and number of DCs and domains or network link between them, the script will take some time to complete.

Once the script is completed, the report will pop up:

So right now, the report is ready. You can take a look at the report and all information in regards with DFS and SYSVOL. Within this report, there are quite number of columns which you can gain good insight about the health of your DFS and SYSVOL by peeking through them. Since the meaning of columns is quite important, I will clarify what each column means:

  • DC: The name of the domain controller.
  • Domain: Name of the domain which value in ‘DC’ column belongs to.
  • Availability: Indicates whether DC is available or unavailable.
  • GPOCount: Total count of Group Policy Objects in domain.
  • SYSVOLCount: Total number of GUID folders in SYSVOL folders.
  • DFSErrors: Count the number of errors in ‘DFS Replication’ log of the event viewer of the remote DC. Remember, only DFS errors belong to the previous day is always taken into account, not the whole log.

Next four columns will validate DFS required parameters and references within Active Directory. These references are required for a clean SYSVOL replication. I have seen scenarios where ‘DFSRLocal Settings’ or ‘SYSVOLSubscription’ are missing. This script will also check if those references are existing in your Active Directory. If the value reported is returned as ‘Valid’, it means the required values are in Active Directory, otherwise it will be returned as ‘Invalid’. If you find yourself in a situation where these values are returned as ‘Invalid’, a quick fix would be to demote and re-promote the DC back to the domain. Otherwise if you are insisting on not doing the demotion and promotion, you may need to create these references manually. You can follow a guide which was provided by "Jorge de Almeida Pinto" for creating these objects manually by navigating to this link.




Analyzing the report

As it has been stated previously, these scripts can be used for reporting purposes only. It will not provide the actual troubleshooting, but it is worth to mention that, by using this report, you can have a glance at health of DFS and SYSVOL of your entire forest or domain. Depending on your environment, it might present different results. But some facts about this report are as follows:

  • If (GPOCounts > SYSVOLCounts): It means that you have missing GUID folders inside SYSVOL. It is likely that you have for example 10 GPOs in your domain, but inside SYSVOL, some of the corresponding folders of those GPOs are missing.
  • If (GPOCounts < SYSVOLCounts): it is likely that your SYSVOL structure is healthy, however it is not 100% true. Basically when ‘GPOCounts’ are lower than ‘SYSVOLCounts’, it means that there are some GUID folders inside SYSVOL structure where there are no corresponding GPO associated to them. Normally this issue appears when you delete a GPO, but the GUID folder remains in place.
  • If (GPOCounts = SYSVOLCounts): A good example of a healthy environment. When ‘GPOCounts’ and ‘SYSVOLCounts’ are equal, it means for each GPO, there a GUID folder associated to them. However, do not hesitate to check DFS errors if there are any.
  • If ‘Events Not Accessible’ is shown for ‘DFSErrors’ column, you need to check if you have enough permission for querying the Event Log of the remote DC, or, there is no firewall rule blocking the ‘Remote Event Log’ management.
  • If ‘Invalid’ is shown on each of the last four columns, as it was stated, there is high chance that there are problems related to DFS references inside your Active Directory. Otherwise it is shown as ‘Valid’ which indicates healthy references. However, I have seen scenarios where the references do exist in Active Directory, but because they belonged to an old DC which was demoted months ago, a lot of errors were producing. Always try to compare object ‘Creation Time’ with original install date of your DC.
  • If ‘Domain Unavailable’ or ‘Unavailable’ is shown, network connectivity, firewall issues and basic availability should be verified.

DFS errors and consequently SYSVOL corruption can be quite difficult to troubleshoot, but in most cases, lack of data is causing more problems. In this articled and the following scripts, I tried to present a method, which can be used in order to monitor the health of your DFS and SYSVOL folder and consequently gather data before doing the troubleshooting. However, as it was stated earlier, this tool will not directly troubleshoot the problems, but instead it can be used as a starting point.