AppLocker blocking getpaths.cmd

When you configure the default AppLocker Script rules in a Group Policy Object (GPO) one of the ones it adds is for:

%OSDRIVE%\*\temp\*\getpaths.cmd

Except when a user logs on, if you’ve enabled the AppLocker MSI and Script event log, you still get the following event logged:

Log Name: Microsoft-Windows-AppLocker/MSI and Script
 Source: Microsoft-Windows-AppLocker
 Date: 20/08/2013 11:37:21
 Event ID: 8007
 Task Category: None
 Level: Error
 Keywords:
 User: RCMTech\JohanSmythe
 Computer: RDS2012-01.rcmtech.co.uk
 Description:
 C:\USERS\JOHA~1\APPDATA\LOCAL\TEMP\2\GETPATHS.CMD was prevented from running.

Which is a nuisance. I’ve not noticed anything bad as a result of this being blocked, but I’m going to assume that it shouldn’t be because there’s a default rule that looks like it should allow it to run. Plus it’s messy to have errors being logged unnecessarily.

So after a bit of experimentation, it seems as though at least part of the problem is the %OSDRIVE% “special” AppLocker variable. I’ve now added a rule for the following path, and getpaths.cmd is running fine:

C:\*\AppData\Local\Temp\*\getpaths.cmd
This entry was posted in Remote Desktop, Windows and tagged , , , , , , , . Bookmark the permalink.

5 Responses to AppLocker blocking getpaths.cmd

  1. M says:

    I have recently implemented Applocker in our environment. Randomly few Users are reporting that it is blocking Office applications (Excel, Word, PowerPoint and Outlook) which are exempted by default rules. I only have one deny rule to stop execution of executable from DVD drive. Please help.

    • rcmtech says:

      Enable the AppLocker event logs (in Event Viewer) and see what it’s blocking. From this you can usually tell why the item is being blocked by comparing with your rules and/or adding extra rule(s) to allow whatever’s being blocked.

  2. Tesfaye Hiwot says:

    And to those who are looking to implement this (and you really should be), use Audit mode first and test test test. Configure machines in your environment to use your ever growing policy and run it in Audit mode and forward the failure events to a computer for periodic review. As you update the policy and test, the failure events returned should be decreasing significantly unless you have a ton of software in your environment to account for.

  3. Christian says:

    For me, this works great (and still using the OSDRIVE-variable):

    %OSDRIVE%\USERS\*\APPDATA\LOCAL\TEMP\*GETPATHS.CMD

  4. Applocker is Great says:

    Thank you !!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s