Group Policy Object
10 TopicsTamper Protection managed by administrator and OFF - cannot be enabled manually when joined on-prem
Hi all, We are currently only managing Microsoft Defender ATP via Group Policy and there is no GPO for tamper protection. But we cannot enable it manually either-. "This setting is managed by your administrator" and set tamper protection to OFF. When deploying a new Windows 10 I can enable it manually. When joining the computer to on-prem AD and GPO for Windows Defender ATP hits, temper protection is turned off and you cannot change it. Is this by design or is there a GPO setting interfering? Thanks!52KViews2likes13CommentsActive Directory DFSR headache
We have 23 DC's, all but one of which are 2012R2. The one-off, I upgraded a couple weeks ago directly from 2012R2 to 2019. For the past year or two we've had 2 DC's that weren't doing SYSVOL replication. I thought I had fixed that before I started with the process of getting them upgraded to 2019, but now that I've done one server, it looks like I was incorrect. So here's what's driving me nuts. Using the "status" tab of the Group Policy Management MMC, things are either horribly FUBAR, or humming along perfectly, depending (apparently) on the OS of the computer I'm running the MMC from. If I run it from a Windows 10 workstation or the Server 2019 DC, things look bad. I show 15 servers with replication "in progress", of which 13 show a status under the SYSVOL column of "Inaccessible", and 2 show a "Contents" issue with a single GPO. If I run the MMC from the 2012R2 DCs or from a Win 8.1 VM I spun up on a hunch, I show all 22 DCs in perfect sync (both AD and SYSVOL) with the baseline DC. When I use a file/folder comparison tool on the contents of the SYSVOL folder for each DC, not one of them matches the contents on the PDC. Although there are no "orphaned" files or folders, the date modified doesn't match on a varying number of files and/or folders for each DC (sometimes off by years). The closest is actually the 2019 DC, which only shows mismatches on the contents of 3 GPOs. The DFSR event logs don't show any regularly occurring errors other than losing replication for a bit between DCs when one goes down for system state backup. I ran a dcdiag /a /c, and didn't see any errors in there aside from the DFS test failing due to the above-mentioned errors caused by backups, some system event log errors due to a deleted computer account, and one DC had a typo in the secondary DNS entry on its network adapter settings. There are also no errors when I run repadmin /showrepl. I've tried running both non-authoritative and authoritative replications using the instructions https://docs.microsoft.com/en-us/troubleshoot/windows-server/group-policy/force-authoritative-non-authoritative-synchronization, and neither made any difference at all. Any suggestions?Solved1.7KViews1like3Comments