edit fixes

Author: greg-lindsay

articles/application-gateway/application-gateway-ilb-arm.md

@@ -35,7 +35,7 @@ This article walks you through the steps to configure a Standard v1 Application
 ## Create an application gateway
 
 The difference between using Azure Classic and Azure Resource Manager is the order in which you create the application gateway and the items that need to be configured.
-With Resource Manager, all items that make an application gateway is configured individually and then put together to create the application gateway resource.
+With Resource Manager, all items that make an application gateway are configured individually and then put together to create the application gateway resource.
 
 Here are the steps that are needed to create an application gateway:
 

articles/application-gateway/application-gateway-troubleshooting-502.md

@@ -41,32 +41,32 @@ Similarly, the presence of a custom DNS in the VNet could also cause issues. An
 
 Validate NSG, UDR, and DNS configuration by going through the following steps:
 
-* Check NSGs associated with the application gateway subnet. Ensure that communication to backend isn't blocked.
-* Check UDR associated with the application gateway subnet. Ensure that the UDR isn't directing traffic away from the backend subnet. For example, check for routing to network virtual appliances or default routes being advertised to the application gateway subnet via ExpressRoute/VPN.
-
-```azurepowershell
-$vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
-Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
-```
-
-* Check effective NSG and route with the backend VM
-
-```azurepowershell
-Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
-Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg
-```
-
-* Check presence of custom DNS in the VNet. DNS can be checked by looking at details of the VNet properties in the output.
-
-```json
-Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
-DhcpOptions            : {
-                           "DnsServers": [
-                             "x.x.x.x"
-                           ]
-                         }
-```
-If present, ensure that the DNS server can resolve the backend pool member's FQDN correctly.
+1. Check NSGs associated with the application gateway subnet. Ensure that communication to backend isn't blocked.
+2. Check UDR associated with the application gateway subnet. Ensure that the UDR isn't directing traffic away from the backend subnet. For example, check for routing to network virtual appliances or default routes being advertised to the application gateway subnet via ExpressRoute/VPN.
+
+    ```azurepowershell
+    $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
+    Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
+    ```
+
+3. Check effective NSG and route with the backend VM
+
+    ```azurepowershell
+    Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
+    Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg
+    ```
+
+4. Check presence of custom DNS in the VNet. DNS can be checked by looking at details of the VNet properties in the output.
+
+    ```json
+    Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
+    DhcpOptions            : {
+                               "DnsServers": [
+                                 "x.x.x.x"
+                               ]
+                             }
+    ```
+5. If present, ensure that the DNS server can resolve the backend pool member's FQDN correctly.
 
 ## Problems with default health probe
 

articles/application-gateway/configuration-infrastructure.md

@@ -32,7 +32,7 @@ Application Gateway (Standard or WAF) SKU can support up to 32 instances (32 ins
 
 Application Gateway (Standard_v2 or WAF_v2 SKU) can support up to 125 instances (125 instance IP addresses + 1 private frontend IP configuration + 5 Azure reserved). A minimum subnet size of /24 is recommended.
 
-To determine the available capacity of a subnet that has existing Application Gateways provisioned, take the size of the subnet and subtract the five reserved IP addresses of the subnet reserved by the platform.  Next, take each gateway and subtract the the max-instance count.  For each gateway that has a private frontend IP configuration, subtract one additional IP address per gateway as well.
+To determine the available capacity of a subnet that has existing Application Gateways provisioned, take the size of the subnet and subtract the five reserved IP addresses of the subnet reserved by the platform.  Next, take each gateway and subtract the max-instance count.  For each gateway that has a private frontend IP configuration, subtract one additional IP address per gateway as well.
 
 For example, here's how to calculate the available addressing for a subnet with three gateways of varying sizes:
 - Gateway 1: Maximum of 10 instances; utilizes a private frontend IP configuration

articles/application-gateway/ssl-overview.md

@@ -115,8 +115,8 @@ The following tables outline the differences in SNI between the v1 and v2 SKU in
 
 ### Frontend TLS connection (client to application gateway)
 
----
-Scenario | v1 | v2 |
+
+|Scenario | v1 | v2 |
 | --- | --- | --- |
 | If the client specifies SNI header and all the multi-site listeners are enabled with "Require SNI" flag | Returns the appropriate certificate and if the site doesn't exist (according to the server_name), then the connection is reset. | Returns appropriate certificate if available, otherwise, returns the certificate of the first HTTPS listener according to the order specified by the request routing rules associated with the HTTPS listeners|
 | If the client doesn't specify a SNI header and if all the multi-site headers are enabled with "Require SNI" | Resets the connection | Returns the certificate of the first HTTPS listener according to the order specified by the request routing rules associated with the HTTPS listeners
@@ -126,8 +126,8 @@ Scenario | v1 | v2 |
 
 #### For probe traffic
 
----
-Scenario | v1 | v2 |
+
+|Scenario | v1 | v2 |
 | --- | --- | --- |
 | SNI (server_name) header during the TLS handshake as FQDN | Set as FQDN from the backend pool. As per [RFC 6066](https://tools.ietf.org/html/rfc6066), literal IPv4 and IPv6 addresses aren't permitted in SNI hostname. <br> **Note:** FQDN in the backend pool should DNS resolve to backend server’s IP address (public or private) | SNI header (server_name) is set as the hostname from the custom probe attached to the HTTP settings (if configured), otherwise from the hostname mentioned in the HTTP settings, otherwise from the FQDN mentioned in the backend pool. The order of precedence is custom probe > HTTP settings > backend pool. <br> **Note:** If the hostnames configured in HTTP settings and custom probe are different, then according to the precedence, SNI will be set as the hostname from the custom probe.
 | If the backend pool address is an IP address (v1) or if custom probe hostname is configured as IP address (v2) | SNI (server_name) won’t be set. <br> **Note:** In this case, the backend server should be able to return a default/fallback certificate and this should be allow-listed in HTTP settings under authentication certificate. If there’s no default/fallback certificate configured in the backend server and SNI is expected, the server might reset the connection and will lead to probe failures | In the order of precedence mentioned previously, if they have IP address as hostname, then SNI won't be set as per [RFC 6066](https://tools.ietf.org/html/rfc6066). <br> **Note:** SNI also won't be set in v2 probes if no custom probe is configured and no hostname is set on HTTP settings or backend pool |
@@ -137,8 +137,8 @@ Scenario | v1 | v2 |
 
 #### For live traffic
 
----
-Scenario | v1 | v2 |
+
+|Scenario | v1 | v2 |
 | --- | --- | --- |
 | SNI (server_name) header during the TLS handshake as FQDN | Set as FQDN from the backend pool. As per [RFC 6066](https://tools.ietf.org/html/rfc6066), literal IPv4 and IPv6 addresses aren't permitted in SNI hostname. <br> **Note:** FQDN in the backend pool should DNS resolve to backend server’s IP address (public or private) | SNI header (server_name) is set as the hostname from the HTTP settings, otherwise, if *PickHostnameFromBackendAddress* option is chosen or if no hostname is mentioned, then it will be set as the FQDN in the backend pool configuration
 | If the backend pool address is an IP address or hostname isn't set in HTTP settings | SNI won't be set as per [RFC 6066](https://tools.ietf.org/html/rfc6066) if the backend pool entry isn't an FQDN | SNI will be set as the hostname from the input FQDN from the client and the backend certificate's CN has to match with this hostname.