for

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

Creating Security Groups for File Shares in Bulk using PowerShell

Security Groups are great for managing large groups for permissions.  A client requested that they needed to have Read-Only, Read-Write, and Ready-Modify (allow for deleting) for all their file shares for better management.

Getting the Share Names

In order for me to create the groups I needed the share names. PowerShell to the rescue!

Type the following on the File Server/ Cluster to list all the shares and capture the output in a text file:

On your file-server you may have a lot of share but for example purposes I am showing just one.

Output should be similar to:

Cleaning up the Share Names

Now that we have the Share names we need to do a bit of cleanup to avoid having duplicates.

  • We need to remove all entries for hidden shares “$”
  • We need to remove duplicates
  • We need to change the case of the share names to lower case. ( I prefer lowercase but you can decide to do what best fits your needs)

Follow my guide to removing duplicates in a text file using NotePad++

Once the sharenames are clean save it to a text file.

Client Requirement for the Security Groups:

For each file share there are three security groups needed:

  • <Sharename>_RO : Read-Only
  • <Sharename>_RW : Read & Write
  • <Sharename>_RM : Read & Modify

For PowerShell to do this I needed to create a .CSV file with all the security group entries.  Now, there are many ways this can be done. I will share what I have been doing.

Open up Microsoft Excel and copy the share on a column to the right (lets say K2)

Now on Cell A2 your value should be =CONCATENATE(K2,"_RW") and drag it down.

It should look something like this:

Do the same for RO & RM. Now you have all the security groups names you need to create.

Create a file called  FileShares_Groups.csv  using the following format.

Create the file Create Security Groups for File Shares.ps1

Copy the two files: FileShares_Groups.csv & Create Security Groups for File Shares.ps1  into a folder called C:\scripts  on the Domain Controller.

Run the PowerShell script and see the security groups get created.

 

 

Active Directory: Changing passwords for users in bulk using a .csv file

Many accounts in your AD might need a password change. What if you want to do this in bulk ?

First, we need to the userlist. Depending on your requirements we need to get a list of users (specifically samaccountname). For random password generation I recommend using http://manytools.org/network/password-generator/ as it can generate up 1000 for free.

Here is what my UserList.csv look like:

Make sure you do the following on a domain controller or connecting to your domain controller via PS-remote with elevated permissions.

Run this in PowerShell (Open PowerShell in Admin Mode)

PowerShell:

-Reset
Specifies to reset the password on an account. (User is not prompted to change password).
To use this parameter, you must set the -NewPassword parameter.
You do not need to specify the -OldPassword parameter.

Extending the Booking days for Conference Room Calendar (Resource)

By default Office365 limits Resource booking days to just 180 days. The maximum days it can be booked for 1080 days.

I like to make resource booking days 1 year from the day of making the reservation/ appointment. Now instead of visiting each calendar and making the change, powershell can help us out.

Happy Booking!

Maintain Your Mac – Check the File System for Errors

Use File System Check

Your Mac seems stable and healthy, and you figure you’ve got it made. Because of this, you’re probably thinking you don’t need to check the file system for errors. Don’t do that though, because there may be problems lurking in the background that you can’t see. Just as it’s a good idea to go to the doctor once a year even if you feel great, you need to give your Mac the once-over every once in a while too.

Although you could purchase expensive third-party utilities to search your hard disk for errors and repair them, your Mac OS X machine comes with a built-in utility called File System Check that you can use to do the same thing. File system checks are run using Single-User mode by typing in a simple command. You should perform these checks monthly. To run a file system check now, follow these steps:

1. From the Apple menu, choose Restart.

2. As your Mac boots, hold down the Command+S key combination to start the computer in Single-User mode. (Make sure to press this key combination right after the chime; otherwise, you won’t get in.)

3. At the command prompt, type /sbin/fsck –fy. There’s a space before the –fy. This command tells your Mac to run File System Check, force the check (f) and answer yes (y) to any and all questions regarding fixing, repairing, or salvaging information. Apple says this is the optimal approach because answering no to any question causes fsck to stop running.

4. If the File System Check finds errors, run it again until no more errors are found. You’ll know errors were found if you receive the message “FILE SYSTEM WAS MODIFIED.” You’ll know when all errors have been repaired when you see the message “The volume Macintosh HD appears to be OK.”

5. Type reboot once all of the errors have been found and repaired.