Build an AD DS Lab in Azure

Build a two-server Active Directory lab in Azure with DNS and domain trust.

Introduction

30 Second Summary

When someone cannot sign in to a work computer, the account itself may be fine. The real problem may sit in the machine's connection to the organisation's login system.

In this project, you will build a self-managed Active Directory Domain Services lab in Microsoft Azure. The finished lab gives you command-line evidence that its domain works from discovery through user administration.

What You'll Build

From your Mac, you'll open both Windows Server desktops to demonstrate a working corp.contoso.com domain with a trusted member server.

By the end of this project, you'll have:

Secure remote access: You can launch both Windows Server desktops from your Mac through Windows App.
Domain health evidence: You can query DNS to see DC01 returned for corp.contoso.com. You can also confirm that MEMBER01 has a healthy secure channel.
Identity administration: You can create jlee in Active Directory Users and Computers. You can inspect the same enabled account in Windows PowerShell.
Secret Mission: Inspect your active RDP session with quser. Then compare it with lower-level Windows logon-session records.

Are there any prerequisites?

You'll need an active Microsoft Azure subscription that can create lab resources within a learner-set ceiling of $25. You'll also need Windows App installed on your Mac.

Before We Start

Before the hands-on work begins, lock in the self-managed Windows administration lab you are building. Connecting the lab to your target role gives every later action a purpose.

Verify Access and Set Cost Guardrails

Your self-managed lab depends on an Azure subscription with permission to create two Azure Virtual Machines. Missing permissions can stop the build before the domain exists.

VM sizing controls how quickly compute costs grow. Shutdown rules control how long those costs continue.

This step also confirms Windows App is ready on your Mac. Both tools need to work before you can reach the servers in the next step.

In this step, get ready to:

Verify your intended Azure subscription has resource-creation permission.
Confirm Windows App launches on your Mac.
Set the lab's cost and network-access guardrails.

Verify your Azure subscription access

Azure role-based access control shows what your account can do at the subscription scope. Checking your access now confirms that resource creation is available before the lab depends on it.

Open the Azure portal in your browser.
Sign in with the account attached to your intended subscription.
Search for Subscriptions in the portal search box.
Select the subscription you intend to use for this lab.
Select Access control (IAM) from the subscription menu.
Select the Check access tab.
Select View my access.
Confirm a listed role grants permission to create resources at this subscription scope.

You should see your access assignments for the intended subscription. That permission check removes the first hidden blocker from your lab.

No Resource-Creation Permission?

Ask your subscription administrator to grant a role that permits resource creation at the intended subscription scope.
Return to View my access after the role becomes active.

Help me understand which Azure permission I need for this lab.

Launch Windows App

Windows App provides the RDP connection from your Mac to each Windows Server desktop. Confirming it launches now removes a client-side surprise when the VMs are ready.

Press Cmd+Space to open Spotlight on your Mac.
Type Windows App into Spotlight.
Press Enter to launch the application.
Confirm the Windows App main window opens successfully.

That connection tool is ready. Your Mac can open the RDP files you download for the servers later.

Where Will the Commands Run?

You do not need local PowerShell or Azure CLI on your Mac. Every administration command in this project runs inside the Windows Server VMs.

Set your cost and access guardrails

The next step starts billable resources. Your $25 ceiling bounds that risk before you select Create.

A resource group keeps related resources under one cleanup boundary. Every lab resource will use the same group name.

Reserve rg-adlab as the resource group name for every lab resource.
Set $25 as your maximum budget for the entire lab.
Require Standard_B2ls_v2 for both planned VMs.
Require Standard SSD for both OS disks.

Why These VM Choices?

The chosen VM size belongs to a burstable series designed for development and testing. It provides enough capacity for this compact two-server lab.

Standard SSD suits lightly used development environments. Azure bills disk storage separately from VM compute.

Stop if Standard_B2ls_v2 is unavailable in your chosen region.
Review the live estimate before each Create action.
Require Auto-shutdown on both VMs.
Permit only RDP (3389) over TCP.
Restrict the RDP source to your current IP address or range.

You have defined the acceptance checks for the next step. Azure still contains no lab resources.

Before the final check, which two open windows should prove that your access path is ready?

Return to the Azure portal.
Confirm your intended subscription remains selected with resource-creation permission verified.
Switch back to Windows App.
Confirm its main window remains open on your Mac.

You should see your intended subscription open with resource-creation access confirmed. You should also see the Windows App main window.

You've cleared the setup gate. Next, you'll deploy DC01 and MEMBER01 without losing sight of cost or network exposure.

Deploy Two Windows Servers

Your access checks and spending limit are ready. The lab now needs two Azure Virtual Machines that can communicate through one Azure Virtual Network.

MEMBER01 relies on DNS to locate Active Directory Domain Services. You will deliberately test that discovery before the domain exists.

In this step, get ready to:

Deploy DC01 on a new Azure virtual network.
Assign DC01 a static private address.
Deploy MEMBER01 before testing domain-controller discovery.

Deploy DC01 on a new network

An Azure resource group gives every lab resource one cleanup boundary. DC01 also creates the private network that both servers use.

Use the Azure portal search to reach the page for resource groups.
Start a new resource-group deployment.
Select the intended Azure subscription.
Enter rg-adlab as the resource-group name.
Choose the region you will use throughout the lab: your Azure region.
Submit the resource-group form.

You should see rg-adlab listed under the intended subscription.

Use the portal search to return to Virtual machines.
Select Create.
Select Virtual machine.

You should now see the form for creating a virtual machine.

Select the intended Azure subscription.
Select rg-adlab as the resource group.
Enter DC01 as the virtual machine name.
Select your Azure region as the VM region.

The form should now place DC01 inside rg-adlab in your chosen region.

Select Windows Server 2022 Datacenter: Azure Edition - x64 Gen 2 as the image.
Select Standard_B2ls_v2 as the size.

The VM summary should show the required Windows Server image. It should also show the required VM size.

Cannot Find the Required Size?

Availability varies by Azure region. Keep the required Standard_B2ls_v2 size by selecting another region for the entire lab.

Ask for help with finding a region that offers Standard_B2ls_v2.

Protect the Administrator Password

This credential controls the server. Use a unique lab-only password with at least 12 characters.

Enter azureuser as the administrator username.
Enter your unique lab-only administrator password.
Select Allow selected ports for public inbound ports.
Select RDP (3389) as the only inbound port.

The form should now show one public inbound option for RDP on TCP port 3389.

Select Standard SSD as the OS disk type.
Enable Delete with VM for the OS disk.
Enable Delete public IP and NIC when VM is deleted.

The disk and network attachments should now be configured for automatic deletion with DC01.

Create a new virtual network named vnet-adlab in the networking settings.
Set its address space to 10.10.0.0/16.
Name the subnet snet-adlab.
Set the subnet address range to 10.10.10.0/24.
Keep Azure-provided DNS for this stage.

The network summary should show vnet-adlab with the snet-adlab subnet. Domain DNS remains absent.

Why Use This Address Plan?

The 10.10.0.0/16 address space leaves room for future lab subnets. The 10.10.10.0/24 subnet holds both servers in this project.

Creating DC01 starts billable Azure usage. Your live estimate is the final checkpoint before that happens.

Select Review + create.
Review the live cost estimate.
Stop if the projected lab total could exceed $25.
Select Create after validation succeeds.

Provisioning can take several minutes. The deployment page shows when DC01 is ready.

Select Go to resource after the deployment succeeds.
Select Auto-shutdown under Operations.
Toggle Auto-shutdown to On.
Choose a shutdown time after your planned lab session.
Select Save.

You should see Auto-shutdown enabled for DC01.

The VM wizard enables RDP access. Restricting its source keeps the server reachable only from your approved address.

Return to Network settings for DC01.
Edit the existing inbound rule for TCP port 3389.
Set Source to your current public IP address or range.
Set Destination port ranges to 3389.
Set Protocol to TCP.
Set Action to Allow.
Set Name to Allow-RDP.
Save the updated inbound rule.

Remove every other custom inbound rule from DC01.

You should see one custom inbound rule for TCP port 3389. Its source should match your approved IP address or range.

DC01 Deployment Blocked?

Confirm that rg-adlab belongs to the intended subscription. Confirm that the selected region offers Standard_B2ls_v2.

Ask for help with diagnosing the DC01 deployment.

Assign DC01 a static private address

DNS clients need a stable destination for future domain queries. Azure assigns that address through the VM's network interface.

This setting sits inside the network interface configuration. The VM overview page provides the path to it.

Select the network interface from the DC01 network settings.
Select IP configurations.
Select the primary IP configuration.
Change Allocation to Static.
Enter 10.10.10.11 as the private IP address.
Select Save.

Where Should the Address Live?

Azure manages the primary private address through the network interface. Keep the Windows guest operating system on its Azure-managed network configuration.

Return to the DC01 overview page.

You should see 10.10.10.11 as the private IP address. That stable address is ready for the DNS configuration in the next step.

Cannot Save the Static Address?

Confirm that the network interface belongs to DC01. Confirm that it is attached to snet-adlab.

Ask for help with assigning 10.10.10.11 to the DC01 network interface.

Deploy MEMBER01 and prove the discovery gap

The second server uses the existing network as an ordinary member machine. Its first domain-controller lookup captures the lab before any forest or domain DNS service exists.

Return to Virtual machines in the Azure portal.
Select Create.
Select Virtual machine.

You should see a new virtual-machine form.

Select the intended Azure subscription.
Select rg-adlab as the resource group.
Enter MEMBER01 as the virtual machine name.
Select your Azure region as the VM region.

The form should place MEMBER01 beside DC01 in the same region.

Select Windows Server 2022 Datacenter: Azure Edition - x64 Gen 2 as the image.
Select Standard_B2ls_v2 as the size.
Enter azureuser as the administrator username.
Enter your unique lab-only administrator password.

The VM summary should match the image and size used by DC01.

Select Standard SSD as the OS disk type.
Enable Delete with VM for the OS disk.
Enable Delete public IP and NIC when VM is deleted.

The disk and network attachments should now be configured for automatic deletion with MEMBER01.

Select vnet-adlab as the existing virtual network.
Select snet-adlab as the subnet.
Select Allow selected ports for public inbound ports.
Select RDP (3389) as the only inbound port.

The networking summary should show the same virtual network and subnet as DC01.

Creating MEMBER01 adds the second billable VM. Check the combined projection against your spending ceiling before continuing.

Select Review + create.
Review the live cost estimate for MEMBER01.
Stop if the projected lab total could exceed $25.
Select Create after validation succeeds.

Provisioning can take several minutes. The deployment page shows when MEMBER01 is ready.

Select Go to resource after the deployment succeeds.
Select Auto-shutdown under Operations.
Toggle Auto-shutdown to On.
Choose a shutdown time after your planned lab session.
Select Save.

You should see Auto-shutdown enabled for MEMBER01.

Return to Network settings for MEMBER01.
Edit the existing inbound rule for TCP port 3389.
Set Source to your current public IP address or range.
Set Destination port ranges to 3389.
Set Protocol to TCP.
Set Action to Allow.
Set Name to Allow-RDP.
Save the updated inbound rule.

Remove every other custom inbound rule from MEMBER01.

You should see one custom inbound rule for TCP port 3389. Its source should match the rule on DC01.

MEMBER01 Deployment Blocked?

Confirm that MEMBER01 uses the same region as DC01. Confirm that it uses vnet-adlab with snet-adlab.

Ask for help with diagnosing the MEMBER01 deployment.

Each downloaded RDP file tells Windows App which public address to use. Your local azureuser credentials authenticate directly to each server.

Return to the DC01 overview page.
Select Connect.
Choose Native RDP.
Select Download RDP File.
Open the downloaded file with Windows App from earlier.
Enter azureuser as the local username.
Enter your lab-only administrator password.

The first sign-in can take a minute while Windows prepares the profile. You should see the DC01 desktop.

Return to the MEMBER01 overview page.
Select Connect.
Choose Native RDP.
Select Download RDP File.
Open the downloaded file with Windows App from earlier.
Enter azureuser as the local username.
Enter your lab-only administrator password.

You should see the MEMBER01 desktop. Both server desktops are now reachable from your Mac.

The final check uses Windows PowerShell 5.1 on MEMBER01. The query asks for the locator record that a domain controller would register.

Launch Windows PowerShell 5.1 as an administrator from the Windows Start menu on MEMBER01.

Before you run the query, do you think this network can return a domain controller yet?

Test domain-controller discovery by running this command:

Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.corp.contoso.com" -Type SRV

What Does This Query Test?

The query asks DNS for the SRV record used to locate a domain controller for corp.contoso.com.
A domain controller normally registers this locator record.

The lookup fails with a DNS-resolution error. No SRV answer identifies DC01 as a domain controller.

That failure is the planned baseline. No AD DS forest exists yet.

Does the Lookup Succeed Unexpectedly?

A successful SRV answer means MEMBER01 is using a DNS source that already knows corp.contoso.com. Confirm that vnet-adlab still uses Azure-provided DNS.

Ask for help with checking the unexpected SRV result.

Your two-server network is running. Next, you will turn DC01 into the domain controller that satisfies this lookup.

Promote DC01 to a Domain Controller

The DNS lookup on MEMBER01 proved that no domain controller can answer yet. The corp.contoso.com forest and locator record do not exist.

In this step, you will turn DC01 into the first domain controller for corp.contoso.com with Active Directory Domain Services. You will then direct the virtual network to DC01 so MEMBER01 can discover the new domain.

In this step, get ready to:

Install AD DS with its management tools on DC01.
Create the corp.contoso.com forest with DC01 as its first domain controller.
Direct vnet-adlab to DC01 for domain discovery.

Install AD DS on DC01

The AD DS server role gives DC01 the components required for promotion. The built-in Windows PowerShell 5.1 host includes the administration commands used in this project.

Switch back to the DC01 desktop in Windows App.
Press the Windows key to open Windows search.
Type Windows PowerShell into the search field.
Right-click Windows PowerShell in the search results.
Choose the option that runs Windows PowerShell as an administrator.
Install the AD DS role with its management tools by running this command:

Install-WindowsFeature -name AD-Domain-Services -IncludeManagementTools

What Does This Command Do?

The AD-Domain-Services feature gives DC01 the server role required to become a domain controller.
The -IncludeManagementTools option adds the administration components used to manage the domain.
The command prepares DC01 for promotion without creating the forest yet.

Review the installation result in Windows PowerShell.
Confirm that Success reports True.

That clears the first gate. DC01 now has the server role and management tools required for promotion.

Installation Did Not Succeed?

Confirm that the Windows PowerShell window has administrator privileges.
Check that you are running the command on DC01 instead of MEMBER01.

If the result still does not report True, help me troubleshoot the AD DS role installation on DC01.

Create the corp.contoso.com forest

The promotion command creates the corp.contoso.com forest. It also asks for a Directory Services Restore Mode password that protects recovery access.

A recovery password can feel sensitive. A unique lab-only value keeps it separate from your personal credentials.

Choose a unique lab-only password for the upcoming Directory Services Restore Mode prompts.
Promote DC01 by running this command:

Install-ADDSForest -DomainName "corp.contoso.com" -InstallDNS

What Does This Command Do?

The -DomainName "corp.contoso.com" option creates the forest root domain.
The -InstallDNS option installs the DNS service used for domain controller discovery.
DC01 restarts automatically after the promotion finishes.

Enter the lab-only password you chose at the first prompt.
Enter the same password at the confirmation prompt.
Accept the installation confirmation when asked.

Your RDP session disconnects when DC01 restarts. A few quiet minutes are normal while the forest and DNS services finish configuring.

Wait until DC01 is ready for an RDP connection again.
Return to the DC01 connection in Windows App.
Sign in with CORP\azureuser using the original administrator password.

You will see the DC01 desktop reopen under the domain administrator identity. DC01 is now the first domain controller and DNS server for corp.contoso.com.

Cannot Reconnect to DC01?

Confirm that DC01 has finished restarting in the Azure portal.
Check that the username uses the domain form CORP\azureuser.
Use the same administrator password that worked before the promotion.

If the domain sign-in still fails, help me troubleshoot the first sign-in to DC01 after AD DS promotion.

Point the virtual network at DC01

Your Azure Virtual Network still directs MEMBER01 to Azure-provided DNS. Setting 10.10.10.11 as the custom DNS server makes DC01 answer the domain locator query.

Switch back to the Azure portal on your Mac.
Use the portal search bar to find vnet-adlab.
Select vnet-adlab from the results.
Select DNS servers under Settings.
Choose Custom.
Add 10.10.10.11 as the DNS server address.
Select Save.

The saved virtual network configuration now points its connected servers to DC01 for DNS.

Why Restart MEMBER01?

Connected VMs receive the new virtual network DNS setting after a restart. Restarting MEMBER01 replaces its previous Azure-provided DNS configuration with 10.10.10.11.

Return to the MEMBER01 VM page in the Azure portal.
Restart MEMBER01.
Confirm that MEMBER01 returns to the Running state.
Return to MEMBER01 through Windows App using the local azureuser credentials from earlier.
Press the Windows key to open Windows search.
Type Windows PowerShell into the search field.
Select Windows PowerShell from the results.

Before you run the lookup again, predict which server the query should return.

Test domain controller discovery from MEMBER01 by running this command:

Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.corp.contoso.com" -Type SRV

What Does This Query Prove?

The Resolve-DnsName command asks the configured DNS server to resolve the domain controller locator name.
The -Type SRV option requests a service locator record.
The _ldap._tcp.dc._msdcs.corp.contoso.com name identifies the domain controller discovery record for this forest.

That is the breakthrough. You will see an SRV record targeting DC01.corp.contoso.com, which proves MEMBER01 can discover the domain controller through DNS.

Does the Lookup Still Fail?

Confirm that vnet-adlab lists 10.10.10.11 under its custom DNS servers.
Restart MEMBER01 again after saving the virtual network DNS setting.
Return to DC01 through Windows App to confirm that the server completed its restart.

If the locator record is still missing, help me troubleshoot DNS discovery between MEMBER01 and DC01.

Your forest is live and MEMBER01 can find its domain controller. Next, you will join MEMBER01 to corp.contoso.com and prove that its computer trust works.

Join MEMBER01 to the Domain

Your DNS lookup proved MEMBER01 can find DC01 for corp.contoso.com. The member server now knows where the domain controller lives.

Discovery alone does not create a computer account for MEMBER01. The server still has no machine trust with the domain.

This step joins MEMBER01 to Active Directory Domain Services. A secure channel check then proves the member server can trust the domain.

In this step, get ready to:

Join MEMBER01 to corp.contoso.com.
Reconnect to MEMBER01 with the domain administrator identity.
Verify the computer secure channel to the domain.

Join MEMBER01 to the domain

Joining creates a computer account for MEMBER01 inside corp.contoso.com. This account identifies the server as a managed domain member.

The same Windows PowerShell 5.1 host from the promotion step contains Add-Computer. The command opens a separate credential prompt for the domain administrator password.

Your password never needs to appear in the command text. You only enter it when the protected credential prompt appears.

Return to the MEMBER01 desktop in Windows App from earlier.
Press the Windows key to open search.
Type Windows PowerShell into search.
Select the administrator launch option for Windows PowerShell.
Approve the Windows permission prompt.
Join MEMBER01 to the domain by running this command:

Add-Computer -DomainName "corp.contoso.com" -Credential "CORP\azureuser" -Restart -Force

What Does This Command Do?

The -DomainName "corp.contoso.com" parameter identifies the domain that MEMBER01 joins.
The -Credential "CORP\azureuser" parameter requests the domain administrator credentials used to authorize the join.
The -Restart -Force parameters restart MEMBER01 after a successful join. The restart activates its domain membership.

Enter the domain administrator password when the credential prompt appears.

Windows App disconnects while MEMBER01 restarts. The restart can take a few minutes, so a brief period without remote desktop access is expected.

Did MEMBER01 Stay Online?

Confirm the command ran in Windows PowerShell 5.1 on MEMBER01.
Confirm vnet-adlab still assigns 10.10.10.11 as its custom DNS server.
Retry the domain administrator password for CORP\azureuser if the credential prompt rejects it.

Help me diagnose why MEMBER01 did not join corp.contoso.com or restart.

Verify the domain trust

The restart activates MEMBER01's new domain membership. A healthy secure channel confirms the member server can trust its domain controller.

Wait until MEMBER01 accepts a remote desktop connection.
In Windows App, select the existing MEMBER01 connection.
Enter CORP\azureuser as the user name.
Enter the domain administrator password.
Submit the credentials to connect.

You should see the MEMBER01 desktop under the CORP\azureuser domain identity.

Press the Windows key to open search.
Type Windows PowerShell into search.
Select the administrator launch option for Windows PowerShell.
Approve the Windows permission prompt.

Before you run the check, do you expect MEMBER01's trust relationship to be healthy after the restart?

Test MEMBER01's secure channel by running this command:

Test-ComputerSecureChannel -Verbose

What Does the Result Prove?

A result of True confirms that MEMBER01 has a working trust relationship with corp.contoso.com.

The verbose message reports that the secure channel is alive and working correctly. This proves the member server can authenticate through its domain computer account.

You have established the machine trust. MEMBER01 can now authenticate as a managed member of corp.contoso.com.

Secure Channel Not Healthy?

Confirm the PowerShell window is running on MEMBER01.
Confirm you reconnected with CORP\azureuser.
Confirm vnet-adlab still assigns 10.10.10.11 as its custom DNS server.

Help me troubleshoot MEMBER01's computer secure channel.

Your two-server lab now has a trusted domain member. Next, you will create Jordan Lee as a domain user and inspect the new identity from graphical and command-line tools.

Create and Inspect a Domain User

MEMBER01 now trusts the domain that runs on DC01. Your Active Directory Domain Services foundation is ready to manage identities across that domain.

A functioning domain becomes useful when administrators can manage identities consistently. In this step, you will create Jordan Lee through the graphical console and inspect the same directory object from the command line.

In this step, get ready to:

Access the Users container through Active Directory Users and Computers.
Create the enabled domain user Jordan Lee with the logon name jlee.
Inspect the domain user through Windows PowerShell 5.1.

Open Active Directory Users and Computers

DC01 includes the management console installed with the AD DS tools. Its domain tree gives you a graphical view of the users and computers stored in corp.contoso.com.

Return to DC01 through Windows App.
Reconnect as CORP\azureuser if Windows App requests your credentials.
Press the Windows key to open search.
Type Active Directory Users and Computers into the search field.
Press Enter to open the console.
Expand corp.contoso.com in the left pane.
Select the Users container.

You will see the directory objects currently stored in the Users container. This is where you will add the lab identity.

Create Jordan Lee

A domain user stores an identity that domain members can authenticate. The logon name becomes the short identifier that administrators use to find the account.

Select Action from the console menu.
Select New.
Select User.

The New Object - User wizard collects the identity details first. Its next page protects the account with a temporary password.

Why Use a Temporary Password?

The temporary password gives Jordan Lee an initial way to authenticate. Requiring a password change makes the user choose a replacement during the first sign-in.

This password belongs only to the lab. Use a unique value that you do not use for any personal or work account.

Enter Jordan Lee in the Full name field.
Enter jlee in the User logon name field.
Continue to the password page.
Enter a unique lab-only temporary password in the password field.
Enter the same temporary password in the confirmation field.
Select User must change password at next logon.
Leave Account is disabled cleared.
Complete the wizard.

Jordan Lee now appears in the Users container. The account is enabled and ready for its first domain sign-in.

User Missing From the List?

Confirm that the left pane still has the Users container selected.
Repeat the wizard if it closed before showing the completion page.

Ask for help if Jordan Lee still does not appear: help me check why the Jordan Lee user is missing from the Users container in Active Directory Users and Computers.

Inspect the directory object

The graphical console confirms that the user exists. PowerShell lets you retrieve the underlying domain details and account properties as command-line evidence.

Press the Windows key to open search on DC01.
Type Windows PowerShell into the search field.
Press Enter to open the built-in Windows PowerShell host.
Inspect the domain of DC01 by running this command:

Get-ADDomain -Current LocalComputer

What Does This Command Show?

The Get-ADDomain command retrieves information about an Active Directory domain. The -Current LocalComputer option selects the domain associated with DC01.

You will see domain details for corp.contoso.com. This confirms that the command is reading the forest you created.

Domain Details Missing?

Confirm that your Windows App session is connected to DC01.
Confirm that you opened Windows PowerShell instead of another command-line host.

Ask for help with the domain query: help me troubleshoot why Get-ADDomain is not returning corp.contoso.com on DC01.

Before you run the final query, make a quick prediction about whether the new account reports an enabled or disabled state.

Inspect every available property for jlee by running this command:

Get-ADUser -Identity jlee -Properties *

What Does This User Query Show?

The -Identity jlee argument selects the domain user with the logon name jlee.
The -Properties * argument requests all available properties for that directory object.
The Enabled property shows whether the account can authenticate.

You will see jlee identified as the queried directory object. Its directory path places the account in the Users container under corp.contoso.com.

The Enabled property reports True. You have confirmed that the new domain identity is active.

User Not Returned?

Compare the query identity with the jlee logon name entered in the wizard.
Confirm that Jordan Lee appears in the Users container before repeating the query.
Confirm that the PowerShell window is running on DC01.

Ask for help with the account query: help me troubleshoot why Get-ADUser is not returning the jlee directory object.

That completes the identity-management loop. You created a domain user graphically and verified the same directory object from Windows PowerShell.

Secret mission

Investigate the Live RDP Session

Directory properties explain who an account is. In this mission, you will inspect the live RDP session on MEMBER01. You will compare it with broader Windows logon records in a three-sentence incident note.

Clean Up Your Resources

Choose whether to keep the lab running, pause it for later, or delete it entirely. This pay-as-you-go Azure lab can incur charges until its resources are deleted.

Cost warning

The virtual machines accrue compute charges while their state is Running. A Stopped (deallocated) state stops VM compute billing.

Standard SSD disks can still incur charges. Some networking resources can also incur charges.

Resources you used:

The rg-adlab resource group that contains every Azure lab resource.
Compute resources: the DC01 and MEMBER01 virtual machines.
Storage resources: two Standard SSD operating-system disks.
Networking resources: the vnet-adlab Azure Virtual Network, the snet-adlab subnet, both network interfaces, both public IP addresses, the custom DNS setting, and the restricted RDP rules.
Directory data: the corp.contoso.com AD DS forest, the MEMBER01 computer account, and the jlee domain user stored on DC01.

Keep everything running

No action is needed. Choose this if you are continuing the lab immediately.

Both VMs continue to accrue compute charges while they remain running.

Leave DC01 running while you continue the lab.
Leave MEMBER01 running while you continue the lab.
Keep Auto-shutdown enabled on each VM.

Pause - I'll come back to this later

Shut down both VMs to stop compute billing while keeping the lab intact. Your disks can still incur charges during the pause.

Some networking resources can also continue to incur charges.

Return to the Azure portal from earlier.
Stop MEMBER01 from its VM page.
Confirm that MEMBER01 reaches Stopped (deallocated).
Stop DC01 from its VM page.
Confirm that DC01 reaches Stopped (deallocated).
Start DC01 first when you return to the lab.
Wait until DC01 accepts a sign-in through Windows App.
Start MEMBER01 after DC01 is ready.

Delete - I don't want to use this again

Remove all lab resources when you are finished. Deleting rg-adlab permanently removes both servers.

You can recreate the lab later by following the project again.

Return to the Azure portal from earlier.
Search for rg-adlab.
Select rg-adlab from the search results.
Confirm that its resource list includes DC01, MEMBER01, and vnet-adlab.
Select Delete resource group on the resource group page.
Enter rg-adlab when Azure asks you to confirm the resource group name.
Select Delete to complete the confirmation.

Azure can take several minutes to remove a resource group. A short wait here is normal.

Wait for Azure to finish deleting rg-adlab.
Search for rg-adlab again to confirm that it no longer appears in the Azure portal.

Nice Work!

Excellent work! You've built a self-managed Active Directory Domain Services lab in Azure.

You've learned how to:

Deployed a two-server Windows lab in Azure. Reached DC01 and MEMBER01 from your Mac through Windows App over restricted RDP.
Promoted DC01 into the first domain controller for corp.contoso.com. Set DC01's static private IP as the custom DNS server for vnet-adlab. Joined MEMBER01 to the domain. Confirmed its secure channel returned True.
Created the enabled jlee domain user with Active Directory Users and Computers. Queried the same directory object with Windows PowerShell to confirm its properties.
Secret Mission: Investigated the active RDP session with quser. Compared its focused interactive-session data with broader Win32_LogonSession records. Wrote an incident note that separates Get-ADUser directory properties from both session data sources.

Ready to quiz yourself?