Merge pull request #100935 from MicrosoftDocs/master

ShannonLeavitt · web-flow · commit 68a85e257499 · 2020-01-13T16:10:22.000+04:00
Merge master to live 4:10 AM
diff --git a/articles/app-service/app-service-web-get-started-windows-container.md b/articles/app-service/app-service-web-get-started-windows-container.md
@@ -159,15 +159,15 @@ The streamed logs looks like this:
 
 ## Use a different parent image
 
-You're free to use a different custom Docker image to run your app. However, you must choose the right [parent image](https://docs.docker.com/develop/develop-images/baseimages/) for the framework you want:
+You're free to use a different custom Docker image to run your app. However, you must choose the right [parent image (base image)](https://docs.docker.com/develop/develop-images/baseimages/) for the framework you want:
 
 - To deploy .NET Framework apps, use a parent image based on the Windows Server Core 2019 [Long-Term Servicing Channel (LTSC)](https://docs.microsoft.com/windows-server/get-started-19/servicing-channels-19#long-term-servicing-channel-ltsc) release. 
 - To deploy .NET Core apps, use a parent image based on the Windows Server Nano 1809 [Semi-Annual Servicing Channel (SAC)](https://docs.microsoft.com/windows-server/get-started-19/servicing-channels-19#semi-annual-channel) release. 
 
 It takes some time to download a parent image during app start-up. However, you can reduce start-up time by using one of the following parent images that are already cached in Azure App Service:
 
 - [mcr.microsoft.com/dotnet/framework/aspnet](https://hub.docker.com/_/microsoft-dotnet-framework-aspnet/):4.7.2-windowsservercore-ltsc2019
-- [mcr.microsoft.com/windows/nanoserver](https://hub.docker.com/_/microsoft-windows-nanoserver/):1809 - this image is the base container used across Microsoft [ASP.NET Core](https://hub.docker.com/_microsoft-dotnet-cores-aspnet) Microsoft Windows Nano Server images.
+- [mcr.microsoft.com/windows/nanoserver](https://hub.docker.com/_/microsoft-windows-nanoserver/):1809 - this image is the base container used across Microsoft [ASP.NET Core](https://hub.docker.com/_/microsoft-dotnet-core-aspnet/) Microsoft Windows Nano Server images.
 
 ## Next steps
 
diff --git a/articles/app-service/containers/how-to-configure-python.md b/articles/app-service/containers/how-to-configure-python.md
@@ -46,7 +46,7 @@ az webapp config set --resource-group <resource-group-name> --name <app-name> --
 
 ## Container characteristics
 
-Python apps deployed to App Service on Linux run within a Docker container that's defined in the GitHub repository, [Python 3.6](https://github.com/Azure-App-Service/python/tree/master/3.6.6) or [Python 3.7](https://github.com/Azure-App-Service/python/tree/master/3.7.0).
+Python apps deployed to App Service on Linux run within a Docker container that's defined in the [App Service Python GitHub repository](https://github.com/Azure-App-Service/python). You can find the image configurations inside the version-specific directories.
 
 This container has the following characteristics:
 
diff --git a/articles/app-service/containers/toc.yml b/articles/app-service/containers/toc.yml
@@ -180,7 +180,7 @@
   - name: Azure CLI
     href: /cli/azure/appservice
   - name: Azure PowerShell
-    href: /powershell
+    href: /powershell/module/az.websites/#app_service
   - name: REST API
     href: /rest/api/appservice/
 - name: Resources
diff --git a/articles/app-service/deploy-zip.md b/articles/app-service/deploy-zip.md
@@ -85,6 +85,8 @@ For more information, see [Kudu documentation](https://github.com/projectkudu/ku
 
 To deploy a WAR file to App Service, send a POST request to `https://<app_name>.scm.azurewebsites.net/api/wardeploy`. The POST request must contain the .war file in the message body. The deployment credentials for your app are provided in the request by using HTTP BASIC authentication.
 
+Always use `/api/wardeploy` when deploying WAR files. This API will expand your WAR file and place it on the shared file drive. using other deployment APIs may result in inconsistent behavior. 
+
 For the HTTP BASIC authentication, you need your App Service deployment credentials. To see how to set your deployment credentials, see [Set and reset user-level credentials](deploy-configure-credentials.md#userscope).
 
 ### With cURL
diff --git a/articles/app-service/toc.yml b/articles/app-service/toc.yml
@@ -220,7 +220,7 @@
   - name: Azure CLI
     href: /cli/azure/appservice
   - name: Azure PowerShell
-    href: /powershell
+    href: /powershell/module/az.websites/#app_service
   - name: REST API
     href: /rest/api/appservice/
   - name: Resource Manager template
diff --git a/articles/automation/automation-secure-asset-encryption.md b/articles/automation/automation-secure-asset-encryption.md
@@ -18,13 +18,13 @@ Based on the top-level key used for the encryption, there are two models for enc
 -	Using Microsoft-managed keys
 -	Using customer-managed keys
 
-### Microsoft-managed Keys
+## Microsoft-managed Keys
 
 By default, your Azure Automation account uses Microsoft-managed keys.
 
 Each secure asset is encrypted and stored in Azure Automation using a unique key (Data Encryption key) that is generated for each automation account. These keys themselves are encrypted and stored in Azure Automation using yet another unique key that is generated for each account called an Account Encryption Key (AEK). These account encryption keys encrypted and stored in Azure Automation using Microsoft Managed Keys. 
 
-### Customer-managed Keys with Key Vault (preview)
+## Customer-managed Keys with Key Vault (preview)
 
 You can manage encryption of secure assets in Azure Automation at the level of an automation account with your own keys. When you specify a customer-managed key at the level of the Automation account, that key is used to protect and control access to the account encryption key for the automation account, which in turn is used to encrypt and decrypt all the secure assets. Customer-managed keys offer greater flexibility to create, rotate, disable, and revoke access controls. You can also audit the encryption keys used to protect your secure assets. 
 
@@ -36,12 +36,12 @@ When you enable encryption with customer-managed keys for an automation account,
 
 A new automation account is always encrypted using Microsoft-managed keys. It's not possible to enable customer-managed keys at the time that the account is created. Customer-managed keys are stored in Azure Key Vault, and the key vault must be provisioned with access policies that grant key permissions to the managed identity that is associated with the automation account. The managed identity is available only after the storage account is created.
 
-When you modify the key being used for Azure Automation secure asset encryption by enabling or disabling customer-managed keys, updating the key version, or specifying a different key, then the encryption of the root key changes, but the secure assets in your Azure Automation account do not need to be re-encrypted.
+When you modify the key being used for Azure Automation secure asset encryption by enabling or disabling customer-managed keys, updating the key version, or specifying a different key, then the encryption of the account encryption key changes, but the secure assets in your Azure Automation account do not need to be re-encrypted.
 
 The following three sections describe the mechanics of enabling customer-managed keys for an Automation account. 
 
 > [!NOTE] 
-> To enable customer-managed keys, you will currently need to make Azure Automation REST APIs using api version 2020-01-13-preview
+> To enable customer-managed keys, you will currently need to make Azure Automation REST API calls using api version 2020-01-13-preview
 
 ### Pre-requisites for using Customer-managed keys in Azure Automation
 
@@ -122,7 +122,7 @@ Request body
 ```
 
 > [!NOTE] 
-> The tenantId and objectId fields must be provided with values of identity.tenantId and identity.principalId from the response of managed identity for the automation account.
+> The **tenantId** and **objectId** fields must be provided with values of **identity.tenantId** and **identity.principalId** respectively from the response of managed identity for the automation account.
 
 ### Change the configuration of automation account to use customer managed key
 
@@ -175,11 +175,11 @@ Sample response
 
 You can rotate a customer-managed key in Azure Key Vault according to your compliance policies. When the key is rotated, you must update the automation account to use the new key URI. 
 
-Rotating the key does not trigger re-encryption of data in the storage account. There is no further action required from the user.
+Rotating the key does not trigger re-encryption of secure assets in the automation account. There is no further action required from the user.
 
-## Revoke access to customer-managed keys
+### Revoke access to customer-managed keys
 
-To revoke access to customer-managed keys, use PowerShell or Azure CLI. For more information, see [Azure Key Vault PowerShell](https://docs.microsoft.com/powershell/module/az.keyvault/) or [Azure Key Vault CLI](https://docs.microsoft.com/cli/azure/keyvault). Revoking access effectively blocks access to all data in the storage account, as the encryption key is inaccessible by Azure Storage.
+To revoke access to customer-managed keys, use PowerShell or Azure CLI. For more information, see [Azure Key Vault PowerShell](https://docs.microsoft.com/powershell/module/az.keyvault/) or [Azure Key Vault CLI](https://docs.microsoft.com/cli/azure/keyvault). Revoking access effectively blocks access to all secure assets in the automation account, as the encryption key is inaccessible by Azure Automation.
 
 ## Next steps
 
diff --git a/articles/backup/tutorial-backup-azure-files.md b/articles/backup/tutorial-backup-azure-files.md
@@ -23,7 +23,6 @@ Before you can back up an Azure file share, ensure that it's present in one of t
 
 Backup for Azure file shares is in preview. Azure file shares in both general-purpose v1 and general-purpose v2 storage accounts are supported. The following backup scenarios aren't supported for Azure file shares:
 
-* You can't protect Azure file shares in storage accounts that have Virtual Networks or Firewall enabled.
 * There is no CLI available for protecting Azure Files using Azure Backup.
 * The maximum number of scheduled backups per day is one.
 * The maximum number of on-demand backups per day is four.
diff --git a/articles/cognitive-services/Speech-Service/batch-transcription.md b/articles/cognitive-services/Speech-Service/batch-transcription.md
@@ -154,6 +154,7 @@ For mono input audio, one transcription result file is being created. For stereo
                   "Duration": number                       'time in milliseconds'
                   "OffsetInSeconds": number                'Real number. Two decimal places'
                   "DurationInSeconds": number              'Real number. Two decimal places'
+                  "Confidence": number                     'between 0 and 1'
                 }
               ]
             }
diff --git a/articles/data-factory/solution-template-bulk-copy-from-files-to-database.md b/articles/data-factory/solution-template-bulk-copy-from-files-to-database.md
@@ -1,5 +1,5 @@
 ---
-title: Bulk Copy from Files to Database
+title: Bulk copy from files to database
 description: Learn how to use a solution template to copy data in bulk from Azure Data Lake Storage Gen2 to Azure Synapse Analytics / Azure SQL Database.
 services: data-factory
 author: linda33wj
@@ -10,7 +10,7 @@ ms.topic: conceptual
 ms.date: 01/08/2020
 ---
 
-# Bulk Copy from Files to Database
+# Bulk copy from files to database
 
 This article describes a solution template that you can use to copy data in bulk from Azure Data Lake Storage Gen2 to Azure Synapse Analytics / Azure SQL Database.
 
diff --git a/articles/event-grid/cloudevents-schema.md b/articles/event-grid/cloudevents-schema.md
@@ -56,7 +56,7 @@ Here is an example of an Azure Blob Storage event in CloudEvents format:
 }
 ```
 
-A detailed description of the available fields, their types, and definitions in CloudEvents v0.1 is [available here](https://github.com/cloudevents/spec/blob/v1.0/spec.md#required-attributes).
+A detailed description of the available fields, their types, and definitions in CloudEvents v1.0 is [available here](https://github.com/cloudevents/spec/blob/v1.0/spec.md#required-attributes).
 
 The headers values for events delivered in the CloudEvents schema and the Event Grid schema are the same except for `content-type`. For CloudEvents schema, that header value is `"content-type":"application/cloudevents+json; charset=utf-8"`. For Event Grid schema, that header value is `"content-type":"application/json; charset=utf-8"`.
 
diff --git a/articles/event-hubs/TOC.yml b/articles/event-hubs/TOC.yml
@@ -164,7 +164,7 @@
       href: event-hubs-service-endpoints.md
     - name: Enable Virtual Networks Integration and Firewalls on Event Hubs Namespace
       href: event-hubs-tutorial-virtual-networks-firewalls.md
-    - name: Configure customer-managed keys for encrypting data at rest (Preview)
+    - name: Configure customer-managed keys for encrypting data at rest
       href: configure-customer-managed-key.md
   - name: Troubleshoot
     items:
diff --git a/articles/search/search-api-preview.md b/articles/search/search-api-preview.md
@@ -1,7 +1,7 @@
 ---
 title: REST API version 2019-05-06-Preview
 titleSuffix: Azure Cognitive Search
-description: Azure Cognitive Search service REST API Version 2019-05-06-Preview includes experimental features such as knowledge store and customer-managed encryption keys.
+description: Azure Cognitive Search service REST API Version 2019-05-06-Preview includes experimental features such as knowledge store and indexer caching for incremental enrichment..
 
 manager: nitinme
 author: brjohnstmsft
@@ -32,8 +32,6 @@ This article describes the `api-version=2019-05-06-Preview` version of Search se
 
 + [Knowledge store](knowledge-store-concept-intro.md) is a new destination of an AI-based enrichment pipeline. The physical data structure exists in Azure Blob storage and Azure Table storage, and it is created and populated when you run an indexer that has an attached cognitive skillset. The definition of a knowledge store itself is specified within a skillset definition. Within the knowledge store definition, you control the physical structures of your data through *projection* elements that determine how data is shaped, whether data is stored in Table storage or Blob storage, and whether there are multiple views.
 
-+ [Customer-managed encryption keys](search-security-manage-encryption-keys.md) for service-side encryption-at-rest is also a new preview feature. In addition to the built-in encryption-at-rest managed by Microsoft, you can apply an additional layer of encryption where you are the sole owner of the keys.
-
 ## Earlier preview features
 
 Features announced in earlier previews are still in public preview. If you're calling an API with an earlier preview api-version, you can continue to use that version or switch to `2019-05-06-Preview` with no changes to expected behavior.
diff --git a/articles/search/search-security-overview.md b/articles/search/search-security-overview.md
@@ -39,7 +39,7 @@ Encryption extends throughout the entire indexing pipeline: from connections, th
 |----------------|-------------|
 | Encryption in transit <br>(HTTPS/SSL/TLS) | Azure Cognitive Search listens on HTTPS port 443. Across the platform, connections to Azure services are encrypted. <br/><br/>All client-to-service Azure Cognitive Search interactions are SSL/TLS 1.2 capable.  Be sure to use TLSv1.2 for SSL connections to your service.|
 | Encryption at rest <br>Microsoft managed keys | Encryption is fully internalized in the indexing process, with no measurable impact on indexing time-to-completion or index size. It occurs automatically on all indexing, including on incremental updates to an index that is not fully encrypted (created before January 2018).<br><br>Internally, encryption is based on [Azure Storage Service Encryption](https://docs.microsoft.com/azure/storage/common/storage-service-encryption), using 256-bit [AES encryption](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard).<br><br> Encryption is internal to Azure Cognitive Search, with certificates and encryption keys managed internally by Microsoft, and universally applied. You cannot turn encryption on or off, manage or substitute your own keys, or view encryption settings in the portal or programmatically.<br><br>Encryption at rest was announced in January 24, 2018 and applies to all service tiers, including the free tier, in all regions. For full encryption, indexes created prior to that date must be dropped and rebuilt in order for encryption to occur. Otherwise, only new data added after January 24 is encrypted.|
-| Encryption at rest <br>Customer managed keys | Encryption with customer managed keys is a **preview** feature that is not available for free services. For paid services, it is only available for search services created on or after January 2019, using the latest preview api-version (api-version=2019-05-06-Preview).<br><br>Azure Cognitive Search indexes and synonym maps can now be encrypted at rest with customer keys managed keys in Azure Key Vault. To learn more, see [Manage encryption keys in Azure Cognitive Search](search-security-manage-encryption-keys.md).<br>This feature is not replacing the default encryption at rest, but rather applied in addition to it.<br>Enabling this feature will increase index size and degrade query performance. Based on observations to date, you can expect to see an increase of 30%-60% in query times, although actual performance will vary depending on the index definition and types of queries. Because of this performance impact, we recommend that you only enable this feature on indexes that really require it.
+| Encryption at rest <br>Customer managed keys | Encryption with customer managed keys is now generally available.<br><br>Azure Cognitive Search indexes and synonym maps can now be encrypted at rest with customer keys managed keys in Azure Key Vault. To learn more, see [Manage encryption keys in Azure Cognitive Search](search-security-manage-encryption-keys.md).<br>This feature is not replacing the default encryption at rest, but rather applied in addition to it.<br>Enabling this feature will increase index size and degrade query performance. Based on observations to date, you can expect to see an increase of 30%-60% in query times, although actual performance will vary depending on the index definition and types of queries. Because of this performance impact, we recommend that you only enable this feature on indexes that really require it.
 
 ## Azure-wide user access controls
 
diff --git a/articles/search/search-what-is-azure-search.md b/articles/search/search-what-is-azure-search.md
@@ -63,7 +63,7 @@ Azure Cognitive Search is well suited for the following application scenarios:
 |-------------------|----------|
 | Tools for prototyping and inspection | In the portal, you can use the [**Import data wizard**](search-import-data-portal.md) to configure indexers, index designer to stand up an index, and [**Search explorer**](search-explorer.md) to test queries and refine scoring profiles. You can also open any index to view its schema. |
 | Monitoring and diagnostics | [**Enable monitoring features**](search-monitor-usage.md) to go beyond the metrics-at-a-glance that are always visible in the portal. Metrics on queries per second, latency, and throttling are captured and reported in portal pages with no additional configuration required.|
-| Server-side encryption | [**Microsoft-managed encryption-at-rest**](search-security-overview.md#encrypted-transmission-and-storage) is built into the internal storage layer and is irrevocable. Optionally, you can supplement the default encryption with [**customer-managed encryption keys (preview)**](search-security-manage-encryption-keys.md). Keys that you create and manage in Azure Key Vault are used to encrypt indexes and synonym maps in Azure Cognitive Search. |
+| Server-side encryption | [**Microsoft-managed encryption-at-rest**](search-security-overview.md#encrypted-transmission-and-storage) is built into the internal storage layer and is irrevocable. Optionally, you can supplement the default encryption with [**customer-managed encryption keys**](search-security-manage-encryption-keys.md). Keys that you create and manage in Azure Key Vault are used to encrypt indexes and synonym maps in Azure Cognitive Search. |
 | Infrastructure | The **highly available platform** ensures an extremely reliable search service experience. When scaled properly, [Azure Cognitive Search offers a 99.9% SLA](https://azure.microsoft.com/support/legal/sla/search/v1_0/).<br/><br/> **Fully managed and scalable** as an end-to-end solution, Azure Cognitive Search requires absolutely no infrastructure management. Your service can be tailored to your needs by scaling in two dimensions to handle more document storage, higher query loads, or both.<br/><br/>|
 
 ## How to use Azure Cognitive Search
diff --git a/articles/service-bus-messaging/TOC.yml b/articles/service-bus-messaging/TOC.yml
@@ -205,7 +205,7 @@
         href: service-bus-resource-manager-namespace-topic-with-rule.md
   - name: Secure
     items:
-    - name: Configure customer-managed keys for encryption at rest (Preview)
+    - name: Configure customer-managed keys for encryption at rest
       href: configure-customer-managed-key.md
   - name: Troubleshoot
     items:
diff --git a/articles/service-fabric/service-fabric-reliable-services-backup-restore.md b/articles/service-fabric/service-fabric-reliable-services-backup-restore.md
@@ -59,7 +59,7 @@ As shown below, `BackupAsync` takes in a `BackupDescription` object, where one c
 
 ```csharp
 
-BackupDescription myBackupDescription = new BackupDescription(backupOption.Incremental,this.BackupCallbackAsync);
+BackupDescription myBackupDescription = new BackupDescription(BackupOption.Incremental,this.BackupCallbackAsync);
 
 await this.BackupAsync(myBackupDescription);
 
diff --git a/articles/storage/common/account-encryption-key-create.md b/articles/storage/common/account-encryption-key-create.md
diff --git a/articles/virtual-network/service-tags-overview.md b/articles/virtual-network/service-tags-overview.md
diff --git a/articles/vpn-gateway/vpn-gateway-howto-always-on-device-tunnel.md b/articles/vpn-gateway/vpn-gateway-howto-always-on-device-tunnel.md

Original file line number	Diff line number	Diff line change
`@@ -154,6 +154,7 @@ For mono input audio, one transcription result file is being created. For stereo`
`154`	`154`	`"Duration": number 'time in milliseconds'`
`155`	`155`	`"OffsetInSeconds": number 'Real number. Two decimal places'`
`156`	`156`	`"DurationInSeconds": number 'Real number. Two decimal places'`
	`157`	`+ "Confidence": number 'between 0 and 1'`
`157`	`158`	`}`
`158`	`159`	`]`
`159`	`160`	`}`
Original file line number	Diff line number	Diff line change
`@@ -56,7 +56,7 @@ Here is an example of an Azure Blob Storage event in CloudEvents format:`
`56`	`56`	`}`
`57`	`57`	```
`58`	`58`
`59`		`-A detailed description of the available fields, their types, and definitions in CloudEvents v0.1 is [available here](https://github.com/cloudevents/spec/blob/v1.0/spec.md#required-attributes).`
	`59`	`+A detailed description of the available fields, their types, and definitions in CloudEvents v1.0 is [available here](https://github.com/cloudevents/spec/blob/v1.0/spec.md#required-attributes).`
`60`	`60`
`61`	`61`	The headers values for events delivered in the CloudEvents schema and the Event Grid schema are the same except for `content-type`. For CloudEvents schema, that header value is `"content-type":"application/cloudevents+json; charset=utf-8"`. For Event Grid schema, that header value is `"content-type":"application/json; charset=utf-8"`.
`62`	`62`