Merge pull request #142590 from MicrosoftDocs/master

Merge Master to Live, 4 AM

.openpublishing.publish.config.json

@@ -143,7 +143,12 @@
     {
       "path_to_root": "samples-durable-functions",
       "url": "https://github.com/Azure/azure-functions-durable-extension",
-      "branch": "master"
+      "branch": "main"
+    },
+    {
+      "path_to_root": "samples-durable-functions-python",
+      "url": "https://github.com/Azure/azure-functions-durable-python",
+      "branch": "main"
     },
     {
       "path_to_root": "functions-python-tensorflow-tutorial",

.openpublishing.redirection.json

@@ -14166,6 +14166,11 @@
       "redirect_url": "/azure/cosmos-db/create-mongodb-dotnet",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/cosmos-db/table-storage-overview.md",
+      "redirect_url": "/azure/storage/tables/table-storage-overview",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/documentdb/documentdb-create-mongodb-account.md",
       "redirect_url": "/azure/cosmos-db/create-mongodb-dotnet#create-account",

articles/active-directory/develop/active-directory-optional-claims.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: how-to
 ms.workload: identity
-ms.date: 1/05/2021
+ms.date: 1/06/2021
 ms.author: ryanwi
 ms.reviewer: paulgarn, hirsin, keyam
 ms.custom: aaddev
@@ -83,10 +83,12 @@ These claims are always included in v1.0 Azure AD tokens, but not included in v2
 | `given_name`  | First name                      | Provides the first or "given" name of the user, as set on the user object.<br>"given_name": "Frank"                   | Supported in MSA and Azure AD.  Requires the `profile` scope. |
 | `upn`         | User Principal Name | An identifer for the user that can be used with the username_hint parameter.  Not a durable identifier for the user and should not be used to uniquely identity user information (for example, as a database key). Instead, use the user object ID (`oid`) as a database key. Users signing in with an [alternate login ID](../authentication/howto-authentication-use-email-signin.md) should not be shown their User Principal Name (UPN). Instead, use the following `preferred_username` claim for displaying sign-in state to the user. | See [additional properties](#additional-properties-of-optional-claims) below for configuration of the claim. Requires the `profile` scope.|
 
+## v1.0-specific optional claims set
+
+Some of the improvements of the v2 token format are available to apps that use the v1 token format, as they help improve security and reliability. These will not take effect for ID tokens requested from the v2 endpoint, nor access tokens for APIs that use the v2 token format. These only apply to JWTs, not SAML tokens. 
 
 **Table 4: v1.0-only optional claims**
 
-Some of the improvements of the v2 token format are available to apps that use the v1 token format, as they help improve security and reliability. These will not take effect for ID tokens requested from the v2 endpoint, nor access tokens for APIs that use the v2 token format. 
 
 | JWT Claim     | Name                            | Description | Notes |
 |---------------|---------------------------------|-------------|-------|

articles/active-directory/hybrid/how-to-connect-health-diagnose-sync-errors.md

@@ -136,6 +136,9 @@ The user with conflicting attribute in Azure AD should be cleaned before you can
 **Updating source anchor to cloud-based user in your tenant is not supported.**  
 Cloud-based user in Azure AD should not have source anchor. Updating source anchor is not supported in this case. Manual fix is required from on premises. 
 
+**The fix process failed to update the values.**
+The specific settings such as [UserWriteback in Azure AD Connect](https://docs.microsoft.com/azure/active-directory/hybrid/how-to-connect-preview#user-writeback) is not supported. Please disable in the settings. 
+
 ## FAQ
 **Q.** What happens if execution of the **Apply Fix** fails?  
 **A.** If execution fails, it's possible that Azure AD Connect is running an export error. Refresh the portal page and retry after the next sync. The default sync cycle is 30 minutes. 

articles/active-directory/identity-protection/troubleshooting-identity-protection-faq.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: identity-protection
 ms.topic: troubleshooting
-ms.date: 10/07/2020
+ms.date: 01/07/2021
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -32,7 +32,7 @@ There is a current known issue causing latency in the user risk dismissal flow.
 
 If you are an Azure AD Identity Protection customer, go to the [risky users](howto-identity-protection-investigate-risk.md#risky-users) view and click on an at-risk user. In the drawer at the bottom, tab ‘Risk history’ will show all the events that led to a user risk change. To see all risky sign-ins for the user, click on ‘User’s risky sign-ins’. To see all risk detections for this user, click on ‘User’s risk detections’.
 
-## Why was my sign-in blocked but Identity Protection didn't generate a risk detection?
+### Why was my sign-in blocked but Identity Protection didn't generate a risk detection?
 Sign-ins can be blocked for several reasons. It is important to note that Identity Protection only generates risk detections when correct credentials are used in the authentication request. If a user uses incorrect credentials, it will not be flagged by Identity Protection since there is not of risk of credential compromise unless a bad actor uses the correct credentials. Some reasons a user can be blocked from signing that will not generate an Identity Protection detection include:
 * The **IP can been blocked** due to malicious activity from the IP address. The IP blocked message does not differentiate whether the credentials were correct or not. If the IP is blocked and correct credentials are not used, it will not generate an Identity Protection detection
 * **[Smart Lockout](../authentication/howto-password-smart-lockout.md)** can block the account from signing-in after multiple failed attempts
@@ -93,3 +93,7 @@ Given the user risk is cumulative in nature and does not expire, a user may have
 ### Why does a sign-in have a “sign-in risk (aggregate)” score of High when the detections associated with it are of low or medium risk?
 
 The high aggregate risk score could be based on other features of the sign-in, or the fact that more than one detection fired for that sign-in. And conversely, a sign-in may have a sign-in risk (aggregate) of Medium even if the detections associated with the sign-in are of High risk.
+
+### What is the difference between the "Activity from anonymous IP address" and "Anonymous IP address" detections?
+
+The "Anonymous IP address" detection's source is Azure AD Identity Protection, while the "Activity from anonymous IP address" detection is integrated from MCAS (Microsoft Cloud App Security). While they have very similar names and it is possible that you may see overlap in these signals, they have distinct back-end detections.

articles/azure-functions/durable/durable-functions-cloud-backup.md

@@ -67,6 +67,23 @@ Notice the `yield context.df.Task.all(tasks);` line. All the individual calls to
 
 After yielding from `context.df.Task.all`, we know that all function calls have completed and have returned values back to us. Each call to `E2_CopyFileToBlob` returns the number of bytes uploaded, so calculating the sum total byte count is a matter of adding all those return values together.
 
+# [Python](#tab/python)
+
+The function uses the standard *function.json* for orchestrator functions.
+
+[!code-json[Main](~/samples-durable-functions-python/samples/fan_in_fan_out/E2_BackupSiteContent/function.json)]
+
+Here is the code that implements the orchestrator function:
+
+[!code-python[Main](~/samples-durable-functions-python/samples/fan_in_fan_out/E2_BackupSiteContent/\_\_init\_\_.py)]
+
+Notice the `yield context.task_all(tasks);` line. All the individual calls to the `E2_CopyFileToBlob` function were *not* yielded, which allows them to run in parallel. When we pass this array of tasks to `context.task_all`, we get back a task that won't complete *until all the copy operations have completed*. If you're familiar with [`asyncio.gather`](https://docs.python.org/3/library/asyncio-task.html#asyncio.gather) in Python, then this is not new to you. The difference is that these tasks could be running on multiple virtual machines concurrently, and the Durable Functions extension ensures that the end-to-end execution is resilient to process recycling.
+
+> [!NOTE]
+> Although tasks are conceptually similar to Python awaitables, orchestrator functions should use `yield` as well as the `context.task_all` and `context.task_any` APIs to manage task parallelization.
+
+After yielding from `context.task_all`, we know that all function calls have completed and have returned values back to us. Each call to `E2_CopyFileToBlob` returns the number of bytes uploaded, so we can calculate the sum total byte count by adding all the return values together.
+
 ---
 
 ### Helper activity functions
@@ -91,6 +108,16 @@ And here is the implementation:
 
 The function uses the `readdirp` module (version 2.x) to recursively read the directory structure.
 
+# [Python](#tab/python)
+
+The *function.json* file for `E2_GetFileList` looks like the following:
+
+[!code-json[Main](~/samples-durable-functions-python/samples/fan_in_fan_out/E2_GetFileList/function.json)]
+
+And here is the implementation:
+
+[!code-python[Main](~/samples-durable-functions-python/samples/fan_in_fan_out/E2_GetFileList/\_\_init\_\_.py)]
+
 ---
 
 > [!NOTE]
@@ -117,6 +144,16 @@ The JavaScript implementation uses the [Azure Storage SDK for Node](https://gith
 
 [!code-javascript[Main](~/samples-durable-functions/samples/javascript/E2_CopyFileToBlob/index.js)]
 
+# [Python](#tab/python)
+
+The *function.json* file for `E2_CopyFileToBlob` is similarly simple:
+
+[!code-json[Main](~/samples-durable-functions-python/samples/fan_in_fan_out/E2_CopyFileToBlob/function.json)]
+
+The Python implementation uses the [Azure Storage SDK for Python](https://github.com/Azure/azure-storage-python) to upload the files to Azure Blob Storage.
+
+[!code-python[Main](~/samples-durable-functions-python/samples/fan_in_fan_out/E2_CopyFileToBlob/\_\_init\_\_.py)]
+
 ---
 
 The implementation loads the file from disk and asynchronously streams the contents into a blob of the same name in the "backups" container. The return value is the number of bytes copied to storage, that is then used by the orchestrator function to compute the aggregate sum.
@@ -126,7 +163,7 @@ The implementation loads the file from disk and asynchronously streams the conte
 
 ## Run the sample
 
-You can start the orchestration by sending the following HTTP POST request.
+You can start the orchestration, on Windows, by sending the following HTTP POST request.
 
 ```
 POST http://{host}/orchestrators/E2_BackupSiteContent
@@ -136,6 +173,16 @@ Content-Length: 20
 "D:\\home\\LogFiles"
 ```
 
+Alternatively, on a Linux Function App (Python currently only runs on Linux for App Service), you can start the orchestration like so:
+
+```
+POST http://{host}/orchestrators/E2_BackupSiteContent
+Content-Type: application/json
+Content-Length: 20
+
+"/home/site/wwwroot"
+```
+
 > [!NOTE]
 > The `HttpStart` function that you are invoking only works with JSON-formatted content. For this reason, the `Content-Type: application/json` header is required and the directory path is encoded as a JSON string. Moreover, HTTP snippet assumes there is an entry in the `host.json` file which removes the default `api/` prefix from all HTTP trigger functions URLs. You can find the markup for this configuration in the `host.json` file in the samples.