Merge pull request #87467 from MicrosoftDocs/repo_sync_working_branch

huypub · web-flow · commit 44b45dc51d00 · 2019-09-05T09:46:10.000-07:00
Confirm merge from repo_sync_working_branch to master to sync with https://github.com/Microsoft/azure-docs (branch master)
diff --git a/articles/active-directory/reports-monitoring/reference-sign-ins-error-codes.md b/articles/active-directory/reports-monitoring/reference-sign-ins-error-codes.md
@@ -150,6 +150,8 @@ You can also programmatically access the sign-in data using the [reporting API](
 |70018|Invalid verification code due to User typing in wrong user code for device code flow. Authorization is not approved.|
 |70019|Verification code expired. Have the user retry the sign-in.|
 |70037|Incorrect challenge response provided. Remote auth session denied.|
+|70043|Azure Conditional Access session management forces the session to expire|
+|70044|Azure Conditional Access session management forces the session to expire|
 |75001|An error occurred during SAML message binding.|
 |75003|The application returned an error related to unsupported Binding (SAML protocol response cannot be sent via bindings other than HTTP POST). Contact the application owner.|
 |75005|Azure AD doesn’t support the SAML Request sent by the application for Single Sign-on. Contact the application owner.|
diff --git a/articles/azure-functions/durable/durable-functions-bindings.md b/articles/azure-functions/durable/durable-functions-bindings.md
@@ -46,7 +46,7 @@ Here are some notes about the orchestration trigger:
 * **Return values** - Return values are serialized to JSON and persisted to the orchestration history table in Azure Table storage. These return values can be queried by the orchestration client binding, described later.
 
 > [!WARNING]
-> Orchestrator functions should never use any input or output bindings other than the orchestration trigger binding. Doing so has the potential to cause problems with the Durable Task extension because those bindings may not obey the single-threading and I/O rules.
+> Orchestrator functions should never use any input or output bindings other than the orchestration trigger binding. Doing so has the potential to cause problems with the Durable Task extension because those bindings may not obey the single-threading and I/O rules. If you'd like to use other bindings, add them to an Activity function called from your Orchestrator function.
 
 > [!WARNING]
 > JavaScript orchestrator functions should never be declared `async`.
@@ -237,6 +237,35 @@ public static async Task<dynamic> Mapper([ActivityTrigger] DurableActivityContex
 }
 ```
 
+### Using input and output bindings
+
+You can use regular input and output bindings in addition to the activity trigger binding. For example, you can take the input to your activity binding, and send a message to an EventHub using the EventHub output binding:
+
+```json
+{
+  "bindings": [
+    {
+      "name": "message",
+      "type": "activityTrigger",
+      "direction": "in"
+    },
+    {
+      "type": "eventHub",
+      "name": "outputEventHubMessage",
+      "connection": "EventhubConnectionSetting",
+      "eventHubName": "eh_messages",
+      "direction": "out"
+  }
+  ]
+}
+```
+
+```javascript
+module.exports = async function (context) {
+    context.bindings.outputEventHubMessage = context.bindings.message;
+};
+```
+
 ## Orchestration client
 
 The orchestration client binding enables you to write functions which interact with orchestrator functions. For example, you can act on orchestration instances in the following ways:
@@ -360,4 +389,4 @@ More details on starting instances can be found in [Instance management](durable
 ## Next steps
 
 > [!div class="nextstepaction"]
-> [Learn about checkpointing and replay behaviors](durable-functions-checkpointing-and-replay.md)
+> [Learn about checkpointing and replay behaviors](durable-functions-checkpointing-and-replay.md)
diff --git a/articles/data-explorer/data-lake-query-data.md b/articles/data-explorer/data-lake-query-data.md
@@ -45,6 +45,7 @@ Azure Data Explorer integrates with Azure Blob Storage and Azure Data Lake Stora
     > * Increased performance is expected with more granular partitioning. For example, queries over external tables with daily partitions, will have better performance than those queries with monthly partitioned tables.
     > * When you define an external table with partitions, the storage structure is expected to be identical.
 For example, if the table is defined with a DateTime partition in yyyy/MM/dd format (default), the URI storage file path should be *container1/yyyy/MM/dd/all_exported_blobs*. 
+    > * If the external table is partitioned by a datetime column, always include a time filter for a closed range in your query (for example, the query - `ArchivedProducts | where Timestamp between (ago(1h) .. 10m)` - should perform better than this (opened range) one - `ArchivedProducts | where Timestamp > ago(1h)` ). 
 
 1. The external table is visible in the left pane of the Web UI
 
diff --git a/articles/data-factory/create-self-hosted-integration-runtime.md b/articles/data-factory/create-self-hosted-integration-runtime.md
@@ -74,6 +74,9 @@ Here is a high-level data flow for the summary of steps for copying with a self-
 - If the host machine hibernates, the self-hosted integration runtime does not respond to data requests. Configure an appropriate power plan on the computer before you install the self-hosted integration runtime. If the machine is configured to hibernate, the self-hosted integration runtime installation prompts a message.
 - You must be an administrator on the machine to install and configure the self-hosted integration runtime successfully.
 - Copy activity runs happen on a specific frequency. Resource usage (CPU, memory) on the machine follows the same pattern with peak and idle times. Resource utilization also depends heavily on the amount of data being moved. When multiple copy jobs are in progress, you see resource usage go up during peak times.
+- Tasks may fail if extracting data in Parquet, ORC, or Avro formats. The file creation runs on the self-hosted integration machine and requires the following pre-requisites to work as expected (see [Parquet format in Azure Data Factory](https://docs.microsoft.com/azure/data-factory/format-parquet#using-self-hosted-integration-runtime)).
+    - [Visual C++ 2010 Redistributable](https://download.microsoft.com/download/3/2/2/3224B87F-CFA0-4E70-BDA3-3DE650EFEBA5/vcredist_x64.exe) package (x64)
+    - Java Runtime (JRE) version 8 from a JRE provider such as [Adopt OpenJDK](https://adoptopenjdk.net/), ensuring that the `JAVA_HOME` environment variable is set.
 
 ## Installation best practices
 You can install the self-hosted integration runtime by downloading an MSI setup package from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=39717). See [Move data between on-premises and cloud article](tutorial-hybrid-copy-powershell.md) for step-by-step instructions.
diff --git a/articles/key-vault/key-vault-overview-storage-keys-powershell.md b/articles/key-vault/key-vault-overview-storage-keys-powershell.md
@@ -106,7 +106,7 @@ Using the same PowerShell session, update the Key Vault access policy for manage
 ```azurepowershell-interactive
 # Give your user principal access to all storage account permissions, on your Key Vault instance
 
-Set-AzKeyVaultAccessPolicy -VaultName $keyVaultName -UserPrincipalName $userId -PermissionsToStorage get, list, listsas, delete, set, update, regeneratekey, recover, backup, restore, purge
+Set-AzKeyVaultAccessPolicy -VaultName $keyVaultName -UserPrincipalName $userId -PermissionsToStorage get, list, delete, set, update, regeneratekey, getsas, listsas, deletesas, setsas, recover, backup, restore, purge
 ```
 
 Note that permissions for storage accounts aren't available on the storage account "Access policies" page in the Azure portal.
diff --git a/articles/service-health/alerts-activity-log-service-notifications.md b/articles/service-health/alerts-activity-log-service-notifications.md
@@ -56,8 +56,8 @@ For information on how to configure service health notification alerts by using
 
     ![The "Add activity log alert" dialog box](media/alerts-activity-log-service-notifications/activity-log-alert-new-ux.png)
 
-> [!NOTE]
-> This subscription is used to save the activity log alert. The alert resource is deployed to this subscription and monitors events in the activity log for it.
+    > [!NOTE]
+    > This subscription is used to save the activity log alert. The alert resource is deployed to this subscription and monitors events in the activity log for it.
 
 1. Choose the **Event types** you want to be alerted for: *Service issue*, *Planned maintenance*, and *Health advisories* 
 
@@ -86,7 +86,6 @@ Learn how to [Configure webhook notifications for existing problem management sy
 >[!NOTE]
 >The action group defined in these steps is reusable as an existing action group for all future alert definitions.
 >
->
 
 ## Alert with existing action group using Azure portal
 
diff --git a/articles/site-recovery/azure-to-azure-tutorial-failback.md b/articles/site-recovery/azure-to-azure-tutorial-failback.md
@@ -40,26 +40,19 @@ After VMs are reprotected, you can fail back to the primary region as needed.
 
     ![Failback to primary](./media/site-recovery-azure-to-azure-failback/azure-to-azure-failback.png)
 
-3. Select **Test failover** to perform a test failover back to the primary region.
-4. Select the recovery point and virtual network for the test failover, and then select **OK**. You can review the test VM created in the primary region.
-5. After the test failover finishes successfully, select **Cleanup test failover** to clean up resources created in the source region for the test failover.
-6. In **Replicated items**, select the VM, and then select **Failover**.
-7. In **Failover**, select a recovery point to fail over to:
+2. In **Replicated items**, select the VM, and then select **Failover**.
+3. In **Failover**, select a recovery point to fail over to:
     - **Latest (default)**: Processes all the data in the Site Recovery service and provides the lowest recovery point objective (RPO).
     - **Latest processed**: Reverts the VM to the latest recovery point that has been processed by Site Recovery.
     - **Custom**: Fails over to a particular recovery point. This option is useful for performing a test failover.
-
-8. Select **Shut down machine before beginning failover** if you want Site Recovery to attempt a shutdown of source VMs before triggering the failover. The failover continues even if shutdown fails. Note that Site Recovery doesn't clean up the source after failover.
-9. Follow the failover progress on the **Jobs** page.
-10. After the failover is complete, validate the VM by logging in to it. You can change the recovery point as needed.
-11. After you've verified the failover, select **Commit the failover**. Committing deletes all the available recovery points. The change recovery point option is no longer available.
-12. The VM should show as failed over and failed back.
+4. Select **Shut down machine before beginning failover** if you want Site Recovery to attempt a shutdown of VMs in DR region before triggering the failover. The failover continues even if shutdown fails. 
+5. Follow the failover progress on the **Jobs** page.
+6. After the failover is complete, validate the VM by logging in to it. You can change the recovery point as needed.
+7. After you've verified the failover, select **Commit the failover**. Committing deletes all the available recovery points. The change recovery point option is no longer available.
+8. The VM should show as failed over and failed back.
 
     ![VM at primary and secondary regions](./media/site-recovery-azure-to-azure-failback/azure-to-azure-failback-vm-view.png)
 
-> [!NOTE]
-> The disaster recovery VMs will remain in the shutdown/deallocated state. This is by design because Site Recovery saves the VM information, which might be useful for failover from the primary to the secondary region later. You aren't charged for the deallocated VMs, so they should be kept as they are.
-
 ## Next steps
 
 [Learn more](azure-to-azure-how-to-reprotect.md#what-happens-during-reprotection) about the reprotection flow.
diff --git a/articles/site-recovery/site-recovery-failover.md b/articles/site-recovery/site-recovery-failover.md
@@ -22,8 +22,8 @@ Use the following table to know about the failover options provided by Azure Sit
 
 | Scenario | Application recovery requirement | Workflow for Hyper-V | Workflow for VMware
 |---|--|--|--|
-|Planned failover due to an upcoming datacenter downtime| Zero data loss for the application when a planned activity is performed| For Hyper-V, ASR replicates data at a copy frequency that is specified by the user. Planned Failover is used to override the frequency and replicate the final changes before a failover is initiated. <br/> <br/> 1.	Plan a maintenance window as per your business's change management process. <br/><br/> 2.Notify users of upcoming downtime. <br/><br/> 3. Take the user-facing application offline.<br/><br/>4.Initiate Planned Failover using the ASR portal. The on-premises virtual machine is automatically shut-down.<br/><br/>Effective application data loss = 0 <br/><br/>A journal of recovery points is also provided in a retention window for a user who wants to use an older recovery point. (24 hours retention for Hyper-V). If replication has been stopped beyond the time frame of the retention window, customers may still be able to failover using the latest available recovery points. | For VMware, ASR replicates data continually using CDP. Failover gives the user the option to failover to the Latest data (including post application shut-down)<br/><br/> 1. Plan a maintenance window as per the change management process <br/><br/>2.Notify users of upcoming downtime <br/><br/>3.	Take the user-facing application offline. <br/><br/>4.	Initiate a Planned Failover using ASR portal to the Latest point after the application is offline. Use the "Unplanned Failover" option on the portal and select the Latest point to failover. The on-premises virtual machine is automatically shut-down.<br/><br/>Effective application data loss = 0 <br/><br/>A journal of recovery points in a retention window is provided for a customer who wants to use an older recovery point. (72 hours of retention for VMware). If replication has been stopped beyond the time frame of the retention window, customers may still be able to failover using the latest available recovery points.
-|Failover due to an unplanned datacenter downtime (natural or IT disaster) | Minimal data loss for the application | 1.Initiate the organization’s BCP plan <br/><br/>2. Initiate Unplanned Failover using ASR portal to the Latest or a point from the retention window (journal).| 1.	Initiate the organization’s BCP plan. <br/><br/>2.	Initiate unplanned Failover using ASR portal to the Latest or a point from the retention window (journal).
+|Planned failover due to an upcoming datacenter downtime| Zero data loss for the application when a planned activity is performed| For Hyper-V, ASR replicates data at a copy frequency that is specified by the user. Planned Failover is used to override the frequency and replicate the final changes before a failover is initiated. <br/> <br/> 1. Plan a maintenance window as per your business's change management process. <br/><br/> 2. Notify users of upcoming downtime. <br/><br/> 3. Take the user-facing application offline.<br/><br/>4. Initiate Planned Failover using the ASR portal. The on-premises virtual machine is automatically shut-down.<br/><br/>Effective application data loss = 0 <br/><br/>A journal of recovery points is also provided in a retention window for a user who wants to use an older recovery point. (24 hours retention for Hyper-V). If replication has been stopped beyond the time frame of the retention window, customers may still be able to failover using the latest available recovery points. | For VMware, ASR replicates data continually using CDP. Failover gives the user the option to failover to the Latest data (including post application shut-down)<br/><br/> 1. Plan a maintenance window as per the change management process <br/><br/>2.Notify users of upcoming downtime <br/><br/>3.	Take the user-facing application offline.<br/><br/>4. Initiate a Planned Failover using ASR portal to the Latest point after the application is offline. Use the "Planned Failover" option on the portal and select the Latest point to failover. The on-premises virtual machine is automatically shut-down.<br/><br/>Effective application data loss = 0 <br/><br/>A journal of recovery points in a retention window is provided for a customer who wants to use an older recovery point. (72 hours of retention for VMware). If replication has been stopped beyond the time frame of the retention window, customers may still be able to failover using the latest available recovery points.
+|Failover due to an unplanned datacenter downtime (natural or IT disaster) | Minimal data loss for the application | 1. Initiate the organization’s BCP plan <br/><br/>2. Initiate Unplanned Failover using ASR portal to the Latest or a point from the retention window (journal).| 1. Initiate the organization’s BCP plan. <br/><br/>2. Initiate unplanned Failover using ASR portal to the Latest or a point from the retention window (journal).
 
 
 ## Run a failover
diff --git a/articles/virtual-machines/extensions/agent-windows.md b/articles/virtual-machines/extensions/agent-windows.md
@@ -63,6 +63,9 @@ The VM Agent can be installed by double-clicking the Windows installer file. For
 msiexec.exe /i WindowsAzureVmAgent.2.7.1198.778.rd_art_stable.160617-1120.fre /quiet
 ```
 
+### Prerequisites
+The Windows VM Agent needs at least Windows Server 2008 R2 (64-bits) to run, with the .Net Framework 4.0.
+
 ## Detect the VM Agent
 
 ### PowerShell
diff --git a/articles/virtual-network/virtual-networks-faq.md b/articles/virtual-network/virtual-networks-faq.md
