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!
Fig. 01 - Virtual Machine resources setup in Microsoft Azure
Fig. 02 - Domain Controller roles applied
I created three Virtual Machines through Azure:
SOU-LAB-DC01 (Domain Controller) – Windows Server 2022
FS-LAB (File Server) – Windows Server 2022
CLIENT01 (Workstation) – Windows 10 Pro
Network: 10.0.0.0/24
Domain: fs-lab.local
DNS/DHCP: hosted on DC01
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.
DHCP successfully handed out IPs within the defined scope.
Both Bob and Alice could authenticate via the domain.
Permissions applied correctly — Bob full access, Alice restricted.
File shares and DNS resolution worked consistently across reboots.
Fig. 03 - Shared Folder
Fig. 04 - NTFS Permissions set
The first lessons from this lab were definitely the most human ones: always check that the file server is actually powered on before blaming DNS, and when mapping your network drive it certainly helps to add the letter "d" on the end of your shared folder called "Shared". The sort of moments that causes a sheepish look to take over your face...
Beyond that, this lab really showed how tightly linked Active Directory, DNS, and DHCP are. It’s one thing to read about how they work together, but setting them up and troubleshooting them made it all click properly.
I learned how critical DNS is to a healthy network — one missing A record and suddenly nothing connects. I also realised why it’s better to map network drives using the server’s hostname (or FQDN) rather than its IP. Initially, I used the IP address, but if that ever changed, the mapping would break. Using the hostname ensures DNS always points users to the right server automatically.
Finally, I now understand when to use the short hostname versus the fully qualified domain name. In a single-domain setup like this one, \\FS-LAB\CompanyShare works perfectly, but if I were working across multiple domains or remote links, using the full path \\FS-LAB.fs-lab.local\CompanyShare would be the safer choice.