Merge pull request #220946 from MicrosoftDocs/repo_sync_working_branch

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

Author: huypub

articles/active-directory/authentication/how-to-mfa-number-match.md

@@ -16,7 +16,7 @@ ms.collection: M365-identity-device-management
 This topic covers how to enable number matching in Microsoft Authenticator push notifications to improve user sign-in security.  
 
 >[!NOTE]
->Number matching is a key security upgrade to traditional second factor notifications in Microsoft Authenticator that will begin to be enabled by default for all users starting February 27, 2023.<br> 
+>Number matching is a key security upgrade to traditional second factor notifications in Microsoft Authenticator. We will remove the admin controls and enforce the number match experience tenant-wide for all users starting February 27, 2023.<br> 
 >We highly recommend enabling number matching in the near term for improved sign-in security.
 
 ## Prerequisites

articles/search/search-howto-index-one-to-many-blobs.md

@@ -112,6 +112,30 @@ If you do want to set up an explicit field mapping, make sure that the _sourceFi
 > [!NOTE]
 > The approach used by `AzureSearch_DocumentKey` of ensuring uniqueness per extracted entity is subject to change and therefore you should not rely on it's value for your application's needs.
 
+## Specifiying the index key field in your data
+
+Assuming the same index definition as the previous example and **parsingMode** is set to `jsonLines` without specifying any explicit field mappings so the mappings look like in the first example, suppose your blob container has blobs with the following structure:
+
+_Blob1.json_
+
+```json
+id, temperature, pressure, timestamp
+1, 100, 100,"2019-02-13T00:00:00Z" 
+2, 33, 30,"2019-02-14T00:00:00Z"
+```
+
+_Blob2.json_
+
+```json
+id, temperature, pressure, timestamp
+1, 1, 1,"2018-01-12T00:00:00Z" 
+2, 120, 3,"2013-05-11T00:00:00Z" 
+```
+
+Notice that each document contains the `id` field, which is defined as the `key` field in the index. In such a case, even though a document-unique `AzureSearch_DocumentKey` will be generated, it won't be used as the "key" for the document. Rather, the value of the `id` field will be mapped to the `key` field
+
+Similar to the example above, this mapping will _not_ result in four documents showing up in the index, because the `id` field is not unique _across blobs_. When this is the case, any json entry that specifies an `id` will result in a merge on the existing document instead of an upload of a new document, and the state of the index will reflect the latest read entry with the specified `id`.
+
 ## Next steps
 
 If you aren't already familiar with the basic structure and workflow of blob indexing, you should review [Indexing Azure Blob Storage with Azure Cognitive Search](search-howto-index-json-blobs.md) first. For more information about parsing modes for different blob content types, review the following articles.