踩坑，BUG，以及MDB和MDE之间的区别

ANY.LNK

在家里的机器上部署了一天的MDE后，除了ASR规则之外的绝大部分设置仍未同步下来，遂去寻找原因

结果折腾了一番后发现了如下内容：

MDB的简化设置默认自带了一套的配置，开箱即用，部署了之后相关设置即同步。相较之下，MDE的各种设置需要自己调

其一

在https://security.microsoft.com的门户Portal>Endpoints>Configuration Management>Endpoint Security Policies可以创建和编辑策略



但是没有那么简单，单纯的在这里配置好策略仅够让部分ASR规则生效，由于微软的神人设置，这里实际上是经由intune的设置项，还需要intune的参与才能将所有的配置同步过来。（大致如下图）



为此，我们还需要手动开启Intune-MDE设置强制实施的连接器

在门户的System>Settings>Endpoints下拉，找到Configuration Management>Enforcement scope，至少手动开启其中的Use MDE to enforce security configuration settings from Intune和Enable configuration management的Windows项



还要到intune里面把对应的设置打开



保存设置后，Defender连接器应在数分钟内变为启用状态，同时门户内的Assets>Devices里的设备Device Management一栏会由Unknown变为MDE



对应设置也会随之同步下来。


其二

部署本地的ATP时的篡改保护源默认为ATP（0x41），而如果在Endpoint Security Policies配置了另一层篡改保护，则源变为Intune（0x40）





其三

诸如Block Mode的EDR的设置在MDB里是默认开启配置好的，但MDE的这些设置都需要手动调

其四

MDB默认有邮件告警，MDE需要自己配置（Endpoint设置里的email notification一栏）

其五：其他和BUG

但在这些设置生效的同时，此前有效的ASR规则同时失效。我曾认为是配置了DisableLocalAdminMerge的原因，但更改此项后效果依旧。
2026.1.28更新：经过排查，问题出在这几条Not Applicable的规则上和Block executable files from running unless they meet a prevalence, age, or trusted list criterion这条规则上




通过Intune-MDE部署的微软的ASR规则（不包括受控文件夹访问）遵循“全或无”原则，当规则的任意之一部署失败，则全部失败。上述规则目前的Intune-MDE部署方式不可用，在尝试将其与其余规则一同设置时，将连带其余规则一同部署失败返回N/A错误。

在通过上述方式设置ASR时，需要注意将这几条特定的规则排除在外。此后，规则将部署成功。


此问题的解决方案同样适用于MDB。

allentong

我也用过MD的相关配置。怎么说呢，要想好用的话，要么就MDB的简化设置，直接开箱即用。如果要MDE-P1以上的话，最好配一个Intune许可管理，成本会高一点，不然配置会延迟生效（有那种迟钝的感觉）。Microsoft 365 F1含intune的一个月17，后来就用MDB了，感觉还行，属于简单够用的。哈哈哈