Share via

Active Directory: How to generate a health report of DFS and SYSVOL structure?

Introduction

There are quite a number of tasks in which an Active Directory administrator should always perform regularly during the day. This task can be varied from performing backups to troubleshooting serious problems of an Active Directory environment. Talking about tasks, some people tend to patrol through the different areas like ‘Event Viewer’ to find more information about the health of the infrastructure, some other people including me or maybe you, prefer to use other methods to do these same tasks with maximum efficiency. Some clear example of these methods is using SCOM or PowerShell scripting.

Within an Active Directory environment, there are certain things which need to be monitored regularly. It can be done on a daily basis or weekly basis, but not monthly! One of these areas which are heavily important in your environment is ‘Distributed File System’ or as it is known DFS. If you have been using DFS namespace 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 knows, 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 the SYSVOL folder is not functioning properly. Talking about the importance of DFS, it can be said that DFS errors are the main reasons for 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 the SYSVOL folder using that GUID for the folder name. Right after, DFS will come 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 exists in one domain controller but not on another domain controller, you probably will have GPO processing problems on the client side. Because if a client, connect to a 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 the 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.

Requirements

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’.

Generating 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 space). Once it is done, the script will be loaded into the memory and you can simply call the function.


*Typing the name of the script.
*


*Hitting 'Tab' will automatically complete the script name.

*

*"Dot Sourcing" by placing a (Dot) and a (Space).

*

*The script is now loaded into PowerShell.

*

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 to DFS and SYSVOL. Within this report, there are quite a 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 a 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. These references can be found via the ADSIEDIT tool.

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 the 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 a 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 an original install date of your DC.
  • If ‘Domain Unavailable’ or ‘Unavailable’ is shown, network connectivity, firewall issues, and basic availability should be verified.

Conclusion

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 article 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.