Merge pull request #287011 from batamig/more-laa

removing laa

Author: v-dirichards

articles/sentinel/ama-migrate.md

@@ -1,65 +1,55 @@
 ---
-title: Migrate to the Azure Monitor agent (AMA) from the Log Analytics agent (MMA/OMS) for Microsoft Sentinel
-description: Learn about migrating from the Log Analytics agent (MMA/OMS) to the Azure Monitor agent (AMA), when working with Microsoft Sentinel.
+title: Migrate to the Azure Monitor Agent (AMA) from the Log Analytics agent (MMA/OMS) for Microsoft Sentinel
+description: Learn about migrating from the Log Analytics agent (MMA/OMS) to the Azure Monitor Agent (AMA), when working with Microsoft Sentinel.
 author: yelevin
 ms.topic: reference
-ms.date: 04/03/2024
+ms.date: 10/01/2024
 ms.author: yelevin
 ---
 
 # AMA migration for Microsoft Sentinel
-This article describes the migration process to the Azure Monitor Agent (AMA) when you have an existing Log Analytics Agent (MMA/OMS), and are working with Microsoft Sentinel. 
 
-> [!IMPORTANT]
-> The Log Analytics agent will be [retired on **31 August, 2024**](https://azure.microsoft.com/updates/were-retiring-the-log-analytics-agent-in-azure-monitor-on-31-august-2024/). If you are using the Log Analytics agent in your Microsoft Sentinel deployment, we recommend that you start planning your migration to the AMA.
+This article describes the migration process to the Azure Monitor Agent (AMA) when you have an existing, legacy [Log Analytics Agent (MMA/OMS)](/azure/azure-monitor/agents/log-analytics-agent), and are working with Microsoft Sentinel.
 
-## Prerequisites
-Start with the [Azure Monitor documentation](/azure/azure-monitor/agents/azure-monitor-agent-migration) which provides an agent comparison and general information for this migration process. 
-
-This article provides specific details and differences for Microsoft Sentinel.
-
-
-## Gap analysis between agents
+The Log Analytics agent is [retired as of 31 August, 2024](https://azure.microsoft.com/updates/were-retiring-the-log-analytics-agent-in-azure-monitor-on-31-august-2024/). If you are using the Log Analytics agent in your Microsoft Sentinel deployment, we recommend that you migrate to the AMA.
 
-The Azure Monitor agent provides extra functionality and a throughput that is 25% better than legacy Log Analytics agents. Migrate to the new AMA connectors to get higher performance, especially if you are using your servers as log forwarders for Windows security events or forwarded events.
-
-The Azure Monitor agent provides the following extra functionality, which is not supported by legacy Log Analytics agents:
+## Prerequisites
 
-| Log type | Functionality |
-| --- |---|
-| **Windows logs** | Filtering by security event ID <br>Windows event forwarding |
-| **Linux logs** | Multi-homing | 
+- Start with the [Azure Monitor documentation](/azure/azure-monitor/agents/azure-monitor-agent-migration), which provides an agent comparison and general information for this migration process. This article provides specific details and differences for Microsoft Sentinel.
 
-The only logs supported only by the legacy Log Analytics agent are Windows Firewall logs.
 
 ## Recommended migration plan
 
 Each organization will have different metrics of success and internal migration processes. This section provides suggested guidance to consider when migrating from the Log Analytics MMA/OMS agent to the AMA, specifically for Microsoft Sentinel.
 
 **Include the following steps in your migration process**:
 
-1. Make sure that you've reviewed necessary prerequisites and other considerations as [documented here](/azure/azure-monitor/agents/azure-monitor-agent-migration#before-you-begin) in the Azure Monitor documentation.
+1. Make sure that you've reviewed necessary prerequisites and other considerations as documented in the Azure Monitor documentation. For more information, see [Before you begin](/azure/azure-monitor/agents/azure-monitor-agent-migration#before-you-begin).
 
 1. Run a proof of concept to test how the AMA sends data to Microsoft Sentinel, ideally in a development or sandbox environment.
 
-    1. To connect your Windows machines to the [Windows Security Event connector](data-connectors/windows-security-events-via-ama.md), start with **Windows Security Events via AMA** data connector page in Microsoft Sentinel. For more information, see [Windows agent-based connections](connect-services-windows-based.md).
+    1. In Microsoft Sentinel, install the **Windows Security Events** Microsoft Sentinel solution. For more information, see [Discover and manage Microsoft Sentinel out-of-the-box content](sentinel-solutions-deploy.md).
+
+    1. To connect your Windows machines to the [Windows Security Event connector](data-connectors/windows-security-events-via-ama.md), start with the **Windows Security Events via AMA** data connector page in Microsoft Sentinel. For more information, see [Windows agent-based connections](connect-services-windows-based.md).
 
-    1. Go to the **Security Events via Legacy Agent** data connector page. On the **Instructions** tab, under **Configuration** > Step 2, **Select which events to stream**, select **None**. This configures your system so that you won't receive any security events through the MMA/OMS, but other data sources relying on this agent will continue to work. This step affects all machines reporting to your current Log Analytics workspace.
+    1. Continue with the **Security Events via Legacy Agent** data connector page. On the **Instructions** tab, under **Configuration** > **Step 2** > **Select which events to stream**, select **None**. This configures your system so that you won't receive any security events through the MMA/OMS, but other data sources relying on this agent will continue to work. This step affects all machines reporting to your current Log Analytics workspace.
 
     > [!IMPORTANT]
-    > Ingesting data from the same source using two different types of agents will result in double ingestion charges and duplicate events in the Microsoft Sentinel workspace. 
+    > Ingesting data from the same source using two different types of agents will result in double ingestion charges and duplicate events in the Microsoft Sentinel workspace.
     >
     > If you need to keep both data connectors running simultaneously, we recommend that you do so only for a limited time for a benchmarking, or test comparison activity, ideally in a separate test workspace.
     >
 
-1. Measure the success of your proof of concept. 
+1. Measure the success of your proof of concept.
 
     To help with this step, use the **AMA migration tracker** workbook, which displays the servers reporting to your workspaces, and whether they have the legacy MMA, the AMA, or both agents installed. You can also use this workbook to view the DCRs collecting events from your machines, and which events they are collecting.
 
-    For example:
+    Make sure to select you subscription and resource group at the top of the workbook to show data for your environment. For example:
 
     :::image type="content" source="media/ama-migrate/migrate-workbook.png" alt-text="Screenshot of the AMA migration tracker workbook." lightbox="media/ama-migrate/migrate-workbook.png" :::
 
+    For more information, see [Visualize and monitor your data by using workbooks in Microsoft Sentinel](monitor-your-data.md).
+
     Success criteria should include a statistical analysis and comparison of the quantitative data ingested by the MMA/OMS and AMA agents on the same host:
 
     - Measure your success over a predefined time period that represents a normal workload for your environment.
@@ -68,39 +58,22 @@ Each organization will have different metrics of success and internal migration
 
     - Plan your rollout for AMA agents in your production environment according to your organization's risk profile and change processes.
 
-3. Roll out the new agent on your production environment and run a final test of the AMA functionality.
+1. Roll out the new agent on your production environment and run a final test of the AMA functionality.
 
-4. Disconnect any data connectors that rely on the legacy connector, such as Security Events with MMA. Leave the new connector, such as Windows Security Events with AMA, running.
+1. Disconnect any data connectors that rely on the legacy connector, such as Security Events with MMA. Leave the new connector, such as Windows Security Events with AMA, running.
 
     While you can have both the legacy MMA/OMS and the AMA agents running in parallel, prevent duplicate costs and data by making sure that each data source uses only one agent to send data to Microsoft Sentinel.
 
-5. Check your Microsoft Sentinel workspace to make sure that all your data streams have been replaced using the new AMA-based connectors.
-
-6. Uninstall the legacy agent. For more information, see [Manage the Azure Log Analytics agent ](/azure/azure-monitor/agents/agent-manage#uninstall-agent).
-
-## FAQs
-The following FAQs address issues specific to AMA migration with Microsoft Sentinel. For more information, see [Frequently asked questions for Azure Monitor Agent](/azure/azure-monitor/agents/agents-overview#frequently-asked-questions) in the Azure Monitor documentation.
-  
-## What happens if I run both MMA/OMS and AMA in parallel in my Microsoft Sentinel deployment?
-Both the AMA and MMA/OMS agents can co-exist on the same machine. If they both send data, from the same data source to a Microsoft Sentinel workspace, at the same time, from a single host, duplicate events and double ingestion charges will occur.
-
-For your production rollout, we recommend that you configure either an MMA/OMS agent or the AMA for each data source. To address any issues for duplication, see the relevant FAQs in the [Azure Monitor documentation](/azure/azure-monitor/agents/agents-overview#frequently-asked-questions).
-
-## The AMA doesn’t yet have the features my Microsoft Sentinel deployment needs to work. Should I migrate yet?
-The legacy Log Analytics agent will be retired on 31 August 2024.
-
-We recommend that you keep up to date with the new features being released for the AMA over time, as it reaches towards parity with the MMA/OMS. Aim to migrate as soon as the features you need to run your Microsoft Sentinel deployment are available in the AMA.
-
-While you can run the MMA and AMA simultaneously, you may want to migrate each connector, one at a time, while running both agents.
+1. Check your Microsoft Sentinel workspace to make sure that all your data streams have been replaced using the new AMA-based connectors.
 
+1. Uninstall the legacy agent. For more information, see [Manage the Azure Log Analytics agent](/azure/azure-monitor/agents/agent-manage#uninstall-agent).
 
+For your production rollout, we recommend that you configure the AMA for each data source. To address any issues for duplication, see the relevant FAQs in the [Azure Monitor documentation](/azure/azure-monitor/agents/agents-overview#frequently-asked-questions).
 
-## Next steps
+## Related content
 
 For more information, see:
 
-- [Overview of the Azure Monitor agents](/azure/azure-monitor/agents/agents-overview)
+- [Overview of the Azure Monitor Agents](/azure/azure-monitor/agents/agents-overview)
 - [Migrate from Log Analytics agents](/azure/azure-monitor/agents/azure-monitor-agent-migration)
-- [Windows Security Events via AMA](data-connectors/windows-security-events-via-ama.md)
-- [Security events via Legacy Agent (Windows)](data-connectors/security-events-via-legacy-agent.md)
 - [Windows agent-based connections](connect-services-windows-based.md)

articles/sentinel/billing-reduce-costs.md

@@ -88,9 +88,9 @@ You can reduce costs even further by enrolling tables that contain secondary sec
 
 ## Use data collection rules for your Windows Security Events
 
-The [Windows Security Events connector](connect-windows-security-events.md?tabs=LAA) enables you to stream security events from any computer running Windows Server that's connected to your Microsoft Sentinel workspace, including physical, virtual, or on-premises servers, or in any cloud. This connector includes support for the Azure Monitor agent, which uses data collection rules to define the data to collect from each agent.
+The [Windows Security Events connector](connect-windows-security-events.md?tabs=LAA) enables you to stream security events from any computer running Windows Server that's connected to your Microsoft Sentinel workspace, including physical, virtual, or on-premises servers, or in any cloud. This connector includes support for the Azure Monitor Agent, which uses data collection rules to define the data to collect from each agent.
 
-Data collection rules enable you to manage collection settings at scale, while still allowing unique, scoped configurations for subsets of machines. For more information, see [Configure data collection for the Azure Monitor agent](/azure/azure-monitor/agents/azure-monitor-agent-data-collection).
+Data collection rules enable you to manage collection settings at scale, while still allowing unique, scoped configurations for subsets of machines. For more information, see [Configure data collection for the Azure Monitor Agent](/azure/azure-monitor/agents/azure-monitor-agent-data-collection).
 
 Besides for the predefined sets of events that you can select to ingest, such as All events, Minimal, or Common, data collection rules enable you to build custom filters and select specific events to ingest. The Azure Monitor Agent uses these rules to filter the data at the source, and then ingest only the events you selected, while leaving everything else behind. Selecting specific events to ingest can help you optimize your costs and save more.
 

articles/sentinel/configure-connector-login-detection.md

@@ -34,4 +34,3 @@ As the machine learning algorithm requires 30 days' worth of data to build a bas
 
 - [Windows security event sets that can be sent to Microsoft Sentinel](windows-security-event-id-reference.md)
 - [Windows Security Events via AMA connector for Microsoft Sentinel](data-connectors/windows-security-events-via-ama.md)
-- [Security Events via Legacy Agent connector for Microsoft Sentinel](data-connectors/security-events-via-legacy-agent.md)

articles/sentinel/configure-data-transformation.md

@@ -35,12 +35,11 @@ Before you start configuring DCRs for data transformation:
 | If you are ingesting | Ingestion-time transformation is... | Use this DCR type |
 | -------------------- | ---------------------------- | ----------------- |
 | **Custom data** through <br>the [**Log Ingestion API**](/azure/azure-monitor/logs/logs-ingestion-api-overview) | <li>Required<li>Included in the DCR that defines the data model | Standard DCR |
-| **Built-in data types** <br>(Syslog, CommonSecurityLog, WindowsEvent, SecurityEvent) <br>using the legacy **Log Analytics Agent (MMA)** | <li>Optional<li>If desired, added to the DCR attached to the Workspace where this data is being ingested | Workspace transformation DCR |
+| **Built-in data types** <br>(Syslog, CommonSecurityLog, WindowsEvent, SecurityEvent) <br>using the Azure Monitor Agent | <li>Optional<li>If desired, added to the DCR that configures how this data is being ingested | Standard DCR |
 | **Built-in data types** <br>from most other sources | <li>Optional<li>If desired, added to the DCR attached to the Workspace where this data is being ingested | Workspace transformation DCR |
 
 
 
-
 ## Configure your data transformation
 
 Use the following procedures from the Log Analytics and Azure Monitor documentation to configure your data transformation DCRs:
@@ -81,4 +80,4 @@ For more information about data transformation and DCRs, see:
 - [Data collection transformations in Azure Monitor Logs (preview)](/azure/azure-monitor/essentials/data-collection-transformations)
 - [Logs ingestion API in Azure Monitor Logs (Preview)](/azure/azure-monitor/logs/logs-ingestion-api-overview)
 - [Structure of a data collection rule in Azure Monitor (preview)](/azure/azure-monitor/essentials/data-collection-rule-structure)
-- [Configure data collection for the Azure Monitor agent](/azure/azure-monitor/agents/azure-monitor-agent-data-collection)
+- [Configure data collection for the Azure Monitor Agent](/azure/azure-monitor/agents/azure-monitor-agent-data-collection)

articles/sentinel/connect-azure-virtual-desktop.md

@@ -17,9 +17,11 @@ For example, monitoring your Azure Virtual Desktop environments can enable you t
 
 Azure Virtual Desktop data in Microsoft Sentinel includes the following types:
 
+
+
 |Data  |Description  |
 |---------|---------|
-|**Windows event logs**     |  Windows event logs from the Azure Virtual Desktop environment are streamed into a Microsoft Sentinel-enabled Log Analytics workspace in the same manner as Windows event logs from other Windows machines, outside of the Azure Virtual Desktop environment. <br><br>Install the Log Analytics agent onto your Windows machine and configure the Windows event logs to be sent to the Log Analytics workspace.<br><br>For more information, see:<br>- [Install Log Analytics agent on Windows computers](/azure/azure-monitor/agents/agent-windows)<br>- [Collect Windows event log data sources with Log Analytics agent](/azure/azure-monitor/agents/data-sources-windows-events)<br>- [Connect Windows security events](connect-windows-security-events.md)       |
+|**Windows event logs**     |  Windows event logs from the Azure Virtual Desktop environment are streamed into a Microsoft Sentinel-enabled Log Analytics workspace in the same manner as Windows event logs from other Windows machines, outside of the Azure Virtual Desktop environment. <br><br>Install the Azure Monitor Agent onto your Windows machine and configure the Windows event logs to be sent to the Log Analytics workspace.<br><br>For more information, see:<br>- [Install Azure Monitor Agent on Windows client devices using the client installer](/azure/azure-monitor/agents/azure-monitor-agent-windows-client)<br>- [Collect Windows events with Azure Monitor Agent](/azure/azure-monitor/agents/data-collection-windows-events)<br>- [Windows Security Events via AMA connector for Microsoft Sentinel](data-connectors/windows-security-events-via-ama.md)    |
 |**Microsoft Defender for Endpoint alerts**     |  To configure Defender for Endpoint for Azure Virtual Desktop, use the same procedure as you would for any other Windows endpoint. <br><br>For more information, see: <br>- [Set up Microsoft Defender for Endpoint deployment](/windows/security/threat-protection/microsoft-defender-atp/production-deployment)<br>- [Connect data from Microsoft Defender XDR to Microsoft Sentinel](connect-microsoft-365-defender.md)       |
 |**Azure Virtual Desktop diagnostics**     | Azure Virtual Desktop diagnostics is a feature of the Azure Virtual Desktop PaaS service, which logs information whenever someone assigned Azure Virtual Desktop role uses the service. <br><br>Each log contains information about which Azure Virtual Desktop role was involved in the activity, any error messages that appear during the session, tenant information, and user information. <br><br>The diagnostics feature creates activity logs for both user and administrative actions. <br><br>For more information, see [Use Log Analytics for the diagnostics feature in Azure Virtual Desktop](../virtual-desktop/virtual-desktop-fall-2019/diagnostics-log-analytics-2019.md).        |