fixed broken links

Author: flang-msft

articles/redis/best-practices-connection.md

@@ -72,14 +72,6 @@ If you're reconnecting many client instances, consider staggering the new connec
 
 Caches have limits on the number of client connections per cache tier. Ensure that when your client application recreates connections that it closes and removes the old connections.
 
-<!-- ## Advance maintenance notification -->
-<!-- FXL - check with Umang if this is ok. -->
-<!-- Use notifications to learn of upcoming maintenance. For more information, see [Can I be notified in advance of a planned maintenance](failover.md#can-i-be-notified-in-advance-of-maintenance). -->
-
-## Schedule maintenance window
-
-Adjust your cache settings to accommodate maintenance. For more information about creating a maintenance window to reduce any negative effects to your cache, see [Update channel and Schedule updates](administration.md#update-channel-and-schedule-updates).
-
 ## More design patterns for resilience
 
 Apply design patterns for resiliency. For more information, see [How do I make my application resilient](failover.md#how-do-i-make-my-application-resilient).

articles/redis/best-practices-server-load.md

@@ -46,10 +46,6 @@ The **Server Load** metric represents the load on the Redis Server alone. We rec
 
 When monitoring server load, we also recommend that you examine the max spikes of Server Load rather than average because even brief spikes can trigger failovers and command timeouts.
 
-## Plan for server maintenance
-
-Ensure you have enough server capacity to handle your peak load while your cache servers are undergoing maintenance. Test your system by rebooting nodes while under peak load. For more information on how to simulate deployment of a patch, see [reboot](administration.md#reboot).
-
 ## Test for increased server load after failover
 
 For standard and premium SKUs, each cache is hosted on two nodes. A load balancer distributes the client connections to the two nodes. When planned or unplanned maintenance occurs on the primary node, the node closes all the client connections. In such situations, all client connections could land on a single node causing the server load to increase on the one remaining node. We recommend testing this scenario by rebooting the primary node and ensuring that one node can handle all your client connections without the server load going too high.

articles/redis/failover.md

@@ -113,14 +113,6 @@ Refer to these design patterns to build resilient clients, especially the circui
 - [Retry guidance for Azure services - Best practices for cloud applications](/azure/architecture/best-practices/retry-service-specific)
 - [Implement retries with exponential backoff](/dotnet/architecture/microservices/implement-resilient-applications/implement-retries-exponential-backoff)
 
-<!-- To test a client application's resiliency, use a [reboot](administration.md#reboot) as a manual trigger for connection breaks. -->
-
-<!-- Additionally, we recommend that you use scheduled updates to choose an update channel and a maintenance window for your cache to apply Redis runtime patches during specific weekly windows. These windows are typically periods when client application traffic is low, to avoid potential incidents. For more information, see [Update channel and Schedule updates](administration.md#update-channel-and-schedule-updates). -->
-
-<!-- For more information, see [Connection resilience](best-practices-connection.md). -->
-
 ## Related content
 
-<!-- - [Update channel and Schedule updates](administration.md#update-channel-and-schedule-updates) -->
-<!-- - Test application resiliency by using a [reboot](administration.md#reboot) -->
 - [Connection resilience](best-practices-connection.md)

articles/redis/how-to-manage-redis-cache-powershell.md

@@ -1526,7 +1526,7 @@ The following command exports data from an Azure Cache for Redis instance into t
 You can reboot your Azure Cache for Redis instance using the `Reset-AzRedisCache` cmdlet.
 
 > [!IMPORTANT]
-> Reboot is only available for [Basic, Standard, and Premium tier]/azure-cache-for-redis/cache-overview.md#service-tiers) caches. For more information about rebooting your cache, see [Cache administration - reboot]/azure-cache-for-redis/cache-administration.md#reboot).
+> Reboot is only available for Basic, Standard, and Premium tier caches in Azure Cache for Redis. It is not available for Azure Managed Redis. For more information about rebooting your Azure Cache for Redis instances, see [Cache administration - reboot](/azure/azure-cache-for-redis/cache-administration.md#reboot).
 >
 >
 

articles/redis/how-to-scale.md

@@ -141,7 +141,6 @@ The following list contains answers to commonly asked questions about Azure Mana
   [How many shards does each Azure Managed Redis SKU use?](#how-many-shards-does-each-azure-managed-redis-sku-use)
 - [How are keys distributed in a cluster?](#how-are-keys-distributed-in-a-cluster)
 - [What is the largest cache size I can create?](#what-is-the-largest-cache-size-i-can-create)
-- [What is the difference between the OSS and Enterprise cluster policies?](#what-is-the-difference-between-the-oss-and-enterprise-cluster-policies)
 
 ### Can I scale within or across tiers?
 
@@ -150,7 +149,7 @@ You can always scale to a higher performance tier at the same memory size or a l
 
 ### What will happen to my data if I scale to smaller memory size?
 
-You can scale to a smaller memory size only if the current memory usage is less than the intended smaller memory size. If the current memory usage is higher than the intended smaller size, your scaling request will fail. You can reduce the current memory usage by deleted unwanted key value pairs or by running the flush operation. 
+You can scale to a smaller memory size only if the current memory usage is less than the intended smaller memory size. If the current memory usage is higher than the intended smaller size, your scaling request will fail. You can reduce the current memory usage by deleted unwanted key value pairs or by running the flush operation.
 
 <!-- (Add link) -->
 

articles/redis/overview.md

@@ -106,7 +106,6 @@ The following table helps describe some of the features supported by tier:
 | [Probabilistic data structures (that is, Redis Bloom)](redis-modules.md)                    | Yes               | Yes               | Yes               | Yes               |
 | [Time Series database capability (that is, Redis TimeSeries)](redis-modules.md)             | Yes               | Yes               | Yes               | Yes               |
 | [Import/Export](how-to-import-export-data.md)                                           | Yes               | Yes               | Yes               | Yes               |
-| [Update channel and Schedule updates](administration.md)                                | No                | No                | No                | No                |
 
 > [!IMPORTANT]
 > The Balanced B0 and B1 SKU options don't support active geo-replication.