DC

Force synchronization for DFSR-replicated SYSVOL

One of my clients had a problem with processing GPO on client computers. Different computers applied different settings from the same GPO but from different domain controllers. All tests related to replication was successful, all GPOs are applied, but replication between domain controllers was a problem, and because of that most clients had a different GPO configuration.

I had a similar problem with a newly promoted domain controller which I previously blogged about here.

Scenarios where this problem typically occurs:

  • Replication was moved  from FRS to DFSR
  • Demoting an old domain controller in the environment
  • When there is a problem with the DFS replication of the SYSVOL folder

To solve this problem, I had to manually perform an authoritative synchronization between the domain controllers.

I am including steps for authoritative and non-authoritative synchronization, but before we get started we need to see the state of the replication.

Steps:

  1. Find the state of the replication state. Typically the problem DCs will be at 0 or 2. The goal is to get to state 4.
  2. Get to State 2
  3. Get to State 4

Find the state of the replication of all DCs

The states should translate as below

0 = Uninitialized
1 = Initialized
2 = Initial Sync
3 = Auto Recovery
4 = Normal
5 = In Error

Non-authoritative synchronization of DFSR-replicated SYSVOL

  • Stop the DFS Replication service ( net stop dfsr).
  • In the ADSIEDIT.MSC tool modify the following distinguished name (DN) value and attribute on each of the domain controllers that you want to make non-authoritative:
    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>
    msDFSR-Enabled=FALSE
  • Force Active Directory replication throughout the domain  ( repadmin /syncall primary_dc_name /APed )
  • Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:
    DFSRDIAG POLLAD 
  • You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated (Open up event viewer and navigate to Applications and Services Logs -> DFS Replication).
  • On the same DN from Step 1, set:
    msDFSR-Enabled=TRUE
  • Force Active Directory replication throughout the domain ( repadmin /syncall primary_dc_name /APed).
  • Start the DFS Replication service ( net start dfsr).
  • Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:
  • You will see Event ID 4614 and 4604 in the DFSR event log indicating SYSVOL has been initialized. That domain controller has now done non-authoritative sync of SYSVOL.
  • Run Wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo get replicationgroupname,replicatedfoldername,stat and make sure the state is at 4. If it is at 2, it may take some time to reach state 4. Wait a few minutes and try again until all DCs are at state 4.

Authoritative synchronization of DFSR-replicated SYSVOL

  1. Find the PDC Emulator (Elevated Command Prompt: netdom query fsmo ) – which is usually the most up to date for SYSVOL contents. Or the server holding all the policies and scripts. Consider this the primary server.
  2. Stop the DFS Replication service ( net stop dfsr) on the primary server.
  3. On the primary server, In the ADSIEDIT.MSC tool, modify the following DN and two attributes to make authoritative:
    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>
    msDFSR-Enabled=FALSE
    msDFSR-options=1
  4. Modify the following DN and single attribute on all other domain controllers in that domain:
    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>
    msDFSR-Enabled=FALSE
  5. Force Active Directory replication throughout the domain and validate its success on all DCs ( repadmin /syncall primary_dc_name /APed). Probably need to run the same command 3-4 times.
  6. Start the DFSR service set as authoritative ( net start dfsr) on the primary DC.
  7. You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated (Open up event viewer and navigate to Applications and Services Logs -> DFS Replication).
  8. On the same DN from Step 1, set:
    msDFSR-Enabled=TRUE
  9. Force Active Directory replication throughout the domain and validate its success on all DCs ( repadmin /syncall primary_dc_name /APed ). Probably need to run the same command 3-4 times.
  10. Run the following command from an elevated command prompt on the same server that you set as authoritative (primary server):
    DFSRDIAG POLLAD 
  11. Wait a few minutes you will see Event ID 4602 in the DFSR event log (Open up event viewer and navigate to Applications and Services Logs -> DFS Replication) indicating SYSVOL has been initialized. That domain controller has now done an authoritative sync of SYSVOL.
  12. Start the DFSR service on the other non-authoritative DCs ( net start dfsr). You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated on each of them.
  13. Modify the following DN and single attribute on all other domain controllers in that domain:
    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>
    msDFSR-Enabled=TRUE
  14. Run the following command from an elevated command prompt on all non-authoritative DCs (i.e. all but the formerly authoritative one):
  15. Verify you see Event ID 2002 and 4602 on all other domain controllers.
  16. Run Wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo get replicationgroupname,replicatedfoldername,stat and make sure the state is at 4. If it is at 2, it may take some time to reach state 4. Wait a few minutes and try again until all DCs are at state 4.
If setting the authoritative flag on one DC, you must non-authoritatively synchronize all other DCs in the domain. Otherwise, you will see conflicts on DCs, originating from any DCs where you did not set auth/non-auth and restarted the DFSR service. For example, if all logon scripts were accidentally deleted and a manual copy of them was placed back on the PDC Emulator role holder, making that server authoritative and all other servers non-authoritative would guarantee success and prevent conflicts. If making any DC authoritative, the PDC Emulator as authoritative is preferable, since its SYSVOL contents are usually most up to date. The use of the authoritative flag is only necessary if you need to force synchronization of all DCs. If only repairing one DC, simply make it non-authoritative and do not touch other servers. This article is designed with a 2-DC environment in mind, for simplicity of description. If you had more than one affected DC, expand the steps to includeALL of those as well. It also assumes you have the ability to restore data that was deleted, overwritten, damaged, etc. previously if this is a disaster recovery scenario on all DCs in the domain.

After these actions, all problems with GPO processing and SYSVOL replication disappeared. 🙂

Get Inactive Users Report for the past 60 days in a multi domain environment

I had a request recently to provide an inactive user report for the past 60 days. Basically, find out which accounts have not logged in for the past 60 days so action can be taken against them.

The request was for a multi domain forest which queries every domain controller and gets the latest lastlogon value by comparing value from each. I wrote a script and wanted to share as other might find it handy too.

 

Get All DCs in the Entire Forest

Getting a know a new environment for a new client and I a quickly needed information about all domain controllers in the entire forest.

Wrote a small little script to provide me all the information I needed:

 

Connecting to a remote domain controller using PowerShell

Covering one of the basic day to day task if you are a Windows Administrator; connecting to the domain controller.  I try to minimize logging onto servers as much as possible.  Your thought should be around connecting to the server remotely and doing the work as needed instead of natively logging on to it.

I will be discussing two approaches below to connect to a domain controller:

  1. Connecting from a client machine on the same domain
  2. Connecting from a client machine on a different domain or a workstation/server

Before we get started, and regardless of which approach you take below, the following will need to be installed on the client Windows machine. Primarily you need to get the Active Directory Module for Windows PowerShell installed.

Installing the Active Directory Module

GUI:

The Active Directory for Windows PowerShell is already built-in into Windows Server operating systems (starting from Windows Server 2008 R2), but it is not enabled by default.

On Windows Server 2016, you can install the AD for PowerShell module from the Server Manager (Add Roles and Features -> Features -> Remote Server Administration Tools -> Role Administration Tools -> AD DS and AD LDS Tools -> Active Directory module for Windows PowerShell).

PowerShell:

You can also install the module from the PowerShell console using the command:

The RSAT-AD-PowerShell can be installed not only on the domain controllers, but also on any domain member server or even a workstation. The PowerShell Active Directory Module is installed automatically when you deploying the Active Directory Domain Services (AD DS) role (when promoting server to AD domain controller).

Approach 1: Connecting from a client machine on the same domain

First step you need to do is find all of your domain controllers and allow remote connections to it.

Logon to your one of your domain controllers and open up PowerShell:

You need to do this once on each domain controller so you can remotely connect to each one of them at a later time.

You can read more about WinRM here.

Alternatively, the following command can be ran in an elevated Powershell console on the DC. This enables WinRM and configures the firewall so that it can accept incoming commands.

Once that is done you are ready to connect to your domain controller.

Make sure your system is configured to run PowerShell scripts.

Copy the content below and paste it into your PowerShell Editor. Rename your value of “yourdomaincontroller” to your actual DC Server name.

Now all command you enter will be applied to the DC.

To check if your connection is successful. Try the command below to get a list of all of your domain controllers.

Approach 2: Connecting from a client machine on a different domain or a workstation

Windows Remoting works perfectly for same domain situations, and the set-up is relatively straight-forward. It’s extremely powerful when it works, and offers a highly flexible way to securely execute commands remotely.

Problems arise however when trying to use WinRM in mixed domain environments, or where only one machine is on a domain. This requires some additional configuration steps outlined below.

Logon to your one of your domain controllers and open up PowerShell and run the following:

The following registry key needs to be added to the target domain controllers:

Make sure the ports are open:

By default, WS-Man and PowerShell remoting use port 5985 and 5986 for connections over HTTP and HTTPS, respectively.

The module is interacting with AD through the Active Directory Web Service that must be installed on your domain controller (communication is performed over the TCP port 9389).

In some environments, you may need to check if the server authentication certs are valid and not expired. Also, in some situations I have seen that if the client is not resolving the FQDN, it is because the DNSzone doesn’t exist in the source domain. Either the zone can be added, or the host file can be modified to add the DC’s FQDN.

Trusted Hosts:

Adding the client IP or name can help avoid errors.

Depending on your environment and what is allowed or not one of the following should work for your situation.

View the computers of TrustedHosts list

To view the list of TrustedHosts added to the machine, type the following command. By default, its value is blank.

Add all computers to the TrustedHosts list

Using the Set-Item cmdlet and the wildcard you can add all the computers to the TrustedHosts list with the following command.

Add all domain computers to the TrustedHosts list

In the following command, replace .yourdomain.com with your own domain name.

Add specific computers to the TrustedHosts list

You can add specific computers you choose based on their hostname by separating them with a comma (,) using the following command.

Where ComputerName can be in the Server01 or Server01.yourdomain.com format

Add a computer to an existing list of TrustedHosts

If you have already added some computers to the TrustedHosts list and want to add an additional computer, without deleting the previous entries, you should use the following method. This is because the TrustedHosts list is updated based on the last Set-Item command you have run overwriting the previous entries.

Use the following command to save the current TrustedHosts computer list to a curList variable.

To add a computer to the current list, type the following command by specifying both the variable you created and the computer name you are going to add.

Alternatively, to avoid using a variable, add the -Concatenate switch to the Set-Item command to add both new and previous entries. For example:

Add computers to the TrustedHosts list using the IP address

Similarly to the previous commands, you can use an IPv4 or IPv6 address. In the case of IPv6, you have to type the address between [].

Add computers to the TrustedHosts list using multiple IP address (Most common)

Another way to add trusted hosts is via an elevated Command Prompt:

Importing the AD Module:

Before using any cmdlets of the Active Directory module, you need to import it to your PowerShell session (on Windows Server 2012 R2/ Windows 8.1 and newer the module is imported automatically).

With this configuration, it’s now possible to authenticate and execute a command remotely with explicit credentials.

Lets check if it is working:

It WORKS! 🙂

Common Errors & Solutions:

Error: WinRM service started.  Set-WSManQuickConfig : <f:WSManFault…. WinRM firewall exception will not work since one of the network connection types on this machine is set to Public…… Change the network connection type to either Domain or Private and try again.

Solution: 

Explanation:

The above error message indicates that we have set the network to Public in order to enable PowerShell Remoting. Several ways exist to change the connection type. For some reason that only Microsoft knows, you can’t do this in the Network and Sharing Center.

 

Error: Enter-PSSession : Connecting to remote server 10.0.2.33 failed with the following error message : The WinRM client cannot process the request….

Solution:

Explanation:

In an Active Directory environment, you can just use the computer name to connect to a remote machine. If you remotely connect to a standalone machine, you usually have to use the IP address instead. If you try to connect to the remote computer with the Enter-PSSession cmdlet using the IP address of the remote machine, PowerShell will throw the above error.

Error: Cannot connect to host…

Solution:

Check with your network/ firewall team if  the port 5985, 5986, and 9389 are open.

Explanation: 

Most of the times the ports are overlooked and are the root cause as to why the connection is not working