Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr

Author: PatrickFarley

articles/api-management/api-management-howto-use-azure-monitor.md

@@ -7,7 +7,7 @@ author: dlepow
 ms.service: api-management
 ms.custom: engagement-fy23, devdivchpfy22
 ms.topic: tutorial
-ms.date: 06/27/2023
+ms.date: 05/15/2024
 ms.author: danlep
 ---
 # Tutorial: Monitor published APIs
@@ -179,7 +179,7 @@ For more information about using resource logs for API Management, see:
 
 ## Modify API logging settings
 
-By default, when you create a diagnostic setting to enable collection of resource logs, logging is enabled for all APIs, with default settings. You can adjust the logging settings for all APIs, or override them for individual APIs. For example, adjust the sampling rate or the verbosity of the data, or disable logging for some APIs.
+By default, when you create a diagnostic setting to enable collection of resource logs, logging is enabled for all APIs, with default settings. You can adjust the logging settings for all APIs, or override them for individual APIs. For example, adjust the sampling rate or the verbosity of the data, enable logging of headers or request or response payloads, or disable logging for some APIs.
 
 For details about the logging settings, see [Diagnostic logging settings reference](diagnostic-logs-reference.md).
 
@@ -188,14 +188,16 @@ To configure logging settings for all APIs:
 1. In the left menu of your API Management instance, select **APIs** > **All APIs**.
 1. Select the **Settings** tab from the top bar.
 1. Scroll down to the **Diagnostic Logs** section, and select the **Azure Monitor** tab.
-1. Review the settings and make changes if needed. Select **Save**.
+1. Review the settings and make changes if needed. Select **Save**. 
 
 To configure logging settings for a specific API:
 
 1. In the left menu of your API Management instance, select **APIs** and then the name of the API.
 1. Select the **Settings** tab from the top bar.
 1. Scroll down to the **Diagnostic Logs** section, and select the **Azure Monitor** tab.
-1. Review the settings and make changes if needed. Select **Save**.
+1. Review the settings and make changes if needed. Select **Save**. 
+
+[!INCLUDE [api-management-log-entry-size-limit](../../includes/api-management-log-entry-size-limit.md)]
 
 ## Next steps
 

articles/api-management/diagnostic-logs-reference.md

@@ -6,7 +6,7 @@ author: dlepow
 
 ms.service: api-management
 ms.topic: reference
-ms.date: 11/18/2022
+ms.date: 05/15/2024
 ms.author: danlep
 ms.custom: engagement-fy23
 ---
@@ -35,11 +35,13 @@ This reference describes settings for API diagnostics logging from an API Manage
 | Verbosity         |                                   | Specifies the verbosity of the logs and whether custom traces that are configured in [trace](trace-policy.md) policies are logged.    <br/><br/>* Error - failed requests, and custom traces of severity `error`<br/>* Information -  failed and successful requests, and custom traces of severity `error` and `information`<br/> * Verbose - failed and successful requests, and custom traces of severity `error`, `information`, and `verbose`<br/><br/>Default: Information  | 
 | Correlation protocol |  |  Specifies the protocol used to correlate telemetry sent by multiple components to Application Insights. Default: Legacy <br/><br/>For information, see [Telemetry correlation in Application Insights](../azure-monitor/app/distributed-tracing-telemetry-correlation.md).  |
 | Headers to log              | list                              | Specifies the headers that are logged for requests and responses.  Default: no headers are logged.                                                                                                                                                                                                             |
-| Number of payload bytes to log | integer                           | Specifies the number of initial bytes of the body that are logged for requests and responses. Maximum: 8,192. Default: 0                                                                                                                                                                                                   |
+| Number of payload (body) bytes to log| integer                           | Specifies the number of initial bytes of the frontend or backend request or response body that are logged. Maximum: 8,192. Default: 0                                                                                                                                                                                                |
 | Frontend Request  |                                   | Specifies whether and how *frontend requests* (requests incoming to the API Management gateway) are logged.<br/><br/> If this setting is enabled, specify **Headers to log**, **Number of payload bytes to log**, or both.                                                                                                                                                                        |
 | Frontend Response |                                   | Specifies whether and how *frontend responses* (responses outgoing from the API Management gateway) are logged.<br/><br/> If this setting is enabled, specify **Headers to log**, **Number of payload bytes to log**, or both.                                                                                                                                                                   |
 | Backend Request   |                                   | Specifies whether and how *backend requests* (requests outgoing from the API Management gateway) are logged.<br/><br/> If this setting is enabled, specify **Headers to log**, **Number of payload bytes to log**, or both.                                                                                                                                                                        |
-| Backend Response  |                                   | Specifies whether and how *backend responses* (responses incoming to the API Management gateway) are logged. <br/><br/> If this setting is enabled, specify **Headers to log**, **Number of payload bytes to log**, or both.                                                     
+| Backend Response  |                                   | Specifies whether and how *backend responses* (responses incoming to the API Management gateway) are logged. <br/><br/> If this setting is enabled, specify **Headers to log**, **Number of payload bytes to log**, or both.     
+
+[!INCLUDE [api-management-log-entry-size-limit](../../includes/api-management-log-entry-size-limit.md)]                                                
 
 ## Next steps
 

articles/azure-resource-manager/bicep/deployment-stacks.md

@@ -3,7 +3,7 @@ title: Create & deploy deployment stacks in Bicep
 description: Describes how to create deployment stacks in Bicep.
 ms.topic: conceptual
 ms.custom: devx-track-azurecli, devx-track-azurepowershell, devx-track-bicep
-ms.date: 05/14/2024
+ms.date: 04/11/2024
 ---
 
 # Deployment stacks
@@ -42,13 +42,6 @@ Deployment stacks provide the following benefits:
 - [What-if](./deploy-what-if.md) isn't available in the preview.
 - A management group-scoped stack is restricted from deploying to another management group. It can only deploy to the management group of the stack itself or to a child subscription.
 
-## Built-in roles
-
-There are two built-in roles for deployment stack:
-
-- **Azure Deployment Stack Contributor**: Allows users to manage deployment stacks, but cannot create or delete deny assignments within the deployment stacks.
-- **Azure Deployment Stack Owner**: Allows users to manage deployment stacks, including those with deny assignments.
-
 ## Create deployment stacks
 
 A deployment stack resource can be created at resource group, subscription, or management group scope. The template passed into a deployment stack defines the resources to be created or updated at the target scope specified for the template deployment.
@@ -599,16 +592,6 @@ To delete a managed resource, remove the resource definition from the underlying
 
 ## Protect managed resources against deletion
 
-When creating a deployment stack, it's possible to assign a specific type of permissions to the managed resources, which prevents their deletion by unauthorized security principals. These settings are referred to as deny settings. You want to store the stack at a parent scope.
-
-> [!NOTE]
-> The latest release requires specific permissions at the stack scope in order to:
->
-> - Create or update a deployment stack and set the deny setting to a value other than "None".
-> - Update or delete a deployment stack with an existing deny setting of something other than "None"
->
-> Use the [built-in roles](#built-in-roles) to grant the permissions.
-
 # [PowerShell](#tab/azure-powershell)
 
 The Azure PowerShell includes these parameters to customize the deny assignment:

articles/copilot/index.yml

@@ -88,10 +88,7 @@ conceptualContent:
               text: Generate Azure CLI scripts
             - url: ./generate-powershell-scripts.md
               itemType: get-started
-              text: Generate Azure PowerShell scripts
-            - url: ./optimize-code-application-insights.md
-              itemType: get-started
-              text: Discover performance recommendations with Code Optimizations
+              text: Generate PowerShell scripts
             - url: ./generate-kubernetes-yaml.md
               itemType: get-started
               text: Generate Kubernetes YAML files
@@ -101,3 +98,6 @@ conceptualContent:
             - url: ./troubleshoot-app-service.md
               itemType: get-started
               text: Troubleshoot deployed web apps
+            - url: ./optimize-code-application-insights.md
+              itemType: get-started
+              text: Discover recommendations with Code Optimizations

articles/copilot/overview.md

@@ -27,7 +27,7 @@ Microsoft Copilot for Azure (preview) is made available to customers under the t
 
 ## Manage access
 
-By default, Copilot for Azure is available to all users in a tenant. However, [Global Administrators](/entra/identity/role-based-access-control/permissions-reference#global-administrator) can choose to limit access to Copilot for Azure for their organization.
+By default, Copilot for Azure is available to all users in a tenant. However, [Global Administrators](/entra/identity/role-based-access-control/permissions-reference#global-administrator) can choose to control access to Copilot for Azure for their organization.
 
 For more information, see [Manage access to Microsoft Copilot for Azure](manage-access.md).
 

articles/cosmos-db/nosql/how-to-change-capacity-mode.md

@@ -6,8 +6,6 @@ author: richagaur
 ms.author: richagaur
 ms.service: cosmos-db
 ms.subservice: nosql
-ms.custom:
-  - build-2024
 ms.topic: how-to
 ms.date: 05/08/2024
 #Customer Intent: As an administrator, I want to change the capacity mode, so that I can migrate from serverless to provisioned capacity.
@@ -17,7 +15,8 @@ ms.date: 05/08/2024
 
 [!INCLUDE[NoSQL](../includes/appliesto-nosql.md)]
 
-Azure Cosmos DB for NoSQL accounts in serverless capacity mode can be changed to provisioned capacity mode. Changing from serverless to provisioned capacity mode converts all containers within the account to manual provisioned throughput containers in-place. The containers' throughput is determined according to the following formula: `Throughput(RU/s) = max(5000, StorageInGB * 10)`.
+Azure Cosmos DB for NoSQL accounts in serverless capacity mode can be changed to provisioned capacity mode. Changing from serverless to provisioned capacity mode converts all containers within the account to manual provisioned throughput containers in-place. The containers' throughput is determined according to the following formula: 
+            `Throughput(RU/s) = max(5000, number of partitions * 1000)`.
 
 You can also change the throughput or provisioning mode from manual to autoscale once the migration is complete.
 
@@ -33,26 +32,33 @@ You can also change the throughput or provisioning mode from manual to autoscale
 
 ## Register for preview
 
-To enable this feature, register for the preview feature **Change capacity mode (preview)** in your subscription. For more information, see [register for an Azure Cosmos DB preview feature](../access-previews.md).
+
+To enable this feature, register for the preview feature **Change capacity mode from serverless to provisioned throughput** in your subscription. For more information, see [register for an Azure Cosmos DB preview feature](../access-previews.md).
 
 ## Change capacity mode
 
 Follow these steps to change the capacity mode using Azure portal.
 
 1. In the Azure portal, navigate to your API for NoSQL account.
 
-1. Select the **Change** option associated with the **capacity mode** field in the **Overview** section of the account page.
+1. Select the **Change capacity mode to provisioned throughput** option in the **Overview** section of the account page.
 
 1. Review the changes and select **Confirm** to start the migration.
 
 1. Monitor the status using the **state** field in the **Overview** section. The status indicates that the account is **updating** while the migration is in progress.
 
-1. Once the migration is complete, the **capacity mode** field is now set to **provisioned capacity**.
+1. Once the migration is complete, the **capacity mode** field is now set to **provisioned throughput**.
+
+## Limitations
 
-> [!IMPORTANT]
-> There are no service level agreements (SLAs) associated with the duration of the capacity mode change. You cannot execute any management operation while the migration is in progress. However, the containers can be accessed as usual by any client application.
+- This is one time migration that is; the account can't be reversed to serverless capacity mode again.
+- There's no SLA associated with the duration of migration. 
+- Any management operation can't be executed while the migration is in progress.
+- In cases where you need to restore a deleted Cosmos DB account, the account is restored to provisioned throughput if the capacity mode was changed from serverless to provisioned, irrespective of the backup timestamp. 
+- In cases where you need to restore a deleted serverless container within an existing account, which was migrated from serverless to provisioned throughput, contact Microsoft support.
 
 ## Related content
 
 - [Chose between autoscale and manual throughput](../how-to-choose-offer.md).
 - [Choose between serverless and provisioned throughput](../throughput-serverless.md).
+