Merge pull request #177342 from alexbuckgit/alexbuckgit/docutune-autopr-20211023-043414-6997834-1

DocuTune: Fix casing of U words and acronyms (part 1)

Author: v-andreaco

articles/active-directory/app-proxy/application-proxy-configure-connectors-with-proxy-servers.md

@@ -108,7 +108,7 @@ There are four aspects to consider at the outbound proxy:
 
 Allow access to the following URLs:
 
-| URL | Port |  How it's used |
+| URL | Port | How it's used |
 | --- | --- | --- |
 | &ast;.msappproxy.net<br>&ast;.servicebus.windows.net | 443/HTTPS | Communication between the connector and the Application Proxy cloud service |
 | crl3.digicert.com<br>crl4.digicert.com<br>ocsp.digicert.com<br>crl.microsoft.com<br>oneocsp.microsoft.com<br>ocsp.msocsp.com<br> | 80/HTTP | The connector uses these URLs to verify certificates. |

articles/active-directory/app-proxy/application-proxy-configure-cookie-settings.md

@@ -35,7 +35,7 @@ Starting in version Chrome 80 and eventually in browsers leveraging Chromium, co
 
 These changes to Application Proxy cookies will roll out over the course of the next several weeks before the Chrome 80 release date.
 
-Additionally, if your back-end application has cookies that need to be available in a third-party context, you must explicitly opt in by changing your application to use SameSite=None for these cookies. Application Proxy translates the Set-Cookie header to its URLS and will respect the settings for these cookies set by the back-end application.
+Additionally, if your back-end application has cookies that need to be available in a third-party context, you must explicitly opt in by changing your application to use SameSite=None for these cookies. Application Proxy translates the Set-Cookie header to its URLs and will respect the settings for these cookies set by the back-end application.
 
 
 

articles/active-directory/app-proxy/application-proxy-configure-native-client-application.md

@@ -106,12 +106,12 @@ The required info in the sample code can be found in the Azure AD portal, as fol
 | \<Tenant ID> | **Azure Active Directory** > **Properties** > **Directory ID** |
 | \<App ID of the Native app> | **Application registration** > *your native application* > **Overview** > **Application ID** |
 | \<Scope> | **Application registration** > *your native application* > **API permissions** > Click on the Permission API (user_impersonation) > A panel with the caption **user_impersonation** appears on the right hand side. > The scope is the URL in the edit box.
-| \<Proxy App Url> | the External Url and path to the API
+| \<Proxy App URL> | the External URL and path to the API
 
 After you edit the MSAL code with these parameters, your users can authenticate to native client applications even when they are outside of the corporate network.
 
 ## Next steps
 
 For more information about the native application flow, see [Native apps in Azure Active Directory](../azuread-dev/native-app.md).
 
-Learn about setting up [Single sign-on to applications in Azure Active Directory](../manage-apps/sso-options.md#choosing-a-single-sign-on-method).
+Learn about setting up [Single sign-on to applications in Azure Active Directory](../manage-apps/sso-options.md#choosing-a-single-sign-on-method).

articles/active-directory/app-proxy/application-proxy-configure-single-sign-on-on-premises-apps.md

@@ -77,7 +77,7 @@ Before you can provide SSO for on-premises applications, you need to enable Appl
    * For an SP-initiated flow, make sure the back-end application specifies the correct **Reply URL** or Assertion Consumer Service URL for receiving the authentication token.
 
     > [!NOTE]
-    > If the back-end application expects the **Reply URL** to be the Internal URL, you'll need to either use [custom domains](application-proxy-configure-custom-domain.md) to have matching internal and external URLS or install the My Apps secure sign-in extension on users' devices. This extension will automatically redirect to the appropriate Application Proxy Service. To install the extension, see [My Apps secure sign-in extension](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510#download-and-install-the-my-apps-secure-sign-in-extension).
+    > If the back-end application expects the **Reply URL** to be the Internal URL, you'll need to either use [custom domains](application-proxy-configure-custom-domain.md) to have matching internal and external URLs or install the My Apps secure sign-in extension on users' devices. This extension will automatically redirect to the appropriate Application Proxy Service. To install the extension, see [My Apps secure sign-in extension](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510#download-and-install-the-my-apps-secure-sign-in-extension).
     
 ## Test your app
 
@@ -89,4 +89,4 @@ When you've completed all these steps, your app should be up and running. To tes
 ## Next steps
 
 - [How does Azure AD Application Proxy provide single sign-on?](../manage-apps/what-is-single-sign-on.md)
-- [Troubleshoot Application Proxy](application-proxy-troubleshoot.md)
+- [Troubleshoot Application Proxy](application-proxy-troubleshoot.md)

articles/active-directory/app-proxy/application-proxy-integrate-with-remote-desktop-services.md

@@ -37,7 +37,7 @@ In an RDS deployment, the RD Web role and the RD Gateway role run on Internet-fa
 ## Requirements
 
 - Both the RD Web and RD Gateway endpoints must be located on the same machine, and with a common root. RD Web and RD Gateway are published as a single application with Application Proxy so that you can have a single sign-on experience between the two applications.
-- You should already have [deployed RDS](/windows-server/remote/remote-desktop-services/rds-in-azure), and [enabled Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md). Ensure you have satisfied the pre-requisites to enable Application Proxy, such as installing the connector, opening required ports and URLS, and enabling TLS 1.2 on the server. To learn which ports need to be opened, and other details, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md).
+- You should already have [deployed RDS](/windows-server/remote/remote-desktop-services/rds-in-azure), and [enabled Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md). Ensure you have satisfied the pre-requisites to enable Application Proxy, such as installing the connector, opening required ports and URLs, and enabling TLS 1.2 on the server. To learn which ports need to be opened, and other details, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md).
 - Your end users must use a compatible browser to connect to RD Web or the RD Web client. For more details see [Support for client configurations](#support-for-other-client-configurations).
 - When publishing RD Web, it is recommended to use the same internal and external FQDN. If the internal and external FQDNs are different then you should disable Request Header Translation to avoid the client receiving invalid links.
 - If you are using RD Web on Internet Explorer, you will need to enable the RDS ActiveX add-on.

articles/active-directory/app-proxy/application-proxy-secure-api-access.md

@@ -133,13 +133,13 @@ You've now registered the AppProxyNativeAppSample app in Azure Active Directory.
 
 The last step is to configure the native app. The following snippet from the *Form1.cs* file in the NativeClient sample app causes the MSAL library to acquire the token for requesting the API call, and attach it as bearer to the app header.
 
-   ```
-   // Acquire Access Token from AAD for Proxy Application
- IPublicClientApplication clientApp = PublicClientApplicationBuilder
-.Create(<App ID of the Native app>)
-.WithDefaultRedirectUri() // will automatically use the default Uri for native app
-.WithAuthority("https://login.microsoftonline.com/{<Tenant ID>}")
-.Build();
+```csharp
+// Acquire Access Token from AAD for Proxy Application
+IPublicClientApplication clientApp = PublicClientApplicationBuilder
+    .Create(<App ID of the Native app>)
+    .WithDefaultRedirectUri() // Will automatically use the default Uri for native app
+    .WithAuthority("https://login.microsoftonline.com/{<Tenant ID>}")
+    .Build();
 
 AuthenticationResult authResult = null;
 var accounts = await clientApp.GetAccountsAsync();
@@ -148,22 +148,22 @@ IAccount account = accounts.FirstOrDefault();
 IEnumerable<string> scopes = new string[] {"<Scope>"};
 
 try
- {
+{
     authResult = await clientApp.AcquireTokenSilent(scopes, account).ExecuteAsync();
- }
-    catch (MsalUiRequiredException ex)
- {
-     authResult = await clientApp.AcquireTokenInteractive(scopes).ExecuteAsync();                
- }
- 
+}
+catch (MsalUiRequiredException ex)
+{
+    authResult = await clientApp.AcquireTokenInteractive(scopes).ExecuteAsync();
+}
+
 if (authResult != null)
- {
-  //Use the Access Token to access the Proxy Application
-  
-  HttpClient httpClient = new HttpClient();
-  HttpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", authResult.AccessToken);
-  HttpResponseMessage response = await httpClient.GetAsync("<Proxy App Url>");
- }
+{
+    // Use the Access Token to access the Proxy Application
+
+    HttpClient httpClient = new HttpClient();
+    HttpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", authResult.AccessToken);
+    HttpResponseMessage response = await httpClient.GetAsync("<Proxy App Url>");
+}
 ```
 
 To configure the native app to connect to Azure Active Directory and call the API App Proxy, update the placeholder values in the *App.config* file of the NativeClient sample app with values from Azure AD:

articles/active-directory/app-proxy/application-proxy-troubleshoot.md

@@ -47,8 +47,8 @@ Once you find the Connector error from the event log, use this table of common e
 | Connector registration failed: Make sure you enabled Application Proxy in the Azure Management Portal and that you entered your Active Directory user name and password correctly. Error: 'AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials and search by service principal URI has failed. | You're trying to sign in using a Microsoft Account and not a domain that is part of the organization ID of the directory you're trying to access. Make sure that the admin is part of the same domain name as the tenant domain, for example, if the Azure AD domain is contoso.com, the admin should be [email protected]. |
 | Failed to retrieve the current execution policy for running PowerShell scripts. | If the Connector installation fails, check to make sure that PowerShell execution policy isn't disabled. <br><br>1. Open the Group Policy Editor.<br>2. Go to **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows PowerShell** and double-click **Turn on Script Execution**.<br>3. The execution policy can be set to either **Not Configured** or **Enabled**. If set to **Enabled**, make sure that under Options, the Execution Policy is set to either **Allow local scripts and remote signed scripts** or to **Allow all scripts**. |
 | Connector failed to download the configuration. | The Connector’s client certificate, which is used for authentication, expired. This may also occur if you have the Connector installed behind a proxy. In this case, the Connector cannot access the Internet and will not be able to provide applications to remote users. Renew trust manually using the `Register-AppProxyConnector` cmdlet in Windows PowerShell. If your Connector is behind a proxy, it is necessary to grant Internet access to the Connector accounts “network services” and “local system.” This can be accomplished either by granting them access to the Proxy or by setting them to bypass the proxy. |
-| Connector registration failed: Make sure you are an Application Administrator of your Active Directory to register the Connector. Error: 'The registration request was denied.' | The alias you're trying to log in with isn't an admin on this domain. Your Connector is always installed for the directory that owns the user’s domain. Make sure that the admin account you're trying to sign in with has atleast application administrator permissions to the Azure AD tenant. |
-| The Connector was unable to connect to the service due to networking issues. The Connector tried to access the following URL. | The connector is unable to connect to the Application Proxy cloud service. This may happen if you have a firewall rule blocking the connection. Make sure that you have allowed access to the correct ports and URLS listed in [Application Proxy prerequisites](application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment). |
+| Connector registration failed: Make sure you are an Application Administrator of your Active Directory to register the Connector. Error: 'The registration request was denied.' | The alias you're trying to log in with isn't an admin on this domain. Your Connector is always installed for the directory that owns the user’s domain. Make sure that the admin account you're trying to sign in with has at least application administrator permissions to the Azure AD tenant. |
+| The Connector was unable to connect to the service due to networking issues. The Connector tried to access the following URL. | The connector is unable to connect to the Application Proxy cloud service. This may happen if you have a firewall rule blocking the connection. Make sure that you have allowed access to the correct ports and URLs listed in [Application Proxy prerequisites](application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment). |
 
 ## Kerberos errors
 

articles/active-directory/app-proxy/application-proxy-understand-cors-issues.md

@@ -1,4 +1,4 @@
----
+---
 title: Understand and solve Azure Active Directory Application Proxy CORS issues
 description: Provides an understanding of CORS in Azure Active Directory Application Proxy, and how to identify and solve CORS issues. 
 services: active-directory
@@ -88,6 +88,7 @@ Add a custom HTTP response header on the web service to match the origin request
 
 This modification doesn't require any code changes. You can verify it in the Fiddler traces:
 
+```output
 **Post the Header Addition**\
 HTTP/1.1 200 OK\
 Cache-Control: no-cache\
@@ -100,6 +101,7 @@ Server: Microsoft-IIS/8.5 Microsoft-HTTPAPI/2.0\
 X-AspNet-Version: 4.0.30319\
 X-Powered-By: ASP.NET\
 Content-Length: 17
+```
 
 ### Option 4: Modify the app
 
@@ -112,4 +114,4 @@ Some CORS issues can't be resolved, such as when your app redirects to *login.mi
 ## See also
 - [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../app-proxy/application-proxy-add-on-premises-application.md) 
 - [Plan an Azure AD Application Proxy deployment](application-proxy-deployment-plan.md) 
-- [Remote access to on-premises applications through Azure Active Directory Application Proxy](application-proxy.md)
+- [Remote access to on-premises applications through Azure Active Directory Application Proxy](application-proxy.md)

articles/active-directory/authentication/troubleshoot-sspr-writeback.md

@@ -47,7 +47,7 @@ Azure [GOV endpoints](../../azure-government/compare-azure-government-global-azu
 
 If you need more granularity, see the [list of Microsoft Azure Datacenter IP Ranges](https://www.microsoft.com/download/details.aspx?id=41653). This list is updated every Wednesday and goes into effect the next Monday.
 
-To determine if access to a url and port are restricted in an environment, run the following cmdlet:
+To determine if access to a URL and port are restricted in an environment, run the following cmdlet:
 
 ```powershell
 Test-NetConnection -ComputerName ssprdedicatedsbprodscu.servicebus.windows.net -Port 443

articles/active-directory/azuread-dev/active-directory-acs-migration.md

@@ -108,9 +108,9 @@ As of November 2017, all Access Control components are fully supported and opera
 
 Here's the schedule for deprecating Access Control components:
 
-- **November 2017**:  The Azure AD admin experience in the Azure classic portal [is retired](https://blogs.technet.microsoft.com/enterprisemobility/2017/09/18/marching-into-the-future-of-the-azure-ad-admin-experience-retiring-the-azure-classic-portal/). At this point, namespace management for Access Control is available at a new, dedicated URL: `https://manage.windowsazure.com?restoreClassic=true`. Use this URl to view your existing namespaces, enable and disable namespaces, and to delete namespaces, if you choose to.
+- **November 2017**: The Azure AD admin experience in the Azure classic portal [is retired](https://blogs.technet.microsoft.com/enterprisemobility/2017/09/18/marching-into-the-future-of-the-azure-ad-admin-experience-retiring-the-azure-classic-portal/). At this point, namespace management for Access Control is available at a new, dedicated URL: `https://manage.windowsazure.com?restoreClassic=true`. Use this URL to view your existing namespaces, enable and disable namespaces, and to delete namespaces, if you choose to.
 - **April 2, 2018**: The Azure classic portal is completely retired, meaning Access Control namespace management is no longer available via any URL. At this point, you can't disable or enable, delete, or enumerate your Access Control namespaces. However, the Access Control management portal will be fully functional and located at `https://<namespace>.accesscontrol.windows.net`. All other components of Access Control continue to operate normally.
-- **November 7, 2018**: All Access Control components are permanently shut down. This includes the Access Control management portal, the management service, STS, and the token transformation rule engine. At this point, any requests sent to Access Control (located at \<namespace\>.accesscontrol.windows.net) fail. You should have migrated all existing apps and services to other technologies well before this time.
+- **November 7, 2018**: All Access Control components are permanently shut down. This includes the Access Control management portal, the management service, STS, and the token transformation rule engine. At this point, any requests sent to Access Control (located at `<namespace>.accesscontrol.windows.net`) fail. You should have migrated all existing apps and services to other technologies well before this time.
 
 > [!NOTE]
 > A policy disables namespaces that have not requested a token for a period of time. As of early September 2018, this period of time is currently at 14 days of inactivity, but this will be shortened to 7 days of inactivity in the coming weeks. If you have Access Control namespaces that are currently disabled, you can [download and install ACS PowerShell](#download-and-install-acs-powershell) to re-enable the namespace(s).
@@ -357,4 +357,4 @@ For passthrough authentication with arbitrary token transformation, there is no
 
 ## Questions, concerns, and feedback
 
-We understand that many Access Control customers won't find a clear migration path after reading this article. You might need some assistance or guidance in determining the right plan. If you would like to discuss your migration scenarios and questions, please leave a comment on this page.
+We understand that many Access Control customers won't find a clear migration path after reading this article. You might need some assistance or guidance in determining the right plan. If you would like to discuss your migration scenarios and questions, please leave a comment on this page.