Merge pull request #222575 from MicrosoftDocs/main

12/28 PM Publish

Author: huypub

articles/active-directory/authentication/concept-mfa-data-residency.md

@@ -6,7 +6,7 @@ services: multi-factor-authentication
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: conceptual
-ms.date: 10/29/2022
+ms.date: 12/13/2022
 
 ms.author: justinha
 author: justinha
@@ -24,7 +24,7 @@ Cloud-based Azure AD multifactor authentication and MFA Server process and store
 
 The Azure AD multifactor authentication service has datacenters in the United States, Europe, and Asia Pacific. The following activities originate from the regional datacenters except where noted:
 
-* Multifactor authentication phone calls originate from datacenters in the customer's region and are routed by global providers. Phone calls using custom greetings always originate from data centers in the United States.
+* Multifactor authentication SMS and phone calls originate from datacenters in the customer's region and are routed by global providers. Phone calls using custom greetings always originate from data centers in the United States.
 * General purpose user authentication requests from other regions are currently processed based on the user's location.
 * Push notifications that use the Microsoft Authenticator app are currently processed in regional datacenters based on the user's location. Vendor-specific device services, such as Apple Push Notification Service or Google Firebase Cloud Messaging, might be outside the user's location.
 
@@ -102,22 +102,12 @@ Standard voice calls may failover to a different region.
 >[!NOTE]
 >The multifactor authentication activity reports contain personal data such as User Principal Name (UPN) and complete phone number.
 
-### NPS extension and AD FS adapter
-
-| Authentication method                                                             | Customer region                      | Activity report location | Service log location |
-|-----------------------------------------------------------------------------------|--------------------------------------|--------------------------|----------------------|
-| OATH software and hardware tokens                                                 | Australia and New Zealand            | Australia/New Zealand    | Cloud in-region      |
-| OATH software and hardware tokens                                                 | Outside of Australia and New Zealand | United States            | Cloud in-region      |
-| Voice calls without custom greetings and all other authentication methods except OATH software and hardware tokens  | Any                               | United States            | Cloud in-region      |
-| Voice calls with custom greetings                                         | Any                                  | United States            | MFA backend in United States |
-
 ### MFA server and cloud-based MFA
 
 | Component  | Authentication method                          | Customer region                      | Activity report location        | Service log location         |
 |------------|------------------------------------------------|--------------------------------------|---------------------------------|------------------------------|
 | MFA server | All methods                                    | Any                                  | United States                   | MFA backend in United States |
-| Cloud MFA  | Standard voice calls and all other methods     | Any                                  | Azure AD Sign-in logs in region | Cloud in-region              |
-| Cloud MFA  | Voice calls with custom greetings              | Any                                  | Azure AD Sign-in logs in region | MFA backend in United States |
+| Cloud MFA  | All methods     | Any                                  | Azure AD Sign-in logs in region | Cloud in-region              |
 
 ## Multifactor authentication activity reports for sovereign clouds
 

articles/active-directory/authentication/howto-authentication-passwordless-phone.md

@@ -7,7 +7,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: how-to
-ms.date: 12/06/2022
+ms.date: 12/28/2022
 
 
 ms.author: justinha
@@ -32,17 +32,14 @@ People who enabled phone sign-in from Microsoft Authenticator see a message that
 1. Choose **Approve**.
 1. Provide their PIN or biometric.
 
-## Multiple accounts on iOS (preview)
+## Multiple accounts on iOS 
 
 You can enable passwordless phone sign-in for multiple accounts in Microsoft Authenticator on any supported iOS device. Consultants, students, and others with multiple accounts in Azure AD can add each account to Microsoft Authenticator and use passwordless phone sign-in for all of them from the same iOS device. 
 
 Previously, admins might not require passwordless sign-in for users with multiple accounts because it requires them to carry more devices for sign-in. By removing the limitation of one user sign-in from a device, admins can more confidently encourage users to register passwordless phone sign-in and use it as their default sign-in method.
 
 The Azure AD accounts can be in the same tenant or different tenants. Guest accounts aren't supported for multiple account sign-ins from one device.
 
->[!NOTE]
->Multiple accounts on iOS is currently in public preview. Some features might not be supported or have limited capabilities. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/). 
-
 ## Prerequisites
 
 To use passwordless phone sign-in with Microsoft Authenticator, the following prerequisites must be met:

articles/active-directory/conditional-access/concept-condition-filters-for-devices.md

@@ -128,6 +128,9 @@ The following device attributes can be used with the filter for devices conditio
 | trustType | Equals, NotEquals | A valid registered state for devices. Supported values are: AzureAD (used for Azure AD joined devices), ServerAD (used for Hybrid Azure AD joined devices), Workplace (used for Azure AD registered devices) | (device.trustType -eq "ServerAD") |
 | extensionAttribute1-15 | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | extensionAttributes1-15 are attributes that customers can use for device objects. Customers can update any of the extensionAttributes1 through 15 with custom values and use them in the filter for devices condition in Conditional Access. Any string value can be used. | (device.extensionAttribute1 -eq "SAW") |
 
+> [!NOTE] 
+> When building complex rules or using too many individual identifiers like deviceid for device identities, keep in mind "The maximum length for the filter rule is 3072 characters".
+
 > [!NOTE] 
 > The `Contains` and the `NotContains` operators work differently depending on attribute types. For string attributes such as `operatingSystem` and `model`, the `Contains` operator indicates whether a specified substring occurs within the attribute. For string collection attributes such as `physicalIds` and `systemLabels`, the `Contains` operator indicates whether a specified string matches one of the whole strings in the collection.
 

articles/active-directory/devices/concept-azure-ad-register.md

@@ -53,7 +53,7 @@ Azure AD registration can be accomplished when accessing a work application for
 
 ## Scenarios
 
-A user in your organization wants to access your benefits enrollment tool from their home PC. Your organization requires that anyone accesses this tool from an Intune compliant device. The user registers their home PC with Azure AD and the required Intune policies are enforced giving the user access to their resources.
+A user in your organization wants to access your benefits enrollment tool from their home PC. Your organization requires that anyone accesses this tool from an Intune compliant device. The user registers their home PC with Azure AD and Enrolls the device in Intune, then the required Intune policies are enforced giving the user access to their resources.
 
 Another user wants to access their organizational email on their personal Android phone that has been rooted. Your company requires a compliant device and has created an Intune compliance policy to block any rooted devices. The employee is stopped from accessing organizational resources on this device.
 

articles/azure-maps/tutorial-creator-indoor-maps.md

@@ -334,7 +334,7 @@ To check the status of the tileset creation process and retrieve the `tilesetId`
 5. Enter the `status URL` you copied in [Create a tileset](#create-a-tileset). The request should look like the following URL:
 
     ```http
-    https://us.atlas.microsoft.com/tilesets/operations/{operationId}?api-version=2.0&subscription-key={Your-Azure-Maps-Subscription-key}
+    https://us.atlas.microsoft.com/tilesets/operations/{operationId}?api-version=2022-09-01-preview&subscription-key={Your-Azure-Maps-Subscription-key}
     ```
 
 6. Select **Send**.

articles/azure-monitor/app/asp-net-core.md

@@ -28,6 +28,9 @@ We'll use an [MVC application](/aspnet/core/tutorials/first-mvc-app) example. If
 
 [!INCLUDE [azure-monitor-log-analytics-rebrand](../../../includes/azure-monitor-instrumentation-key-deprecation.md)]
 
+> [!NOTE]
+> You can also use the Microsoft.Extensions.Logging.ApplicationInsights package to capture logs. For more information, see [Application Insights logging with .NET](ilogger.md). For an example, see [Console application](ilogger.md#console-application).
+
 ## Supported scenarios
 
 The [Application Insights SDK for ASP.NET Core](https://nuget.org/packages/Microsoft.ApplicationInsights.AspNetCore) can monitor your applications no matter where or how they run. If your application is running and has network connectivity to Azure, telemetry can be collected. Application Insights monitoring is supported everywhere .NET Core is supported and covers the following scenarios:

articles/azure-monitor/app/azure-ad-authentication.md

@@ -106,7 +106,7 @@ Application Insights Node.JS supports the credential classes provided by [Azure
 #### DefaultAzureCredential
 
 ```javascript
-let appInsights = require("applicationinsights");
+import appInsights from "applicationinsights";
 import { DefaultAzureCredential } from "@azure/identity"; 
 
 const credential = new DefaultAzureCredential();
@@ -118,7 +118,7 @@ appInsights.defaultClient.config.aadTokenCredential = credential;
 #### ClientSecretCredential
 
 ```javascript
-let appInsights = require("applicationinsights");
+import appInsights from "applicationinsights";
 import { ClientSecretCredential } from "@azure/identity"; 
 
 const credential = new ClientSecretCredential(

articles/azure-monitor/app/ilogger.md

@@ -226,6 +226,8 @@ namespace WebApplication
 
 ## Console application
 
+The following example uses the Microsoft.Extensions.Logging.ApplicationInsights package. The Microsoft.Extensions.Logging.ApplicationInsights package should be used in a console application or whenever you want a bare minimum implementation of Application Insights without the full feature set such as metrics, distributed tracing, sampling, and telemetry initializers.
+
 Here are the installed packages:
 
 ```xml
@@ -284,7 +286,7 @@ namespace ConsoleApp
 
 ```
 
-The preceding example uses the `Microsoft.Extensions.Logging.ApplicationInsights` package. By default, this configuration uses the "bare minimum" `TelemetryConfiguration` setup for sending data to Application Insights: the `InMemoryChannel` channel. There's no sampling and no standard `TelemetryInitializer` instance. You can override this behavior for a console application, as the following example shows.
+The previous example demonstrates the default behavior for a console application. As the following example shows, you can override this default behavior.
 
 Also install this package: