This short blog will be about what to do when you have locked yourself out of your device when implementing Intune Applocker device configuration policies. Some time ago I blogged about how a not configured DLL rule can break your devices.
At that time, just changing the Applocker device config inside Intune did the job. But what if the new Applocker policy just won’t sync to the device and the old policies still apply.
UPDATE 09-06-2021. Added a weird issue which can also be solved by following the steps above. So I will show you both problems/issues in this blog
The first issue
At the same company, there was still 1 device left that had still the old Applocker policy. Inside this policy, the DLL rule was set to not configured like I was showing in the blog above. It didn’t matter what we tried, the new working Applocker policy just did not apply.
So you have got your device, which only shows you a nice black screen and there is nothing you can do about it. Or could there be some other solution to fix this problem?
Of course, there is… you will need to have access to the drive. In our example, we are using N-able remote background to do the job.
When you still fancy your old fashioned domain controller. The Applocker policy will be stored on the workstations inside the SrvpV2 registry key:
But with Intune… there is no such key. As I showed in one of my last blogs about Applocker, the information is also stored inside the c:\windows\system32\applocker\MDM folder.
The first step to get your device working again:
- Trash the contents of the MDM folder itself.
- Make a note of the time stamp
- Delete the .policy files inside the Applocker folder which have the same timestamp.
- Reboot the device
After a reboot, check the Applocker event log, you will notice the same warning you will have when you want to run/enforce Applocker without Intune on a Windows 10 pro device.
But for now, it’s great, you can log in again without Applocker. But your Applocker device config is gone… for now. The quickest way to get Applocker back working is to just simply run the scheduled tasks.
Or just trigger a device sync from your Company Portal
After a few minutes, you will notice the new working Applocker policy will be created inside the MDM folder.
The second issue:
We also encountered a very weird problem which can also be solved by following the steps to resolve the first issue.
We were asked to allow a KPN click to run application, so we allowed this KPN tool by adding a publisher rule to the app locker policy.
Of course we tested it on our test environment before we called the customer. On the device which really needed the KPN tool it didn’t worked.
We still received the famous block error
The eventlog showed us the same.
So, just like at the first issue I showed you we checked if this issue could be the same.
But instead of finding a not updated Applocker XML we noticed 2 applocker folders? One of them had the new settings, but the other one still had the old settings. Did you notice the timestamps?
Having 2 Applocker policies, fighting for the win will give you some weird behaviour.
Just like the first issue we deleted the Applocker folder and synced the device. Within a few minutes, a new Applocker policy arrived at the device and the KPN tool worked as it should.
Even when everything seems broken, you can still fix the problem by deleting the whole folder… click click deleted!