another article

Author: v-thepet

articles/devtest-labs/devtest-lab-reference-architecture.md

@@ -12,7 +12,7 @@ This article provides a reference architecture for deploying Azure DevTest Labs
 
 - On-premises connectivity via Azure ExpressRoute
 - A remote desktop gateway to remotely sign in to virtual machines (VMs)
-- Connectivity to an artifact repository for private artifacts
+- Connectivity to a private artifact repository
 - Other platform-as-a-service (PaaS) components that labs use
 
 
@@ -24,35 +24,47 @@ This reference architecture has the following key elements:
 
 - DevTest Labs. DevTest Labs makes it easy and fast for enterprises to provide access to Azure resources. For more information, see [About DevTest Labs](devtest-lab-overview.md).
 
-- VMs and other software-as-a-service (SaaS), infrastructure-as-a-service (IaaS), and PaaS resources. DevTest Labs instances contain VMs and other Azure resources like PaaS environments and VM artifacts, which are software and settings to apply to VMs. 
+- VMs and other software-as-a-service (SaaS), infrastructure-as-a-service (IaaS), and PaaS resources.
 
-- [Azure Active Directory (Azure AD)] for identity management. Lab owners use Azure role-based access control (Azure RBAC) to assign roles to users and set resource and access-level permissions.
+  DevTest Labs instances contain VMs and other Azure resources like PaaS environments and VM artifacts. Artifacts are tools, actions, or software to add to lab VMs. 
+
+- [Azure Active Directory (Azure AD)](/azure/active-directory/fundamentals/active-directory-whatis) for identity management.
 
   Lab VMs usually have a local admin account. If there's an Azure AD, on-premises, or [Azure AD Domain Services](../active-directory-domain-services/overview.md) domain available, you can join lab VMs to the domain. Users can then use their domain-based identities to connect to the VMs.
 
-- [ExpressRoute](../expressroute/expressroute-introduction.md) for on-premises connectivity. You can also use a [site-to-site VPN](../vpn-gateway/vpn-gateway-about-vpn-gateway-settings.md). You need on-premises connectivity only if your labs need access to on-premises corporate resources. Common scenarios are:
+- [ExpressRoute](../expressroute/expressroute-introduction.md) for on-premises connectivity. You can also use a [site-to-site VPN](../vpn-gateway/vpn-gateway-about-vpn-gateway-settings.md). You need on-premises connectivity only if your labs need access to on-premises corporate resources.
+
+  Common scenarios are:
 
   - Some on-premises data can't move to the cloud.
-  - You want to join lab VMs to the on-premises domain.
+  - You want to join lab VMs to an on-premises domain.
   - You want to force all cloud network traffic through an on-premises firewall for security or compliance reasons.
 
-- A [remote desktop gateway](/windows-server/remote/remote-desktop-services/desktop-hosting-logical-architecture) to enable outgoing remote desktop protocol (RDP) connections to DevTest Labs. Enterprise corporate firewalls usually block outgoing connections at the corporate firewall. To enable connectivity, you can:
+- A [remote desktop gateway](/windows-server/remote/remote-desktop-services/desktop-hosting-logical-architecture) to enable outgoing remote desktop protocol (RDP) connections to DevTest Labs.
+
+  Enterprise corporate firewalls usually block outgoing connections at the corporate firewall. To enable connectivity, you can:
 
   - Use a remote desktop gateway, and allow the static IP address of the gateway load balancer.
-  - [Use forced tunneling](../vpn-gateway/vpn-gateway-forced-tunneling-rm.md) to redirect all RDP traffic back over the ExpressRoute or site-to-site VPN connection. This functionality is common for enterprises using a DevTest Labs deployment.
+  - [Use forced tunneling](../vpn-gateway/vpn-gateway-forced-tunneling-rm.md) to redirect all RDP traffic back over the ExpressRoute or site-to-site VPN connection. This is common functionality for enterprise-scale DevTest Labs deployments.
+
+- [Azure networking topology](../networking/fundamentals/networking-overview.md) to control how lab resources access and communicate with on-premises networks and the internet.
 
-- [Azure networking topology](../networking/fundamentals/networking-overview.md) controls how lab resources access and communicate with on-premises networks and the internet. This architecture shows the most common way customers connect DevTest Labs. All labs connect via [peered virtual networks](../virtual-network/virtual-network-peering-overview.md) in a [hub-spoke configuration](/azure/architecture/reference-architectures/hybrid-networking/hub-spoke), through the ExpressRoute or site-to-site VPN connection, to the on-premises network. Because DevTest Labs uses Azure Virtual Network directly, there are no restrictions on how you set up the networking infrastructure.
+  This architecture shows a common way enterprises network DevTest Labs. The labs connect via [peered virtual networks](../virtual-network/virtual-network-peering-overview.md) in a [hub-spoke configuration](/azure/architecture/reference-architectures/hybrid-networking/hub-spoke), through the ExpressRoute or site-to-site VPN connection, to the on-premises network.
 
-- A [network security group](../virtual-network/network-security-groups-overview.md) restricts traffic to or within the cloud environment, based on source and destination IP addresses. For example, you can allow only traffic that originates from the corporate network into the lab's networks.
+  Because DevTest Labs uses Azure Virtual Network directly, there are no restrictions on how you set up the networking infrastructure.
+
+- A [network security group](../virtual-network/network-security-groups-overview.md) to restrict cloud traffic based on source and destination IP addresses. For example, you can allow only traffic that originates from the corporate network into the lab's networks.
 
 ## Scalability considerations
 
-DevTest Labs doesn't have built-in quotas or limits, but other Azure resources that labs use have [subscription-level quotas](../azure-resource-manager/management/azure-subscription-service-limits.md). In a typical enterprise deployment, you need multiple Azure subscriptions to cover a large deployment of DevTest Labs. The quotas that enterprises most commonly reach are:
+DevTest Labs has no built-in quotas or limits, but other Azure resources that labs use have [subscription-level quotas](../azure-resource-manager/management/azure-subscription-service-limits.md). In a typical enterprise deployment, you need several Azure subscriptions to cover a large DevTest Labs deployment. Enterprises commonly reach the following quotas:
+
+- Resource groups. DevTest Labs creates a resource group for every new VM, and lab users create environments in resource groups. Subscriptions can contain [up to 980 resource groups](../azure-resource-manager/management/azure-subscription-service-limits.md#subscription-limits), so that's the limit of VMs and environments in a subscription.
 
-- Resource groups. In the default configuration, DevTest Labs creates a resource group for every new VM, or lab users create environments in resource groups. Subscriptions can contain [up to 980 resource groups](../azure-resource-manager/management/azure-subscription-service-limits.md#subscription-limits), so that's the limit of VMs and environments in a subscription. Two strategies can help you stay under resource group limits:
+  Two strategies can help you stay under resource group limits:
 
-  - [All VMs go in the same resource group](resource-group-control.md). This strategy setup helps you meet the resource group limit, but it affects the resource-type-per-resource-group limit.
-  - Use shared Public IPs. If VMs are allowed to have public IP addresses, put all VMs of the same size and region into the same resource group. This configuration helps meet resource group quotas and resource-type-per-resource-group quotas.
+  - [All VMs go in the same resource group](resource-group-control.md). This strategy helps you meet the resource group limit, but it affects the resource-type-per-resource-group limit.
+  - Use shared Public IPs. If VMs are allowed to have public IP addresses, put all VMs of the same size and region into the same resource group. This configuration helps meet both resource group quotas and resource-type-per-resource-group quotas.
 
 - Resources per resource group per resource type. The default limit for [resources per resource group per resource type is 800](../azure-resource-manager/management/azure-subscription-service-limits.md#resource-group-limits).  Putting all VMs in the same resource group hits this limit much sooner, especially if the VMs have many extra disks.
 
@@ -62,27 +74,29 @@ DevTest Labs doesn't have built-in quotas or limits, but other Azure resources t
 
   By default, DevTest Labs creates a resource group for each VM. The VM creator gets *owner* permission for the VM and *reader* permission to the resource group. So each new VM uses two role assignments. Granting user permissions to the lab also uses role assignments.
 
-- API reads/writes. You can automate Azure and DevTest Labs by using REST APIs, PowerShell, Azure CLI, and Azure SDK. Each Azure subscription allows up to [12,000 read requests and 1,200 write requests per hour](../azure-resource-manager/management/request-limits-and-throttling.md). Be aware that by automating DevTest Labs, you might hit the limit on API requests.
+- API reads/writes. You can automate Azure and DevTest Labs by using REST APIs, PowerShell, Azure CLI, and Azure SDK. Each Azure subscription allows up to [12,000 read requests and 1,200 write requests per hour](../azure-resource-manager/management/request-limits-and-throttling.md). By automating DevTest Labs, you might hit the limit on API requests.
 
 ## Manageability considerations
 
-You can use the DevTest Labs administrative user interface in the Azure portal to work with a single lab. Enterprises might have multiple Azure subscriptions and many labs. Making changes consistently to all labs requires scripting automation. Here are some examples and best management practices for scripting in DevTest Labs deployments:
+You can use the DevTest Labs user interface in the Azure portal to administer a single lab at a time. Enterprises might have multiple Azure subscriptions and many labs to administer. Making changes consistently to all labs requires scripting automation.
+
+Here are some examples of using scripting in DevTest Labs deployments:
 
 - Change lab settings. Update a specific lab setting across all labs by using PowerShell scripts, Azure CLI, or REST APIs. For example, update all labs to allow a new VM instance size.
 
-- Update artifact repository personal access tokens (PATs). PATs for Git repositories typically expire in 90 days, one year, or two years. To ensure continuity, it's important to extend the PAT. Or, or create a new one and use automation to apply it to all the labs.
+- Update artifact repository personal access tokens (PATs). PATs for Git repositories typically expire in 90 days, one year, or two years. To ensure continuity, it's important to extend the PAT. Or, create a new PAT and use automation to apply it to all labs.
 
-- Restrict changes to lab settings. To restrict certain settings, such as allowing marketplace image use, you can use Azure Policy to prevent changes to a resource type. Or you can create a custom role, and grant users that role instead of the Owner role for the lab. You can restrict changes for most lab settings, such as internal support, lab announcements, and allowed VM sizes.
+- Restrict changes to lab settings. To restrict certain settings, such as allowing marketplace image use, you can use Azure Policy to prevent changes to a resource type. Or you can create a custom role, and grant users that role instead of a built-in lab role. You can restrict changes for most lab settings, such as internal support, lab announcements, and allowed VM sizes.
 
-- Require VMs to follow a naming convention. You can easily identify VMs that are part of a cloud-based environment by using Azure Policy to [specify a naming pattern](https://github.com/Azure/azure-policy/tree/master/samples/TextPatterns/allow-multiple-name-patterns).
+- Require VMs to follow a naming convention. You can use Azure Policy to [specify a naming pattern](https://github.com/Azure/azure-policy/tree/master/samples/TextPatterns/allow-multiple-name-patterns) that helps identify VMs in cloud-based environments.
 
-You manage underlying Azure resources for DevTest Labs the same way you manage them for other purposes. For example, Azure Policy applies to VMs you create in a lab. Microsoft Defender for Cloud can report on lab VM compliance. Azure Backup can provide regular backups for lab VMs.
+You manage underlying Azure resources for DevTest Labs the same as for other purposes. For example, Azure Policy applies to VMs you create in a lab. Microsoft Defender for Cloud can report on lab VM compliance. Azure Backup can provide regular backups for lab VMs.
 
 ## Security considerations
 
-DevTest Labs automatically benefits from built-in Azure security features. For example, to require incoming remote desktop connections to originate only from the corporate network, simply add a network security group to the virtual network on the remote desktop gateway.
+DevTest Labs automatically benefits from built-in Azure security features. For example, to require incoming remote desktop connections to originate only from the corporate network, you can add a network security group to the virtual network on the remote desktop gateway.
 
-The only other security consideration is the permission level you grant to lab users. The most common lab permissions are Owner, Contributor, and User. For more information, see [Add owners and users in Azure DevTest Labs](devtest-lab-add-devtest-user.md).
+Another security consideration is the permission level you grant to lab users. Lab owners use Azure role-based access control (Azure RBAC) to assign roles to users and set resource and access-level permissions. The most common DevTest Labs permissions are Owner, Contributor, and User. You can also create and assign [custom roles](devtest-lab-grant-user-permissions-to-specific-lab-policies.md). For more information, see [Add owners and users in Azure DevTest Labs](devtest-lab-add-devtest-user.md).
 
 ## Next steps
-See the next article in this series: [Scale up your Azure DevTest Labs infrastructure](devtest-lab-guidance-scale.md).
+See the next article in this series: [Deliver a proof of concept](deliver-proof-concept.md).

articles/devtest-labs/encrypt-storage.md

@@ -1,71 +1,50 @@
 ---
-title: Encrypt an Azure storage account used by a lab
-description: Learn how to configure encryption of an Azure storage used by a lab in Azure DevTest Labs 
+title: Manage storage accounts for labs
+description: Learn about DevTest Labs storage accounts, encryption, customer-managed keys, and setting expiration dates for artifact results storage.
 ms.topic: how-to
-ms.date: 07/29/2020
+ms.date: 03/15/2022
 ---
 
-# Encrypt Azure storage used by a lab in Azure DevTest Labs
-Every lab created in Azure DevTest Labs is created with an associated Azure storage account. The storage account is used for the following purposes: 
+# Manage storage accounts in Azure DevTest Labs
 
-- Storing [formula](devtest-lab-manage-formulas.md) documents that can be used to create virtual machines.
-- Storing artifact results that include deployment and extension logs generated from applying artifacts. 
-- [Uploading virtual hard disks (VHDs) to create custom images in the lab.](devtest-lab-create-template.md)
-- Caching frequently used [artifacts](add-artifact-vm.md) and [Azure Resource Manager templates](devtest-lab-create-environment-from-arm.md) for faster retrieval during virtual machine/environment creation.
+This article explains how to view and manage the Azure Storage accounts associated with Azure DevTest Labs instances.
 
-> [!NOTE]
-> The information above is critical for the lab to operate. It's stored for the life of the lab (and lab resources) unless explicitly deleted. Manually deleting these resources can lead to errors in creating lab VMs and/or formulas becoming corrupt for future use. 
+## View storage account contents
 
-## Locate the storage account and view its contents
+DevTest Labs automatically creates an Azure Storage account for every lab it creates. To see a lab's storage account and the information it holds:
 
-1. On the home page for the lab, select the **resource group** on the **Overview** page. You should see the **Resource group** page for the resource group that contains the lab. 
+1. On the lab's **Overview** page, select the **Resource group**.
 
-    :::image type="content" source="./media/encrypt-storage/overview-resource-group-link.png" alt-text="Select resource group on the Overview page":::
-1. Select the Azure storage account of the lab. The naming convention for the lab storage account is: `a<labNameWithoutInvalidCharacters><4-digit number>`. For example, if the lab name is `contosolab`, the storage account name could be `acontosolab7576`. 
+   :::image type="content" source="./media/encrypt-storage/overview-resource-group-link.png" alt-text="Screenshot that shows selecting the resource group on the lab Overview page.":::
 
-    :::image type="content" source="./media/encrypt-storage/select-storage-account.png" alt-text="Select storage account in the resource group of the lab":::
-3. On the **Storage account** page, select **Storage Explorer (preview)** on the left menu, and then select **BLOB CONTAINERS** to find relevant lab-related content. 
+1. On the resource group's **Overview** page, select the lab's storage account. The naming convention for the lab storage account is: `a<labName><4-digit number>`. For example, if the lab name is `contosolab`, the storage account name could be `acontosolab5237`. 
 
-   :::image type="content" source="./media/encrypt-storage/storage-explorer.png" alt-text="Storage Explorer (Preview)" lightbox="./media/encrypt-storage/storage-explorer.png":::
+   :::image type="content" source="./media/encrypt-storage/select-storage-account.png" alt-text="Screenshot that shows selecting the storage account in the lab's resource group.":::
 
-## Encrypt the lab storage account
-Azure Storage automatically encrypts your data when it's persisted to the cloud. Azure Storage encryption protects your data and helps you to meet your organizational security and compliance commitments. For more information, see [Azure Storage encryption for data at rest](../storage/common/storage-service-encryption.md).
+3. On the **Storage account** page, select **Storage browser (preview)** on the left menu, and then select **Blob containers** to see relevant lab-related content.
 
-Data in the lab storage account is encrypted with a **Microsoft-managed key**. You can rely on Microsoft-managed keys for the encryption of your data, or you can manage encryption with your own keys. If you choose to manage encryption with your own keys for the lab’s storage account, you can specify a **customer-managed key** with Azure Key Vault to use for encrypting/decrypting data in Blob storage and in Azure Files. For more information about customer-managed keys, see [Use customer-managed keys with Azure Key Vault to manage Azure Storage encryption](../storage/common/customer-managed-keys-overview.md).
+   :::image type="content" source="./media/encrypt-storage/storage-explorer.png" alt-text="Screenshot that shows the Storage browser (preview).":::
 
-To learn how to configure customer-managed keys for Azure Storage encryption, see the following articles: 
+## Manage Azure Storage lifecycle
 
-- [Azure portal](../storage/common/customer-managed-keys-configure-key-vault.md)
-- [Azure PowerShell](../storage/common/customer-managed-keys-configure-key-vault.md)
-- [Azure CLI](../storage/common/customer-managed-keys-configure-key-vault.md)
+The lab storage account stores:
 
+- [Formula documents](devtest-lab-manage-formulas.md) to use for creating lab virtual machines (VMs).
+- [Uploaded virtual hard disks (VHDs)](devtest-lab-create-template.md) to use for creating custom VM images.
+- [Artifact](add-artifact-vm.md) and [Azure Resource Manager (ARM) template](devtest-lab-create-environment-from-arm.md) caches, for faster retrieval during VM and environment creation.
+- Artifact results, which are deployment and extension logs generated from applying artifacts.
 
-## Manage the Azure Blob storage life cycle
-As mentioned, the information stored in the Lab’s storage account is critical for the lab to operate without any errors. Unless explicitly deleted, this data will continue to remain in the lab’s storage account for the life of the lab or the life of specific lab virtual machines, depending on the type of data.
+The information in the lab storage account persists for the life of the lab and its resources, unless explicitly deleted. Most of this information is critical for the lab to operate. Manually deleting storage account information can cause data corruption or VM creation errors.
 
-### Uploaded VHDs
-These VHDs are used to create custom images. Removing them will make it no longer possible to create custom images from these VHDs.
+- Removing uploaded VHDs makes it no longer possible to create custom images from these VHDs.
+- Deleting formula documents can lead to errors when creating VMs from formulas, updating formulas, or creating new formulas.
+- DevTest Labs refreshes the artifact and ARM template caches whenever the lab connects to the artifact or template repositories. If you remove the caches manually, DevTest Labs recreates the caches the next time it connects to the repositories.
 
-### Artifacts Cache
-These caches will be re-created any time artifacts are applied. They'll be refreshed with the latest content from the respective referenced repositories. So, if you delete this information to save Storage-related expenses, the relief will be temporary.
+### Set expiration for artifact results
 
-### Azure Resource Manager template Cache
-These caches will be re-created any time Azure Resource Manager-based template repositories are connected and spun up in the lab. They'll be refreshed with the latest content from the respective referenced repositories. So, if you delete this information to save Storage-related expenses, the relief will be temporary.
+The artifact results size can increase over time as artifacts are applied. You can set an expiration rule for artifact results to regularly delete older results from the storage account. This practice reduces storage account size and helps control costs.
 
-### Formulas
-These documents are used to support the option to both create formulas from existing VMs, and creating VMs from formulas. Deleting these formula documents may lead to errors while doing the following operations:
-
-- Creating a formula from an existing lab VM
-- Creating or updating formulas 
-- Creating a VM from a formula.
-
-### Artifact results
-As artifacts are applied, the size of the respective artifact results can increase over time depending on the number and type of artifacts being run on lab VMs. So, as a lab owner, you may want to control the lifecycle of such documents. For more information, see [Manage the Azure Blob storage lifecycle](../storage/blobs/lifecycle-management-overview.md).
-
-> [!IMPORTANT]
-> We recommend that you do this step to reduce expenses associated with the Azure Storage account. 
-
-For example, the following rule is used to set a 90-day expiration rule specifically for artifact results. It ensures that older artifact results are recycled from the storage account on a regular cadence.
+The following rule sets a 90-day expiration specifically for artifact results:
 
 ```json
 {
@@ -93,9 +72,15 @@ For example, the following rule is used to set a 90-day expiration rule specific
 }
 ```
 
+## Storage encryption and customer-managed keys
+
+Azure Storage automatically encrypts all data in the lab storage account. Azure Storage encryption protects your data and helps meet organizational security and compliance commitments. For more information, see [Azure Storage encryption for data at rest](../storage/common/storage-service-encryption.md).
+
+Azure Storage encrypts lab data with a Microsoft-managed key. Optionally, you can manage encryption with your own keys. If you choose to manage lab storage account encryption with your own keys, you can specify a customer-managed key with Azure Key Vault to use for encrypting and decrypting data. For more information, see [Use customer-managed keys with Azure Key Vault to manage Azure Storage encryption](../storage/common/customer-managed-keys-overview.md).
+
+For instructions on configuring customer-managed keys for Azure Storage encryption, see [Configure encryption with customer-managed keys stored in Azure Key Vault](/azure/storage/common/customer-managed-keys-configure-key-vault).
+
 ## Next steps
-To learn how to configure customer-managed keys for Azure Storage encryption, see the following articles: 
 
-- [Azure portal](../storage/common/customer-managed-keys-configure-key-vault.md)
-- [Azure PowerShell](../storage/common/customer-managed-keys-configure-key-vault.md)
-- [Azure CLI](../storage/common/customer-managed-keys-configure-key-vault.md)
+For more information about managing Azure Storage, see [Optimize costs by automatically managing the data lifecycle](../storage/blobs/lifecycle-management-overview.md).
+