Merge pull request #202306 from MicrosoftDocs/main

6/21 AM Publish

Author: huypub

articles/active-directory/authentication/howto-authentication-temporary-access-pass.md

@@ -191,6 +191,7 @@ Keep these limitations in mind:
 - Users in scope for Self Service Password Reset (SSPR) registration policy *or* [Identity Protection Multi-factor authentication registration policy](../identity-protection/howto-identity-protection-configure-mfa-policy.md) will be required to register authentication methods after they have signed in with a Temporary Access Pass. 
 Users in scope for these policies will get redirected to the [Interrupt mode of the combined registration](concept-registration-mfa-sspr-combined.md#combined-registration-modes). This experience does not currently support FIDO2 and Phone Sign-in registration. 
 - A Temporary Access Pass cannot be used with the Network Policy Server (NPS) extension and Active Directory Federation Services (AD FS) adapter.
+- After a Temporary Access Pass is added to an account or expires, it can take a few minutes for the changes to replicate. Users may still see a prompt for Temporary Access Pass during this time. 
 
 ## Troubleshooting    
 

articles/active-directory/develop/v2-oauth-ropc.md

@@ -31,6 +31,7 @@ The Microsoft identity platform supports the [OAuth 2.0 Resource Owner Password
 > * If users need to use [multi-factor authentication (MFA)](../authentication/concept-mfa-howitworks.md) to log in to the application, they will be blocked instead.
 > * ROPC is not supported in [hybrid identity federation](../hybrid/whatis-fed.md) scenarios (for example, Azure AD and ADFS used to authenticate on-premises accounts). If users are full-page redirected to an on-premises identity providers, Azure AD is not able to test the username and password against that identity provider. [Pass-through authentication](../hybrid/how-to-connect-pta.md) is supported with ROPC, however.
 > * An exception to a hybrid identity federation scenario would be the following: Home Realm Discovery policy with AllowCloudPasswordValidation set to TRUE will enable ROPC flow to work for federated users when on-premises password is synced to cloud. For more information, see [Enable direct ROPC authentication of federated users for legacy applications](../manage-apps/home-realm-discovery-policy.md#enable-direct-ropc-authentication-of-federated-users-for-legacy-applications).
+> * Passwords with leading or trailing whitespaces are not supported by the ROPC flow.
 
 [!INCLUDE [try-in-postman-link](includes/try-in-postman-link.md)]
 

articles/active-directory/manage-apps/configure-user-consent.md

@@ -21,8 +21,10 @@ In this article, you'll learn how to configure the way users consent to applicat
 
 Before an application can access your organization's data, a user must grant the application permissions to do so. Different permissions allow different levels of access. By default, all users are allowed to consent to applications for permissions that don't require administrator consent. For example, by default, a user can consent to allow an app to access their mailbox but can't consent to allow an app unfettered access to read and write to all files in your organization.
 
-> [!IMPORTANT]
->To reduce the risk of malicious applications attempting to trick users into granting them access to your organization's data, we recommend that you allow user consent only for applications that have been published by a [verified publisher](../develop/publisher-verification-overview.md).
+To reduce the risk of malicious applications attempting to trick users into granting them access to your organization's data, we recommend that you allow user consent only for applications that have been published by a [verified publisher](../develop/publisher-verification-overview.md).
+
+>[!IMPORTANT]
+>As from September 30, 2022, the new default consent setting for new tenants will be to Follow Microsoft's Recommendation. Microsoft's initial recommendation at that time will be that end-users can’t consent to multi-tenant applications without publisher verification if the application  requests basic permissions like sign-in and read user profile permissions.
 
 ## Prerequisites
 
@@ -35,7 +37,7 @@ To configure user consent, you need:
 
 ## Configure user consent settings
 
-To configure user consent settings through the Azure portal, do the following:
+To configure user consent settings through the Azure portal:
 
 1. Sign in to the [Azure portal](https://portal.azure.com) as a [Global Administrator](../roles/permissions-reference.md#global-administrator).
 

articles/advisor/azure-advisor-score.md

@@ -68,7 +68,7 @@ The calculation of the Advisor score can be summarized in four steps:
    * Resources with long-standing recommendations will count more against your score.
    * Resources that you postpone or dismiss in Advisor are removed from your score calculation entirely.
 
-Advisor applies this model at an Advisor category level to give an Advisor score for each category. **Security** uses a [secure score](../defender-for-cloud/secure-score-security-controls.md#introduction-to-secure-score) model. A simple average produces the final Advisor score.
+Advisor applies this model at an Advisor category level to give an Advisor score for each category. **Security** uses a [secure score](../defender-for-cloud/secure-score-security-controls.md#overview-of-secure-score) model. A simple average produces the final Advisor score.
 
 ## Advisor score FAQs
 

articles/api-management/TOC.yml

@@ -162,8 +162,6 @@
                   href: how-to-deploy-self-hosted-gateway-kubernetes-helm.md
                 - name: Deploy self-hosted gateway to Kubernetes with OpenTelemetry Collector integration
                   href: how-to-deploy-self-hosted-gateway-kubernetes-opentelemetry.md
-                - name: Guidance for running on Kubernetes
-                  href: how-to-self-hosted-gateway-on-kubernetes-in-production.md
                 - name: Deploy a self-hosted gateway to Docker
                   href: how-to-deploy-self-hosted-gateway-docker.md
                 - name: Configure custom domain for self-hosted gateway
@@ -172,6 +170,10 @@
                   href: how-to-configure-cloud-metrics-logs.md
                 - name: Configure local metrics and logs for self-hosted gateway
                   href: how-to-configure-local-metrics-logs.md
+                - name: Guidance for running on Kubernetes
+                  href: how-to-self-hosted-gateway-on-kubernetes-in-production.md
+                - name: Migrate to self-hosted gateway v2
+                  href: self-hosted-gateway-migration-guide.md
       - name: Define and manage APIs
         items:
           - name: Create APIs

articles/api-management/self-hosted-gateway-migration-guide.md

@@ -0,0 +1,110 @@
+---
+title: Self-hosted gateway migration guide - Azure API Management
+description: Learn how to migrate the Azure API Management self-hosted gateway to v2.
+services: api-management
+documentationcenter: ''
+author: tomkerkhove
+
+ms.service: api-management
+ms.topic: article
+ms.date: 03/08/2022
+ms.author: tomkerkhove
+---
+
+# Self-hosted gateway migration guide
+
+This article explains how to migrate existing self-hosted gateway deployments to self-hosted gateway v2.
+
+## What's new?
+
+As we strive to make it easier for customers to deploy our self-hosted gateway, we've **introduced a new configuration API** that removes the dependency on Azure Storage, unless you're using [API inspector](api-management-howto-api-inspector.md) or quotas.
+
+The new configuration API allows customers to more easily adopt, deploy and operate our self-hosted gateway in their existing infrastructure.
+
+We have [introduced new container image tags](how-to-self-hosted-gateway-on-kubernetes-in-production.md#container-image-tag) to let customers choose the best way to try our gateway and deploy it in production.
+
+To help customers run our gateway in production we've extended [our production guidance](how-to-self-hosted-gateway-on-kubernetes-in-production.md) to cover how to autoscale the gateway, and deploy it for high availability in your Kubernetes cluster.
+
+Learn more about the connectivity of our gateway, our new infrastructure requirements, and what happens if connectivity is lost in [this article](self-hosted-gateway-overview.md#connectivity-to-azure).
+
+## Prerequisites
+
+Before you can migrate to self-hosted gateway v2, you need to ensure your infrastructure [meets the requirements](self-hosted-gateway-overview.md#gateway-v2-requirements).
+
+## Migrating to self-hosted gateway v2
+
+Migrating from self-hosted gateway v2 requires a few small steps to be done:
+
+1. [Use the new container image](#container-image)
+2. [Use the new configuration API](#using-the-new-configuration-api)
+3. [Meet minimal security requirements](#meet-minimal-security-requirements)
+
+### Container Image
+
+Change the image tag in your deployment scripts to use `2.0.0` or above.
+
+Alternatively, choose one of our other [container image tags](self-hosted-gateway-overview.md#container-images).
+
+You can find a full list of available tags [here](https://mcr.microsoft.com/v2/azure-api-management/gateway/tags/list) or find us on [Docker Hub](https://hub.docker.com/_/microsoft-azure-api-management-gateway).
+
+### Using the new configuration API
+
+In order to migrate to self-hosted gateway v2, customers need to use our new Configuration API v2.
+
+Currently, Azure API Management provides the following Configuration APIs for self-hosted gateway:
+
+| Configuration Service | URL | Supported | Requirements |
+| --- | --- | --- | --- |
+| v2 | `{name}.configuration.azure-api.net` | Yes | [Link](self-hosted-gateway-overview.md#gateway-v2-requirements) |
+| v1 | `{name}.management.azure-api.net/subscriptions/{sub-id}/resourceGroups/{rg-name}/providers/Microsoft.ApiManagement/service/{name}?api-version=2021-01-01-preview` | No | [Link](self-hosted-gateway-overview.md#gateway-v1-requirements) |
+
+Customer must use the new Configuration API v2 by changing their deployment scripts to use the new URL and meet infrastructure requirements.
+
+> [!IMPORTANT]
+> * DNS hostname must be resolvable to IP addresses and the corresponding IP addresses must be reachable.
+> This might require additional configuration in case you are using a private DNS, internal VNET or other infrastrutural requirements.
+
+### Meet minimal security requirements
+
+During startup, the self-hosted gateway will prepare the CA certificates that will be used. This requires the gateway container to run with at least user ID 1001 and can't use read-only file system.
+
+When configuring a security context for the container in Kubernetes, the following are required at minimum:
+
+```yaml
+securityContext:
+  runAsNonRoot: true
+  runAsUser: 1001
+  readOnlyRootFilesystem: false
+```
+
+However, as of `2.0.3` the self-hosted gateway is able to run as non-root in Kubernetes allowing customers to run the gateway more securely.
+
+Here's an example of the security context for the self-hosted gateway:
+```yml
+securityContext:
+  allowPrivilegeEscalation: false
+  runAsNonRoot: true
+  runAsUser: 1001       # This is a built-in user, but you can use any user ie 1000 as well
+  runAsGroup: 2000      # This is just an example
+  privileged: false
+  capabilities:
+    drop:
+    - all
+```
+
+> [!WARNING]
+> Running the self-hosted gateway with read-only filesystem (`readOnlyRootFilesystem: true`) is not supported.
+
+## Known limitations
+
+Here's a list of known limitations for the self-hosted gateway v2:
+
+- Configuration API v2 doesn't support custom domain names
+
+## Next steps
+
+-   Learn more about [API Management in a Hybrid and Multi-Cloud World](https://aka.ms/hybrid-and-multi-cloud-api-management)
+-   Learn more about guidance for [running the self-hosted gateway on Kubernetes in production](how-to-self-hosted-gateway-on-kubernetes-in-production.md)
+-   [Deploy self-hosted gateway to Docker](how-to-deploy-self-hosted-gateway-docker.md)
+-   [Deploy self-hosted gateway to Kubernetes](how-to-deploy-self-hosted-gateway-kubernetes.md)
+-   [Deploy self-hosted gateway to Azure Arc-enabled Kubernetes cluster](how-to-deploy-self-hosted-gateway-azure-arc.md)

articles/app-service/reference-app-settings.md

@@ -32,7 +32,7 @@ The following environment variables are related to the app environment in genera
 | `WEBSOCKET_CONCURRENT_REQUEST_LIMIT` | Read-only. Limit for websocket's concurrent requests. For **Standard** tier and above, the value is `-1`, but there's still a per VM limit based on your VM size (see [Cross VM Numerical Limits](https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#cross-vm-numerical-limits)). ||
 | `WEBSITE_PRIVATE_EXTENSIONS` | Set to `0` to disable the use of private site extensions. ||
 | `WEBSITE_TIME_ZONE` | By default, the time zone for the app is always UTC. You can change it to any of the valid values that are listed in [TimeZone](/previous-versions/windows/it-pro/windows-vista/cc749073(v=ws.10)). If the specified value isn't recognized, UTC is used. | `Atlantic Standard Time` |
-| `WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG` | In the case of a storage volume failover or reconfiguration, your app is switched over to a standby storage volume. The default setting of `1` prevents your worker process from recycling when the storage infrastructure changes. If you are running a Windows Communication Foundation (WCF) app, disable it by setting it to `0`. The setting is slot-specific, so you should set it in all slots. ||
+| `WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG` | After slot swaps, the app may experience unexpected restarts. This is because after a swap, the hostname binding configuration goes out of sync, which by itself doesn't cause restarts. However, certain underlying storage events (such as storage volume failovers) may detect these discrepancies and force all worker processes to restart. To minimize these types of restarts, set the app setting value to `1`on all slots (default is`0`). However, do not set this value if you are running a Windows Communication Foundation (WCF) application. For more information, see [Troubleshoot swaps](deploy-staging-slots.md#troubleshoot-swaps)||
 | `WEBSITE_PROACTIVE_AUTOHEAL_ENABLED` | By default, a VM instance is proactively "autohealed" when it's using more than 90% of allocated memory for more than 30 seconds, or when 80% of the total requests in the last two minutes take longer than 200 seconds. If a VM instance has triggered one of these rules, the recovery process is an overlapping restart of the instance. Set to `false` to disable this recovery behavior. The default is `true`. For more information, see [Proactive Auto Heal](https://azure.github.io/AppService/2017/08/17/Introducing-Proactive-Auto-Heal.html). ||
 | `WEBSITE_PROACTIVE_CRASHMONITORING_ENABLED` | Whenever the w3wp.exe process on a VM instance of your app crashes due to an unhandled exception for more than three times in 24 hours, a debugger process is attached to the main worker process on that instance, and collects a memory dump when the worker process crashes again. This memory dump is then analyzed and the call stack of the thread that caused the crash is logged in your App Service’s logs. Set to `false` to disable this automatic monitoring behavior. The default is `true`. For more information, see [Proactive Crash Monitoring](https://azure.github.io/AppService/2021/03/01/Proactive-Crash-Monitoring-in-Azure-App-Service.html). ||
 | `WEBSITE_DAAS_STORAGE_SASURI` | During crash monitoring (proactive or manual), the memory dumps are deleted by default. To save the memory dumps to a storage blob container, specify the SAS URI.  ||

articles/azure-arc/data/managed-instance-disaster-recovery.md

@@ -65,14 +65,9 @@ The following image shows a properly configured distributed availability group:
 
 4. Create the failover group resource on both sites. 
 
-   If the managed instance names are identical between the two sites, you do not need to use the `--shared-name <name of failover group>` parameter.
 
-   If the managed instance names are different between the two sites, use the `--shared-name <name of failover group>` parameter. 
-
-   The following examples use the `--shared-name <name of failover group>...` to complete the task. The command seeds system databases in the disaster recovery instance, from the primary instance.
- 
    > [!NOTE]
-   > The `shared-name` value should be identical on both sites.
+   > Ensure the SQL instances have different names for both primary and secondary sites, and the `shared-name` value should be identical on both sites.
    
     ```azurecli
     az sql instance-failover-group-arc create --shared-name <name of failover group> --name <name for primary DAG resource> --mi <local SQL managed instance name> --role primary --partner-mi <partner SQL managed instance name>  --partner-mirroring-url tcp://<secondary IP> --partner-mirroring-cert-file <secondary.pem> --k8s-namespace <namespace> --use-k8s

articles/azure-arc/data/storage-configuration.md

@@ -200,6 +200,7 @@ If there are multiple databases on a given database instance, all of the databas
 
 Important factors to consider when choosing a storage class for the database instance pods:
 
+- Starting with the February, 2022 release of Azure Arc data services, you need to specify a **ReadWriteMany** (RWX) capable storage class for backups. Learn more about [access modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes). If no storage class is specified for backups, the default storage class in kubernetes is used and if this is not RWX capable, an Azure SQL managed instance deployment may not succeed.
 - Database instances can be deployed in either a single pod pattern or a multiple pod pattern. An example of a single pod pattern is a General Purpose pricing tier Azure SQL managed instance. An example of a multiple pod pattern is a highly available Business Critical pricing tier Azure SQL managed instance. Database instances deployed with the single pod pattern **must** use a remote, shared storage class in order to ensure data durability and so that if a pod or node dies that when the pod is brought back up it can connect again to the persistent volume. In contrast, a highly available Azure SQL managed instance uses Always On Availability Groups to replicate the data from one instance to another either synchronously or asynchronously. Especially in the case where the data is replicated synchronously, there is always multiple copies of the data - typically three copies. Because of this, it is possible to use local storage or remote, shared storage classes for data and log files. If utilizing local storage, the data is still preserved even in the case of a failed pod, node, or storage hardware because there are multiple copies of the data. Given this flexibility, you might choose to use local storage for better performance.
 - Database performance is largely a function of the I/O throughput of a given storage device. If your database is heavy on reads or heavy on writes, then you should choose a storage class with hardware designed for that type of workload. For example, if your database is mostly used for writes, you might choose local storage with RAID 0. If your database is mostly used for reads of a small amount of "hot data", but there is a large overall storage volume of cold data, then you might choose a SAN device capable of tiered storage. Choosing the right storage class is not any different than choosing the type of storage you would use for any database.
 - If you are using a local storage volume provisioner, ensure that the local volumes that are provisioned for data, logs, and backups are each landing on different underlying storage devices to avoid contention on disk I/O. The OS should also be on a volume that is mounted to a separate disk(s). This is essentially the same guidance as would be followed for a database instance on physical hardware.

articles/azure-monitor/logs/private-link-design.md

@@ -126,7 +126,6 @@ Restricting access as explained above applies to data in the resource. However,
 > Queries sent through the Azure Resource Management (ARM) API can't use Azure Monitor Private Links. These queries can only go through if the target resource allows queries from public networks (set through the Network Isolation blade, or [using the CLI](./private-link-configure.md#set-resource-access-flags)).
 >
 > The following experiences are known to run queries through the ARM API:
-> * Sentinel
 > * LogicApp connector
 > * Update Management solution
 > * Change Tracking solution