Merge pull request #310023 from MicrosoftDocs/main

Auto Publish – main to live - 2026-01-01 12:00 UTC

Author: learn-build-service-prod[bot]

articles/sentinel/move-to-defender.md

@@ -1,10 +1,10 @@
 ---
 title: Transition Your Microsoft Sentinel Environment to the Defender Portal
 description: Move Microsoft Sentinel operations from the Azure portal to the Microsoft Defender portal.
-author: batamig
-ms.author: bagol
+author: guywi-ms
+ms.author: guywild
 ms.topic: how-to #Required; leave this attribute/value as-is
-ms.date: 07/29/2025
+ms.date: 01/01/2026
 ms.collection: usx-security
 
 #Customer intent: As a security operations team member, I want to understand the process involved in moving our Microsoft Sentinel experience from the Azure portal to the Defender portal so that I can benefit from unified security operations across my entire environment.
@@ -260,6 +260,9 @@ Most functionalities of User and Entity Behavior Analytics (UEBA) remain the sam
 
 - After onboarding Microsoft Sentinel to the Defender portal, the `IdentityInfo` table used in the Defender portal includes unified fields from both Defender XDR and Microsoft Sentinel. Some fields that existed when used in the Azure portal are either renamed in the Defender portal, or aren't supported at all. We recommend that you check your queries for any references to these fields and update them as needed. For more information, see [IdentityInfo table](ueba-reference.md?tabs=unified-table#identityinfo-table).
 
+> [!IMPORTANT]
+> When you transition to the Defender portal, the `IdentityInfo` table becomes a native Defender table that doesn't support table-level role-based access control (RBAC). If your organization uses table-level RBAC to restrict access to the `IdentityInfo` table in the Azure portal, this access control will no longer be available after you transition to the Defender portal.
+
 ### Update investigation processes to use Microsoft Defender threat intelligence
 
 For Microsoft Sentinel customers moving from the Azure portal to the Defender portal, the familiar threat intelligence features are retained in the Defender portal under **Intel management**, and enhanced with other threat intelligence features available in the Defender portal. Supported features depend on the licenses you have, such as:
@@ -299,4 +302,3 @@ The Microsoft Sentinel [similar incidents](investigate-cases.md#similar-incident
 - [The Best of Microsoft Sentinel - now in Microsoft Defender](https://techcommunity.microsoft.com/blog/MicrosoftThreatProtectionBlog/the-best-of-microsoft-sentinel-%E2%80%94-now-in-microsoft-defender/4415822) (blog)
 - Watch the webinar: [Transition to the Unified SOC Platform: Deep Dive and Interactive Q&A for SOC Professionals](https://www.youtube.com/watch?v=WIM6fbJDkK4).
 - See frequently asked questions in the [TechCommunity blog](https://techcommunity.microsoft.com/blog/microsoftsentinelblog/unified-security-operations-platform---technical-faq/4189136) or the [Microsoft Community Hub](https://techcommunity.microsoft.com/blog/microsoftsentinelblog/frequently-asked-questions-about-the-unified-security-operations-platform/4212048).
-

articles/sentinel/normalization-about-parsers.md

@@ -17,7 +17,7 @@ Use Advanced Security Information Model (ASIM) parsers instead of table names in
 
 ## Unifying parsers
 
-When using ASIM in your queries, use **unifying parsers** to combine all sources, normalized to the same schema, and query them using normalized fields. The unifying parser name is `_Im_<schema>` for built-in parsers and `im<schema>` for workspace deployed parsers, where `<schema>` stands for the specific schema it serves.
+When using ASIM in your queries, use **unifying parsers** to combine all sources, normalized to the same schema, and query them using normalized fields. The unifying parser name is `_Im_<schema>`, where `<schema>` stands for the specific schema it serves.
 
 For example, the following query uses the built-in unifying DNS parser to query DNS events using the `ResponseCodeName`, `SrcIpAddr`, and `TimeGenerated` normalized fields:
 
@@ -35,21 +35,20 @@ _Im_Dns
   | summarize count() by SrcIpAddr, bin(TimeGenerated,15m)
 ```
 
-> [!NOTE]
-> When using the ASIM parsers in the **Logs** page, the time range selector is set to `custom`. You can still set the time range yourself. Alternatively, specify the time range using parser parameters.
->
-
 The following table lists the available unifying parsers:
 
 | Schema | Unifying parser | 
 | ------ | ------------------------- |
+| Alert Event | _Im_AlertEvent |
 | Audit Event | _Im_AuditEvent |
 | Authentication | _Im_Authentication | 
+| DHCP Event | _Im_DhcpEvent |
 | Dns | _Im_Dns |
 | File Event | _Im_FileEvent |
 | Network Session | _Im_NetworkSession | 
 | Process Event | _Im_ProcessCreate<br> _Im_ProcessTerminate |
-| Registry Event |  _Im_Registry |
+| Registry Event | _Im_RegistryEvent |
+| User Management | _Im_UserManagement |
 | Web Session | _Im_WebSession |  
 
 
@@ -59,15 +58,7 @@ Using parsers might affect your query performance, primarily from filtering the
 
 When invoking the parser, always use available filtering parameters by adding one or more named parameters to ensure optimal performance of the ASIM parsers.
 
-Each schema has a standard set of filtering parameters documented in the relevant schema documentation. Filtering parameters are entirely optional. The following schemas support filtering parameters:
-
-- [Audit Event](normalization-schema-audit.md)
-- [Authentication](normalization-schema-authentication.md)
-- [DNS](normalization-schema-dns.md#filtering-parser-parameters)
-- [Network Session](normalization-schema-network.md#filtering-parser-parameters)
-- [Web Session](normalization-schema-web.md#filtering-parser-parameters)
-
-Every schema that supports filtering parameters supports at least the `starttime` and `endtime` parameters and using them is often critical for optimizing performance.
+Each schema has a standard set of filtering parameters documented in the relevant schema documentation. Filtering parameters are entirely optional.
 
 For an example of using filtering parsers, see [Unifying parsers](#unifying-parsers). 
 

articles/sentinel/normalization-entity-device.md

@@ -8,7 +8,7 @@ ms.author: ofshezaf
 
 
 
-#Customer intent: As a security analyst, I want to understand the ASIM Device Entity so that I can accurately understand user information captured in normalized events, enabling consistent and comprehensive monitoring across security platforms and improving threat detection and response efforts.
+#Customer intent: As a security analyst, I want to understand the ASIM Device Entity so that I can accurately understand device information captured in normalized events, enabling consistent and comprehensive monitoring across security platforms and improving threat detection and response efforts.
 
 ---
 

articles/sentinel/normalization-modify-content.md

@@ -65,15 +65,7 @@ _Im_Dns(responsecodename='NXDOMAIN')
 | extend timestamp = TimeGenerated, IPCustomEntity = SrcIpAddr
 ```
 
-To use workspace-deployed ASIM parsers, replace the first line with the following code:
-
-```kusto
-imDns(responsecodename='NXDOMAIN')
-```
-
-### Differences between built-in and workspace-deployed parsers
-
-The two options in the example [above](#sample-normalization-for-analytics-rules) are functionally identical. The normalized, source-agnostic version has the following differences:
+The normalized, source-agnostic version has the following differences:
 
 - The `_Im_Dns` or `imDns`normalized parsers are used instead of the Infoblox Parser.
 

articles/sentinel/normalization-schema-alert.md

@@ -26,9 +26,7 @@ For more information about ASIM parsers, see the [ASIM parsers overview](normali
 
 ### Unifying Parsers
 
-To use parsers that unify all ASIM out-of-the-box parsers and ensure that your analysis runs across all the configured sources, use the `_Im_AlertEvent` filtering parser or the `_ASim_AlertEvent` parameter-less parser. You can also use workspace-deployed `imAlertEvent` and `ASimAlertEvent` parsers by deploying them from the [Microsoft Sentinel GitHub repository](https://aka.ms/DeployASIM).
-
-For more information, see [built-in ASIM parsers and workspace-deployed parsers](normalization-parsers-overview.md#built-in-asim-parsers-and-workspace-deployed-parsers).
+To use parsers that unify all ASIM out-of-the-box parsers and ensure that your analysis runs across all the configured sources, use the `_Im_AlertEvent` parser.
 
 ### Out-of-the-box, Source-specific Parsers
 

articles/sentinel/normalization-schema-dhcp.md

@@ -135,15 +135,15 @@ The source system is the system that requests a DHCP lease
 | **RuleNumber** | Optional | int | The number of the rule associated with the alert.<br><br>e.g. `123456` |
 | **RuleName** | Optional | string | The name or ID of the rule associated with the alert.<br><br>e.g. `Server PSEXEC Execution via Remote Access` |
 | **ThreatId** | Optional | string | The ID of the threat or malware identified in the alert.<br><br> e.g. `1234567891011121314` |
-| **ThreatName** | Optional | string | The name of the threat or malware identified in the alert.<br><br> e.g. `Init.exe` |
-| **ThreatFirstReportedTime** | Optional | Date/Time | Date and time when the threat was first reported.<br><br> e.g. `2024-09-19T10:12:10.0000000Z` |
-| **ThreatLastReportedTime** | Optional | Date/Time | Date and time when the threat was last reported.<br><br> e.g. `2024-09-19T10:12:10.0000000Z` |
 | **ThreatCategory** | Optional | String | 	The category of the threat or malware identified in the alert.<br><br>Supported values are: `Malware`, `Ransomware`, `Trojan`, `Virus`, `Worm`, `Adware`, `Spyware`, `Rootkit`, `Cryptominor`, `Phishing`, `Spam`, `MaliciousUrl`, `Spoofing`, `Security Policy Violation`, `Unknown` |
-| **ThreatIsActive** | Optional | bool | Indicates whether the threat is currently active.<br><br>Supported values are: `True`, `False` |
-| **ThreatRiskLevel** | Optional | RiskLevel (Integer) | The risk level associated with the threat. The level should be a number between 0 and 100.<br><br>Note: The value might be provided in the source record by using a different scale, which should be normalized to this scale. The original value should be stored in ThreatRiskLevelOriginal. |
-| **ThreatOriginalRiskLevel** | Optional | string | The risk level as reported by the originating system. |
+| **ThreatName** | Optional | string | The name of the threat or malware identified in the alert.<br><br> e.g. `Init.exe` |
 | **ThreatConfidence** | Optional | ConfidenceLevel (Integer) | The confidence level of the threat identified, normalized to a value between 0 and a 100. |
 | **ThreatOriginalConfidence** | Optional | string | The confidence level as reported by the originating system. |
+| **ThreatRiskLevel** | Optional | RiskLevel (Integer) | The risk level associated with the threat. The level should be a number between 0 and 100.<br><br>Note: The value might be provided in the source record by using a different scale, which should be normalized to this scale. The original value should be stored in ThreatRiskLevelOriginal. |
+| **ThreatOriginalRiskLevel** | Optional | string | The risk level as reported by the originating system. |
+| **ThreatIsActive** | Optional | bool | Indicates whether the threat is currently active.<br><br>Supported values are: `True`, `False` |
+| **ThreatFirstReportedTime** | Optional | Date/Time | Date and time when the threat was first reported.<br><br> e.g. `2024-09-19T10:12:10.0000000Z` |
+| **ThreatLastReportedTime** | Optional | Date/Time | Date and time when the threat was last reported.<br><br> e.g. `2024-09-19T10:12:10.0000000Z` |
 
 
 ### Schema updates

articles/sentinel/normalization-schema-web.md

@@ -49,9 +49,7 @@ For more information about ASIM parsers, see the [ASIM parsers overview](normali
 
 ### Unifying parsers
 
-To use parsers that unify all ASIM out-of-the-box parsers, and ensure that your analysis runs across all the configured sources, use the `_Im_WebSession` filtering parser or the `_ASim_WebSession` parameter-less parser.
-
-You can also use workspace-deployed `ImWebSession` and `ASimWebSession` parsers by deploying them from the [Microsoft Sentinel GitHub repository](https://aka.ms/DeployASIM). For more information, see [built-in ASIM parsers and workspace-deployed parsers](normalization-parsers-overview.md#built-in-asim-parsers-and-workspace-deployed-parsers).
+To use parsers that unify all ASIM out-of-the-box parsers, and ensure that your analysis runs across all the configured sources, use the `_Im_WebSession` parser.
 
 ### Out-of-the-box, source-specific parsers
 

articles/sentinel/ueba-reference.md

@@ -271,6 +271,9 @@ There are multiple versions of the *IdentityInfo* table:
 
     For more information on the unified version, see [IdentityInfo in the *Advanced hunting* documentation](/defender-xdr/advanced-hunting-identityinfo-table).
 
+> [!IMPORTANT]
+> When you transition to the Defender portal, the `IdentityInfo` table becomes a native Defender table that doesn't support table-level RBAC (Role-Based Access Control). If your organization uses table-level RBAC to restrict access to the `IdentityInfo` table in the Azure portal, this access control will no longer be available after you transition to the Defender portal.
+
 #### Schema
 
 The table in the following "Log Analytics schema" tab describes the user identity data included in the **IdentityInfo** table in Log Analytics in the Azure portal. 
@@ -421,4 +424,4 @@ This document described the Microsoft Sentinel entity behavior analytics table s
 
 - Learn more about [entity behavior analytics](identify-threats-with-entity-behavior-analytics.md).
 - [Enable UEBA in Microsoft Sentinel](enable-entity-behavior-analytics.md).
-- [Put UEBA to use](investigate-with-ueba.md) in your investigations.
+- [Put UEBA to use](investigate-with-ueba.md) in your investigations.