Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into rolyon-mto-portal-entra-admin-center

rolyon · rolyon · commit d42422215c0d · 2023-09-11T12:32:12.000-07:00
diff --git a/articles/azure-functions/dotnet-isolated-process-guide.md b/articles/azure-functions/dotnet-isolated-process-guide.md
@@ -229,6 +229,7 @@ Placeholders are a platform capability that improves cold start. Normally, you d
 
 - Set the `WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED` application setting to "1"
 - Ensure that the `netFrameworkVersion` property of the function app matches your project's target framework, which must be .NET 6 or later.
+- Ensure that the function app is configured to use a 64-bit process.
 - Update your project file:
     - Upgrade [Microsoft.Azure.Functions.Worker] to version 1.19.0 or later
     - Upgrade [Microsoft.Azure.Functions.Worker.Sdk] to version 1.14.1 or later
@@ -239,11 +240,12 @@ Placeholders are a platform capability that improves cold start. Normally, you d
 > [!NOTE]
 > Setting `FunctionsEnableWorkerIndexing` to "True" may cause an issue when debugging locally using version 4.0.5274 or earlier of the [Azure Functions Core Tools](./functions-run-local.md). The issue manifests with the debugger not being able to attach. If you encounter this issue, remove the `FunctionsEnableWorkerIndexing` property during local testing.
 
-The following CLI commands will set the application setting and update the `netFrameworkVersion` property. Replace `<groupName>` with the name of the resource group, and replace `<appName>` with the name of your function app. Replace `<framework>` with the appropriate version string, such as "v6.0" or "v7.0", according to your target .NET version.
+The following CLI commands will set the application setting, update the `netFrameworkVersion` property, and make the app run as 64-bit. Replace `<groupName>` with the name of the resource group, and replace `<appName>` with the name of your function app. Replace `<framework>` with the appropriate version string, such as "v6.0" or "v7.0", according to your target .NET version.
 
 ```azurecli
 az functionapp config appsettings set -g <groupName> -n <appName> --settings 'WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED=1'
 az functionapp config set -g <groupName> -n <appName> --net-framework-version <framework>
+az functionapp config set -g <groupName> -n <appName> --use-32bit-worker-process false
 ```
 
 The following example shows a project file with the appropriate changes in place:
@@ -326,34 +328,42 @@ You can compile your function app as [ReadyToRun binaries](/dotnet/core/deployin
 
 ReadyToRun requires you to build the project against the runtime architecture of the hosting app. **If these are not aligned, your app will encounter an error at startup.** Select your runtime identifier from the table below:
 
-|Operating System | App is 32-bit | Runtime identifier |
+|Operating System | App is 32-bit<sup>1</sup> | Runtime identifier |
 |-|-|-|
 | Windows | True | `win-x86` |
 | Windows | False | `win-x64` |
 | Linux | True | N/A (not supported) |
 | Linux | False | `linux-x64` | 
 
+<sup>1</sup> Only 64-bit apps are eligible for some other performance optimizations such as [placeholders](#placeholders-preview).
+
 To check if your Windows app is 32-bit or 64-bit, you can run the following CLI command, substituting `<group_name>` with the name of your resource group and `<app_name>` with the name of your application. An output of "true" indicates that the app is 32-bit, and "false" indicates 64-bit.
 
 ```azurecli
  az functionapp config show -g <group_name> -n <app_name> --query "use32BitWorkerProcess"
 ```
 
-To compile your project as ReadyToRun, update your project file by adding the `<PublishReadyToRun>` and `<RuntimeIdentifier>` elements. The following examples shows a configuration for publishing to a Windows 32-bit function app.
+You can change your application to 64-bit with the following command, using the same substitutions:
+
+```azurecli
+az functionapp config set -g <group_name> -n <app_name> --use-32bit-worker-process false`
+```
+
+To compile your project as ReadyToRun, update your project file by adding the `<PublishReadyToRun>` and `<RuntimeIdentifier>` elements. The following examples shows a configuration for publishing to a Windows 64-bit function app.
 
 ```xml
 <PropertyGroup>
   <TargetFramework>net6.0</TargetFramework>
   <AzureFunctionsVersion>v4</AzureFunctionsVersion>
-  <RuntimeIdentifier>win-x86</RuntimeIdentifier>
+  <RuntimeIdentifier>win-x64</RuntimeIdentifier>
   <PublishReadyToRun>true</PublishReadyToRun>
 </PropertyGroup>
 ```
 
-If you don't want to set the `<RuntimeIdentifier>` as part of the project file, you can also configure this as part of the publish gesture itself. For example, with a Windows 32-bit function app, the .NET CLI command would be:
+If you don't want to set the `<RuntimeIdentifier>` as part of the project file, you can also configure this as part of the publish gesture itself. For example, with a Windows 64-bit function app, the .NET CLI command would be:
 
 ```dotnetcli
-dotnet publish --runtime win-x86
+dotnet publish --runtime win-x64
 ```
 
 In Visual Studio, the "Target Runtime" option in the publish profile should be set to the correct runtime identifier. If it is set to the default value "Portable", ReadyToRun will not be used.
diff --git a/articles/dns/private-resolver-endpoints-rulesets.md b/articles/dns/private-resolver-endpoints-rulesets.md
@@ -6,7 +6,7 @@ author: greg-lindsay
 ms.service: dns
 ms.custom: ignite-2022
 ms.topic: conceptual
-ms.date: 08/07/2023
+ms.date: 09/11/2023
 ms.author: greglin
 #Customer intent: As an administrator, I want to understand components of the Azure DNS Private Resolver.
 ---
@@ -106,7 +106,7 @@ A query for `secure.store.azure.contoso.com` matches the **AzurePrivate** rule f
 #### Rule processing
 
 - If multiple DNS servers are entered as the destination for a rule, the first IP address that is entered is used unless it doesn't respond. An exponential backoff algorithm is used to determine whether or not a destination IP address is responsive. Destination addresses that are marked as unresponsive aren't used for 30 minutes.
-- Certain domains are ignored when using a wildcard rule for DNS resolution, because they are reserved for Azure services. See [Azure services DNS zone configuration](../private-link/private-endpoint-dns.md#azure-services-dns-zone-configuration) for a list of domains that are reserved. The two-label DNS names listed in this article (ex: windows.net, azure.com, azure.net, windowsazure.us) are reserved for Azure services.
+- Certain domains are ignored when using a wildcard rule for DNS resolution, because they are reserved for Azure services. See [Azure services DNS zone configuration](../private-link/private-endpoint-dns.md#azure-services-dns-zone-configuration) for a list of domains that are reserved. The two-label DNS names listed in this article (for example: windows.net, azure.com, azure.net, windowsazure.us) are reserved for Azure services.
 
 > [!IMPORTANT]
 > - You can't enter the Azure DNS IP address of 168.63.129.16 as the destination IP address for a rule. Attempting to add this IP address will output the error: **Exception while making add request for rule**. 
diff --git a/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade.md b/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade.md
@@ -256,7 +256,11 @@ A scale set can optionally be configured with Application Health Probes to provi
 
 If the scale set is configured to use multiple placement groups, probes using a [Standard Load Balancer](../load-balancer/load-balancer-overview.md) need to be used.
 
+> [!NOTE]
+> Only one source of health monitoring can be used for a Virtual Machine Scale Set, either an Application Health Extension or a Health Probe. If you have both options enabled, you will need to remove one before using orchestration services like Instance Repairs or Automatic OS Upgrades. 
+
 ### Configuring a Custom Load Balancer Probe as Application Health Probe on a scale set
+
 As a best practice, create a load balancer probe explicitly for scale set health. The same endpoint for an existing HTTP probe or TCP probe can be used, but a health probe could require different behavior from a traditional load-balancer probe. For example, a traditional load balancer probe could return unhealthy if the load on the instance is too high, but that would not be appropriate for determining the instance health during an automatic OS upgrade. Configure the probe to have a high probing rate of less than two minutes.
 
 The load-balancer probe can be referenced in the *networkProfile* of the scale set and can be associated with either an internal or public facing load-balancer as follows:
@@ -275,6 +279,7 @@ The load-balancer probe can be referenced in the *networkProfile* of the scale s
 > When using Automatic OS Upgrades with Service Fabric, the new OS image is rolled out Update Domain by Update Domain to maintain high availability of the services running in Service Fabric. To utilize Automatic OS Upgrades in Service Fabric your cluster node type must be configured to use the Silver Durability Tier or higher. For Bronze Durability tier, automatic OS image upgrade is only supported for Stateless node types. For more information on the durability characteristics of Service Fabric clusters, please see [this documentation](../service-fabric/service-fabric-cluster-capacity.md#durability-characteristics-of-the-cluster).
 
 ### Keep credentials up to date
+
 If your scale set uses any credentials to access external resources, such as a VM extension configured to use a SAS token for storage account, then ensure that the credentials are updated. If any credentials, including certificates and tokens, have expired, the upgrade will fail and the first batch of VMs will be left in a failed state.
 
 The recommended steps to recover VMs and re-enable automatic OS upgrade if there's a resource authentication failure are:
@@ -285,12 +290,16 @@ The recommended steps to recover VMs and re-enable automatic OS upgrade if there
 * Deploy the updated scale set, which will update all VM instances including the failed ones.
 
 ## Using Application Health extension
+
 The Application Health extension is deployed inside a Virtual Machine Scale Set instance and reports on VM health from inside the scale set instance. You can configure the extension to probe on an application endpoint and update the status of the application on that instance. This instance status is checked by Azure to determine whether an instance is eligible for upgrade operations.
 
 As the extension reports health from within a VM, the extension can be used in situations where external probes such as Application Health Probes (that utilize custom Azure Load Balancer [probes](../load-balancer/load-balancer-custom-probe-overview.md)) can’t be used.
 
 There are multiple ways of deploying the Application Health extension to your scale sets as detailed in the examples in [this article](virtual-machine-scale-sets-health-extension.md#deploy-the-application-health-extension).
 
+> [!NOTE]
+> Only one source of health monitoring can be used for a Virtual Machine Scale Set, either an Application Health Extension or a Health Probe. If you have both options enabled, you will need to remove one before using orchestration services like Instance Repairs or Automatic OS Upgrades. 
+
 ## Get the history of automatic OS image upgrades
 You can check the history of the most recent OS upgrade performed on your scale set with Azure PowerShell, Azure CLI 2.0, or the REST APIs. You can get history for the last five OS upgrade attempts within the past two months.
 
diff --git a/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-health-extension.md b/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-health-extension.md
@@ -26,6 +26,9 @@ This article assumes that you're familiar with:
 > [!CAUTION]
 > Application Health Extension expects to receive a consistent probe response at the configured port `tcp` or request path `http/https` in order to label a VM as *Healthy*. If no application is running on the VM, or you're unable to configure a probe response, your VM is going to show up as *Unhealthy*.
 
+> [!NOTE]
+> Only one source of health monitoring can be used for a Virtual Machine Scale Set, either an Application Health Extension or a Health Probe. If you have both options enabled, you will need to remove one before using orchestration services like Instance Repairs or Automatic OS Upgrades.
+
 ## When to use the Application Health extension
 
 The Application Health Extension is deployed inside a Virtual Machine Scale Set instance and reports on application health from inside the scale set instance. The extension probes on a local application endpoint and will update the health status based on TCP/HTTP(S) responses received from the application. This health status is used by Azure to initiate repairs on unhealthy instances and to determine if an instance is eligible for upgrade operations. 
diff --git a/includes/functions-dotnet-migrate-v4-versions.md b/includes/functions-dotnet-migrate-v4-versions.md
@@ -17,7 +17,7 @@ When you migrate your function app, you have the opportunity to choose the targe
 
 <sup>1</sup> The [isolated worker model] supports Long Term Support (LTS) and Standard Term Support (STS) versions of .NET, as well as .NET Framework. The [in-process model] only supports LTS releases of .NET. For a full feature and functionality comparison between the two models, see [Differences between in-process and isolate worker process .NET Azure Functions](../articles/azure-functions/dotnet-isolated-in-process-differences.md). 
 
-<sup>2</sup> Preview support for .NET 8 function apps is currently limited to Linux applications. To develop using .NET 8 Preview SDKs in Visual Studio, you must use [Visual Studio 2022 Preview](https://visualstudio.microsoft.com/vs/preview/).
+<sup>2</sup> Preview support for .NET 8 function apps is currently limited to Linux applications. To develop using .NET 8 Preview SDKs in Visual Studio, you must use [Visual Studio 2022 Preview](https://visualstudio.microsoft.com/vs/preview/). Within Visual Studio, you must also get the latest toolset and template updates by navigating to `Tools->Options`, selecting `Azure Functions` under `Projects and Solutions`, and then clicking the `Check for updates` button and installing updates as prompted.
 
 [.NET Official Support Policy]: https://dotnet.microsoft.com/platform/support/policy
 [netfxpolicy]: https://dotnet.microsoft.com/platform/support/policy/dotnet-framework
diff --git a/includes/functions-dotnet-supported-versions.md b/includes/functions-dotnet-supported-versions.md
@@ -26,7 +26,7 @@ The following table shows the highest level of .NET or .NET Framework that can b
 
 <sup>3</sup> Build process also requires [.NET 6 SDK](https://dotnet.microsoft.com/download).
 
-<sup>4</sup> Preview support for .NET 8 function apps is currently limited to Linux applications. To develop using .NET 8 Preview SDKs in Visual Studio, you must use [Visual Studio 2022 Preview](https://visualstudio.microsoft.com/vs/preview/).
+<sup>4</sup> Preview support for .NET 8 function apps is currently limited to Linux applications. To develop using .NET 8 Preview SDKs in Visual Studio, you must use [Visual Studio 2022 Preview](https://visualstudio.microsoft.com/vs/preview/). Within Visual Studio, you must also get the latest toolset and template updates by navigating to `Tools->Options`, selecting `Azure Functions` under `Projects and Solutions`, and then clicking the `Check for updates` button and installing updates as prompted.
 
 For the latest news about Azure Functions releases, including the removal of specific older minor versions, monitor [Azure App Service announcements](https://github.com/Azure/app-service-announcements/issues).
 
