Merge pull request #292871 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: Taojunshen

articles/application-gateway/application-gateway-probe-overview.md

@@ -46,7 +46,7 @@ Once the probe detects a failed response, the counter for "Unhealthy threshold"
 
 An application gateway automatically configures a default health probe when you don't set up any custom probe configuration. The monitoring behavior works by making an HTTP GET request to the IP addresses or FQDN configured in the backend pool. For default probes if the backend http settings are configured for HTTPS, the probe uses HTTPS to test health of the backend servers.
 
-For example: You configure your application gateway to use backend servers A, B, and C to receive HTTP network traffic on port 80. The default health monitoring tests the three servers every 30 seconds for a healthy HTTP response with a 30-second-timeout for each request. A healthy HTTP response has a [status code](/troubleshoot/developer/webapps/iis/www-administration-management/http-status-code) between 200 and 399. In this case, the HTTP GET request for the health probe looks like `http://127.0.0.1/`. Also see [HTTP response codes in Application Gateway](http-response-codes.md).
+For example: You configure your application gateway to use backend servers A, B, and C to receive HTTP network traffic on port 80. The default health monitoring tests the three servers every 30 seconds for a healthy HTTP response with a 30-second-timeout for each request. A healthy HTTP response has a [status code](/troubleshoot/developer/webapps/iis/www-administration-management/http-status-code) between 200 and 399. In this case, the HTTP GET host header for the health probe looks like `http://127.0.0.1/`. Also see [HTTP response codes in Application Gateway](http-response-codes.md).
 
 If the default probe check fails for server A, the application gateway stops forwarding requests to this server. The default probe still continues to check for server A every 30 seconds. When server A responds successfully to one request from a default health probe, application gateway starts forwarding the requests to the server again.
 

articles/application-gateway/configuration-listeners.md

@@ -29,7 +29,7 @@ When you create a new listener, you choose between [*basic* and *multi-site*](./
 
 For the v1 SKU, requests are matched according to the order of the rules and the type of listener. If a rule with basic listener comes first in the order, it's processed first and will accept any request for that port and IP combination. To avoid this, configure the rules with multi-site listeners first and push the rule with the basic listener to the last in the list.
 
-For the v2 SKU, multi-site listeners are processed before basic listeners, unless rule priority is defined. If using rule priority, wildcard listeners should be defined a priority with a number greater than non-wildcard listeners, to ensure non-wildcard listeners execute prior to the wildcard listeners.
+For the v2 SKU, rule priority defines the order in which listeners are processed. Wildcard and basic listeners should be defined a priority with a number greater than site-specific and multi-site listeners, to ensure site-specific and multi-site listeners execute prior to the wildcard and basic listeners.
 
 ## Frontend IP address
 

articles/application-gateway/ingress-controller-letsencrypt-certificate-application-gateway.md

@@ -32,7 +32,7 @@ Use the following steps to install [cert-manager](https://docs.cert-manager.io)
     #!/bin/bash
 
     # Install the CustomResourceDefinition resources separately
-    kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.10.1/cert-manager.crds.yaml
+    kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.16.1/cert-manager.crds.yaml
 
     # Create the namespace for cert-manager
     kubectl create namespace cert-manager
@@ -51,7 +51,7 @@ Use the following steps to install [cert-manager](https://docs.cert-manager.io)
     helm install \
       cert-manager jetstack/cert-manager \
       --namespace cert-manager \
-      --version v1.10.1 \
+      --version v1.16.1 \
       # --set installCRDs=true
 
     # To automatically install and manage the CRDs as part of your Helm release,
@@ -94,8 +94,12 @@ Use the following steps to install [cert-manager](https://docs.cert-manager.io)
         # file is present at the domain
         solvers:
           - http01:
-               ingress:
-                  ingressclassName: azure/application-gateway
+            ingress:
+             #   class: azure/application-gateway
+               ingressTemplate:
+                 metadata:
+                   annotations:
+                     kubernetes.io/ingress.class: azure/application-gateway
     EOF
     ```
 
@@ -110,8 +114,8 @@ Use the following steps to install [cert-manager](https://docs.cert-manager.io)
     apiVersion: networking.k8s.io/v1
     kind: Ingress
     metadata:
-    name: guestbook-letsencrypt-staging
-    annotations:
+      name: guestbook-letsencrypt-staging
+      annotations:
         kubernetes.io/ingress.class: azure/application-gateway
         cert-manager.io/cluster-issuer: letsencrypt-staging
     spec:
@@ -135,7 +139,7 @@ Use the following steps to install [cert-manager](https://docs.cert-manager.io)
 
 4. After you successfully set up your staging certificate, you can switch to a production ACME server:
 
-    1. Replace the staging annotation on your ingress resource with `certmanager.k8s.io/cluster-issuer: letsencrypt-prod`.
+    1. Replace the staging annotation on your ingress resource with `cert-manager.io/cluster-issuer: letsencrypt-prod`.
     1. Delete the existing staging `ClusterIssuer` resource that you created earlier. Create a new staging resource by replacing the ACME server from the previous `ClusterIssuer` YAML with `https://acme-v02.api.letsencrypt.org/directory`.
 
 Before the Let's Encrypt certificate expires, `cert-manager` automatically updates the certificate in the Kubernetes secret store. At that point, the Application Gateway Ingress Controller applies the updated secret referenced in the ingress resources that it's using to configure Application Gateway.

articles/application-gateway/redirect-external-site-cli.md

@@ -65,12 +65,13 @@ az network application-gateway create \
   --vnet-name myVNet \
   --subnet myAGsubnet \
   --capacity 2 \
-  --sku Standard_Medium \
+  --sku Standard_v2 \
   --http-settings-cookie-based-affinity Disabled \
   --frontend-port 8080 \
   --http-settings-port 80 \
   --http-settings-protocol Http \
-  --public-ip-address myAGPublicIPAddress
+  --public-ip-address myAGPublicIPAddress \
+  --priority 10 
 ```
 
 It may take several minutes for the application gateway to be created. After the application gateway is created, you can see these new features of it:
@@ -116,7 +117,9 @@ az network application-gateway rule create \
   --resource-group myResourceGroupAG \
   --http-listener redirectListener \
   --rule-type Basic \
-  --redirect-config myredirect
+  --redirect-config myredirect \
+  --priority 11
+
 ```
 
 ## Test the application gateway

articles/application-gateway/tutorial-autoscale-ps.md

@@ -151,9 +151,9 @@ $listener02 = New-AzApplicationGatewayHttpListener -Name "HTTPListener" `
 $setting = New-AzApplicationGatewayBackendHttpSettings -Name "BackendHttpSetting1" `
           -Port 80 -Protocol Http -CookieBasedAffinity Disabled -PickHostNameFromBackendAddress
 $rule01 = New-AzApplicationGatewayRequestRoutingRule -Name "Rule1" -RuleType basic `
-         -BackendHttpSettings $setting -HttpListener $listener01 -BackendAddressPool $pool
+         -BackendHttpSettings $setting -HttpListener $listener01 -BackendAddressPool $pool -Priority 1
 $rule02 = New-AzApplicationGatewayRequestRoutingRule -Name "Rule2" -RuleType basic `
-         -BackendHttpSettings $setting -HttpListener $listener02 -BackendAddressPool $pool
+         -BackendHttpSettings $setting -HttpListener $listener02 -BackendAddressPool $pool -Priority 2
 ```
 
 ## Specify autoscale

articles/dns/dns-traffic-log-how-to.md

@@ -239,7 +239,8 @@ Set up a local PowerShell repository and install the Az.DnsResolver PowerShell m
     $domainListName = "domainlist-$($nameSuffix)"
     $securityRuleName = "securityrule-$($nameSuffix)"
     $resolverPolicyLinkName = "dnsresolverpolicylink"
-    $storageAccountName = "stor-$($name)" # Customize this, taking care that the name is not too long
+    $storageAccountName = "stor$($name.ToLower())"  # Customize this, taking care that the name is not too long
+    $storageAccountName = $storageAccountName.Substring(0, [Math]::Min(24, $storageAccountName.Length)) # Storage account names must be 3-24 characters long
     $diagnosticSettingName = "diagnosticsetting-$($nameSuffix)"
     $vnetId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Network/virtualNetworks/$virtualNetworkName"
 
@@ -369,4 +370,4 @@ At line:1 char:1
 
 - Review concepts related to [DNS security policy](dns-security-policy.md).
 - Review [Azure Private DNS zones scenarios](private-dns-scenarios.md).
-- Review [DNS resolution in virtual networks](../virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances.md).
+- Review [DNS resolution in virtual networks](../virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances.md).

articles/storage/common/storage-explorer-network.md

@@ -34,7 +34,8 @@ Storage Explorer makes requests to various endpoints while in use. The following
   - `(blob|file|queue|table|dfs).core.windows.net` (global Azure)
   - `(blob|file|queue|table|dfs).core.chinacloudapi.cn` (Microsoft Azure operated by 21Vianet)
   - `(blob|file|queue|table|dfs).core.usgovcloudapi.net` (Azure US Government)
-- Storage Explorer updating: `storageexplorerpublish.blob.core.windows.net`
+- Storage Explorer updating:
+  - `storage-explorer-publishing-feapcgfgbzc2cjek.b01.azurefd.net`
 - Microsoft link forwarding:
   - `aka.ms`
   - `go.microsoft.com`

articles/traffic-manager/traffic-manager-configure-weighted-routing-method.md

@@ -45,8 +45,8 @@ In this tutorial, you learn how to:
     | Protocol    | Select a protocol for endpoint monitoring. *Options: HTTP, HTTPS, and TCP* |
     | Port | Specify the port number. |
     | Path | To monitor endpoints, you must specify a path and filename. A forward slash "/" is a valid entry for the relative path and implies that the file is in the root directory (default). |
-    | Custom Header settings | Configure the Custom Headers in format host:contoso.com,newheader:newvalue. Maximum supported pair is 8. Applicable for Http and Https protocol. Applicable for all endpoints in the profile |
-    | Expected Status Code Ranges (default: 200) | Configure the Status Code Ranges in format 200-299,301-301. Maximum supported range is 8. Applicable for Http and Https protocol. Applicable for all endpoints in the profile |
+    | Custom Header settings | Configure the Custom Headers in format host:contoso.com,newheader:newvalue. Maximum supported pair is 8. Applicable for HTTP and HTTPS protocol. Applicable for all endpoints in the profile |
+    | Expected Status Code Ranges (default: 200) | Configure the Status Code Ranges in format 200-299,301-301. Maximum supported range is 8. Applicable for HTTP and HTTPS protocol. Applicable for all endpoints in the profile |
     | Probing interval | Configure the time interval between endpoint health probes. You can choose 10 or 30 seconds. |
     | Tolerate number of failures | Configure the number of health probe failures tolerated before an endpoint failure is triggered. You can enter a number between 0 and 9. | 
     | Probe timeout | Configure the time required before an endpoint health probe times out. This value must be at least 5 and smaller than the probing interval value. |

includes/dns-limits.md

@@ -99,10 +99,12 @@ ms.author: greglin
 | Resource | Limit |
 | --- | --- |
 | DNS private resolvers per subscription |15|
+| DNS private resolvers per virtual network |1|
 | Inbound endpoints per DNS private resolver |5|
 | Outbound endpoints per DNS private resolver |5|
 | Forwarding rules per DNS forwarding ruleset |1000|
 | Virtual network links per DNS forwarding ruleset |500|
+| DNS forwarding ruleset linked to a virtual network |1|
 | Outbound endpoints per DNS forwarding ruleset |2|
 | DNS forwarding rulesets per outbound endpoint |2|
 | Target DNS servers per forwarding rule |6|