Remember the days when you spend hours if not days just to get a lab environment in place and any time you wanted to use the environment again, you spend another couple of hours to get It updated. About 3 years ago I started to make more use of Azure based compute to run my virtual machines, that I use for technology learning and research activities. Initially created the virtual machines through the portal, but then soon started to use Azure Resource Manager based provisioning techniques and PowerShell which speeded up provisioning times quite a bit.
This week I took a closer look at the Azure Dev Test labs, and it’s just AWESOME. It’s only the beginning of 2017, but I am pretty sure this is one of the coolest things I see in 2017. Why? It only took me about 90 minutes only to configure and provision a complete fresh lab environment with an Active Directory domain, a Windows 10 client and an instance of the System Center Configuration Manager current branch. And now that I have the basic configuration in place, future lab deployments will even go faster.
I see a lot potential for small shops and enterprises to adopt Azure Dev Test lab, as it helps reducing time for deploying and managing test environments. In these days were companies continuously deliver new software versions, it’s essential that these versions can be tested. Azure Dev Test lab can facilitate this process.
I you haven’t heard of Azure Dev Test Lab yet, here’s an overview video: https://channel9.msdn.com/Blogs/Azure/What-is-Azure-DevTest-Labs
In this blog post I will walk through the process of deploying a test lab for System Center Configuration Manager current branch TP.
The lab consists of the following:
· Virtual Network
· Azure Active Directory domain
· System Center Configuration Manager current branch
· SQL Server 2014 SP2
· Windows 10 client
Setting up Azure Dev Test Lab
Within the Azure portal, search for “Dev Test Labs” in the market place.
Select “Dev Test Labs” and then “Create”. Provide a name, select the subscription and location. I recommend to leave the Auto Shutdown enabled, this can be changed later if needed. Then select “Create” to start provisioning the dev test lab instance.
Now wait for the deployment to complete.
Before we continue, let’s take a look at the resources that were created.
Configuring Secrets
First we setup a secret, select the “My Screts” tab, then add “MasterAdmin” and enter a complex password. Example: @Access4theAdmin123
Important: Ensure that you create a complex password, otherwise the creation of an Active Directory will fail.
Formula for Active Directory
Select “Formulas”, “Add”
1. Select Windows Server 2016 Datacenter
2. Enter the formula name “Active Directory”
3. Add a description
4. Enter a user name Note this user will be the domain enterprise admin.
5. Select the password from the “secrets list”
Next select the VM Size.
Next select the “Artifacts” tab (1), then select “Create Domain” (2).
Next enter the Domain NetBios name (1), the Domain FQDN (2) and finally the Recovery password from the “Secrets” list.
No changes are needed for “Advanced Settings” but I share the screenshot anyway for illustration purposes. Next select “Create” to start the Formula deployment process. Note this does not deploy the VM yet, it only saves the formula.
Deploying Active Directory
Select the “All Virtual Machines” tab and then click “Add”
Next select a “Base”
1. Select the “Active Directory” base we just created previously.
2. Enter a name for the VM “DC1”
3. Select “Create” to start the VM deployment process.
After a few seconds, you will see the VM appear in the list. While Active Directory is being deployed, we will continue creating a formula for the other lab components.
Formula for Active Directory
1. Select the “Formulas” tab
2. Select “Add”
1. Select “SQL Server 2016 SP1 on Windows Server 2016” as the base.
2. Enter the formula name “ConfigMgr TP”
3. Add a description
4. Enter a user name “Master_Admin”
5. Select the password from the “Secrets List”
Select “VM Size” Since this server will have to host SQL Server and ConfigMgr, I have chosen a larger VM size.
1. Select the “Artifacts” tab
2. Select “Active Directory domain join”
3. Enter the domain name “contoso.com”
4. Enter the OU name OU=CM,DC=contoso,DC=com
5. Enter the domain join account “contoso.com\Mcaster_Admin”
6. Select the password from the Secrets list.
7. Leave domain join option to “3”
8. Select “Add”.
Note the domain account (5) in the above screenshot is wrong and should be: contoso.com\Master_Admin
Next we add the “Configuration Manager” artifact.
1. Select configuration manager current branch”
2. Select “Add”
Select “OK” to finish the artifacts configuration.
No changes to “Advanced Settings” are needed, so we skip that one.
Next, select “Create” to save the formula.
When completed, the ConfigMgr template will appear in the formulas list.
Before we continue…..
Before continue with the deployment of the ConfigMgr instance, let’s first take a look at the Active Directory domain that should now be deployed and running. Furthermore, we will need to do some pre-configuration so that the ConfigMgr deployment will work.
System “DC1” is running, and the artifact “Windows Create Domain” was successful.
Now we need to logon to the domain controller. You might have noticed that previously when we entered the domain join information for the ConfigMgr formula, we entered the OU path OU=CM,DC=contoso,DC=com.
The “CM” OU doesn’t exist yet, so let’s create that one now.
Within the Remote session on DC1, open PowerShell as Administrator and enter the following commands.
New-ADOrganizationalUnit -Name “CM” -Path “DC=contoso,DC=com”
Get-ADOrganizationalUnit -Filter * | Where-Object {$_.name -eq “CM”}
Next open a command prompt and run ipconfig, then note down the IP address of the server.
DNS Configurtion
In order to allow other systems to be joined to the domain, we have to add a DNS configuration to the Virtual Network used by the Azure Dev Test lab.
1. Within the Azure Portal, select “Virtual Networks”
1. Select the Virtual Network that belongs to the Dev Test Lab
2. Select “DNS Servers”
3. Select “Custom” and add the IP address of the Active Directory Server.
4. Click “Save”
Now all prerequisites are in place, so we can continue with the deployment of ConfigMgr.
Deploying ConfigMgr
Now let’s continue with deploying an instance of ConfigMgr.
1. Select “All virtual machines”
2. Select “Add”
1. Select “ConfigMgr” as the base
2. Enter a name for the VM “CM1”
3. Select “Create” to start the deployment process.
Formula for Windows 10 Client
Now that we have already created two formulas, you should be familiar how to create one. Here’s the formula definition I created for the Windows 10 Client.
· Based on Windows 10 Enterprise N
· Added the Join Domain artifact
· Size = Standard DS1
Deploying Windows 10 Client
1. Select “All virtual machines”
2. Select “Add”
3. Select “Windows10Client” as the base
4. Enter a name for the VM “VM1”
5. Select “Create”
Wait for the deployment process to complete and there we go; our lab is ready.
I hope you enjoyed this post and hopefully it provided you with some inspiration on how to run your labs within a Cloud environment. I personally think this is a great solution.
Hi there,
We are attempting to follow this article but found the windows-Domain artifact is failing – have you encountered this? We have re-created several times now. The error simply is showing a status error from the BM agent or extension.
Very useful article! Thank you for this.
If I may suggest to add a comment at the RDP level when connecting to the DC VM, you need to modify the RDP file because it contains the username credentials in the format of devicename\username instead of domain\username. So you’ll have people (such as myself :)) who will keep trying to connect using the password they’ve stored in the My Secrets vault and won’t know why they can’t.
You basically have to do 1 of 2 things (or both):
1. Either open the RDP file in Notepad and modify the credentials
OR
2. Right click on the RDP file and select Edit. This will open the RDP connection settings dialog box. You can then edit the credentials and click on ‘Save’
Great post!
How come you did not add the step for extending the AD schema? Also, what account is used to install the site? You will have issues launching the console unless you have a way to add your account to SCCM admins group.
I followed your directions but have one issue. Site was deployed under local system machine account which basically locks all the other users out of SCCM. Do you have a workaround or did I miss a step? When I try to connect with the account created in the formula I get this user does not have access…. error at the console. Any help will be appreciated.