AD – Force SYSVOL and AD replication

Update 17/03/2016: Added a download link for the script.

Recently I’ve been doing a lot of work on group policies and due to the nature of our network replication between our domain controllers is slow. This was causing me issues when testing my changes as they hadn’t replicated to some domain controllers. Knowing that group policies consist of two parts files located in the SYSVOL and a version attribute in AD, I wanted a quick way of replicating my changes to all DC’s within our domain.

Below is a batch file that I written to do this.

Update 17/08/2015 : Now automatically determines all domains in a forest, and forces the KCC to recalculate.


REM Location of the ntfrsutil tool from the File Replication Service Diagnostics Tool.
REM This can be downloaded from:
SET NTFRSUTL="C:\Program Files (x86)\Windows Resource Kits\Tools\FRSDiag\ntfrsutl.exe"

CALL :ForceKCCUpdate

REM Get the forest partition dn without specifying the parent domain.
FOR /F %%p IN ('dsquery * forestroot -scope subtree -filter "(objectClass=crossRefContainer)" -l -limit 0') DO (

	REM Get all parent/child domains from the forest configuration.
	FOR /F %%d IN ('dsquery * %%p -scope subtree -filter "(&(objectClass=crossRef)(nETBIOSName=*))" -attr dnsRoot -l -limit 0') DO (
		CALL :ReplicateDomain %%d


	ECHO Replicating Domain: %1
	REM Replicate SYSVOL.
	FOR /F %%f IN ('DsQuery Server -domain %1 -limit 0 -o rdn') DO (
		FOR /F %%t IN ('DsQuery Server -domain %1 -limit 0 -o rdn') DO (
			IF /I "%%f" NEQ "%%t" (
				ECHO Replicating SYSVOL from %%f to %%t
				%NTFRSUTL% forcerepl %%t /r "Domain System Volume (SYSVOL share)" /p %%f

	REM Replicate AD.
	ECHO Replicating AD
	repadmin /syncall %1 /APed


	ECHO Forcing KCC Update

	REM Force the KCC to recalculate in all sites.
	FOR /F %%s IN ('DsQuery Site -limit 0 -o rdn') DO (
		repadmin /kcc site:%%s



Download (Right click and click ‘Save Link as’)

vSphere – ‘inaccessible’ VM’s

Update 17/03/2016: Added a download link for the script.

Recently we had a power  blip in our comms room where I work, this caused some of our VM’s to show as inaccessible. After a little reading I found that you could reload the configuration of the VM’s to remedy this issue.

Below is a PowerShell/PowerCLI script that I used to automate this.

# Refresh all VM's

param (
	[string]$server = $(Throw "parameter 'server' is required!"),

# Connect to the specified server
If ($username -eq "") {
	# Connect to server without username & password
	Connect-VIServer -Server $server
ElseIf ($username -ne "" -and $password -eq "") {
	# Connect to server with username only
	Connect-VIServer -Server $server -User $username
	# Connect to server with username & password
	Connect-VIServer -Server $server -User $username -Password $password

# Get all VM's, excluding templates
$vms = Get-View -ViewType VirtualMachine -Property Name -Filter @{"Config.Template"="false"}
foreach($vm in $vms){

Download (Right click and click ‘Save Link as’)

Example usage:

C:\>.\RefreshVMs.ps1 -server <server>
C:\>.\RefreshVMs.ps1 -server <server> -username <username>
C:\>.\RefreshVMs.ps1 -server <server> -username <username> -password <password>

GPO – Issue Deploying A Scheduled Task Running As “SYSTEM”

Recently whilst doing our windows 8.1 deployment I came across an issue where a computer based schedule task running as “SYSTEM” wasn’t applying. After doing some research and trying a few things depending how you set the task up you got one of the two error below:

  1. The computer ‘********’ preference item in the ‘OU Policies {********}’ Group Policy object did not apply because it failed with error code ‘0x80070534 No mapping between account names and security IDs was done.’ This error was suppressed.
  2. The computer ‘********’ preference item in the ‘OU Policies {********}’ Group Policy object did not apply because it failed with error code ‘0x80041316 The task XML contains an unexpected node.’ This error was suppressed.

Both the error codes point to the same issue, when creating a schedule task that runs as “NT AUTHORITY\SYSTEM”

The issue lies in the fact that the schedule task runs is set to run as the “SYSTEM” account. In the group policy preferences “Schedule Task (Windows Vista and later)” window you get two different results when looking up the system account.

  1. You get “NT AUTHORITY\SYSTEM” when you lookup the account on a domain.
  2. You get “BUILTIN\SYSTEM” when you lookup the account on a computer.

When you look it up by computer, it appears as if it’s working correctly as the security options grey out. When the policy is deployed though the computer it’s unable to lookup “BUILTIN\SYSTEM” as a security principal and fails to deploy (See error 1). When looked up by domain or by manually entering “NT AUTHORITY\SYSTEM” the security options do not grey out. Again when it’s deployed to a computer it fails with the error that it’s unable to deploy the task as it has an unexpected XML node (See error 2).

The only way I’ve found to work around this issue is to:

  1. Set the user as “NT AUTHORITY\SYSTEM”.
  2. Select the “Run only when user is logged on” option.
  3. Manually edit the XML file that the policy creates, and remove the XML node <LogonType>InteractiveToken</LogonType> from the task in question.

The XML file for the schedule tasks (1 file per group policy, multiple tasks per file) can be located in this location on the domain:


Here are the contents of the file with the XML node still in it. To make the file readable I have expanded the XML.

<?xml version="1.0" encoding="utf-8"?>
<ScheduledTasks clsid="{CC63F200-7309-4ba0-B154-A71CD118DBCC}">
  <TaskV2 clsid="{D8896631-B747-47a7-84A6-C155337F3BC8}" name="EMET Config Refresh" image="1" changed="2014-09-10 12:31:37" uid="{4501D60E-1D83-45A1-8A51-0D4CF9D8432A}" userContext="0" removePolicy="1">
    <Properties action="R" name="EMET Config Refresh" runAs="NT AUTHORITY\SYSTEM" logonType="Group">
      <Task version="1.3">
          <Principal id="Author">
            <GroupId>NT AUTHORITY\SYSTEM</GroupId>
            <Subscription>&lt;QueryList&gt;&lt;Query Id="0" Path="Application"&gt;&lt;Select Path="Application"&gt;*[System[Provider[@Name='SceCli'] and EventID=1704]]&lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>
            <Command>%ProgramFiles(x86)%\EMET 5.0\EMET_Conf.exe</Command>

After this has been done the schedule task will deploy and work as expected, but if the scheduled task that was modifed is edited you will need to reapply this workaround.

As of writing this issue still exists in Windows Server 2012 R2.