Image may be NSFW.
Clik here to view.Welcome, strangers, to the show
I’m the one who should be lying low
Saw the knives out, turned my back
Heard the train coming, stayed out on the track
In the middle, in the middle, in the middle of a dream
I lost my shirt, I pawned my rings
I’ve done all the dumb things– Paul Kelly, Dumb Things
Microsoft AppLocker is a wonderful technology which allows your IT Department to prevent malicious programs from being run on your work computer. Great in theory, and my experience is that it works with some wrinkles. It broadly works by using Group Policy to configure what is a “Trusted” location.
Applocker and Active Setup
Active Setup allows you to execute commands once per user, early, during login. For example, you might want to do this to configure iTunes for each user who logs onto the computer.
Each Active Setup command has a file path to the commands that you need to run. If you don’t trust this file path in Applocker, your Active Setup fails.
If you are using System Center Configuration Manager (SCCM), then it’s likely that you’ll see this failure.
Suggestion:
If you are going to add a “Path” rule to fix this issue, you need to add two. One for EXEs and another one for MSIs.
Removing AppLocker via Group Policy
So for whatever reason, you have a class of “”special”” computers which AppLocker is not to apply to. So you remove the AppLocker Group Policy from the “”special”” computer. And it still seems to have AppLocker blocking programs.
What gives?
Well what seems to be happening is this:
- The AppLocker Application Identity service (AppIDSvc) is set to Manual.
- The AppLocker registry settings are being left behind.
- AppLocker causes applications to be blocked.
The fix?
- Start the Application Identity service (AppIDSvc)
- Logon to the computer.
- Restart the computer.
This causes AppLocker to finish removing the registry settings.