Merge pull request #108882 from MicrosoftDocs/escape-example-links

Escape example links

Author: megvanhuygen

articles/active-directory/authentication/howto-mfa-nps-extension-errors.md

@@ -27,8 +27,8 @@ If you encounter errors with the NPS extension for Azure Multi-Factor Authentica
 | **CLIENT_CERT_INSTALL_ERROR** | There may be an issue with how the client certificate was installed or associated with your tenant. Follow the instructions in [Troubleshooting the MFA NPS extension](howto-mfa-nps-extension.md#troubleshooting) to investigate client cert problems. |
 | **ESTS_TOKEN_ERROR** | Follow the instructions in [Troubleshooting the MFA NPS extension](howto-mfa-nps-extension.md#troubleshooting) to investigate client cert and ADAL token problems. |
 | **HTTPS_COMMUNICATION_ERROR** | The NPS server is unable to receive responses from Azure MFA. Verify that your firewalls are open bidirectionally for traffic to and from https://adnotifications.windowsazure.com |
-| **HTTP_CONNECT_ERROR** | On the server that runs the NPS extension, verify that you can reach  https://adnotifications.windowsazure.com and https://login.microsoftonline.com/. If those sites don't load, troubleshoot connectivity on that server. |
-| **NPS Extension for Azure MFA:** <br> NPS Extension for Azure MFA only performs Secondary Auth for Radius requests in AccessAccept State. Request received for User username with response state AccessReject, ignoring request. | This error usually reflects an authentication failure in AD or that the NPS server is unable to receive responses from Azure AD. Verify that your firewalls are open bidirectionally for traffic to and from https://adnotifications.windowsazure.com and https://login.microsoftonline.com using ports 80 and 443. It is also important to check that on the DIAL-IN tab of Network Access Permissions, the setting is set to "control access through NPS Network Policy". This error can also trigger if the user is not assigned a license. |
+| **HTTP_CONNECT_ERROR** | On the server that runs the NPS extension, verify that you can reach  `https://adnotifications.windowsazure.com` and `https://login.microsoftonline.com/`. If those sites don't load, troubleshoot connectivity on that server. |
+| **NPS Extension for Azure MFA:** <br> NPS Extension for Azure MFA only performs Secondary Auth for Radius requests in AccessAccept State. Request received for User username with response state AccessReject, ignoring request. | This error usually reflects an authentication failure in AD or that the NPS server is unable to receive responses from Azure AD. Verify that your firewalls are open bidirectionally for traffic to and from `https://adnotifications.windowsazure.com` and `https://login.microsoftonline.com` using ports 80 and 443. It is also important to check that on the DIAL-IN tab of Network Access Permissions, the setting is set to "control access through NPS Network Policy". This error can also trigger if the user is not assigned a license. |
 | **REGISTRY_CONFIG_ERROR** | A key is missing in the registry for the application, which may be because the [PowerShell script](howto-mfa-nps-extension.md#install-the-nps-extension) wasn't run after installation. The error message should include the missing key. Make sure you have the key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa. |
 | **REQUEST_FORMAT_ERROR** <br> Radius Request missing mandatory Radius userName\Identifier attribute.Verify that NPS is receiving RADIUS requests | This error usually reflects an installation issue. The NPS extension must be installed in NPS servers that can receive RADIUS requests. NPS servers that are installed as dependencies for services like RDG and RRAS don't receive radius requests. NPS Extension does not work when installed over such installations and errors out since it cannot read the details from the authentication request. |
 | **REQUEST_MISSING_CODE** | Make sure that the password encryption protocol between the NPS and NAS servers supports the secondary authentication method that you're using. **PAP** supports all the authentication methods of Azure MFA in the cloud: phone call, one-way text message, mobile app notification, and mobile app verification code. **CHAPV2** and **EAP** support phone call and mobile app notification. |

articles/app-service-mobile/app-service-mobile-client-and-server-versioning.md

@@ -23,11 +23,11 @@ The key `ZUMO-API-VERSION` may be specified in either the HTTP header or the que
 
 For example:
 
-GET https://service.azurewebsites.net/tables/TodoItem
+`GET https://service.azurewebsites.net/tables/TodoItem`
 
 HEADERS: ZUMO-API-VERSION: 2.0.0
 
-POST https://service.azurewebsites.net/tables/TodoItem?ZUMO-API-VERSION=2.0.0
+`POST https://service.azurewebsites.net/tables/TodoItem?ZUMO-API-VERSION=2.0.0`
 
 ## Opting out of version checking
 You can opt out of version checking by setting a value of **true** for the app setting **MS_SkipVersionCheck**. Specify this either in your web.config or in the Application Settings section of the Azure portal.

articles/app-service/environment/app-service-app-service-environment-create-ilb-ase-resourcemanager.md

@@ -25,7 +25,7 @@ There are three steps involved in automating creation of an ILB ASE:
 
 1. First the base ASE is created in a virtual network using an internal load balancer address instead of a public VIP.  As part of this step, a root domain name is assigned to the ILB ASE.
 2. Once the ILB ASE is created, an SSL certificate is uploaded.  
-3. The uploaded SSL certificate is explicitly assigned to the ILB ASE as its "default" SSL certificate.  This SSL certificate will be used for SSL traffic to apps on the ILB ASE when the apps are addressed using the common root domain assigned to the ASE (e.g. https://someapp.mycustomrootcomain.com)
+3. The uploaded SSL certificate is explicitly assigned to the ILB ASE as its "default" SSL certificate.  This SSL certificate will be used for SSL traffic to apps on the ILB ASE when the apps are addressed using the common root domain assigned to the ASE (e.g. `https://someapp.mycustomrootcomain.com`)
 
 ## Creating the Base ILB ASE
 An example Azure Resource Manager template, and its associated parameters file, are available on GitHub [here][quickstartilbasecreate].

articles/app-service/environment/app-service-environment-with-internal-load-balancer.md

@@ -91,8 +91,8 @@ If you want to try the flow with your own certificates and test both HTTP and HT
 4. Create a web app in ASE after creation. 
 5. Create a VM if you don't have one in that VNET (Not in the same subnet as the ASE or things break).
 6. Set DNS for your subdomain. You can use a wildcard with your subdomain in your DNS or if you want to do some simple tests, edit the hosts file on your VM to set web app name to VIP IP address. If your ASE had the subdomain name .ilbase.com and you made the web app mytestapp so that it would be addressed at mytestapp.ilbase.com, set that in your hosts file. (On Windows, the hosts file is at C:\Windows\System32\drivers\etc\)
-7. Use a browser on that VM and go to https://mytestapp.ilbase.com (or whatever your web app name is with your subdomain).
-8. Use a browser on that VM and go to https://mytestapp.ilbase.com. You must accept the lack of security if using a self-signed certificate. 
+7. Use a browser on that VM and go to `https://mytestapp.ilbase.com` (or whatever your web app name is with your subdomain).
+8. Use a browser on that VM and go to `https://mytestapp.ilbase.com`. You must accept the lack of security if using a self-signed certificate. 
 
 The IP address for your ILB is listed in your Properties as the Virtual IP Address.
 

articles/app-service/environment/create-from-template.md

@@ -33,7 +33,7 @@ To automate your ASE creation:
 
 2. After your ILB ASE is created, an SSL certificate that matches your ILB ASE domain is uploaded.
 
-3. The uploaded SSL certificate is assigned to the ILB ASE as its "default" SSL certificate.  This certificate is used for SSL traffic to apps on the ILB ASE when they use the common root domain that's assigned to the ASE (for example, https://someapp.mycustomrootdomain.com).
+3. The uploaded SSL certificate is assigned to the ILB ASE as its "default" SSL certificate.  This certificate is used for SSL traffic to apps on the ILB ASE when they use the common root domain that's assigned to the ASE (for example, `https://someapp.mycustomrootdomain.com`).
 
 
 ## Create the ASE
@@ -57,7 +57,7 @@ New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-
 It takes about an hour for the ASE to be created. Then the ASE shows up in the portal in the list of ASEs for the subscription that triggered the deployment.
 
 ## Upload and configure the "default" SSL certificate
-An SSL certificate must be associated with the ASE as the "default" SSL certificate that's used to establish SSL connections to apps. If the ASE's default DNS suffix is *internal-contoso.com*, a connection to https://some-random-app.internal-contoso.com requires an SSL certificate that's valid for **.internal-contoso.com*. 
+An SSL certificate must be associated with the ASE as the "default" SSL certificate that's used to establish SSL connections to apps. If the ASE's default DNS suffix is *internal-contoso.com*, a connection to `https://some-random-app.internal-contoso.com` requires an SSL certificate that's valid for **.internal-contoso.com*. 
 
 Obtain a valid SSL certificate by using internal certificate authorities, purchasing a certificate from an external issuer, or using a self-signed certificate. Regardless of the source of the SSL certificate, the following certificate attributes must be configured properly:
 
@@ -142,7 +142,7 @@ New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-
 
 It takes roughly 40 minutes per ASE front end to apply the change. For example, for a default-sized ASE that uses two front ends, the template takes around one hour and 20 minutes to complete. While the template is running, the ASE can't scale.  
 
-After the template finishes, apps on the ILB ASE can be accessed over HTTPS. The connections are secured by using the default SSL certificate. The default SSL certificate is used when apps on the ILB ASE are addressed by using a combination of the application name plus the default host name. For example, https://mycustomapp.internal-contoso.com uses the default SSL certificate for **.internal-contoso.com*.
+After the template finishes, apps on the ILB ASE can be accessed over HTTPS. The connections are secured by using the default SSL certificate. The default SSL certificate is used when apps on the ILB ASE are addressed by using a combination of the application name plus the default host name. For example, `https://mycustomapp.internal-contoso.com` uses the default SSL certificate for **.internal-contoso.com*.
 
 However, just like apps that run on the public multitenant service, developers can configure custom host names for individual apps. They also can configure unique SNI SSL certificate bindings for individual apps.
 

articles/application-gateway/application-gateway-create-multisite-azureresourcemanager-powershell.md

@@ -251,7 +251,7 @@ Get-AzPublicIPAddress -ResourceGroupName myResourceGroupAG -Name myAGPublicIPAdd
 
 ## Test the application gateway
 
-Enter your domain name into the address bar of your browser. Such as, https://www.contoso.com.
+Enter your domain name into the address bar of your browser. Such as, `https://www.contoso.com`.
 
 ![Test contoso site in application gateway](./media/application-gateway-create-multisite-azureresourcemanager-powershell/application-gateway-iistest.png)
 

articles/application-gateway/configuration-overview.md

@@ -336,7 +336,7 @@ For a custom domain whose existing custom DNS name is mapped to the app service,
 
 This capability replaces the *host* header in the incoming request on the application gateway with the host name that you specify.
 
-For example, if *www.contoso.com* is specified in the **Host name** setting, the original request *https://appgw.eastus.cloudapp.azure.com/path1 is changed to *https://www.contoso.com/path1 when the request is forwarded to the back-end server.
+For example, if *www.contoso.com* is specified in the **Host name** setting, the original request *`https://appgw.eastus.cloudapp.azure.com/path1` is changed to *`https://www.contoso.com/path1` when the request is forwarded to the back-end server.
 
 ## Back-end pool
 

articles/application-gateway/self-signed-certificates.md

@@ -14,7 +14,7 @@ ms.author: victorh
 
 The Application Gateway v2 SKU introduces the use of Trusted Root Certificates to allow backend servers. This removes authentication certificates that were required in the v1 SKU. The *root certificate* is a Base-64 encoded X.509(.CER) format root certificate from the backend certificate server. It identifies the root certificate authority (CA) that issued the server certificate and the server certificate is then used for the SSL communication.
 
-Application Gateway trusts your website’s certificate by default if it's signed by a well-known CA (for example, GoDaddy or DigiCert). You don’t need to explicitly upload the root certificate in that case. For more information, see [Overview of SSL termination and end to end SSL with Application Gateway](ssl-overview.md). However, if you have a dev/test environment and don't want to purchase a verified CA signed certificate, you can create your own custom CA and create a self-signed certificate with it. 
+Application Gateway trusts your website's certificate by default if it's signed by a well-known CA (for example, GoDaddy or DigiCert). You don't need to explicitly upload the root certificate in that case. For more information, see [Overview of SSL termination and end to end SSL with Application Gateway](ssl-overview.md). However, if you have a dev/test environment and don't want to purchase a verified CA signed certificate, you can create your own custom CA and create a self-signed certificate with it. 
 
 > [!NOTE]
 > Self-signed certificates are not trusted by default and they can be difficult to maintain. Also, they may use outdated hash and cipher suites that may not be strong. For better security, purchase a certificate signed by a well-known certificate authority.
@@ -70,7 +70,7 @@ Create your root CA certificate using OpenSSL.
 
 Next, you'll create a server certificate using OpenSSL.
 
-### Create the certificate’s key
+### Create the certificate's key
 
 Use the following command to generate the key for the server certificate.
 
@@ -83,7 +83,7 @@ Use the following command to generate the key for the server certificate.
 The CSR is a public key that is given to a CA when requesting a certificate. The CA issues the certificate for this specific request.
 
 > [!NOTE]
-> The CN (Common Name) for the server certificate must be different from the issuer’s domain. For example, in this case, the CN for the issuer is `www.contoso.com` and the server certificate’s CN is `www.fabrikam.com`.
+> The CN (Common Name) for the server certificate must be different from the issuer's domain. For example, in this case, the CN for the issuer is `www.contoso.com` and the server certificate's CN is `www.fabrikam.com`.
 
 
 1. Use the following command to generate the CSR:
@@ -96,7 +96,7 @@ The CSR is a public key that is given to a CA when requesting a certificate. The
 
    ![Server certificate](media/self-signed-certificates/server-cert.png)
 
-### Generate the certificate with the CSR and the key and sign it with the CA’s root key
+### Generate the certificate with the CSR and the key and sign it with the CA's root key
 
 1. Use the following command to create the certificate:
 
@@ -120,9 +120,9 @@ The CSR is a public key that is given to a CA when requesting a certificate. The
    - fabrikam.crt
    - fabrikam.key
 
-## Configure the certificate in your web server’s SSL settings
+## Configure the certificate in your web server's SSL settings
 
-In your web server, configure SSL using the fabrikam.crt and fabrikam.key files. If your web server can’t take two files, you can combine them to a single .pem or .pfx file using OpenSSL commands.
+In your web server, configure SSL using the fabrikam.crt and fabrikam.key files. If your web server can't take two files, you can combine them to a single .pem or .pfx file using OpenSSL commands.
 
 ### IIS
 
@@ -152,7 +152,7 @@ The following configuration is an example [NGINX server block](https://nginx.org
 
 ## Access the server to verify the configuration
 
-1. Add the root certificate to your machine’s trusted root store. When you access the website, ensure the entire certificate chain is seen in the browser.
+1. Add the root certificate to your machine's trusted root store. When you access the website, ensure the entire certificate chain is seen in the browser.
 
    ![Trusted root certificates](media/self-signed-certificates/trusted-root-cert.png)
 
@@ -170,7 +170,7 @@ openssl s_client -connect localhost:443 -servername www.fabrikam.com -showcerts
 
 ![OpenSSL certificate verification](media/self-signed-certificates/openssl-verify.png)
 
-## Upload the root certificate to Application Gateway’s HTTP Settings
+## Upload the root certificate to Application Gateway's HTTP Settings
 
 To upload the certificate in Application Gateway, you must export the .crt certificate into a .cer format Base-64 encoded. Since .crt already contains the public key in the base-64 encoded format, just rename the file extension from .crt to .cer. 
 
@@ -225,9 +225,9 @@ $probe = Get-AzApplicationGatewayProbeConfig `
   -Name testprobe `
   -ApplicationGateway $gw
 
-## Add the configuration to the HTTP Setting and don’t forget to set the “hostname” field
+## Add the configuration to the HTTP Setting and don't forget to set the "hostname" field
 ## to the domain name of the server certificate as this will be set as the SNI header and
-## will be used to verify the backend server’s certificate. Note that SSL handshake will
+## will be used to verify the backend server's certificate. Note that SSL handshake will
 ## fail otherwise and might lead to backend servers being deemed as Unhealthy by the probes
 
 Add-AzApplicationGatewayBackendHttpSettings `
@@ -260,7 +260,7 @@ Set-AzApplicationGateway -ApplicationGateway $gw
 ### Verify the application gateway backend health
 
 1. Click the **Backend Health** view of your application gateway to check if the probe is healthy.
-1.	You should see that the Status is **Healthy** for the HTTPS probe.
+1.    You should see that the Status is **Healthy** for the HTTPS probe.
 
     ![HTTPS probe](media/self-signed-certificates/https-probe.png)
 

articles/application-gateway/troubleshoot-app-service-redirection-app-service-url.md

@@ -72,7 +72,7 @@ Set-Cookie: ARRAffinity=b5b1b14066f35b3e4533a1974cacfbbd969bf1960b6518aa2c2e2619
 
 X-Powered-By: ASP.NET
 ```
-In the previous example, notice that the response header has a status code of 301 for redirection. The location header has the app service’s host name instead of the original host name `www.contoso.com`.
+In the previous example, notice that the response header has a status code of 301 for redirection. The location header has the app service's host name instead of the original host name `www.contoso.com`.
 
 ## Solution: Rewrite the location header
 
@@ -102,7 +102,7 @@ You must own a custom domain and follow this process:
   > [!NOTE]
   > For the next step, make sure that your custom probe isn't associated to your back-end HTTP settings. Your HTTP settings still have the **Pick Hostname from Backend Address** switch enabled at this point.
 
-- Set your application gateway’s HTTP settings to disable **Pick Hostname from Backend Address**. In the Azure portal, clear the check box. In PowerShell, don't use the **-PickHostNameFromBackendAddress** switch in the **Set-AzApplicationGatewayBackendHttpSettings** command.
+- Set your application gateway's HTTP settings to disable **Pick Hostname from Backend Address**. In the Azure portal, clear the check box. In PowerShell, don't use the **-PickHostNameFromBackendAddress** switch in the **Set-AzApplicationGatewayBackendHttpSettings** command.
 
 - Associate the custom probe back to the back-end HTTP settings, and verify that the back end is healthy.