Merge pull request #100476 from MicrosoftDocs/repo_sync_working_branch

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

Author: huypub

articles/active-directory/cloud-provisioning/what-is-cloud-provisioning.md

@@ -57,6 +57,7 @@ The following table provides a comparison between Azure AD Connect and Azure AD
 | Support for writeback (passwords, devices, groups) |● | |
 | Azure AD Domain Services support|● | |
 | Exchange hybrid configuration |● | |
+| Support for more than 50,000 objects per AD domain |● | |
 
 ## Next steps 
 

articles/active-directory/develop/quickstart-v2-javascript.md

@@ -88,7 +88,7 @@ var msalConfig = {
     auth: {
         clientId: "Enter_the_Application_Id_here",
         authority: "https://login.microsoftonline.com/Enter_the_Tenant_info_here",
-        redirectURI: "http://localhost:30662/"
+        redirectUri: "http://localhost:30662/"
     },
     cache: {
         cacheLocation: "localStorage",

articles/active-directory/hybrid/how-to-connect-install-prerequisites.md

@@ -75,7 +75,7 @@ To learn more, see:
 ### SQL Server used by Azure AD Connect
 * Azure AD Connect requires a SQL Server database to store identity data. By default a SQL Server 2012 Express LocalDB (a light version of SQL Server Express) is installed. SQL Server Express has a 10GB size limit that enables you to manage approximately 100,000 objects. If you need to manage a higher volume of directory objects, you need to point the installation wizard to a different installation of SQL Server. The type of SQL Server installation can impact the [performance of Azure AD Connect](https://docs.microsoft.com/azure/active-directory/hybrid/plan-connect-performance-factors#sql-database-factors).
 * If you use a different installation of SQL Server, then these requirements apply:
-  * Azure AD Connect supports all versions of Microsoft SQL Server from 2008 R2 (with latest Service Pack) to SQL Server 2019. Microsoft Azure SQL Database is **not supported** as a database.
+  * Azure AD Connect supports all versions of Microsoft SQL Server from 2012 (with latest Service Pack) to SQL Server 2019. Microsoft Azure SQL Database is **not supported** as a database.
   * You must use a case-insensitive SQL collation. These collations are identified with a \_CI_ in their name. It is **not supported** to use a case-sensitive collation, identified by \_CS_ in their name.
   * You can only have one sync engine per SQL instance. It is **not supported** to share a SQL instance with FIM/MIM Sync, DirSync, or Azure AD Sync.
 

articles/api-management/api-management-howto-api-inspector.md

@@ -44,10 +44,12 @@ In this tutorial, you learn how to:
 4. Select **GetSpeakers** operation.
 5. Make sure to include an HTTP header named **Ocp-Apim-Trace** with the value set to **true**.
 
-    > [!NOTE]
-    > If Ocp-Apim-Subscription-Key is not automatically populated, you can retrieve it by going to the Developer Portal and exposing the keys on the profile page.
+   > [!NOTE]
+   > * If Ocp-Apim-Subscription-Key is not automatically populated, you can retrieve it by going to the Developer Portal and exposing the keys on the profile page.
+   > * To get a trace when the Ocp-Apim-Trace HTTP header is used, the **Allow tracing** setting for the subscription key must be enabled. To configure the **Allow tracing** setting, under **API Management** in the left menu, select **Subscriptions**.
+   >   ![Allow tracing on the API Management Subscriptions pane](media/api-management-howto-api-inspector/allowtracing.png)
 
-6. Click **"Send"** to make an API call. 
+6. Click **Send** to make an API call. 
 7. Wait for the call to complete. 
 8. Go to the **Trace** tab in the **API console**. You can click any of the following links to jump to detailed trace info: **inbound**, **backend**, **outbound**.
 

articles/api-management/api-management-howto-deploy-self-hosted-gateway-to-docker.md

@@ -30,7 +30,7 @@ This article provides the steps for deploying self-hosted Azure API Management g
 - [Provision a gateway resource in your API Management instance](api-management-howto-provision-self-hosted-gateway.md)
 
 > [!NOTE]
-> Self-hosted gateway is packaged as a Linux-based Docker container.
+> Self-hosted gateway is packaged as a x86-64 Linux-based Docker container.
 
 ## Deploy the self-hosted gateway to Docker
 

articles/api-management/media/api-management-howto-api-inspector/allowtracing.png

@@ -37,6 +37,7 @@ ASEs are isolated to running only a single customer's applications and are alway
 * Multiple ASEs can be used to scale horizontally. For more information, see [how to set up a geo-distributed app footprint](app-service-app-service-environment-geo-distributed-scale.md).
 * ASEs can be used to configure security architecture, as shown in the AzureCon Deep Dive. To see how the security architecture shown in the AzureCon Deep Dive was configured, see the [article on how to implement a layered security architecture](app-service-app-service-environment-layered-security.md) with App Service environments.
 * Apps running on ASEs can have their access gated by upstream devices, such as web application firewalls (WAFs). For more information, see [Web application firewall (WAF)][AppGW].
+* App Service Environments can be deployed into Availability Zones (AZ) using zone pinning.  See [App Service Environment Support for Availability Zones][ASEAZ] for more details.
 
 ## Dedicated environment ##
 
@@ -98,3 +99,4 @@ ASEv1 uses a different pricing model from ASEv2. In ASEv1, you pay for each vCPU
 [Kudu]: https://azure.microsoft.com/resources/videos/super-secret-kudu-debug-console-for-azure-web-sites/
 [ASEWAF]: app-service-app-service-environment-web-application-firewall.md
 [AppGW]: ../../application-gateway/waf-overview.md
+[ASEAZ]: https://azure.github.io/AppService/2019/12/12/App-Service-Environment-Support-for-Availability-Zones.html

articles/app-service/environment/intro.md

@@ -93,6 +93,17 @@ Application Gateway supports the following cipher suites from which you can choo
 > [!NOTE]
 > SSL cipher suites used for the connection are also based on the type of the certificate being used. In client to application gateway connections, the cipher suites used are based on the type of server certificates on the application gateway listener. In application gateway to backend pool connections, the cipher suites used are based on the type of server certificates on the backend pool servers.
 
+## Known issue
+Application Gateway v2 does not currently support the following ciphers:
+- DHE-RSA-AES128-GCM-SHA256
+- DHE-RSA-AES128-SHA
+- DHE-RSA-AES256-GCM-SHA384
+- DHE-RSA-AES256-SHA
+- DHE-DSS-AES128-SHA256
+- DHE-DSS-AES128-SHA
+- DHE-DSS-AES256-SHA256
+- DHE-DSS-AES256-SHA
+
 ## Next steps
 
 If you want to learn to configure an SSL policy, see [Configure SSL policy on an application gateway](application-gateway-configure-ssl-policy-powershell.md).

articles/application-gateway/application-gateway-ssl-policy-overview.md

@@ -100,7 +100,7 @@ Here is an example response payload for an orchestration instance with `abc123`
 }
 ```
 
-The http response is intended to be compatible with the *Polling Consumer Pattern*. It also includes the following notable response headers:
+The HTTP response is intended to be compatible with the *Polling Consumer Pattern*. It also includes the following notable response headers:
 
 * **Location**: The URL of the status endpoint. This URL contains the same value as the `statusQueryGetUri` field.
 * **Retry-After**: The number of seconds to wait between polling operations. The default value is `10`.

articles/azure-functions/durable/durable-functions-http-api.md

@@ -186,8 +186,8 @@ By default Functions proxies will utilize a shortcut to send API calls from prox
 
 |Key|Value|Description|
 |-|-|-|
-|AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL|true|Calls with a backend url pointing to a function in the local Function App will no longer be sent directly to the function, and will instead be directed back to the HTTP front end for the Function App|
-|AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL|false|This is the default value. Calls with a  backend url pointing to a function in the local Function App will be forwarded directly to that Function|
+|AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL|true|Calls with a backend URL pointing to a function in the local Function App will no longer be sent directly to the function, and will instead be directed back to the HTTP front end for the Function App|
+|AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL|false|This is the default value. Calls with a  backend URL pointing to a function in the local Function App will be forwarded directly to that Function|
 
 
 ## AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES