Domain Controller and File Server lab through Microsoft Azure VMs

Brief

I wanted to simulate a small business-style Windows Server environment using Microsoft Azure, focusing on building a fully functional domain controller and file server setup. The goal was to understand how domain services, DNS, and DHCP work together, and how to manage shared folder permissions across different users and machines. As you'll see, I learnt some valuable troubleshooting lessons!

Configuration & Process

I began by installing Active Directory Domain Services on DC01 and promoting it to create the domain fs-lab.local. DNS was configured automatically during setup, and once everything rebooted, I confirmed the zones were created correctly.

Next, I added the DHCP Server role, set up a scope from 10.0.0.50 to 10.0.0.150, and pointed the default gateway and DNS to the DC’s address (10.0.0.6). A quick test from CLIENT01 confirmed it was handing out IPs correctly.

On the File Server (FS-LAB), I installed File and Storage Services, changed its DNS to point at the DC, and joined it to the domain. I then created a shared folder called CompanyShare on the C: drive for testing.

In Active Directory, I created two users — Bob Smith (Sales) and Alice Brown (HR) — and added them to the Remote Desktop Users group on the file server. I configured NTFS permissions on the shared folder so that Bob had Modify access (Read/Write/Delete) and Alice had Read & Execute only. Testing from CLIENT01 confirmed that Bob could create and delete files, while Alice could open and edit text but not remove them — exactly as intended.

The only snag came when FS-LAB initially refused to join the domain. The error message suggested it couldn’t contact a domain controller, which led me to check DNS. The server was still pointing to an external address instead of the DC, so I corrected it to 10.0.0.6 and ran ipconfig /flushdns and ipconfig /registerdns.

Even then, pinging fs-lab failed. I realised that while my domain was fs-lab.local, the domain controller’s hostname was SOU-LAB-DC01 — two different names that broke the expected FQDN lookup. The fix was to manually create an A record for fs-lab in DNS Manager, pointing it to the DC’s IP. Once added, nslookup fs-lab.local resolved correctly, the domain join succeeded, and everything snapped into place.