fixing blockers

Author: batamig

.openpublishing.redirection.sentinel.json

@@ -2,12 +2,12 @@
     "redirections": [
         {
             "source_path": "articles/sentinel/best-practices-workspace-architecture.md",
-            "redirect_url": "/azure-monitor/logs/workspace-design",
+            "redirect_url": "/azure/azure-monitor/logs/workspace-design",
             "redirect_document_id": false
         },
         {
             "source_path": "articles/sentinel/design-your-workspace-architecture.md",
-            "redirect_url": "/azure-monitor/logs/workspace-design",
+            "redirect_url": "/azure/azure-monitor/logs/workspace-design",
             "redirect_document_id": false
         },
         {

articles/azure-monitor/logs/cost-logs.md

@@ -57,8 +57,8 @@ See the documentation for different services and solutions for any unique billin
 In addition to the pay-as-you-go model, Log Analytics has *commitment tiers*, which can save you as much as 30 percent compared to the pay-as-you-go price. With commitment tier pricing, you can commit to buy data ingestion for a workspace, starting at 100 GB per day, at a lower price than pay-as-you-go pricing. Any usage above the commitment level (overage) is billed at that same price per GB as provided by the current commitment tier. (Overage is billed using the same commitment tier billing meter. For example if a workspace is in the 200 GB/day commitment tier and ingests 300 GB in a day, that usage is billed as 1.5 units of the 200 GB/day commitment tier.) The commitment tiers have a 31-day commitment period from the time a commitment tier is selected or changed.
 
 - During the commitment period, you can change to a higher commitment tier, which restarts the 31-day commitment period. You can't move back to pay-as-you-go or to a lower commitment tier until after you finish the commitment period.
-- At the end of the commitment period, the workspace retains the selected commitment tier, and the workspace can be moved to Pay-As-You-Go or to a lower commitment tier at any time.
-- If a workspace is inadvertently moved into a commitment tier, contact Microsoft Support to reset the commitment period so you can move back to the Pay-As-You-Go pricing tier.
+- At the end of the commitment period, the workspace retains the selected commitment tier, and the workspace can be moved to pay-as-you-go or to a lower commitment tier at any time.
+- If a workspace is inadvertently moved into a commitment tier, contact Microsoft Support to reset the commitment period so you can move back to the pay-as-you-go pricing tier.
 
 Billing for the commitment tiers is done per workspace on a daily basis. If the workspace is part of a [dedicated cluster](#dedicated-clusters), the billing is done for the cluster. See the following "Dedicated clusters" section. For a list of the commitment tiers and their prices, see [Azure Monitor pricing](https://azure.microsoft.com/pricing/details/monitor/).
 

articles/sentinel/prerequisites.md

@@ -27,7 +27,7 @@ Before deploying Microsoft Sentinel, make sure that your Azure tenant meets the
 
 - A [Log Analytics workspace](../azure-monitor/logs/quick-create-workspace.md) is required to house the data that Microsoft Sentinel ingests and analyzes for detections, analytics, and other features. For more information, see [Design a Log Analytics workspace architecture](/azure/azure-monitor/logs/workspace-design?toc=/azure/sentinel/TOC.json&bc=/azure/sentinel/breadcrumb/toc.json).
 
-- The Log Analytics workspace must not have a resource lock applied, and the workspace pricing tier must be Pay-as-You-Go or a commitment tier. Log Analytics legacy pricing tiers and resource locks aren't supported when enabling Microsoft Sentinel. For more information about pricing tiers, see [Simplified pricing tiers for Microsoft Sentinel](enroll-simplified-pricing-tier.md#prerequisites).
+- The Log Analytics workspace must not have a resource lock applied, and the workspace pricing tier must be pay-as-you-go or a commitment tier. Log Analytics legacy pricing tiers and resource locks aren't supported when enabling Microsoft Sentinel. For more information about pricing tiers, see [Simplified pricing tiers for Microsoft Sentinel](enroll-simplified-pricing-tier.md#prerequisites).
 
 - To reduce complexity, we recommend a dedicated [resource group](../azure-resource-manager/management/manage-resource-groups-portal.md) for your Log Analytics workspace enabled for Microsoft Sentinel. This resource group should only contain the resources that Microsoft Sentinel uses, including the Log Analytics workspace, any playbooks, workbooks, and so on.
 

articles/sentinel/resource-context-rbac.md

@@ -24,7 +24,7 @@ When users have access to Microsoft Sentinel data via the resources they can acc
 Enable resource-context RBAC in Azure Monitor. For more information, see [Manage access to log data and workspaces in Azure Monitor](../azure-monitor/logs/manage-access.md).
 
 > [!NOTE]
-> If your data is not an Azure resource, such as Syslog, CEF, or AAD data, or data collected by a custom collector, you'll need to manually configure the resource ID that's used to identify the data and enable access. For more information, see [Explicitly configure resource-context RBAC for non-Azure resources](#explicitly-configure-resource-context-rbac-for-non-azure-resources). 
+> If your data is not an Azure resource, such as Syslog, CEF, or Microsoft Entra ID data, or data collected by a custom collector, you'll need to manually configure the resource ID that's used to identify the data and enable access. For more information, see [Explicitly configure resource-context RBAC for non-Azure resources](#explicitly-configure-resource-context-rbac-for-non-azure-resources). 
 >
 > Additionally, [functions](../azure-monitor/logs/functions.md) and saved searches are not supported in resource-centric contexts. Therefore, Microsoft Sentinel features such as parsing and [normalization](normalization.md) are not supported for resource-context RBAC in Microsoft Sentinel.
 > 
@@ -145,7 +145,7 @@ The following list describes scenarios where other solutions for data access may
 |**A subsidiary has a SOC team that requires a full Microsoft Sentinel experience**.     |  In this case, use a multi-workspace architecture to separate your data permissions. <br><br>For more information, see: <ul><li>[Extend Microsoft Sentinel across workspaces and tenants](extend-sentinel-across-workspaces-tenants.md)<li>> [Work with incidents in many workspaces at once](multiple-workspace-view.md)          |
 |**You want to provide access to a specific type of event**.     |  For example, provide a Windows administrator with access to Windows Security events in all systems. <br><br>In such cases, use [table-level RBAC](https://techcommunity.microsoft.com/t5/azure-sentinel/table-level-rbac-in-azure-sentinel/ba-p/965043) to define permissions for each table.       |
 | **Limit access to a more granular level, either not based on the resource, or to only a subset of the fields in an event**   |   For example, you might want to limit access to Office 365 logs based on a user's subsidiary. <br><br>In this case, provide access to data using built-in integration with [Power BI dashboards and reports](../azure-monitor/logs/log-powerbi.md).      |
-| **Limit access by management group** | Place Microsoft Sentinel under a separate management group that's dedicated to security, ensuring that only minimal permissions are inherited to group memebers. Within your security team, assign permissions to different groups according to each group function. Since all teams have access to the entire workspace, they'll have access to the full Microsoft Sentinel experience, restricted only by the Microsoft Sentinel roles they're assigned. For more information, see [Permissions in Microsoft Sentinel](roles.md). |
+| **Limit access by management group** | Place Microsoft Sentinel under a separate management group that's dedicated to security, ensuring that only minimal permissions are inherited to group members. Within your security team, assign permissions to different groups according to each group function. Since all teams have access to the entire workspace, they'll have access to the full Microsoft Sentinel experience, restricted only by the Microsoft Sentinel roles they're assigned. For more information, see [Permissions in Microsoft Sentinel](roles.md). |
 
 
 

articles/sentinel/sample-workspace-designs.md

@@ -11,7 +11,7 @@ ms.date: 08/27/2024
 
 This article describes suggested Log Analytics workspace designs for organizations with the following sample requirements:
 
-- Multiple-tenants and regions, with European Data Sovereignty requirements
+- Multiple tenants and regions, with European Data Sovereignty requirements
 - Single tenant with multiple clouds
 - Multiple tenants, with multiple regions and centralized security
 
@@ -155,7 +155,7 @@ The suggested solution includes:
 
 ## Sample 3: Multiple tenants and regions and centralized security
 
-Adventure Works is a multinational company with headquarters in Tokyo. Adventure Works has 10 different sub-entities , based in different countries/regions around the world.
+Adventure Works is a multinational company with headquarters in Tokyo. Adventure Works has 10 different sub-entities, based in different countries/regions around the world.
 
 Adventure Works is Microsoft 365 E5 customer, and already has workloads in Azure.