Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into rolyon-mto-configuration-delete-steps

Author: rolyon

articles/active-directory/fundamentals/whats-deprecated-azure-ad.md

@@ -1,7 +1,7 @@
 ---
 title: What's deprecated in Azure Active Directory?
 description: Learn about features being deprecated in Azure Active Directory
-author: jricketts
+author: janicericketts
 manager: martinco
 ms.service: active-directory
 ms.subservice: fundamentals

articles/active-directory/reports-monitoring/how-to-view-applied-conditional-access-policies.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.topic: how-to
 ms.workload: identity
 ms.subservice: report-monitor
-ms.date: 10/31/2022
+ms.date: 02/03/2023
 ms.author: sarahlipsey
 ms.reviewer: besiler 
 
@@ -32,41 +32,30 @@ As an Azure AD administrator, you can use the sign-in logs to:
 
 Some scenarios require you to get an understanding of how your Conditional Access policies were applied to a sign-in event. Common examples include:
 
-- *Helpdesk administrators* who need to look at applied Conditional Access policies to understand if a policy is the root cause of a ticket that a user opened. 
+- Helpdesk administrators who need to look at applied Conditional Access policies to understand if a policy is the root cause of a ticket that a user opened. 
 
-- *Tenant administrators* who need to verify that Conditional Access policies have the intended effect on the users of a tenant.
+- Tenant administrators who need to verify that Conditional Access policies have the intended effect on the users of a tenant.
 
 You can access the sign-in logs by using the Azure portal, Microsoft Graph, and PowerShell.  
 
 ## Required administrator roles 
 
-To see applied Conditional Access policies in the sign-in logs, administrators must have permissions to view both the logs and the policies.
+To see applied Conditional Access policies in the sign-in logs, administrators must have permissions to view *both* the logs and the policies. The least privileged built-in role that grants *both* permissions is *Security Reader*. As a best practice, your Global Administrator should add the Security Reader role to the related administrator accounts. 
 
-The least privileged built-in role that grants both permissions is *Security Reader*. As a best practice, your global administrator should add the Security Reader role to the related administrator accounts. 
-
-The following built-in roles grant permissions to read Conditional Access policies:
+The following built-in roles grant permissions to *read Conditional Access policies*:
 
 - Global Administrator 
-
 - Global Reader 
-
 - Security Administrator 
-
 - Security Reader 
-
 - Conditional Access Administrator 
 
-
-The following built-in roles grant permission to view sign-in logs: 
+The following built-in roles grant permission to *view sign-in logs*: 
 
 - Global Administrator 
-
 - Security Administrator 
-
 - Security Reader 
-
 - Global Reader 
-
 - Reports Reader 
 
 ## Permissions for client apps 
@@ -76,9 +65,7 @@ If you use a client app to pull sign-in logs from Microsoft Graph, your app need
 Any of the following permissions is sufficient for a client app to access applied certificate authority (CA) policies in sign-in logs through Microsoft Graph: 
 
 - `Policy.Read.ConditionalAccess` 
-
 - `Policy.ReadWrite.ConditionalAccess` 
-
 - `Policy.Read.All` 
 
 ## Permissions for PowerShell 
@@ -89,37 +76,28 @@ Like any other client app, the Microsoft Graph PowerShell module needs client pe
 - `AuditLog.Read.All` 
 - `Directory.Read.All` 
 
-These permissions are the least privileged permissions with the necessary access. 
-
-To consent to the necessary permissions, use: 
-
-`Connect-MgGraph -Scopes Policy.Read.ConditionalAccess, AuditLog.Read.All, Directory.Read.All`
-
-To view the sign-in logs, use: 
+The following permissions are the least privileged permissions with the necessary access:
 
-`Get-MgAuditLogSignIn`
+- To consent to the necessary permissions: `Connect-MgGraph -Scopes Policy.Read.ConditionalAccess, AuditLog.Read.All, Directory.Read.All`
+- To view the sign-in logs: `Get-MgAuditLogSignIn`
 
 For more information about this cmdlet, see [Get-MgAuditLogSignIn](/powershell/module/microsoft.graph.reports/get-mgauditlogsignin).
 
 The Azure AD Graph PowerShell module doesn't support viewing applied Conditional Access policies. Only the Microsoft Graph PowerShell module returns applied Conditional Access policies.  
 
-## Confirming access 
-
-On the **Conditional Access** tab, you see a list of Conditional Access policies applied to that sign-in event. 
-
-To confirm that you have admin access to view applied Conditional Access policies in the sign-in logs: 
-
-1. Go to the Azure portal. 
-
-2. In the upper-right corner, select your directory, and then select **Azure Active Directory** on the left pane. 
+## View Conditional Access policies in Azure AD sign-in logs
 
-3. In the **Monitoring** section, select **Sign-in logs**. 
+The activity details of sign-in logs contain several tabs. The **Conditional Access** tab lists the Conditional Access policies applied to that sign-in event. 
 
-4. Select an item in the sign-in table to open the **Activity Details: Sign-ins context** pane.  
+1. Sign in to the [Azure portal](https://portal.azure.com) using the Security Reader role.
+1. In the **Monitoring** section, select **Sign-in logs**. 
+1. Select  a sign-in item from the table to open the **Activity Details: Sign-ins context** pane.  
+1. Select the **Conditional Access** tab.
 
-5. Select the **Conditional Access** tab on the context pane. If your screen is small, you might need to select the ellipsis (**...**) to see all tabs on the context pane.  
+If you don't see the Conditional Access policies, confirm you're using a role that provides access to both the sign-in logs and the Conditional Access policies.
 
 ## Next steps
 
-* [Sign-in error code reference](./concept-sign-ins.md)
-* [Sign-in report overview](concept-sign-ins.md)
+* [Troubleshoot sign-in problems](../conditional-access/troubleshoot-conditional-access.md#azure-ad-sign-in-events)
+* [Review the Conditional Access sign-in logs FAQs](reports-faq.yml#conditional-access)
+* [Learn about the sign-in logs](concept-sign-ins.md)

articles/active-directory/reports-monitoring/overview-reports.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.topic: overview
 ms.workload: identity
 ms.subservice: report-monitor
-ms.date: 11/01/2022
+ms.date: 02/03/2023
 ms.author: sarahlipsey
 ms.reviewer: sarbar  
 
@@ -70,6 +70,6 @@ In addition to the user interface, Azure AD also provides you with [programmatic
 
 ## Next steps
 
-- [Risky sign-ins report](../identity-protection/overview-identity-protection.md)
+- [Risky sign-ins report](../identity-protection/howto-identity-protection-investigate-risk.md#risky-sign-ins)
 - [Audit logs report](concept-audit-logs.md)
 - [Sign-ins logs report](concept-sign-ins.md)

articles/cosmos-db/index-policy.md

@@ -31,7 +31,7 @@ Azure Cosmos DB supports two indexing modes:
 > [!NOTE]
 > Azure Cosmos DB also supports a Lazy indexing mode. Lazy indexing performs updates to the index at a much lower priority level when the engine is not doing any other work. This can result in **inconsistent or incomplete** query results. If you plan to query an Azure Cosmos DB container, you should not select lazy indexing. New containers cannot select lazy indexing. You can request an exemption by contacting [email protected] (except if you are using an Azure Cosmos DB account in [serverless](serverless.md) mode which doesn't support lazy indexing).
 
-By default, indexing policy is set to `automatic`. It's achieved by setting the `automatic` property in the indexing policy to `true`. Setting this property to `true` allows Azure Cosmos DB to automatically index documents as they're written.
+By default, indexing policy is set to `automatic`. It's achieved by setting the `automatic` property in the indexing policy to `true`. Setting this property to `true` allows Azure Cosmos DB to automatically index items as they're written.
 
 ## <a id="index-size"></a>Index size
 
@@ -87,6 +87,10 @@ Any indexing policy has to include the root path `/*` as either an included or a
 
 - If the indexing mode is set to **consistent**, the system properties `id` and `_ts` are automatically indexed.
 
+- If an explicitly indexed path doesn't exist in an item, a value will be added to the index to indicate that the path is undefined.
+
+All explicitly included paths will have values added to the index for each item in the container, even if the path is undefined for a given item.
+
 See [this section](how-to-manage-indexing-policy.md#indexing-policy-examples) for indexing policy examples for including and excluding paths.
 
 ## Include/exclude precedence
@@ -127,7 +131,7 @@ Azure Cosmos DB, by default, won't create any spatial indexes. If you would like
 
 Queries that have an `ORDER BY` clause with two or more properties require a composite index. You can also define a composite index to improve the performance of many equality and range queries. By default, no composite indexes are defined so you should [add composite indexes](how-to-manage-indexing-policy.md#composite-index) as needed.
 
-Unlike with included or excluded paths, you can't create a path with the `/*` wildcard. Every composite path has an implicit `/?` at the end of the path that you don't need to specify. Composite paths lead to a scalar value that is the only value included in the composite index.
+Unlike with included or excluded paths, you can't create a path with the `/*` wildcard. Every composite path has an implicit `/?` at the end of the path that you don't need to specify. Composite paths lead to a scalar value that is the only value included in the composite index. If a path in a composite index doesn't exist in an item, a value will be added to the index to indicate that the path is undefined.
 
 When defining a composite index, you specify:
 

articles/load-balancer/basic/quickstart-basic-public-load-balancer-powershell.md

@@ -4,7 +4,7 @@ titleSuffix: Azure Load Balancer
 description: This quickstart shows how to create a basic internal load balancer using Azure PowerShell
 author: mbender-ms
 ms.author: mbender
-ms.date: 03/22/2022
+ms.date: 02/03/2023
 ms.topic: quickstart
 ms.service: load-balancer
 ms.custom: devx-track-azurepowershell, mode-api
@@ -106,6 +106,7 @@ $lbrule = @{
     IdleTimeoutInMinutes = '15'
     FrontendIpConfiguration = $feip
     BackendAddressPool = $bePool
+    Probe = $probe
 }
 $rule = New-AzLoadBalancerRuleConfig @lbrule
 

articles/virtual-machines/dedicated-host-retirement.md

@@ -66,9 +66,9 @@ A:
 
 A: You'll need to [exchange your reservation](../cost-management-billing/reservations/exchange-and-refund-azure-reservations.md#how-to-exchange-or-refund-an-existing-reservation) through the Azure portal to match the new Dedicated Host SKU. 
 
-### Q: What would happen if I do not migrate by March 31, 2023?
+### Q: What would happen to my host if I do not migrate by March 31, 2023?
 
-A: After March 31, 2023 any dedicated hosts running the SKUs that are marked for retirement will be pushed to 'Host Pending Deallocate' before eventually deallocating the host. For additional assistance please reach out to Azure support.
+A: After March 31, 2023 any dedicated host running on the SKUs that are marked for retirement will be set to 'Host Pending Deallocate' state before eventually deallocating the host. For additional assistance please reach out to Azure support.
 
 ### Q:  What will happen to my VMs if a Host is automatically deallocated?
 

articles/virtual-machines/dedicated-hosts-how-to.md

@@ -178,6 +178,7 @@ If you set a fault domain count for your host group, you'll need to specify the
 1. Select *myDedicatedHostsRG* as the **Resource group**.
 1. In **Instance details**, type *myHost* for the **Name** and select *East US* for the location.
 1. In **Hardware profile**, select *Standard Es3 family - Type 1* for the **Size family**, select *myHostGroup* for the **Host group** and then select *1* for the **Fault domain**. Leave the defaults for the rest of the fields.
+1. Leave the **Automatically replace host on failure** setting *Enabled* to automatically service heal the host in case of any host level failure.
 1. When you're done, select **Review + create** and wait for validation.
 1. Once you see the **Validation passed** message, select **Create** to create the host.
 
@@ -191,6 +192,7 @@ az vm host create \
    --name myHost \
    --sku DSv3-Type1 \
    --platform-fault-domain 1 \
+   --auto-replace true \
    -g myDHResourceGroup
 ```
 
@@ -205,7 +207,7 @@ $dHost = New-AzHost `
    -Location $location -Name myHost `
    -ResourceGroupName $rgName `
    -Sku DSv3-Type1 `
-   -AutoReplaceOnFailure 1 `
+   -AutoReplaceOnFailure True `
    -PlatformFaultDomain 1
 ```
 

articles/virtual-machines/dedicated-hosts.md

@@ -88,6 +88,27 @@ Known issues and limitations when using automatic VM placement:
 - You won't be able to redeploy your VM.
 - You won't be able to use DCv2, Lsv2, NVasv4, NVsv3, Msv2, or M-series VMs with dedicated hosts.
 
+## Host Service Healing
+
+In case of any failure relating to the underlying node, network connectivity or software issues can push the host and VMs on the host to a non-healthy state causing disruption and downtime to your workloads. The default action is for Azure to automatically service heal the impacted host to a healthy node and move all VMs to the healthy host. Once the VMs are service healed and restarted the impacted host will be deallocated. During the service healing process the host and VMs would become unavailable incurring a slight downtime. 
+
+The newly created host would have all the same constraints as the old host: 
+ - Resource group
+ - Region
+ - Fault Domain 
+ - Host Group
+ - ADH SKU  
+ - Auto replace on failure setting
+
+Users with compliance requirements might need a strong affinity between the host and underlying node and would not like to be automatically service healed, in such scenarios users can choose to opt out of auto service healing at host level by disabling the 'Automatically replace host on failure setting'.
+
+### Implications
+
+If you decide to disable auto service healing and if the underlying node encounters a failure your host state will change to 'Host Pending Deallocate' and will eventually be deallocated. 
+
+To avoid deallocation, you would need to manually redeploy the host by creating a new dedicated host and moving all the VMs from  the old host to the new host.
+
+The auto replace host setting is a create time setting and cannot be changed once the host is created. VMs that are manually stopped/deallocated from the impacted host are not moved as part of the automatic service healing.
 
 ## Virtual Machine Scale Set support