Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into heidist-cases

HeidiSteen · HeidiSteen · commit 048d3d0a415d · 2022-08-24T09:44:07.000-07:00
diff --git a/articles/active-directory/privileged-identity-management/pim-how-to-change-default-settings.md b/articles/active-directory/privileged-identity-management/pim-how-to-change-default-settings.md
@@ -103,6 +103,8 @@ If setting multiple approvers, approval completes as soon as one of them approve
     ![Select a user or group pane to select approvers](./media/pim-resource-roles-configure-role-settings/resources-role-settings-select-approvers.png)
 
 1. Select at least one user and then click **Select**. Select at least one approver. If no specific approvers are selected, Privileged Role Administrators and Global Administrators become the default approvers.
+   > [!Note]
+   > An approver does not have to have an Azure AD administrative role themselves. They can be a regular user, such as an IT executive.
 
 1. Select **Update** to save your changes.
 
diff --git a/articles/aks/ingress-basic.md b/articles/aks/ingress-basic.md
@@ -394,7 +394,7 @@ kubectl apply -f aks-helloworld-two.yaml --namespace ingress-basic
 
 Both applications are now running on your Kubernetes cluster. To route traffic to each application, create a Kubernetes ingress resource. The ingress resource configures the rules that route traffic to one of the two applications.
 
-In the following example, traffic to *EXTERNAL_IP* is routed to the service named `aks-helloworld-one`. Traffic to *EXTERNAL_IP/hello-world-two* is routed to the `aks-helloworld-two` service. Traffic to *EXTERNAL_IP/static* is routed to the service named `aks-helloworld-one` for static assets.
+In the following example, traffic to *EXTERNAL_IP/hello-world-one* is routed to the service named `aks-helloworld-one`. Traffic to *EXTERNAL_IP/hello-world-two* is routed to the `aks-helloworld-two` service. Traffic to *EXTERNAL_IP/static* is routed to the service named `aks-helloworld-one` for static assets.
 
 Create a file named `hello-world-ingress.yaml` and copy in the following example YAML.
 
diff --git a/articles/azure-functions/functions-bindings-register.md b/articles/azure-functions/functions-bindings-register.md
@@ -45,7 +45,7 @@ The following table lists the currently available versions of the default *Micro
 <sup>1</sup> Version 3.x of the extension bundle currently doesn't include the [Table Storage bindings](./functions-bindings-storage-table.md). If your app requires Table Storage, you'll need to continue using the 2.x version for now.
 
 > [!NOTE]
-> While you can a specify custom version range in host.json, we recommend you use a version value from this table.
+> Even though host.json supports custom ranges for `version`, you should use a version value from this table.
 
 ## Explicitly install extensions
 
diff --git a/articles/azure-monitor/profiler/profiler.md b/articles/azure-monitor/profiler/profiler.md
@@ -17,7 +17,7 @@ To enable Profiler on Linux, walk through the [ASP.NET Core Azure Linux web apps
 > For more information about supported runtime, see [.NET Core Support Policy](https://dotnet.microsoft.com/platform/support/policy/dotnet-core).
 
 
-## Pre-requisites
+## Prerequisites
 
 - An [Azure App Services ASP.NET/ASP.NET Core app](../../app-service/quickstart-dotnetcore.md).
 - [Application Insights resource](../app/create-new-resource.md) connected to your App Service app. 
diff --git a/articles/azure-netapp-files/azure-netapp-files-network-topologies.md b/articles/azure-netapp-files/azure-netapp-files-network-topologies.md
@@ -12,7 +12,7 @@ ms.service: azure-netapp-files
 ms.workload: storage
 ms.tgt_pltfrm: na
 ms.topic: conceptual
-ms.date: 08/11/2022
+ms.date: 08/22/2022
 ms.author: ramakk
 ---
 # Guidelines for Azure NetApp Files network planning
@@ -33,7 +33,7 @@ Azure NetApp Files volumes are designed to be contained in a special purpose sub
 
 ### Supported regions 
 
-Azure NetApp Files standard network features are supported for the following regions:
+Azure NetApp Files Standard network features are supported for the following regions:
 
 *   Australia Central
 *   Australia Central 2
@@ -80,7 +80,10 @@ The following table describes what’s supported for each network features confi
 |     Dual stack (IPv4 and   IPv6) VNet    |     No <br> (IPv4 only   supported)    |     No <br> (IPv4 only supported)    |
 
 > [!IMPORTANT]
-> Upgrade from basic to standard network feature is not currently supported.
+> Upgrade from Basic to Standard network feature is not currently supported.
+
+> [!IMPORTANT]
+> Conversion between Basic and Standard networking features is not currently supported.
 
 ### Supported network topologies
 
@@ -158,7 +161,7 @@ The following diagram illustrates an Azure-native environment with cross-region
 
 :::image type="content" source="../media/azure-netapp-files/azure-native-cross-region-peering.png" alt-text="Diagram depicting Azure native environment setup with cross-region VNet peering." lightbox="../media/azure-netapp-files/azure-native-cross-region-peering.png":::
 
-With the standard network feature, VMs are able to connect to volumes in another region via global or cross-region VNet peering. The above diagram adds a second region to the configuration in the [local VNet peering section](#vnet-peering). For VNet 4 in this diagram, an Azure NetApp Files volume is created in a delegated subnet and can be mounted on VM5 in the application subnet.
+With Standard network features, VMs are able to connect to volumes in another region via global or cross-region VNet peering. The above diagram adds a second region to the configuration in the [local VNet peering section](#vnet-peering). For VNet 4 in this diagram, an Azure NetApp Files volume is created in a delegated subnet and can be mounted on VM5 in the application subnet.
 
 In the diagram, VM2 in Region 1 can connect to Volume 3 in Region 2. VM5 in Region 2 can connect to Volume 2 in Region 1 via VNet peering between Region 1 and Region 2.
 
diff --git a/articles/azure-netapp-files/faq-smb.md b/articles/azure-netapp-files/faq-smb.md
@@ -6,7 +6,7 @@ ms.workload: storage
 ms.topic: conceptual
 author: b-hchen
 ms.author: anfdocs
-ms.date: 04/21/2022
+ms.date: 08/24/2022
 ---
 # SMB FAQs for Azure NetApp Files
 
@@ -30,7 +30,7 @@ However, you can map multiple NetApp accounts that are under the same subscripti
 
 Both [Azure Active Directory (AD) Domain Services](../active-directory-domain-services/overview.md) and [Active Directory Domain Services (AD DS)](/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview) are supported. You can use existing Active Directory domain controllers with Azure NetApp Files. Domain controllers can reside in Azure as virtual machines, or on premises via ExpressRoute or S2S VPN. Azure NetApp Files doesn't support AD join for [Azure Active Directory](https://azure.microsoft.com/resources/videos/azure-active-directory-overview/) at this time.
 
-If you are using Azure NetApp Files with Azure Active Directory Domain Services, the organizational unit path is `OU=AADDC Computers` when you configure Active Directory for your NetApp account.
+If you're using Azure NetApp Files with Azure Active Directory Domain Services, the organizational unit path is `OU=AADDC Computers` when you configure Active Directory for your NetApp account.
 
 ## What versions of Windows Server Active Directory are supported?
 
@@ -75,6 +75,10 @@ Azure NetApp Files supports [`CHANGE_NOTIFY` response](/openspecs/windows_protoc
 
 Azure NetApp Files also supports [`LOCK` response](/openspecs/windows_protocols/ms-smb2/e215700a-102c-450a-a598-7ec2a99cd82c). This response is for the client’s request that comes in the form of a [`LOCK` request](/openspecs/windows_protocols/ms-smb2/6178b960-48b6-4999-b589-669f88e9017d).  
 
+## What network authentication methods are supported for SMB volumes in Azure NetApp Files?
+
+NTLMv2 and Kerberos network authentication methods are supported with SMB volumes in Azure NetApp Files. NTLMv1 and LanManager are disabled and are not supported.
+
 ## What is the password rotation policy for the Active Directory machine account for SMB volumes?
 
 The Azure NetApp Files service has a policy that automatically updates the password on the Active Directory machine account that is created for SMB volumes. This policy has the following properties:   
diff --git a/articles/iot-hub-device-update/device-update-proxy-updates.md b/articles/iot-hub-device-update/device-update-proxy-updates.md
@@ -16,7 +16,7 @@ With Proxy updates, you can (1) target over-the-air updates to multiple componen
 * Targeting specific update files to different apps/components on the device  
 * Targeting specific update files to sensors connected to an IoT devices. These sensors could be connected to the IoT device over a network protocol (for example, USB, CANbus etc.). 
 
-## Pre-requisite
+## Prerequisite 
 In order to update a component or components that connected to a target IoT Device, the device builder must register a custom **Component Enumerator Extension** that is built specifically for their IoT devices. The Component Enumerator Extension is required so that the Device Update Agent can map a **'child update'** with a specific component, or group of components, which the update is intended for. See [Contoso Component Enumerator](components-enumerator.md) for an example on how to implement and register a custom Component Enumerator extension.
 
 > [!NOTE]
diff --git a/articles/marketplace/what-is-new.md b/articles/marketplace/what-is-new.md
@@ -5,7 +5,7 @@ ms.author: mingshen
 ms.service: marketplace 
 ms.subservice: partnercenter-marketplace-publisher
 ms.topic: conceptual
-ms.date: 08/01/2022
+ms.date: 08/24/2022
 ---
 
 # What's new in the Microsoft commercial marketplace
@@ -16,6 +16,7 @@ Learn about important updates in the commercial marketplace program of Partner C
 
 | Category | Description | Date |
 | --- | --- | --- |
+| Offers | ISVs can now publish 1-year and 3-year prices for their Virtual Machine plans to let customers save money when they commit for a long-term agreement. To learn more, see [Plan a virtual machine offer](azure-vm-plan-pricing-and-availability.md#configure-reservation-pricing-optional). | 2022-08-24 |
 | Offers | Software as a service (SaaS) plans now support 2-year and 3-year billing term with upfront, monthly or annually payment options. To learn more, see [Plan a SaaS offer for the commercial marketplace](plan-saas-offer.md#saas-billing-terms-and-payment-options). | 2022-08-01 |
 | Offers | ISVs can now offer custom prices, terms, conditions, and pricing for a specific customer through private offers. See [ISV to customer private offers](isv-customer.md) and the [FAQ](isv-customer-faq.yml). | 2022-04-06 |
 | Offers | Publishers can now [change transactable offer and plan pricing](price-changes.md) without having to discontinue an offer and recreate it with new pricing (also see [this FAQ](price-changes-faq.yml)). | 2022-03-30 |
diff --git a/articles/remote-rendering/how-tos/create-an-account.md b/articles/remote-rendering/how-tos/create-an-account.md
@@ -16,7 +16,7 @@ This chapter guides you through the steps to create an account for the **Azure R
 
 The following steps are needed to create an account for the Azure Remote Rendering service:
 
-1. Go to the [Mixed Reality Preview page](https://aka.ms/MixedRealityPrivatePreview)
+1. Go to the Azure portal [portal.azure.com](https://ms.portal.azure.com/)
 1. Click the 'Create a resource' button
 1. In the search field ("Search the marketplace"), type in "Remote Rendering" and hit 'enter'.
 1. In the result list, click on the "Remote Rendering" tile
diff --git a/articles/synapse-analytics/sql/create-external-table-as-select.md b/articles/synapse-analytics/sql/create-external-table-as-select.md
@@ -83,12 +83,12 @@ USE [mydbname];
 GO
 
 SELECT
-    country_name, population
+    CountryName, PopulationCount
 FROM PopulationCETAS
 WHERE
-    [year] = 2019
+    [Year] = 2019
 ORDER BY
-    [population] DESC;
+    [PopulationCount] DESC;
 ```
 
 ## Remarks
diff --git a/articles/virtual-machines/availability-set-overview.md b/articles/virtual-machines/availability-set-overview.md
@@ -13,14 +13,17 @@ ms.date: 02/18/2021
 
 **Applies to:** :heavy_check_mark: Linux VMs :heavy_check_mark: Windows VMs
 
+> [!NOTE]
+> We recommend that new customers choose [virtual machine scale sets with flexible orchestration mode](../virtual-machine-scale-sets/overview.md) for high availability with the widest range of features. Virtual machine scale sets allow VM instances to be centrally managed, configured, and updated, and will automatically increase or decrease the number of VM instances in response to demand or a defined schedule. Availability sets only offer high availability.
+
 This article provides you with an overview of the availability features of Azure virtual machines (VMs).
 
 ## What is an availability set? 
 
 An availability set is a logical grouping of VMs that allows Azure to understand how your application is built to provide for redundancy and availability. We recommended that two or more VMs are created within an availability set to provide for a highly available application and to meet the [99.95% Azure SLA](https://azure.microsoft.com/support/legal/sla/virtual-machines/). There is no cost for the Availability Set itself, you only pay for each VM instance that you create.
 
 ## How do availability sets work?
-Each virtual machine in your availability set is assigned an **update domain** and a **fault domain** by the underlying Azure platform. Each availability set can be configured with up to three fault domains and twenty update domains. Update domains indicate groups of virtual machines and underlying physical hardware that can be rebooted at the same time. When more than five virtual machines are configured within a single availability set with five update domains, the sixth virtual machine is placed into the same update domain as the first virtual machine, the seventh in the same update domain as the second virtual machine, and so on. The order of update domains being rebooted may not proceed sequentially during planned maintenance, but only one update domain is rebooted at a time. A rebooted update domain is given 30 minutes to recover before maintenance is initiated on a different update domain.
+Each virtual machine in your availability set is assigned an **update domain** and a **fault domain** by the underlying Azure platform. Each availability set can be configured with up to three fault domains and twenty update domains. These configurations cannot be changed once the availability set has been created. Update domains indicate groups of virtual machines and underlying physical hardware that can be rebooted at the same time. When more than five virtual machines are configured within a single availability set with five update domains, the sixth virtual machine is placed into the same update domain as the first virtual machine, the seventh in the same update domain as the second virtual machine, and so on. The order of update domains being rebooted may not proceed sequentially during planned maintenance, but only one update domain is rebooted at a time. A rebooted update domain is given 30 minutes to recover before maintenance is initiated on a different update domain.
 
 Fault domains define the group of virtual machines that share a common power source and network switch. By default, the virtual machines configured within your availability set are separated across up to three fault domains. While placing your virtual machines into an availability set does not protect your application from operating system or application-specific failures, it does limit the impact of potential physical hardware failures, network outages, or power interruptions.
 
