Interesting. I was playing with App Locker a little as well. Is the Application Identity service running? Maybe I enabled something that kicked off App Control to start working. I’m going to try and get it on a few more system today and early next week.
From: [email protected] [mailto:[email protected]] On Behalf Of Gannon, Todd Sent: Thursday, February 1, 2018 10:05 PM To: [email protected] Subject: [mssms] RE: Defender Application Control Hi – I am having similar issues with wdac. Using SCCM 1710 with the rollup, and W10 1709 Enterprise. The documentation says that for ISG to work, devices must be running WD SmartScreen for it to be trusted. It doesn’t say that it has to be set to warn or block specifically. Anyhow I didn’t have that configured via gp(default set to warn) – after configuring it to block it didn’t make too much of a difference. Still bricked the OS on reboot. I will continue testing. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of John Aubrey Sent: Friday, 2 February 2018 4:27 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: Defender Application Control I may have got it to work. I had Defender Smartscreen in audit only mode, and it was killing the system as soon as it picked up the policy. It seems it tried to scan the PC to create CI/Policies, failed, and FUBARED the PC. I moved Defender Smartscreen to Block mode, and it appears to be working. It’s gone through Program Files and is now scanning C:\Windows. It’s much further than it was before, so I think it’s working as intended. 1) Windows 10 1709 Enterprise, SCCM 1710 2) No app locker ever implemented, some basic SRP. 3) Machine wouldn’t boot if I tried to reboot. I’ll let you know how it goes. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Aaron Czechowski Sent: Thursday, February 1, 2018 2:14 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: Defender Application Control Dune is our resident expert on this, but he’s not on the list. I’ll proxy for him. 😊 First question: Windows client build and SCCM version Second question: did they have any applocker rules/policy set up before targeting WDAC? If yes to the second, they should try booting the machine from USB, decrypting the OS drive if necessary, deleting %WINDIR%\System32\Applocker\*.applocker and restart the machine. If machine restart is healthy then the problem is applocker, if not then the problem is code integrity. If that is the case I would want to see their %WINDIR%\CCM\logs\DeviceGuardHandler.log From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of John Aubrey Sent: Thursday, 1 February, 2018 10:17 To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: Defender Application Control Agreed. I was assuming that Microsoft’s Intelligent Security Graph would be smart enough to allow Microsoft’s EXE that are required to run windows to run by default. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Heaton, Joseph@Wildlife Sent: Thursday, February 1, 2018 11:21 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: Defender Application Control Well, if it blocks notepad, it has no way to read the text file. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of John Aubrey Sent: Thursday, February 1, 2018 5:22 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] Defender Application Control Has anyone used Defender Application Control policy in SCCM yet? I have a basic policy with the “Authorize software that is trusted by the Intelligent Security Graph” option enabled. Once my test PC checks in, notepad doesn’t work and if I reboot, the system is bricked and won’t boot. Says it can’t access a txt file that is used for event logs. I would have thought the Intelligent Security Graph option would at least let Windows boot….
