Merge pull request #214520 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: huypub

articles/azure-vmware/attach-azure-netapp-files-to-azure-vmware-solution-hosts.md

@@ -64,7 +64,7 @@ There are some important best practices to follow for optimal performance of NFS
 - Create Azure NetApp Files volumes using **Standard** network features to enable optimized connectivity from Azure VMware Solution private cloud via ExpressRoute FastPath connectivity.
 - For optimized performance, choose **UltraPerformance** gateway and enable [ExpressRoute FastPath](../expressroute/expressroute-howto-linkvnet-arm.md#configure-expressroute-fastpath) from a private cloud to Azure NetApp Files volumes virtual network. View more detailed information on gateway SKUs at [About ExpressRoute virtual network gateways](../expressroute/expressroute-about-virtual-network-gateways.md).
 - Based on your performance requirements, select the correct service level needed for the Azure NetApp Files capacity pool. For best performance, it's recommended to use the Ultra tier.
-- Create multiple datastores of 4-TB size for better performance. The default limit is 8 but it can be increased up to a maximum of 256 by submitting a support ticket. To submit a support ticket, go to [Create an Azure support request](../azure-portal/supportability/how-to-create-azure-support-request.md).
+- Create multiple datastores of 4-TB size for better performance. The default limit is 64 but it can be increased up to a maximum of 256 by submitting a support ticket. To submit a support ticket, go to [Create an Azure support request](../azure-portal/supportability/how-to-create-azure-support-request.md).
 -  Work with your Microsoft representative to ensure that the Azure VMware Solution private cloud and the Azure NetApp Files volumes are deployed within same [Availability Zone](../availability-zones/az-overview.md#availability-zones). 
 
 ## Attach an Azure NetApp Files volume to your private cloud

articles/hdinsight/hdinsight-managed-identities.md

@@ -40,7 +40,7 @@ Managed identities are used in Azure HDInsight in multiple scenarios. See the re
 * [Enterprise Security Package](domain-joined/apache-domain-joined-configure-using-azure-adds.md#create-and-authorize-a-managed-identity)
 * [Customer-managed key disk encryption](disk-encryption.md)
 
-HDInsight will automatically renew the certificates for the managed identities you use for these scenarios. However, there is a limitation when multiple different managed identities are used for long running clusters, the certificate renewal may not work as expected for all of the managed identities. Due to this limitation, if you are planning to use long running clusters (e.g. more than 60 days), we recommend to use the same managed identity for all of the above scenarios. 
+HDInsight will automatically renew the certificates for the managed identities you use for these scenarios. However, there is a limitation when multiple different managed identities are used for long running clusters, the certificate renewal may not work as expected for all of the managed identities. Due to this limitation, we recommend to use the same managed identity for all of the above scenarios. 
 
 If you have already created a long running cluster with multiple different managed identities and are running into one of these issues:
  * In ESP clusters, cluster services starts failing or scale up and other operations start failing with authentications errors.

articles/hdinsight/kafka/kafka-mirrormaker-2-0-guide.md

@@ -42,8 +42,8 @@ The summary of the broker setup process is as follows:
 
 **MirrorCheckpointConnector:**
 
-   1. Consumes offset-syncsr.
-   1. Emits checkpoints to enable failover points.
+  1. Consumes offset-syncsr.
+  1. Emits checkpoints to enable failover points.
 
 **MirrorHeartBeatConnector:**
 
@@ -53,47 +53,48 @@ The summary of the broker setup process is as follows:
 
 1. Connect-mirror-maker.sh script bundled with the Kafka library implements a distributed MM2 cluster, which manages the Connect workers internally based on a config file. Internally MirrorMaker driver creates and handles pairs of each connector – MirrorSourceConnector, MirrorSinkConnector, MirrorCheckpoint connector and MirrorHeartbeatConnector.
 1. Start MirrorMaker 2.0.
-    
-```
-./bin/connect-mirror-maker.sh ./config/mirror-maker.properties    
-```
+
+   ```
+   ./bin/connect-mirror-maker.sh ./config/mirror-maker.properties    
+   ```
 
 > [!NOTE]
 > For Kerberos enabled clusters, the JAAS configuration must be exported to the KAFKA_OPTS or must be specified in the MM2 config file.
 
 ```
 export KAFKA_OPTS="-Djava.security.auth.login.config=<path-to-jaas.conf>"    
 ```
+
 ### Sample MirrorMaker 2.0 Configuration file
        
 ```
-    # specify any number of cluster aliases
-    clusters = source, destination
+# specify any number of cluster aliases
+clusters = source, destination
 
-    # connection information for each cluster
-    # This is a comma separated host:port pairs for each cluster
-    # for example. "A_host1:9092, A_host2:9092, A_host3:9092"  and you can see the exact host name on Ambari > Hosts
-    source.bootstrap.servers = wn0-src-kafka.bx.internal.cloudapp.net:9092,wn1-src-kafka.bx.internal.cloudapp.net:9092,wn2-src-kafka.bx.internal.cloudapp.net:9092
-    destination.bootstrap.servers = wn0-dest-kafka.bx.internal.cloudapp.net:9092,wn1-dest-kafka.bx.internal.cloudapp.net:9092,wn2-dest-kafka.bx.internal.cloudapp.net:9092
+# connection information for each cluster
+# This is a comma separated host:port pairs for each cluster
+# for example. "A_host1:9092, A_host2:9092, A_host3:9092"  and you can see the exact host name on Ambari > Hosts
+source.bootstrap.servers = wn0-src-kafka.bx.internal.cloudapp.net:9092,wn1-src-kafka.bx.internal.cloudapp.net:9092,wn2-src-kafka.bx.internal.cloudapp.net:9092
+destination.bootstrap.servers = wn0-dest-kafka.bx.internal.cloudapp.net:9092,wn1-dest-kafka.bx.internal.cloudapp.net:9092,wn2-dest-kafka.bx.internal.cloudapp.net:9092
 
-    # enable and configure individual replication flows
-    source->destination.enabled = true
+# enable and configure individual replication flows
+source->destination.enabled = true
 
-    # regex which defines which topics gets replicated. For eg "foo-.*"
-    source->destination.topics = toa.evehicles-latest-dev
-    groups=.*
-    topics.blacklist="*.internal,__.*"
+# regex which defines which topics gets replicated. For eg "foo-.*"
+source->destination.topics = toa.evehicles-latest-dev
+groups=.*
+topics.blacklist="*.internal,__.*"
 
-    # Setting replication factor of newly created remote topics
-    replication.factor=3
+# Setting replication factor of newly created remote topics
+replication.factor=3
 
-    checkpoints.topic.replication.factor=1
-    heartbeats.topic.replication.factor=1
-    offset-syncs.topic.replication.factor=1
+checkpoints.topic.replication.factor=1
+heartbeats.topic.replication.factor=1
+offset-syncs.topic.replication.factor=1
 
-    offset.storage.replication.factor=1
-    status.storage.replication.factor=1
-    config.storage.replication.factor=1    
+offset.storage.replication.factor=1
+status.storage.replication.factor=1
+config.storage.replication.factor=1    
 ```
 
 ### SSL configuration
@@ -109,7 +110,6 @@ destination.ssl.keystore.location=/path/to/kafka.server.keystore.jks
 destination.sasl.mechanism=GSSAPI
 ```
 
-
 ### Global configurations
 
 |Property |Default value |Description |
@@ -167,9 +167,9 @@ destination.sasl.mechanism=GSSAPI
   Custom Replication Policy can be created by implementing the interface below.
 
 ```
-    /** Defines which topics are "remote topics", e.g. "us-west.topic1". */
-    public interface ReplicationPolicy {
- 
+/** Defines which topics are "remote topics", e.g. "us-west.topic1". */
+public interface ReplicationPolicy {
+
     /** How to rename remote topics; generally should be like us-west.topic1. */
     String formatRemoteTopic(String sourceClusterAlias, String topic);
  

articles/service-bus-messaging/enable-partitions-premium.md

@@ -23,7 +23,7 @@ Service Bus partitions enable queues and topics, or messaging entities, to be pa
 > Some limitations may be encountered during public preview, which will be resolved before going into GA. 
 > - It is currently not possible to use JMS on partitioned entities. 
 > - Metrics are currently only available on an aggregated namespace level, not for individual partitions.
-> - This feature is rolling out during Ignite 2022, and will initially be available in East US and South Central US, with more regions following later.
+> - This feature is rolling out during Ignite 2022, and will initially be available in East US and North Europe, with more regions following later.
 
 ## Use Azure portal
 When creating a **namespace** in the Azure portal, set the **Partitioning** to **Enabled** and choose the number of partitions, as shown in the following image. 

articles/service-bus-messaging/service-bus-dead-letter-queues.md

@@ -53,6 +53,10 @@ If you enable dead-lettering on filter evaluation exceptions, any errors that oc
 ## Application-level dead-lettering
 In addition to the system-provided dead-lettering features, applications can use the DLQ to explicitly reject unacceptable messages. They can include messages that can't be properly processed because of any sort of system issue, messages that hold malformed payloads, or messages that fail authentication when some message-level security scheme is used.
 
+This can be done by calling [QueueClient.DeadLetterAsync(Guid lockToken, string deadLetterReason, string deadLetterErrorDescription) method](/dotnet/api/microsoft.servicebus.messaging.queueclient.deadletterasync#microsoft-servicebus-messaging-queueclient-deadletterasync(system-guid-system-string-system-string)).
+
+It is recommended to include the type of the exception in the DeadLetterReason and the StackTrace of the exception in the DeadLetterDescription as this makes it easier to troubleshoot the cause of the problem resulting in messages being dead-lettered. Be aware that this may result in some messages exceeding [the 256KB quota limit for the Standard Tier of Azure Service Bus](/azure/service-bus-messaging/service-bus-quotas), further indicating that the Premium Tier is what should be used for production environments.
+
 ## Dead-lettering in ForwardTo or SendVia scenarios
 Messages will be sent to the transfer dead-letter queue under the following conditions: