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

Author: HeidiSteen

.openpublishing.redirection.azure-productivity.json

@@ -149,6 +149,11 @@
       "source_path": "articles/lab-services/classroom-labs-faq.yml",
       "redirect_url": "/azure/lab-services/lab-services-overview",
       "redirect_document_id": false
-    }
+    },
+	{
+		"source_path": "articles/lab-services/how-to-enable-nested-virtualization-template-vm-ui.md",
+		"redirect_url": "/azure/lab-services/how-to-enable-nested-virtualization-template-vm-using-script",
+		"redirect_document_id": false
+	}
   ]
 }

articles/active-directory/fundamentals/multi-tenant-user-management-introduction.md

@@ -55,9 +55,9 @@ Most documentation for B2B refers to an external user as a guest user. It confla
 
 [Cross-tenant synchronization](../multi-tenant-organizations/cross-tenant-synchronization-overview.md) enables multi-tenant organizations to provide seamless access and collaboration experiences to end users, leveraging existing B2B external collaboration capabilities. The feature doesn't allow cross-tenant synchronization across Microsoft sovereign clouds (such as Microsoft 365 US Government GCC High, DOD or Office 365 in China). See [Common considerations for multi-tenant user management](multi-tenant-common-considerations.md#cross-tenant-synchronization) for help with automated and custom cross-tenant synchronization scenarios.
 
-Watch John Savill talk about the cross-tenant sync capability in Azure AD (embedded below).
+Watch Arvind Harinder talk about the cross-tenant sync capability in Azure AD (embedded below).
 
-> [!VIDEO https://www.youtube.com/embed/z0J5kteqUVQ]
+> [!VIDEO https://www.youtube.com/embed/7B-PQwNfGBc]
 
 The following conceptual and how-to articles provide information about Azure AD B2B collaboration and cross-tenant synchronization.
 
@@ -119,7 +119,7 @@ Organizations initially focus on requirements that they want in place for immedi
 - **Single Sign On:** Enable users to access resources across the organization without the need to enter more credentials.
 ### Patterns for account creation 
 
-Microsoft mechanisms for creating and managing the lifecycle of your external user accounts follow three common patterns. You can use these patterns to help define and implement your requirements. Choose the pattern that best aligns with your scenario and then focus on the pattern details.
+Microsoft mechanisms for creating and managing the lifecycle of your external user accounts follow three common patterns. You can use these patterns to help define and implement your requirements. Choose the pattern that best aligns with your scenario and then focus on the pattern details.  
 
 | Mechanism |  Description | Best when |
 | - | - | - |

articles/active-directory/reports-monitoring/howto-manage-inactive-user-accounts.md

@@ -22,16 +22,16 @@ This article explains a method to handle obsolete user accounts in Azure Active
 
 ## What are inactive user accounts?
 
-Inactive accounts are user accounts that aren't required anymore by members of your organization to gain access to your resources. One key identifier for inactive accounts is that they haven't been used *for a while* to sign in to your environment. Because inactive accounts are tied to the sign-in activity, you can use the timestamp of the last sign-in that was successful to detect them. 
+Inactive accounts are user accounts that aren't required anymore by members of your organization to gain access to your resources. One key identifier for inactive accounts is that they haven't been used *for a while* to sign in to your environment. Because inactive accounts are tied to the sign-in activity, you can use the timestamp of the last time an account attempted to sign in to detect inactive accounts. 
 
 The challenge of this method is to define what *for a while* means for your environment. For example, users might not sign in to an environment *for a while*, because they are on vacation. When defining what your delta for inactive user accounts is, you need to factor in all legitimate reasons for not signing in to your environment. In many organizations, the delta for inactive user accounts is between 90 and 180 days. 
 
-The last successful sign-in provides potential insights into a user's continued need for access to resources.  It can help with determining if group membership or app access is still needed or could be removed. For external user management, you can understand if an external user is still active within the tenant or should be cleaned up. 
+The last sign-in provides potential insights into a user's continued need for access to resources.  It can help with determining if group membership or app access is still needed or could be removed. For external user management, you can understand if an external user is still active within the tenant or should be cleaned up. 
 
 ## Detect inactive user accounts with Microsoft Graph
 <a name="how-to-detect-inactive-user-accounts"></a>
 
-You can detect inactive accounts by evaluating the `lastSignInDateTime` property exposed by the `signInActivity` resource type of the **Microsoft Graph API**. The `lastSignInDateTime` property shows the last time a user made a successful interactive sign-in to Azure AD. Using this property, you can implement a solution for the following scenarios:
+You can detect inactive accounts by evaluating the `lastSignInDateTime` property exposed by the `signInActivity` resource type of the **Microsoft Graph API**. The `lastSignInDateTime` property shows the last time a user attempted to make an interactive sign-in attempt in Azure AD. Using this property, you can implement a solution for the following scenarios:
 
 - **Last sign-in date and time for all users**: In this scenario, you need to generate a report of the last sign-in date of all users. You request a list of all users, and the last `lastSignInDateTime` for each respective user:
     - `https://graph.microsoft.com/v1.0/users?$select=displayName,signInActivity` 
@@ -59,11 +59,11 @@ The following details relate to the `lastSignInDateTime` property.
     - AuditLog.Read.All
     - User.Read.All
 
-- Each interactive sign-in that was successful results in an update of the underlying data store. Typically, successful sign-ins show up in the related sign-in report within 10 minutes.
+- Each interactive sign-in attempt results in an update of the underlying data store. Typically, sign-ins show up in the related sign-in report within 6 hours. 
 
-- To generate a `lastSignInDateTime` timestamp, you need a successful sign-in. The value of the `lastSignInDateTime` property may be blank if:
-    - The last successful sign-in of a user took place before April 2020.
-    - The affected user account was never used for a successful sign-in.
+- To generate a `lastSignInDateTime` timestamp, you an attempted sign-in. The value of the `lastSignInDateTime` property may be blank if:
+    - The last attempted sign-in of a user took place before April 2020.
+    - The affected user account was never used for a sign-in attempt.
 
 - The last sign-in date is associated with the user object. The value is retained until the next sign-in of the user. 
 

articles/aks/TOC.yml

@@ -500,6 +500,8 @@
               href: azure-disk-csi.md
             - name: Provision Azure Disks storage
               href: azure-csi-disk-storage-provision.md
+            - name: Use Azure Premium SSD v2 disks
+              href: use-premium-v2-disks.md
             - name: Use Azure ultra disks
               href: use-ultra-disks.md
         - name: Other storage options

articles/aks/azure-netapp-files.md

@@ -370,7 +370,7 @@ This section walks you through the installation of Astra Trident using the opera
 1. Before creating a backend, you need to update [backend-anf.yaml][backend-anf.yaml] to include details about the Azure NetApp Files subscription, such as:
 
     * `subscriptionID` for the Azure subscription where Azure NetApp Files will be enabled.
-    * `tenantID`, `clientID`, and `clientSecret` from an [App Registration][azure-ad-app-registration] in Azure Active Directory (AD) with sufficient permissions for the Azure NetApp Files service. The App Registration include the `Owner` or `Contributor` role that's predefined by Azure.
+    * `tenantID`, `clientID`, and `clientSecret` from an [App Registration][azure-ad-app-registration] in Azure Active Directory (AD) with sufficient permissions for the Azure NetApp Files service. The App Registration includes the `Owner` or `Contributor` role that's predefined by Azure.
     * An Azure location that contains at least one delegated subnet.
 
     In addition, you can choose to provide a different service level. Azure NetApp Files provides three [service levels](../azure-netapp-files/azure-netapp-files-service-levels.md): Standard, Premium, and Ultra.
@@ -411,7 +411,7 @@ A storage class is used to define how a unit of storage is dynamically created w
     kubectl apply -f anf-storageclass.yaml
     ```
 
-   The output of the command resembles the following example::
+   The output of the command resembles the following example:
 
     ```console
     storageclass/azure-netapp-files created
@@ -544,10 +544,6 @@ After the PVC is created, a pod can be spun up to access the Azure NetApp Files
       Normal  Started                 10s   kubelet                  Started container nginx
     ```
 
-## Using Azure tags
-
-For more details on using Azure tags, see [Use Azure tags in Azure Kubernetes Service (AKS)][use-tags].
-
 ## Next steps
 
 Astra Trident supports many features with Azure NetApp Files. For more information, see:

articles/aks/use-premium-v2-disks.md

@@ -0,0 +1,205 @@
+---
+title: Enable Premium SSD v2 Disk support on Azure Kubernetes Service (AKS)
+description: Learn how to enable and configure Premium SSD v2 Disks in an Azure Kubernetes Service (AKS) cluster.
+ms.topic: article
+ms.date: 04/25/2023
+
+---
+
+# Use Azure Premium SSD v2 disks on Azure Kubernetes Service
+
+[Azure Premium SSD v2 disks][azure-premium-v2-disk-overview] offer IO-intense enterprise workloads, a consistent submillisecond disk latency, and high IOPS and throughput. The performance (capacity, throughput, and IOPS) of Premium SSD v2 disks can be independently configured at any time, making it easier for more scenarios to be cost efficient while meeting performance needs.
+
+This article describes how to configure a new or existing AKS cluster to use Azure Premium SSD v2 disks.
+
+## Before you begin
+
+Before creating or upgrading an AKS cluster that is able to use Azure Premium SSD v2 disks, you need to create an AKS cluster in the same region and availability zone that supports Premium Storage and attach the disks following the steps below.
+
+For an existing AKS cluster, you can enable Premium SSD v2 disks by adding a new node pool to your cluster, and then attach the disks following the steps below.
+
+> [!IMPORTANT]
+> Azure Premium SSD v2 disks require node pools deployed in regions that support these disks. For a list of supported regions, see [Premium SSD v2 disk supported regions][premium-v2-regions].
+
+### Limitations
+
+- Azure Premium SSD v2 disks have certain limitations that you need to be aware of. For a complete list, see [Premium SSD v2 limitations][premium-v2-limitations].
+
+## Use Premium SSD v2 disks dynamically with a storage class
+
+To use Premium SSD v2 disks in a deployment or stateful set, you can use a [storage class for dynamic provisioning][azure-disk-volume].
+
+### Create the storage class
+
+A storage class is used to define how a unit of storage is dynamically created with a persistent volume. For more information on Kubernetes storage classes, see [Kubernetes Storage Classes][kubernetes-storage-classes].
+
+In this example, you create a storage class that references Premium SSD v2 disks. Create a file named `azure-pv2-disk-sc.yaml`, and copy in the following manifest.
+
+```yaml
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+   name: premium2-disk-sc
+parameters:
+   cachingMode: None
+   skuName: PremiumV2_LRS
+   DiskIOPSReadWrite: "4000"
+   DiskMBpsReadWrite: "1000"
+provisioner: disk.csi.azure.com
+reclaimPolicy: Delete
+volumeBindingMode: Immediate
+allowVolumeExpansion: true
+```
+
+Create the storage class with the [kubectl apply][kubectl-apply] command and specify your *azure-pv2-disk-sc.yaml* file:
+
+```bash
+kubectl apply -f azure-pv2-disk-sc.yaml
+```
+
+The output from the command resembles the following example:
+
+```console
+storageclass.storage.k8s.io/premium2-disk-sc created
+```
+
+## Create a persistent volume claim
+
+A persistent volume claim (PVC) is used to automatically provision storage based on a storage class. In this case, a PVC can use the previously created storage class to create an ultra disk.
+
+Create a file named `azure-pv2-disk-pvc.yaml`, and copy in the following manifest. The claim requests a disk named `premium2-disk` that is *1000 GB* in size with *ReadWriteOnce* access. The *premium2-disk-sc* storage class is specified as the storage class.
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: premium2-disk
+spec:
+  accessModes:
+  - ReadWriteOnce
+  storageClassName: premium2-disk-sc
+  resources:
+    requests:
+      storage: 1000Gi
+```
+
+Create the persistent volume claim with the [kubectl apply][kubectl-apply] command and specify your *azure-pv2-disk-pvc.yaml* file:
+
+```bash
+kubectl apply -f azure-pv2-disk-pvc.yaml
+```
+
+The output from the command resembles the following example:
+
+```console
+persistentvolumeclaim/premium2-disk created
+```
+
+## Use the persistent volume
+
+Once the persistent volume claim has been created and the disk successfully provisioned, a pod can be created with access to the disk. The following manifest creates a basic NGINX pod that uses the persistent volume claim named *premium2-disk* to mount the Azure disk at the path `/mnt/azure`.
+
+Create a file named `nginx-premium2.yaml`, and copy in the following manifest.
+
+```yaml
+kind: Pod
+apiVersion: v1
+metadata:
+  name: nginx-premium2
+spec:
+  containers:
+  - name: nginx-premium2
+    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
+    resources:
+      requests:
+        cpu: 100m
+        memory: 128Mi
+      limits:
+        cpu: 250m
+        memory: 256Mi
+    volumeMounts:
+    - mountPath: "/mnt/azure"
+      name: volume
+  volumes:
+    - name: volume
+      persistentVolumeClaim:
+        claimName: premium2-disk
+```
+
+Create the pod with the [kubectl apply][kubectl-apply] command, as shown in the following example:
+
+```bash
+kubectl apply -f nginx-premium2.yaml
+```
+
+The output from the command resembles the following example:
+
+```bash
+pod/nginx-premium2 created
+```
+
+You now have a running pod with your Azure disk mounted in the `/mnt/azure` directory. This configuration can be seen when inspecting your pod via `kubectl describe pod nginx-premium2`, as shown in the following condensed example:
+
+```bash
+kubectl describe pod nginx-premium2
+
+[...]
+Volumes:
+  volume:
+    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
+    ClaimName:  premium2-disk
+    ReadOnly:   false
+  kube-api-access-sh59b:
+    Type:                    Projected (a volume that contains injected data from multiple sources)
+    TokenExpirationSeconds:  3607
+    ConfigMapName:           kube-root-ca.crt
+    ConfigMapOptional:       <nil>
+    DownwardAPI:             true
+QoS Class:                   Burstable
+Node-Selectors:              <none>
+Tolerations:                 node.kubernetes.io/memory-pressure:NoSchedule op=Exists
+                             node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
+                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
+Events:
+  Type    Reason                  Age    From                     Message
+  ----    ------                  ----   ----                     -------
+  Normal  Scheduled               7m58s  default-scheduler        Successfully assigned default/nginx-premium2 to aks-agentpool-12254644-vmss000006
+  Normal  SuccessfulAttachVolume  7m46s  attachdetach-controller  AttachVolume.Attach succeeded for volume "pvc-ff39fb64-1189-4c52-9a24-e065b855b886"
+  Normal  Pulling                 7m39s  kubelet                  Pulling image "mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine"
+  Normal  Pulled                  7m38s  kubelet                  Successfully pulled image "mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine" in 1.192915667s
+  Normal  Created                 7m38s  kubelet                  Created container nginx-premium2
+  Normal  Started                 7m38s  kubelet                  Started container nginx-premium2
+[...]
+```
+
+## Set IOPS and throughput limits
+
+Input/Output Operations Per Second (IOPS) and throughput limits for Azure Premium v2 SSD disk is currently not supported through AKS. To adjust performance, you can use the Azure CLI command [az disk update][az-disk-update] and including the `--disk-iops-read-write` and `--disk-mbps-read-write` parameters.
+
+The following example updates the disk IOPS read/write to **5000** and Mbps to **200**. For `--resource-group`, the value must be the second resource group automatically created to store the AKS worker nodes with the naming convention *MC_resourcegroupname_clustername_location*. For more information, see [Why are two resource groups created with AKS?][aks-two-resource-groups].
+
+The value for the `--name` parameter is the name of the volume created using the StorageClass, and it starts with `pvc-`. To identify the disk name, you can run `kubectl get pvc` or navigate to the secondary resource group in the portal to find it. See [manage resources from the Azure portal][manage-resources-azure-portal] to learn more.
+
+```azurecli
+az disk update --subscription subscriptionName --resource-group myResourceGroup --name diskName --disk-iops-read-write=5000 --disk-mbps-read-write=200  
+```
+
+## Next steps
+
+- For more about Premium SSD v2 disks, see [Using Azure Premium SSD v2 disks](../virtual-machines/disks-deploy-premium-v2.md).
+- For more about storage best practices, see [Best practices for storage and backups in Azure Kubernetes Service (AKS)][operator-best-practices-storage].
+
+<!-- LINKS - external -->
+[kubectl-apply]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply
+[kubernetes-storage-classes]: https://kubernetes.io/docs/concepts/storage/storage-classes/
+
+<!-- LINKS - internal -->
+[azure-premium-v2-disk-overview]: ../virtual-machines/disks-types.md#premium-ssd-v2
+[premium-v2-regions]: ../virtual-machines/disks-types.md#regional-availability
+[premium-v2-limitations]: ../virtual-machines/disks-types.md#premium-ssd-v2-limitations
+[azure-disk-volume]: azure-disk-csi.md
+[use-tags]: use-tags.md
+[operator-best-practices-storage]: operator-best-practices-storage.md
+[az-disk-update]: /cli/azure/disk#az-disk-update
+[manage-resources-azure-portal]: ../azure-resource-manager/management/manage-resources-portal.md#open-resources
+[aks-two-resource-groups]: faq.md#why-are-two-resource-groups-created-with-aks