Merge pull request #293055 from MicrosoftDocs/main

1/15/2025 11:00 AM IST Publish

Author: PhilKang0704

articles/active-directory-b2c/tenant-management-emergency-access-account.md

@@ -85,7 +85,7 @@ Use the following steps to create an emergency access account:
 
 Once you create your emergency accounts, you need to do the following: 
 
-- Make sure you [exclude at least one account from phone-based multifactor authentication](../active-directory/roles/security-emergency-access.md#exclude-at-least-one-account-from-phone-based-multi-factor-authentication)
+- Make sure at least one of your emergency access accounts shouldn't have the same multifactor authentication mechanism as your other non-emergency accounts.
 
 - If you use [Conditional Access](conditional-access-user-flow.md), at least one emergency access account needs to be excluded from all conditional access policies.
 

articles/application-gateway/application-gateway-autoscaling-zone-redundant.md

@@ -30,7 +30,7 @@ Azure Application Gateways are always deployed in a highly available fashion. Th
 
 Even if you configure autoscaling with zero minimum instances the service is still highly available, which is always included with the fixed price.
 
-However, it’s important to note that provisioning a new instance may take approximately six to seven minutes. Understanding the scaling behavior of Application Gateway instances is key to maintaining performance under varying loads. These instances scale out in groups, and the group size is increased proactively when the current instance count is higher. This strategy allows the system to manage workload surges efficiently, preventing potential service disruptions or slowdowns. Each Azure Application Gateway instance can handle up to 10 Capacity Units. To optimize your autoscaling settings, consider your typical traffic patterns and set the minimum instances accordingly to ensure smooth operation.
+However, it’s important to note that provisioning a new instance may take approximately three to five minutes. Understanding the scaling behavior of Application Gateway instances is key to maintaining performance under varying loads. These instances scale out in groups, and the group size is increased proactively when the current instance count is higher. This strategy allows the system to manage workload surges efficiently, preventing potential service disruptions or slowdowns. Each Azure Application Gateway instance can handle up to 10 Capacity Units. To optimize your autoscaling settings, consider your typical traffic patterns and set the minimum instances accordingly to ensure smooth operation.
 
 For scale-in events, Application Gateway drains existing connections for 5 minutes on the instance that is subject for removal. After 5 minutes, existing connections are closed and the instance removed. Any new connections during or after the 5 minute scale-in time is established to other existing instances on the same gateway.
 

articles/application-gateway/high-traffic-support.md

@@ -44,7 +44,7 @@ Make sure to check your subnet size and available IP address count in your subne
 
 ### Set your minimum instance count based on your average Compute Unit usage
 
-For Application Gateway v2 SKU, autoscaling takes six to seven minutes to scale out and provision additional set of instances ready to take traffic. Until then, if there are short spikes in traffic, your existing gateway instances might get under stress and this may cause unexpected latency or loss of traffic. 
+For Application Gateway v2 SKU, autoscaling takes three to five minutes to scale out and provision additional set of instances ready to take traffic. Until then, if there are short spikes in traffic, your existing gateway instances might get under stress and this may cause unexpected latency or loss of traffic. 
 
 It's recommended that you set your minimum instance count to an optimal level. For example, if you require 50 instances to handle the traffic at peak load, then setting the minimum 25 to 30 is a good idea rather than at <10 so that even when there are short bursts of traffic, Application Gateway would be able to handle it and give enough time for autoscaling to respond and take effect.
 

articles/azure-app-configuration/concept-customer-managed-keys.md

@@ -78,6 +78,9 @@ After these resources are configured, use the following steps so that the Azure
     }
     ```
 
+    > [!NOTE]
+    > To create a user-assigned managed identity, follow this [tutorial](./overview-managed-identity.md#adding-a-user-assigned-identity).
+
 1. The managed identity of the Azure App Configuration instance needs access to the key to perform key validation, encryption, and decryption. The specific set of actions to which it needs access includes: `GET`, `WRAP`, and `UNWRAP` for keys. These permissions can be granted by assigning the `Key Vault Crypto Service Encryption User` role for Azure RBAC enabled Key Vaults. For Key Vaults using access policy authorization, set the policy for the aforementioned key permissions. Granting access requires the principal ID of the App Configuration instance's managed identity. Replace the value shown below as `contoso-principalId` with the principal ID obtained in the previous step. Grant permission to the managed key by using the command line:
 
     ### [Azure RBAC](#tab/azurerbac)
@@ -102,6 +105,11 @@ After these resources are configured, use the following steps so that the Azure
     az appconfig update -g contoso-resource-group -n contoso-app-config --encryption-key-name key-name --encryption-key-version key-version --encryption-key-vault key-vault-Uri
     ```
 
+    The command uses system-assigned managed identity to authenticate with the key vault by default. 
+
+    > [!NOTE]
+    > When using a user-assigned managed identity to access the customer managed key, you can specify its client ID explicitly by adding `--identity-client-id <client ID of your user assigned identity>` to the command.
+
 Your Azure App Configuration instance is now configured to use a customer-managed key stored in Azure Key Vault.
 
 ## Next Steps

articles/azure-cache-for-redis/cache-how-to-active-geo-replication.md

@@ -3,7 +3,7 @@ title: Configure active geo-replication for Enterprise Azure Cache for Redis ins
 description: Learn how to replicate your Azure Cache for Redis Enterprise instances across Azure regions.
 ms.custom: devx-track-azurecli, ignite-2024
 ms.topic: conceptual
-ms.date: 11/11/2024
+ms.date: 01/10/2025
 ---
 
 # Configure active geo-replication for Enterprise Azure Cache for Redis instances
@@ -62,7 +62,7 @@ To remove a cache instance from an active geo-replication group, you just delete
 
 In case one of the caches in your replication group is unavailable due to region outage, you can forcefully remove the unavailable cache from the replication group. After you apply **Force-unlink** to a cache, you can't sync any data that is written to that cache back to the replication group after force-unlinking.
 
-You should remove the unavailable cache because the remaining caches in the replication group start storing the metadata that hasn’t been shared to the unavailable cache. When this happens, the available caches in your replication group might run out of memory.
+You should remove the unavailable cache because the remaining caches in the replication group start storing the metadata that wasn't shared to the unavailable cache. When this happens, the available caches in your replication group might run out of memory.
 
 1. Go to Azure portal and select one of the caches in the replication group that is still available.
 
@@ -154,7 +154,7 @@ Let's say you want to scale up each instance in this geo-replication group to an
 
 At this point, the `Redis01` and `Redis02` instances can only scale up to an Enterprise E20 instance. All other scaling operations are blocked.
 >[!NOTE]
-> The `Redis00` instance is not blocked from scaling further at this point. But it will be blocked once either `Redis01` or `Redis02` is scaled to be an Enterprise E20.
+> The `Redis00` instance isn't blocked from scaling further at this point. But it's blocked once either `Redis01` or `Redis02` is scaled to be an Enterprise E20.
 >
 
 Once each instance is scaled to the same tier and size, all scaling locks are removed:
@@ -169,6 +169,41 @@ Due to the potential for inadvertent data loss, you can't use the `FLUSHALL` and
 
 :::image type="content" source="media/cache-how-to-active-geo-replication/cache-active-flush.png" alt-text="Screenshot showing Active geo-replication selected in the Resource menu and the Flush cache feature has a red box around it.":::
 
+## Geo-replication Metric
+
+The _Geo Replication Healthy_ metric in the Enterprise tier of Azure Cache for Redis helps monitor the health of geo-replicated clusters. You use this metric to monitor the sync status among geo-replicas.  
+
+To monitor the _Geo Replication Healthy_ metric in the Azure portal:
+
+1. Open the Azure portal and select your Azure Cache for Redis instance.
+
+1. On the Resource menu, select **Metrics** under the **Monitoring** section.
+
+1. Select **Add Metric** and select the **Geo Replication Healthy** metric.
+
+1. If needed, apply filters for specific geo-replicas.
+
+1. You can configure an alert to notify you if the **Geo replication Healthy** metric emits an unhealthy value (0) continuously for over 60 minutes.
+
+    1. Select **New Alert Rule**.
+
+    1. Define the condition to trigger if the metric value is 0 for at least 60 minutes, the recommended time.
+
+    1. Add action groups for notifications, for example: email, SMS, and others.
+
+    1. Save the alert.
+
+    1. For more information on how to setup alerts for you Redis Enterprise cache, see the alert section in [Monitor Redis Caches](/azure/azure-cache-for-redis/monitor-cache?tabs=enterprise-enterprise-flash).
+
+> [!IMPORTANT]
+> This metric might temporarily show as unhealthy due to routine operations like maintenance events or scaling, initiated either by Azure or the customer. To avoid false alarms, we recommend setting up an observation window of 60 minutes, where the metric continues to stay unhealthy as the appropriate time for generating an alert as it might indicate a problem that requires intervention.
+
+## Common Client-side issues that can cause sync issues among geo-replicas
+
+- Use of custom Hash tags – Using custom hashtags in Redis can lead to uneven distribution of data across shards, which might cause performance issues and synchronization problems in geo-replicas therefore avoid using custom hashtags unless the database needs to perform multiple key operations.
+
+- Large Key Size - Large keys can create synchronization issues among geo-replicas. To maintain smooth performance and reliable replication, we recommend keeping key sizes under 500MB when using geo-replication. If individual key size gets close to 2GB the cache faces geo-replication health issues.  
+
 ### Flush caches using Azure CLI or PowerShell
 
 The Azure CLI and PowerShell can also be used to trigger a flush operation. For more information on using Azure CLI, see [az redisenterprise database flush](/cli/azure/redisenterprise#az-redisenterprise-database-flush). For more information on using PowerShell, see [Invoke-AzRedisEnterpriseCacheDatabaseFlush](/powershell/module/az.redisenterprisecache/invoke-azredisenterprisecachedatabaseflush).