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.

AD – Reset the pwdLastSet attribute using PowerShell

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

I had a requirement to change some of our AD accounts so that the password expired as per our company policy. Instead of having to call every user to see if they were on-site or not, I wanted a way of making the account adhere without causing the account to expire immediately. After a little look around the internet I found that you could reset the password last set date in AD which would cause the account to expire after x days that our policy defines with all the usual prompts.

Below is a Powershell script that I created to achieve this.

# This script sets a users account so that the password is to expire as per our policy,
# and resets the last password change date so that the user doesn't need login and change
# their password straight away.

# Define input parameters the script can accept.



	[bool]$Change = $False,

	[string]$LogFile = $MyInvocation.MyCommand.Name + ".log"

$Culture = Get-Culture
If ((Test-Path $Logfile) -eq $False)
	# Add headers to the LogFile if it doesn't already exist.
	Add-Content $LogFile "sAMAccountName, LastChange, Today, Changed"

# Get the user & properties from AD
$ADUser = Get-ADUser -Filter {sAMAccountName -eq $sAMAccountName} -SearchScope Subtree -SearchBase $SearchBase -Properties Name,pwdLastSet,PasswordNeverExpires -Server $DNSDomainName

# Check that user exist before going further.
If($ADUser -eq $Null)
	Write-Host "User not found. Aborting."
	# Get the sAMAccountName from AD (Don't rely on the users input)
	$ADsAMAccountName = $ADUser.sAMAccountName

	# Get todays date and format it correctly.
	$Today = Get-Date -Format ($Culture.DateTimeFormat.FullDateTimePattern)

	# Get the date of the last password change and format it correctly.
	$LastChange = Get-Date -Date ([DateTime]::FromFileTime($ADUser.pwdLastSet)) -Format ($Culture.DateTimeFormat.FullDateTimePattern)

	If ($Change -eq $True)
		# Set the password to expired, must be done first.
		$ADUser.pwdLastSet = 0
		# Set the account so that the password expires.
		$ADUser.PasswordNeverExpires = $False
		# Save the changes
		Set-ADUser -Instance $ADUser -Server $DNSDomainName

		# Reset the date of the last password change to today.
		$ADUser.pwdLastSet = -1
		# Save the changes
		Set-ADUser -Instance $ADUser -Server $DNSDomainName

		# Inform the user of the script that the account was changed.
		Write-Host "Account Changed."

	# Log the change to the LogFile.
	Add-Content $LogFile "$ADsAMAccountName, $LastChange, $Today, $Change"

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

Example syntax for the script

./<script>.ps1 -SearchBase "DC=contoso,DC=lan" -DNSDomainName "contoso.lan" -Change $True -sAMAccountName <accountName>

Palo Alto – Backup The Configuration For Restore

Recently I needed to get a hold of the configuration file that we were able to easily restore to another device in the event of a hardware failure. To perform this task we tried using RANCID but all it does is capture the output of

user@hostname> set cli config-output-format default
user@hostname> show config running


user@hostname> set cli config-output-format xml
user@hostname> show config running

Unfortunately the output of these commands are not easily restored to another device in the event of a hardware failure.

To get a configuration backup that you can reload easily on a new/existing device you need to get a copy of the proper XML configuration file. The way to get this is with the following command:

user@hostname> tftp export configuration from running-config.xml to <TFTP Server>

Once you have this you are able to load it back onto a device with no fuss or messing about.

Update: I did eventually get RANCID backing up the XML file that’s TFTP’d from the device with some custom scripts that I wrote, it’s a bit of a fudge but it works.

Palo Alto – Find Processes Hogging The CPU

Update 07/11/2016: Update for PAN OS v7.1.

To show the CPU usage of all processes on the Palo Alto use the following command.

user@hostname> show system resource follow

When run the output will be that of the Linux top command.

For example if the process “logrcvr” was taking up all the CPU time, you can restart the process with the command:

user@hostname> debug software restart log-receiver

For PAN OS v7.1 the syntax has altered slightly and is now.

user@hostname> debug software restart process log-receiver

Palo Alto – Restart The Management Plane

Update 07/11/2016: Update for PAN OS v7.1.

To restart the management plane on a Palo Alto you need to run the following commands from the CLI.

user@hostname> debug software restart device-server
user@hostname> debug software restart management-server

For PAN OS v7.1 the syntax has altered slightly and is now.

user@hostname> debug software restart process device-server
user@hostname> debug software restart process management-server

Note: This only restarts the management plane, the data plane still carries on filtering and forwarding packets.

Palo Alto – Change A URL Category

The Palo Alto firewall uses bright cloud service for it’s URL categorisation. If a URL is incorrectly categorised you can submit a category change request at the URL below:

When submitting a change request select “I would like to receive notifications regarding this change” to receive notifications on the request, I personally alway select this so I receive a notification of what they’ve changed the category too (they don’t always use the category you selected)

In the notification you’ll recieve will be a database version number, this relates to the version number in the PaloAlto web interface.

If the database version is correct and the the URL is still being incorrectly categorized, run the following from the CLI:

user@hostname> clear url-cache

This will clear the URL cache on the device so on the next visit to the website it re-evaluates against the new database.

SRX – Cluster Firmware Upgrade

Before performing a firmware upgrade ensure that you have got a backup of the configuration on the device.

The USB slot in SRX series can be used to copy from/to USB storage to internal flash memory when upgrading or troubleshooting.

  • SRX100 : 1 slot
  • SRX210/240 : 2 slots
  • SRX650 : 2 slot on SRE
  • SRX3400/3600 : 2 slots on SFB and 2 slots on each RE
  • SRX5600/5800 : 2 slots on each RE

In order to copy JUNOS software installation package (e.g., junos-srxxxx-xxx.tgz) from the USB storage to internal flash memory, follow the steps below:

  1. Backup the configuration.
  2. Insert a USB flash drive into your PC.
  3. Copy the JUNOS install package (e.g. “junos-srxxxxx-xxx.tgz”) from the PC to the USB stick. The USB flash drive must be formatted in FAT16 or FAT32.
  4. Insert the USB flash drive into one of the USB slots in the SRX.
  5. Logon to the SRX and run the following command to become the “root” user on the device. You will need to enter the root password for the device.

    user@hostname> start shell user root

  6. Mount the USB flash drive.

    root@hostname% mkdir /var/tmp/usb
    root@hostname% mount -t msdos /dev/da[N]s1 /var/tmp/usb

    Note: Any directory name can be used as a mount point.
    [N] = most of the time is 1.

  7. Verify the contents of the USB flash drive.

    root@hostname% cd /var/tmp/usb
    root@hostname% ls

  8. Copy the the file from the USB flash drive to the internal storage.

    root@hostname% cp /var/tmp/usr/junos-srxxxx-xxx.tgz /root/.

  9. Perform the software upgrade.

    root@hostname% request system software add no-copy unlink /root/junos-srxxxx-xxx.tgz

    Note: It is possible to perform the upgrade directly from the USB flash drive.

  10. Swap to the secondary node, then repeat steps 4 – 9 on this node.

    root@hostname% request routing-engine login node 1

  11. Once the upgrade is complete on all nodes reboot all the nodes simultaneously.

    user@hostname% request system reboot

  12. Once the system is back on-line the firmware upgrade is complete.