Yes, we have a Lab...

Most Customers are looking for a ConfigMgr Test-LAB, a playground for the SCCM Admins to implement and test new features and addons or to simulate a disaster recovery scenario...

It's often the PoC Environment that will be renamed to the new LAB or it will be built during the initial ConfigMgr project... but once running, it's often:

• outdated
• no one is using it (sometimes they don't even know that a such an environment exists)
• it's empty (no Client, no Apps)
• it does not reflect production (e.g. LAB is a single Server, but Prod has remote SQL etc.)

... not very helpful ...

Why do we need a LAB ?!

Everyone is doing backup... ConfigMgr Backup-Task, SQL Backup, File-Backup etc. But have you ever restored a Site or the full Environment ?! That's something you have to practice !!!
Simulating a disaster recovery, is one of the things you should regularly do (in a LAB environment :-).

What is needed:

• Separated environment (no connection to prod)
• same Domain name
• same Server names
• same volumes on the servers (recommended)
• same Service-Accounts (recommended)
• ...

that's the point where most customers give up.. But there is on option:

hosting ConfigMgr in Azure

I'm using Azure DevTest Labs to host my ConfigMgr Lab environment because I can build a simple ConfigMgr environment within an hour (depending on the server size), do my tests, and if not needed anymore, just drop it..

For a full recovery scenario it may require some more things to plan before you start:

Resource Groups

When creating a new Azure DevTest Lab, it's configured to "Default resource group allocation" where server resources sometimes get an own Resource Group and sometimes they share a Resource Group.

I never had a problem with that on smaller environments, but in case of some special requirements like an SQL Always On availability group, it can become a problem (details later)...

I recommend to use a single Resource Group for all the resources in a ConfigMgr Lab.

See also: Specify a resource group for lab virtual machines in Azure DevTest Labs

Shared-IP

Shared-IP is also enabled by default. With Shared-IP, you can access (Remote Desktop) your servers by using a single external IP. Every of your Servers will have a different port for RDP on the external IP.

That's normally not a problem, unless you come to the point where you want to change the size of your server(s).

Note: You can not change the size of a server with a shared IP.

Well, you can, but you have to disconnect the network adapter before you can resize. It's not a big problem but you should be aware of that...

Server Sizing

It does not help if you build a lab with cheapest server sizes, but the infrastructure is so slow that working is a pain... You also don't have to oversize it, but finding the right balance of size and performance may need some adjustments (that's why I had to resize my servers).
I also recommend to use SSD Disks for the OS and other IO intensive volumes from the beginning... Converting an OS Disk to SSD in a later stage can become a challenge.

Data Disks

Do not install everything on the OS Volume just to reduce costs. Data Disks can be re-attached to different servers. So if you have for example a dedicated Data-Disk with your Package- and Installation Sources (this one does not need to be a high performance SSD), you can re-use this disk in case of you rebuild the lab.
For Recovery tests, the Servers should have the same volumes as in Production.

Note: Disk-Storage can generate costs even if the Servers are turned off..

Active Directory Domain

As mentioned before, if you plan to do some recovery tests, you must use the same Active Directory Domain Name as in your Prod Environment. As long as you do not connect your Lab with your Prod Network (e.g. VPN), it will be fine...
Maybe you can involve the AD Team to let them restore the Prod AD in Lab. See: Backing Up and Restoring an Active Directory Server. One benefit will be to get all Service Accounts from Prod. If it's not possible to restore your prod AD (there may be some legal and security constrains), build your own domain with the same name as in prod. Create your Service Accounts before restoring the site.

Design your LAB

Before you create the first Machine, define the number of Servers you want to build and try to calculate the costs based on Azure Pricing calculator. If you are going to restore your Prod Site, define the Site Systems you want to include in your DR test. It does not make sense to build dozens of Distribution-Points an a Lab.

The following diagram was a scenario to test high availability with an active/passive site server. It's a LAB design for some specific test scenarios...

The expected calculated costs are 2000$ per Month, but only if the Environment is running 7/24. You may need a working day or two to set it up but you can shutdown it over night (or per default, Azure DevTest Lab will do that for you automatically). At the end, the infrastructure costs for that Test was less than 300$.

Marketplace Images

Using predefined Marketplace Images (like "SQL Server 2017 Enterprise Windows Server 2019") will reduce the time you need to setup the environment... But remember that if you want to restore a Site On-Premise in case of a disaster, you need to have the installation source and OS images to setup a server.

Note: To restore a ConfigMgr Site, you have to install the same SQL Version (and ServicePack) as in Production.

and another important one:

Marketplace Images do not include licenses for the product you install !!!

Artifacts

I'm the author of several Artifacts (automatated Installation routines) in the public Azure DevTest Lab repository (Install RuckZuck Package, CreateDomain, ConfigurationMangaer CB + TP ...) and I often use these Artifacts for my "adhoc" Site Server installations. In case of a more complex Environment or a DR test, I recommend to setup (and document) the steps you need to install and restore a site manually.

Note: SQL AlwaysOn availability groups in Azure

I'm not an SQL expert but I was able to setup an SQL AlwaysOn availability group (by following the Tutorial)
But the Listener was not working... I was not able to open a connection from a remote server to the Listener.. It took me a while to figure out that the Azure load balancer does need a special setup. See: Configure a load balancer for an Always On availability group in Azure