Merge pull request #191752 from MicrosoftDocs/main

3/15 AM Publish

Author: huypub

articles/active-directory/app-provisioning/skip-out-of-scope-deletions.md

@@ -76,7 +76,7 @@ Copy the updated text from Step 3 into the "Request Body".
 
 Click on “Run Query”. 
 
-You should get the output as "Success – Status Code 204". 
+You should get the output as "Success – Status Code 204". If you receive an error you may need to check that your account has Read/Write permissions for ServicePrincipalEndpoint. You can find this permission by clicking on the *Modify permissions* tab in Graph Explorer.
 
    ![PUT response](./media/skip-out-of-scope-deletions/skip-06.png)
 

articles/active-directory/cloud-infrastructure-entitlement-management/cloudknox-product-data-sources.md

@@ -62,7 +62,7 @@ You can use the **Data Collectors** dashboard in CloudKnox Permissions Managemen
 1. Select the ellipses **(...)** at the end of the row in the table.
 1. Select **Edit Configuration**. 
 
-    The **M-CIEM Onboarding - Summary** box displays.
+    The **CloudKnox Onboarding - Summary** box displays.
 
 1. Select **Edit** (the pencil icon) for each field you want to change. 
 1. Select **Verify now & save**.

articles/active-directory/hybrid/how-to-connect-install-prerequisites.md

@@ -36,7 +36,6 @@ Before you install Azure AD Connect, there are a few things that you need.
 
 ### On-premises Active Directory
 * The Active Directory schema version and forest functional level must be Windows Server 2003 or later. The domain controllers can run any version as long as the schema version and forest-level requirements are met.
-* If you plan to use the feature *password writeback*, the domain controllers must be on Windows Server 2016 or later.
 * The domain controller used by Azure AD must be writable. Using a read-only domain controller (RODC) *isn't supported*, and Azure AD Connect doesn't follow any write redirects.
 * Using on-premises forests or domains by using "dotted" (name contains a period ".") NetBIOS names *isn't supported*.
 * We recommend that you [enable the Active Directory recycle bin](how-to-connect-sync-recycle-bin.md).

articles/active-directory/standards/memo-22-09-meet-identity-requirements.md

@@ -17,7 +17,7 @@ ms.collection: M365-identity-device-management
 
 # Meeting identity requirements of Memorandum 22-09 with Azure Active Directory
 
-This series of articles offer guidance for employing Azure Active Directory (Azure AD) as a centralized identity management system for implementing Zero Trust principles as described by the US Federal Government’s Office of Management and Budget (OMB) [Memorandum M-22-09](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf). Throughout this document wee refer to it as "The memo."
+This series of articles offer guidance for employing Azure Active Directory (Azure AD) as a centralized identity management system for implementing Zero Trust principles as described by the US Federal Government’s Office of Management and Budget (OMB) [Memorandum M-22-09](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf). Throughout this document we refer to it as "The memo."
 
 The release of Memorandum 22-09 is designed to support Zero trust initiatives within federal agencies; it also provides regulatory guidance in supporting Federal Cybersecurity and Data Privacy Laws. The Memo cites the [Department of Defense (DoD) Zero Trust Reference Architecture](https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf), 
 

articles/aks/csi-storage-drivers.md

@@ -3,7 +3,7 @@ title: Enable Container Storage Interface (CSI) drivers on Azure Kubernetes Serv
 description: Learn how to enable the Container Storage Interface (CSI) drivers for Azure disks and Azure Files in an Azure Kubernetes Service (AKS) cluster.
 services: container-service
 ms.topic: article
-ms.date: 03/10/2022
+ms.date: 03/11/2022
 author: palma21
 
 ---
@@ -17,18 +17,12 @@ The CSI storage driver support on AKS allows you to natively use:
 - [*Azure Files*](azure-files-csi.md), which can be used to mount an SMB 3.0/3.1 share backed by an Azure Storage account to pods. With Azure Files, you can share data across multiple nodes and pods. Azure Files can use Azure Standard Storage backed by regular HDDs or Azure Premium Storage backed by high-performance SSDs.
 
 > [!IMPORTANT]
-> Starting in Kubernetes version 1.21, Kubernetes will use CSI drivers only and by default. These drivers are the future of storage support in Kubernetes.
+> Starting in Kubernetes version 1.21, AKS will use CSI drivers only and by default. CSI migration is also turned on starting from AKS 1.21, existing in-tree persistent volumes continue to function as they always have; however, behind the scenes Kubernetes hands control of all storage management operations (previously targeting in-tree drivers) to CSI drivers.
 > 
 > Please remove manual installed open source Azure Disk and Azure File CSI drivers before upgrading to AKS 1.21.
 > 
 > *In-tree drivers* refers to the current storage drivers that are part of the core Kubernetes code versus the new CSI drivers, which are plug-ins.
 
-## Limitations
-
-- This feature can only be set at cluster creation time.
-- The minimum Kubernetes minor version that supports CSI drivers is v1.17.
-- The default storage class will be the `managed-csi` storage class.
-
 ## Install CSI storage drivers on a new cluster with version < 1.21
 
 Create a new cluster that can use CSI storage drivers for Azure disks and Azure Files by using the following CLI commands. Use the `--aks-custom-headers` flag to set the `EnableAzureDiskFileCSIDriver` feature.
@@ -67,14 +61,9 @@ $ echo $(kubectl get CSINode <NODE NAME> -o jsonpath="{.spec.drivers[1].allocata
  - [Set up Azure File CSI driver on AKS cluster](https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/docs/install-driver-on-aks.md)
 
 ## Migrating custom in-tree storage classes to CSI
-If you have created custom storage classes based on the in-tree storage drivers, these will need to be migrated when you have upgraded your cluster to 1.21.x.
-
-Whilst explicit migration to the CSI provider is not needed for your storage classes to still be valid, to be able to use CSI features (snapshotting etc.) you will need to carry out the migration.
-
-Migration of these storage classes will involve deleting the existing storage classes, and re-provisioning them with the provisioner set to **disk.csi.azure.com** if using Azure Disks, and **files.csi.azure.com** if using Azure Files.  
-
-Whilst this will update the mapping of the storage classes, the binding of the Persistent Volume to the CSI provisioner will only take place at provisioning time. This could be during a cordon & drain operation (cluster update) or by detaching and reattaching the Volume.
+If you have created in-tree driver storage classes, those storage classes will continue to work since CSI migration is turned on after upgrading your cluster to 1.21.x, while if you want to use CSI features (snapshotting etc.) you will need to carry out the migration.
 
+Migration of these storage classes will involve deleting the existing storage classes, and re-creating them with the provisioner set to **disk.csi.azure.com** if using Azure Disks, and **files.csi.azure.com** if using Azure Files.  
 
 ### Migrating Storage Class provisioner
 
@@ -86,12 +75,11 @@ As an example for Azure disks:
 kind: StorageClass
 apiVersion: storage.k8s.io/v1
 metadata:
-  name: managed-premium-retain
+  name: custom-managed-premium
 provisioner: kubernetes.io/azure-disk
-reclaimPolicy: Retain
+reclaimPolicy: Delete
 parameters:
-  storageaccounttype: Premium_LRS
-  kind: Managed
+  storageAccountType: Premium_LRS
 ```
 
 #### CSI storage class definition
@@ -100,26 +88,30 @@ parameters:
 kind: StorageClass
 apiVersion: storage.k8s.io/v1
 metadata:
-  name: managed-premium-retain
+  name: custom-managed-premium
 provisioner: disk.csi.azure.com
-reclaimPolicy: Retain
+reclaimPolicy: Delete
 parameters:
-  storageaccounttype: Premium_LRS
-  kind: Managed
+  storageAccountType: Premium_LRS
 ```
 
 The CSI storage system supports the same features as the In-tree drivers, so the only change needed would be the provisioner.
 
-
-### Migrating in-tree disk persistent volumes
+## Migrating in-tree persistent volumes
 
 > [!IMPORTANT]
 > If your in-tree Persistent Volume reclaimPolicy is set to Delete you will need to change the Persistent Volume to Retain to persist your data.  This can be achieved via a [patch operation on the PV](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/). For example:
 > ```console
 > $ kubectl patch pv pv-azuredisk --type merge --patch '{"spec": {"persistentVolumeReclaimPolicy": "Retain"}}'
 > ```
 
-If you have in-tree persistent volumes, get disk ID from `azureDisk.diskURI` and then follow this [guide][azure-disk-static-mount] to set up CSI driver persistent volumes
+### Migrating in-tree Azure Disk persistent volumes
+
+If you have in-tree Azure Disk persistent volumes, get `diskURI` from in-tree persistent volumes and then follow this [guide][azure-disk-static-mount] to set up CSI driver persistent volumes
+
+### Migrating in-tree Azure File persistent volumes
+
+If you have in-tree Azure File persistent volumes, get `secretName`, `shareName` from in-tree persistent volumes and then follow this [guide][azure-file-static-mount] to set up CSI driver persistent volumes
 
 ## Next steps
 
@@ -140,6 +132,7 @@ If you have in-tree persistent volumes, get disk ID from `azureDisk.diskURI` and
 <!-- LINKS - internal -->
 [azure-disk-volume]: azure-disk-volume.md
 [azure-disk-static-mount]: azure-disk-volume.md#mount-disk-as-volume
+[azure-file-static-mount]: azure-files-volume.md#mount-file-share-as-a-persistent-volume
 [azure-files-pvc]: azure-files-dynamic-pv.md
 [premium-storage]: ../virtual-machines/disks-types.md
 [az-disk-list]: /cli/azure/disk#az_disk_list

articles/app-service/environment/migrate.md

@@ -3,7 +3,7 @@ title: Migrate to App Service Environment v3 by using the migration feature
 description: Overview of the migration feature for migration to App Service Environment v3
 author: seligj95
 ms.topic: article
-ms.date: 2/10/2022
+ms.date: 3/14/2022
 ms.author: jordanselig
 ms.custom: references_regions
 ---
@@ -19,13 +19,22 @@ App Service can now automate migration of your App Service Environment v2 to an
 
 At this time, App Service Environment migrations to v3 using the migration feature support both [Internal Load Balancer (ILB)](create-ilb-ase.md) and [external (internet facing with public IP)](create-external-ase.md) App Service Environment v2 in the following regions:
 
-- West Central US
-- Canada Central
-- UK South
-- Germany West Central
-- East Asia
 - Australia East
+- Australia Central
 - Australia Southeast
+- Canada Central
+- Central India
+- East Asia
+- East US
+- East US 2
+- France Central
+- Germany West Central
+- Korea Central
+- Norway East
+- Switzerland North
+- UAE North
+- UK South
+- West Central US
 
 You can find the version of your App Service Environment by navigating to your App Service Environment in the [Azure portal](https://portal.azure.com) and selecting **Configuration** under **Settings** on the left-hand side. You can also use [Azure Resource Explorer](https://resources.azure.com/) and review the value of the `kind` property for your App Service Environment.
 

articles/applied-ai-services/form-recognizer/includes/get-started/java.md

@@ -92,7 +92,7 @@ You will create the following directory structure:
 
 :::image type="content" source="../../media/quickstarts/java-directories.png" alt-text="Screenshot: Java directory structure":::
 
-Navigate to the java directory and create a file called *FormRecognizer.java*.  Open it in your preferred editor or IDE and add the following package declaration and  `import` statements:
+Navigate to the Java directory and create a file called *FormRecognizer.java*.  Open it in your preferred editor or IDE and add the following package declaration and `import` statements:
 
 ```java
 import com.azure.ai.formrecognizer.*;

articles/azure-functions/bring-dependency-to-functions.md

@@ -84,7 +84,7 @@ One of the simplest ways to bring in dependencies is to put the files/artifact t
  | - local.settings.json
  | - pom.xml
 ```
-For java specifically, you need to specifically include the artifacts into the build/target folder when copying resources. Here's  an example on how to do it in Maven:
+For Java specifically, you need to specifically include the artifacts into the build/target folder when copying resources. Here's an example on how to do it in Maven:
 
 ```xml
 ...

articles/azure-functions/functions-how-to-github-actions.md

@@ -330,7 +330,7 @@ env:
   AZURE_FUNCTIONAPP_NAME: your-app-name      # set this to your function app name on Azure
   POM_XML_DIRECTORY: '.'                     # set this to the directory which contains pom.xml file
   POM_FUNCTIONAPP_NAME: your-app-name        # set this to the function app name in your local development environment
-  JAVA_VERSION: '1.8.x'                      # set this to the java version to use
+  JAVA_VERSION: '1.8.x'                      # set this to the Java version to use
 
 jobs:
   build-and-deploy:

articles/azure-functions/functions-versions.md

@@ -149,6 +149,8 @@ The following are some changes to be aware of before upgrading a 3.x app to 4.x.
 
 - Default and maximum timeouts are now enforced in 4.x Linux consumption function apps. ([#1915](https://github.com/Azure/Azure-Functions/issues/1915))
 
+- Azure Functions 4.x uses Azure.Identity and Azure.Security.KeyVault.Secrets for the Key Vault provider and has deprecated the use of Microsoft.Azure.KeyVault. See the Key Vault option in [Secret Repositories](security-concepts.md#secret-repositories) for more information on how to configure function app settings. ([#2048](https://github.com/Azure/Azure-Functions/issues/2048))
+
 - Function apps that share storage accounts will fail to start if their computed hostnames are the same. Use a separate storage account for each function app. ([#2049](https://github.com/Azure/Azure-Functions/issues/2049))
 
 ::: zone pivot="programming-language-csharp"