The security database on the server does not have a computer account for this workstation trust relationship

The problem can almost always be resolved without extra domain add/removes and reboots, which is the most prevalent solution I have seen around.  Usually, this issue is due to a mismatch between attributes of the computer account in Active Directory and those values on the system itself.  Here are the steps I take to fix this issue when it crops up:

  • Open up Active Directory Users & Computers pointed to the domain the computer account resides in
  • From the “View” pull-down menu, make sure that “Advanced Features” is checked
  • Navigate to the part of your organizational unit (OU) structure where the computer account for this server resides
  • Open the Properties for the computer object
  • Choose the “Attribute Editor” tab on the Properties dialog box
  • Check the Attributes dNSHostName & servicePrincipalName – anywhere that a fully qualified hostname is specified (e.g., make sure that the entry matches the hostname you have configured when you go here on your server: Start -> Computer -> Right-Click, Properties -> Change Settings (under “Computer name, domain… settings”) -> Full Computer Name

As an example, for a fictitious W2K8 R2 server whose Full Computer Name is “”, these attribute/value pairs should be in Active Directory:



If you find that any of these entries is incorrect, go ahead and fix them; once they all align correctly try logging in again.  After you make any changes, please remember that it may take up to a few minutes for those changes to replicate between all of the Active Directory domain controllers.  Adjusting these values usually works to get me past the error without a reboot in our environment.


Delegate lock/unlock privilege to users or group

In this article, we will go through the steps needed to delegate account unlocks using “Active Directory Users and Computers” console. If you want to delegate account unlocks to a particular user or a group in Active Directory, you will first have to make the right visible in this console.

All the rights attribute that can be made visible in Active Directory Users and Computers are stored in the “%windir%\System32\dssec.dat” file. The rights’ attributes are grouped under headings surrounded by square brackets (for example, [user], [computer] etc.). The value filter for each attribute is:

  • 0 – Read and Write is visible
  • 1 – Write is visible
  • 2 – Read is visible
  • 7 – Attribute is hidden

To modify the filter, open dssec.dat file in Notepad. Under the [user] heading, find the lockoutTime attribute. Change the value of the filter to 0 (lockoutTime=0), by default the value is 7. Save the changes and close the file.

For delegating the unlock account right

1. Open “Active Directory Users and Computers”
2. Right-click the Organizational Unit or domain in “Active Directory Users and Computers”. From the context menu, select “Delegate Control”
3. “Delegation of Control” wizard opens up. Click Next on the Welcome dialog box to proceed
4. Click “Add” to select the user/group to which the right will be assigned. Type the name of user or group you want to add and click “Check Names” button to verify itClick “OK”.

This takes you back to the wizard. Click “Next” to go to the next page.

5. In this step, you will have to choose the tasks. Select the 2nd radio button, Create a custom task to delegate, and click Next
6. Select the 2nd option, which is Only the following objects in the folder. Select User objects in the list, and click Next
7. Select the Property-specific checkbox and ensure that only this checkbox is selectedIn the Permissions list, check both the Read lockoutTime and Write lockoutTime boxes, and click Next.

8. On the Completing the Delegation of Control Wizard dialog box, click Finish to close the wizard

Unlocking a user’s account

To unlock a user’s account, first login to the system. Open Active Directory Users and Computers. Right-click on the User whose account you need unlocked and select Properties from the context menu. In the Properties window, click on the Account tab. Select the Unlock Account checkbox. Here you will find written that this account has been locked in this ADDC. Click Apply and OK to unlock the account.


In this article, we have gone through the steps by which you can delegate the Account Read lockoutTime and Write lockoutTime right to a user or a group for a given domain or OU. As account policies are domain-specific, this account lockout policy will be implemented in the entire domain. However, this delegation will not affect rights or policies in other domains, even in the domains of the same forest or if this domain is a forest’s root.

You can also take help of LepideAuditor to unlock the user account and to know what all user accounts would be locked out. Lepide Active Directory Self Service lets you delegate the rights to unlock the user account to other users easily and also allows the users to unlock their account themselves at the logon screen itself.

How to Repair Server 2012 DFS Replication after Dirty Shutdown and Journal Wrap

How to Repair Server 2012 DFS Replication after Dirty Shutdown and Journal Wrap


When a server 2012 stops replicating with another member, changes are entered into a journal database. If the replication process does not begin in a timely manner, the journal database runs out of space and begins to overwrite itself. In DFS parlance this is known as a journal wrap. Once the journal is wrapped, it’s rendered ineffective.

In this blog, I will demonstrate how to begin a new replication process. This of course, is a last resort, since data will have to be replicated across all member servers. However, if you find yourself in a situation that merits such action, the steps are outlined below.

In this scenario, we make the following design assumptions:

  • We have two servers replicating across WAN connection, a source server and a target server.
  • Both have Windows Server 2012 operating systems.
  • The two servers stopped replicating long enough to cause a journal wrap.

After a dirty shutdown (loss of power), the DFS Replication will not commence automatically. It’s needs to be started manually instead. You will know that you are in a dirty shutdown state because you will see the following error in the DFS replication log of the server that is hosting the DFS:

Event 2213 The DFS Replication service stopped replication on volume… This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled.


When you encounter a dirty shutdown error, it’s best to resume the replication process and wait to see if the replication begins again. If the journal is not in a wrapped state, the replication should begin to work. Please note that you should have a backup of all data located in both the source and target server before beginning the recovery processes that is outlined below.

How to Resume from a DFSR Dirty Shutdown State

To resolve the dirty shutdown state, scroll down to the bottom of the Event 2213 error message. Copy the entire WMIC command in step 2, including the GUID to the clipboard. To do this, highlight the entire text and press CRTL+C.


Next, run Windows PowerShell as an administrator. In PowerShell type the command CMD and press enter (this is due to the fact that WMIC will not run from PowerShell natively, it requires the command prompt)

Next, right click on the PowerShell screen and paste the clipboard contents. Once the WMIC command has been pasted, press enter to execute the command.

Once the command is executed successfully, it should return a value of 0.


Monitor your replication folders until you feel that they are all replicating once again. There may be a replication backlog so be patient, replication may take longer than usual. If after waiting sufficient time, some or all of the replication folders are failing to replicate, the folder’s corresponding journal database may be in a wrapped state.

Recovering DFS-R Replication from a Wrapped Journal State

The database that keeps track of DFS-R changes is located in the corresponding replicated folder in a hidden file. We will need to delete this folder from both the source and target servers. This is an easy recovery method however, it should be noted that if user’s have made changes in both the target server’s data, it will be lost and replaced by the data that is located on the source server. For this reason, you should keep a copy of the replication data from all replicating members.

To begin, open the DFS management console and locate the replication group that is not working. Right click on it and select delete. Don’t worry, the contents will not be deleted.


After you have deleted replication group, open the folder on the authorative (source) server (the authorative server is the one that contains the most update versions of all replicated files), . Select View-> Options-> View Tab and Show hidden files to display the Dfsrprivate subfolder folder. This is the folder that contains the journal database.


In order to delete this folder, we must first stop the DFS-Replication service. Open the services management console (services.msc) and stop the DFS Replication service.


Once it’s stopped, delete the DfsrPrivate sub folder. DO NOT delete the data files, we need those to seed the replication process.

Now, for each replicating member (non-authorative server), stop the DFS-Replication service, locate the replicating target folder and rename it to .old. This way you have a copy of the data in case some files were updated on multiple servers during the time that the servers were not replicating and you need to go back to find it.

Create a new folder and share it, this will be the new target folder. Do this for each replicating member server.


When finished, re-start the DFS-Replication service on all of the servers.

Go back to the DFS Manager, right click on the DFS Namespace and select new folder. Name the folder and click on the add button to find the target location. Point the target to the corresponding folder on the authorative server. Expand the folder and make sure that you do not see the DfsrPrivae subfolder. if you properly deleted it as outlined prior, it should not be shown.


Click OK to add the target folder. next, right click on the newly created folder under the DFS namespace and select add folder target. Navigate to the replicating member server and look for the target folder. This folder should be empty.


After you click OK, you should be prompted by the replication group creation dialog box. Proceed to create a replication group with your desired settings.


When finished, open the target locations side by side using a UNC path and monitor the progress.


After a few minutes, you should see a new DfsrPrivate folder appear on the authorative server’s target folder, indicating the creation of a new journal database. Shortly after that, your files will begin to replicate to their target locations.


Delegating the permission to generate Group Policy Results of Computer Configuration for domain users

Delegating the permission to generate Group Policy Results of Computer Configuration for domain users

By default, domain users cannot generate the “Group Policy Results” or “Resultant Set of Policy” of Computer Configuration due to insufficient permissions. Only users with local administrator rights on the target computer can remotely access Group Policy Results data.
Figure 1: Gpresult of a domain user
Figure 2: The warning of “Resultant Set of Policy
Figure 3: “Resultant Set of Policy” is being processed
Figure 4: The result of “Resultant Set of Policy
To allow domain users generating the “Group Policy Results” or “Resultant Set of Policy” of Computer Configuration, we can delegate the permission for domain users by using GPMC. The permission can be assigned in a domain or organization unit level.
Remark: To delegate the permission, make sure the forest functional level of the domain environment is Windows Server 2003 or later.
Allow the domain user,Terry, reading the “Group Policy Results” of Computer Configuration in “Win7 Workstations” OU.
Lab environment
  • 1 domain controller named DC02 which is installed Windows Server 2008
  • 1 workstation named W701 which is installed Windows 7 is under Win7 Workstation OU
  • 1 server named FS01 which is installed Windows Server 2008 R2 is under Computer container
  • 1 domain user account named Terry
1. On DC02, log in as Domain Administrator.
2. Launch “Group Policy Management Console“.
3. Expand “Forest > Domains > Domain Name > Win7 Workstations“.
4. Select “Delegation” tab.
5. Next to “Permission“, select “Read Group Policy Results data“.
6. Click “Add“.
7. In “Select User, Computer, or Group” window, enter “Terry“.
8. On “Add Group or User” window, next to “Permissions“, select “This container and all child containers“.
Remark: The child OU of “Win7 workstations” will inherit the permission because “This container and all child containers” is selected.
9. Click “OK“.
10. Click “Advanced“.
11. Next to “Security“, select “Terry“.
The “Generate resultant set of policy” permission is granted Terry.
12. Click “Cancel“.
Now, Terry can generates the “Group Policy Results” or “Resultant Set of Policy” of Computer Configuration on workstations which  is under “Win7 Workstations” OU.
Test result
1. On W701, log in as Terry.
2. Launch “Command Prompt“.
3. Perform “gpresult /r“.
The “Group Policy Results” of Computer Configuration can be generated by Terry.
4. Perform “rsop.msc“.
When the “Resultant Set of Policy” is being processed, there is no warning message. Terry can generate “Resultant Set of Policy” of Computer Configuration.
5. Log out W701.
6. On FS01, log in as Terry.

7. Launch “Command Prompt“.
8. Perform “gpresult /r“.

9. Perform “rsop.msc“.
Because the “Generate resultant set of policy” permission isn’t granted on domain level, Terry cannot generate the “Group Policy Results” or “Resultant Set of Policy” of Computer Configuration.
For more information:
Delegation and policy-related permissions

DNS, Windows Event Log, AD Web Services not starting on Windows 2008 R2 DC


When you try to start the Windows Event Log service from the Services console on Windows Server 2008, the Windows Event Log service fails. Additionally, you receive the following error message:

Error 5: Access denied

The Task Scheduler and Windows Event Collector services, which depend on Windows Event Log service, also fail.


This problem happens if any of the following conditions are true:

  • The built-in security group EventLog does not have permissions on the folder %SystemRoot%\System32\winevt\Logs
  • The Local Service account does not have default permissions on the following registry key:



Restore the default permissions on %SystemRoot%\System32\winevt\logs.

Authenticated user – List folder/read data, Read attributes, Read Extended attributes, Read permissions
Administrators – Full control
SYSTEM – Full control
EventLog – Full control

Method 1

To restore the default permissions on folder %SystemRoot%\System32\winevt\logs, follow these steps.

  1. Right-click on %SystemRoot%\System32\winevt\logs and select Properties.
  2. Select the Security tab.
  3. Click Edit button and click the Add button in the permissions dialog box.
  4. In Select users, computers, or Groups dialog box ensure that under object types Built in Security Principals and the location as local computer name is selected.
  5. Enter the object name as “NT SERVICE\EventLog” without quotes. And click OK. This group should have full control on the folder.
  6. Once EventLog group is added add the rest of the groups with above mentioned permissions.

Method 2

Identify a Windows Server 2008 machine with default permissions.

  1. Click Start, and then type cmd in the Start Search box.
  2. In the search results list, right-click Command Prompt, and then click Run as Administrator.
  3. When you are prompted by User Account Control, click Continue.
  4. Type the command CD %SystemRoot%\SYSTEM32.
  5. Once the working directory is changed to %SystemRoot%\SYSTEM32 type the command icacls winevt\* /save acl /T.
  6. This will save a file named ACL in %SystemRoot%\SYSTEM32. Copy this file to the C: drive on the problem computer.
  7. On the problem computer, open command prompt with administrator privileges (refer to previous steps 1-3).
  8. Change the working directory to %SystemRoot%\SYSTEM32.
  9. Execute the command icacls winevt\ /restore acl.

    Default permissions on the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Reliability should be:

    CREATOR OWNER – Full control
    SYSTEM – Full control
    LOCAL SERVICE – Query Value, Set Value, Create Subkey, Notify and Delete
    Administrators – Full control
    Users – Read

    To set the permission on this registry key:

    1. Click the Start menu, select Run and type Regedit.
    2. Go to the location HKLM\Software\Microsoft\Windows\CurrentVersion\Reliability.
    3. From the Edit menu click Permissions.
    4. Add the permissions for the accounts as listed above.