Merge pull request #986 from MicrosoftDocs/main

Publish main to live 07/19/2024, 3:30 PM

Author: garycentric

defender-endpoint/microsoft-defender-core-service-configurations-and-experimentation.md

@@ -7,7 +7,7 @@ author: YongRhee-MSFT
 ms.author: yongrhee
 manager: deniseb
 ms.localizationpriority: medium
-ms.date: 03/26/2024
+ms.date: 07/19/2024
 audience: ITPro
 ms.topic: troubleshooting
 ms.subservice: ngp
@@ -21,6 +21,9 @@ ms.collection:
 
 This article describes the interaction between Microsoft Defender Core Service and the Experimentation and Configuration Service (ECS). Microsoft Defender Core Service is a part of Microsoft Defender Antivirus and communicates with ECS to request and receive different kinds of payloads. These payloads include configurations, feature rollouts, and experiments. 
 
+> [!CAUTION]
+> If you disable communications with the service, this will affect Microsoft's ability to respond to a severe bug in a timely manner. 
+
 > [!IMPORTANT]
 > Make sure clients can access the following URLs so payloads can be received:
 >
@@ -31,27 +34,25 @@ This article describes the interaction between Microsoft Defender Core Service a
 >
 >Enterprise U.S. Government customers should allow the following URLs: 
 > - `*.events.data.microsoft.com` 
-> - `*.endpoint.security.microsoft.us (GCC-H & DoD)` 
-> - `*.gccmod.ecs.office.com (GCC-M) *.config.ecs.gov.teams.microsoft.us (GCC-H)` 
-> - `*.config.ecs.dod.teams.microsoft.us (DoD)` 
+> - `*.endpoint.security.microsoft.us (GCC-H & DoD)`
+> - `*.gccmod.ecs.office.com (GCC-M)` 
+>- `*.config.ecs.gov.teams.microsoft.us (GCC-H)`
+> - `*.config.ecs.dod.teams.microsoft.us (DoD)`
 
 > [!NOTE]
-> This applies to Microsoft Defender Antivirus platform update version [4.18.24030](microsoft-defender-antivirus-updates.md) or later. 
+> The information in this article applies to Microsoft Defender Antivirus platform update version [4.18.24030](microsoft-defender-antivirus-updates.md) or later. 
 
 ## Configurations
 
 Configurations are the payload meant to ensure product health, security, and privacy compliance, and are intended to have the same value for all the users (based on platforms and channels.) This could be to enable a feature flag for a domain action, and can also be used to disable a feature flag in the event of a bug. 
 
-## Controlled Feature Rollout
+## Controlled feature rollout
 
-Controlled Feature Rollout (CFR) is a procedure for slowly increasing the size of the user group that receives a feature. By distributing a new feature to a randomly selected subset of the user population, it's possible to compare user feedback to an equally sized control group without the feature to measure the impact of the feature. 
+Controlled feature rollout (CFR) is a procedure for slowly increasing the size of the user group that receives a feature. By distributing a new feature to a randomly selected subset of the user population, it's possible to compare user feedback to an equally sized control group without the feature to measure the impact of the feature. 
 
 ## Experiments 
 
-Microsoft Defender Core Service builds have features and functionality that are still in development or are experimental. Experiments are like CFR, but the size of the user group is much smaller for testing the new concept. These features are hidden by default until the feature's rolled out or the experiment's finished. Experiment flags are used to enable and disable these features. 
-
-> [!CAUTION]
-> If you disable communications with the service, this will affect Microsoft's ability to respond to a severe bug in a timely manner. 
+Currently, Microsoft Defender Core service doesn't do any experimental testing. Development is carried out via the [Gradual Rollout process](/defender-endpoint/manage-gradual-rollout#microsoft-gradual-rollout-model). If this changes, an announcement will be posted in the [Message Center](/microsoft-365/admin/manage/message-center). 
 
 ## See also 
 

defender-office-365/defender-for-office-365-whats-new.md

@@ -41,7 +41,7 @@ For more information on what's new with other Microsoft Defender security produc
 
 ## July 2024
 
-- **45 days after last used date**: The value **Remove allow entry after** \> **45 days after last used date** is now the default on new allow entries from submissions and existing allow entries in the [Tenant Allow/Block List](tenant-allow-block-list-about.md). The allow entry is triggered and the **LastUsedDate** property is updated when the entity is encountered and identified as malicious during mail flow or at time of click. After the filtering system determines that the entity is clean, and if the entity isn't submitted again, the allow entry is automatically removed after 45 days. By default, allow entries for spoofed senders never expire.
+- **45 days after last used date**: The value **Remove allow entry after** \> **45 days after last used date** is now the default on new allow entries from submissions and existing allow entries in the [Tenant Allow/Block List](tenant-allow-block-list-about.md). The allow entry is triggered and the **LastUsedDate** property is updated when the entity is encountered and identified as malicious during mail flow or at time of click. After the filtering system determines that the entity is clean, the allow entry is automatically removed after 45 days. By default, allow entries for spoofed senders never expire.
 
 - (GA) Learning hub resources have moved from the Microsoft Defender portal to [learn.microsoft.com](https://go.microsoft.com/fwlink/?linkid=2273118). Access Microsoft Defender XDR Ninja training, learning paths, training modules and more. Browse the [list of learning paths](/training/browse/?products=m365-ems-cloud-app-security%2Cdefender-for-cloud-apps%2Cdefender-identity%2Cm365-information-protection%2Cm365-threat-protection%2Cmdatp%2Cdefender-office365&expanded=m365%2Coffice-365), and filter by product, role, level, and subject. 
 

defender-office-365/submissions-admin.md

@@ -288,7 +288,7 @@ After a few moments, the block entry is available on the **URL** tab on the **Te
 
        For spoofed senders, this value is meaningless, because entries for spoofed senders never expire.
 
-       When **45 days after last used date** is selected, the last used date of the allow entry is updated when the malicious email message is encountered during mail flow. The allow entry is kept for 45 days after the filtering system determines that the email message is clean, and if the email message isn't submitted again.
+       When **45 days after last used date** is selected, the last used date of the allow entry is updated when the malicious email message is encountered during mail flow. The allow entry is kept for 45 days after the filtering system determines that the email message is clean.
 
      - **Allow entry note (optional)**: Enter optional information about why you're allowing this item. For spoofed senders, any value you enter here isn't shown in the allow entry on the **Spoofed senders** tab on the **Tenant Allow/Block Lists** page.
 
@@ -348,7 +348,7 @@ After a few moments, the associated allow entries appear on the **Domains & addr
        - **30 days**
        - **Specific date**: The maximum value is 30 days from today.
 
-       When **45 days after last used date** is selected, the last used date of the allow entry is updated when the malicious email attachment is encountered during mail flow. The allow entry is kept for 45 days after the filtering system determines that the email attachment is clean, and if the email attachment isn't submitted again.
+       When **45 days after last used date** is selected, the last used date of the allow entry is updated when the malicious email attachment is encountered during mail flow. The allow entry is kept for 45 days after the filtering system determines that the email attachment is clean.
 
      - **Allow entry note (optional)**: Enter optional information about why you're allowing this item.
 
@@ -406,7 +406,7 @@ For URLs reported as false positives, we allow subsequent messages that contain
        - **30 days**
        - **Specific date**: The maximum value is 30 days from today.
 
-       When **45 days after last used date** is selected, the last used date of the allow entry is updated when the malicious URL is encountered during mail flow. The allow entry is kept for 45 days after the filtering system determines that the URL is clean, and if the URL isn't submitted again.
+       When **45 days after last used date** is selected, the last used date of the allow entry is updated when the malicious URL is encountered during mail flow. The allow entry is kept for 45 days after the filtering system determines that the URL is clean.
 
      - **Allow entry note (optional)**: Enter optional information about why you're allowing this item.
 
@@ -1100,7 +1100,7 @@ In the **Submit to Microsoft for analysis** flyout that opens, do the following
         - **30 days**
         - **Specific date**: The maximum value is 30 days from today.
 
-       When **45 days after last used date** is selected, the last used date of the allow entry is updated when the malicious email message is encountered during mail flow. The allow entry is kept for 45 days after the filtering system determines that the email message is clean, and if the email message isn't submitted again.
+       When **45 days after last used date** is selected, the last used date of the allow entry is updated when the malicious email message is encountered during mail flow. The allow entry is kept for 45 days after the filtering system determines that the email message is clean.
 
       - **Allow entry note (optional)**: Enter optional information about why you're allowing this item. For spoofed senders, any value you enter here isn't shown in the allow entry on the **Spoofed senders** tab on the **Tenant Allow/Block Lists** page.
 

includes/allow-entry-facts.md

@@ -16,4 +16,4 @@ search.appverid: met150
 >
 > During mail flow or time of click, if messages containing the entities in the allow entries pass other checks in the filtering stack, the messages are delivered (all filters associated with the allowed entities are skipped). For example, if a message passes [email authentication checks](../defender-office-365/email-authentication-about.md), URL filtering, and file filtering, a message from an allowed sender email address is delivered if it's also from an allowed sender.
 >
-> By default, allow entries for [domains and email addresses](../defender-office-365/submissions-admin.md#report-good-email-to-microsoft), [files](../defender-office-365/submissions-admin.md#report-good-email-attachments-to-microsoft), and [URLs](../defender-office-365/submissions-admin.md#report-good-urls-to-microsoft) are kept for 45 days after the filtering system determines that the entity is clean. if the entity isn't submitted again, the allow entry is automatically removed after 45 days. Or you can set allow entries to expire up to 30 days after you create them. Allow entries for [spoofed senders](../defender-office-365/tenant-allow-block-list-email-spoof-configure.md#create-allow-entries-for-spoofed-senders) never expire.
+> By default, allow entries for [domains and email addresses](../defender-office-365/submissions-admin.md#report-good-email-to-microsoft), [files](../defender-office-365/submissions-admin.md#report-good-email-attachments-to-microsoft), and [URLs](../defender-office-365/submissions-admin.md#report-good-urls-to-microsoft) are kept for 45 days after the filtering system determines that the entity is clean, and then the allow entry is removed. Or you can set allow entries to expire up to 30 days after you create them. Allow entries for [spoofed senders](../defender-office-365/tenant-allow-block-list-email-spoof-configure.md#create-allow-entries-for-spoofed-senders) never expire.