From the Endpoint
to the Domain

Every enterprise build starts the same way — a blank virtual machine. For this task, I deployed a fresh Windows 11 installation inside VMware Fusion on my MacBook, using a consistent lab naming convention so each later configuration step could be traced clearly.

Getting Windows 11 to install on Fusion required downloading the ISO, creating the VM with sufficient specs, and navigating through the Setup wizard. The machine name followed the lab convention during initial configuration — a detail that mattered for identification across subsequent screenshots.

In enterprise environments, IT teams rarely configure each PC manually — they use provisioning packages to automate setup. This task required creating a .ppkg file using Windows Configuration Designer (WCD) that would create a lab-only local administrator account and apply it to the VM.

I built the package step by step in WCD: selecting the account settings, defining local sign-in details, exporting the .ppkg file, and then applying it to the Windows 11 VM. After application, the account appeared under local users — confirming the package deployed correctly.

Security hardening is non-negotiable in any enterprise environment. This task required configuring Local Security Policy to enforce UAC (User Account Control) behavior — specifically, ensuring that any privileged action triggers a secure authentication prompt and dims the desktop (Secure Desktop mode). This prevents malware from spoofing the UAC dialog.

I accessed secpol.msc, navigated to Local Policies → Security Options, and located the UAC settings. I configured the elevation prompt for administrators in Admin Approval Mode to require authentication on the secure desktop. Screenshots captured the before/after state of each policy setting.

Standardized Start menu and taskbar layouts are a common enterprise requirement — IT departments often deploy a locked-down layout to ensure consistency across all endpoints. This task required pinning the Microsoft News app to the Start menu, then exporting the taskbar configuration to an XML file using PowerShell.

I pinned the app through the Start menu UI, then used Export-StartLayout and related cmdlets in PowerShell to export the configuration. The resulting layout file could be deployed company-wide through Group Policy — a direct bridge to what I'd implement on the server side later.

Network configuration via PowerShell is a core sysadmin skill. Rather than using the GUI, this task required setting a static IPv4 address of redacted lab IPv4 address directly through the command line using New-NetIPAddress. This approach is scriptable, repeatable, and deployable at scale — exactly how enterprise teams manage endpoints.

I identified the correct adapter using Get-NetAdapter, removed any existing DHCP-assigned address, and applied the static configuration. Running ipconfig /all after confirmed the address was correctly assigned to the adapter.

Storage Spaces is Windows' software-defined storage solution — it pools physical disks into resilient volumes. A 2-way mirror writes data to two disks simultaneously, providing fault tolerance if one drive fails. This task required creating a Storage Pool from available virtual disks, then creating a 2-way mirror virtual disk on top of it.

I navigated to Server Manager → File and Storage Services → Storage Pools, added the available disks to a pool, and created the mirrored virtual disk. The resulting volume was mounted and ready for use — setting up the foundation for the file sharing tasks that followed.

With the storage pool created, the next step was creating the File Share folder on the new volume — this would serve as the shared network resource for the next task. Placing it on the mirrored storage space ensures any data stored here has redundancy built in.

File sharing permissions in Windows are a two-layer system: Share permissions control network access at the share level, while NTFS permissions control access at the file system level. The effective permissions are the most restrictive of the two. This task required sharing the File Share folder with specific user access levels — read vs. read/write — matching a permission matrix defined in the course.

I right-clicked the folder, set up sharing through Advanced Sharing, configured the share permissions, then drilled into Security to set NTFS permissions. Each user/group was assigned the correct permission level and verified by reviewing the access control list.

Application deployment from the Microsoft Store is a standard workflow in modern endpoint management. This task required installing Microsoft Whiteboard from the Store — simulating how IT might push a collaboration app to a managed workstation. Post-install verification confirmed the app launched correctly and was visible in the Start menu.

File History is Windows' built-in backup and versioning solution — it automatically saves copies of files to a designated drive, allowing recovery of older versions. This task required configuring it to keep historical copies for 30 days, pointed at the storage space volume created earlier.

The first challenge wasn't the server — it was the hardware. Building Windows Server 2022 on an Apple Silicon MacBook Air required using UTM, a virtualization platform for macOS that supports both ARM and x86 emulation. I created the primary Domain Controller VM (LAB-DC01) with 4 vCPUs, 8GB RAM, and 64GB storage in x86_64 mode, then installed Windows Server 2022 Datacenter Evaluation (Desktop Experience) for full GUI access.

This was the moment the server transformed from a standalone box into the authority of a lab Active Directory domain. I installed the AD DS role through Server Manager's Add Roles and Features Wizard, selected the lab domain controller as the target, and began the promotion process. Choosing "Add a new forest" created the lab-local root domain.

The promotion wizard walked through DNS integration, Global Catalog designation, recovery-mode setup, and NetBIOS naming. The wizard auto-generated a PowerShell deployment script, showing that the configuration could be repeated and automated. After the final prerequisites check passed with the expected DNS delegation warning in an isolated lab, the server rebooted and came back online as the domain controller.

With the domain running, the next critical service was DHCP — the mechanism by which clients receive an IP address, gateway, and DNS server automatically. I installed the DHCP Server role on the domain controller after assigning a static IPv4 address so DHCP and DNS services were anchored to a fixed address.

I created one primary lab scope plus four simulated site scopes to model a multi-site enterprise network with offices in Toronto and Montreal. Each scope was configured with subnet ranges, exclusions, and scope options (Router 003, DNS Server 006, DNS Domain Name 015). A DHCP reservation for the member server ensured it would receive a consistent lab address.

A single-server domain is a lab — an enterprise network normally includes member servers. I deployed a second Windows Server 2022 VM, LAB-SRV02, as a member server for domain lab services. The process mirrored the first server installation: create the UTM VM, install Windows Server 2022 Datacenter, complete first-time setup, rename the machine, and then complete the domain join.

Joining the domain required pointing the member server's DNS to the domain controller, completing domain authentication, and confirming the successful domain join. A static IP and DHCP reservation were then configured, with hardware identifiers redacted in public evidence.

Active Directory's power comes from organization. I opened Active Directory Users and Computers (ADUC) on the domain controller and built a full OU hierarchy under lab.local: Toronto, Montreal, Servers, Workstations, Groups, and Users — mirroring how a real enterprise organizes its directory structure by geography and function.

Inside each location OU, I created user accounts with proper UPN suffixes (lab user account, lab user account), enforced first-logon account-change policies, and built Global Security Groups — Toronto-Users and Montreal-Users — adding each user to their respective group. This group structure would directly drive NTFS permissions and GPO filtering later.

Group Policy is the central nervous system of Windows domain management. I configured lab policy settings to validate workstation/user policy behavior, including a UI restriction policy and a domain-wide account policy enforcing complexity, minimum length, history, and account lockout.

I opened the Group Policy Management Console (GPMC), created a lab lockdown GPO, and validated policy application from the workstation. Inside the policy editor, I navigated through Administrative Templates and enabled a UI restriction. For the account policy, I modified the Default Domain Policy: minimum length, complexity, maximum password age, and account lockout after repeated failed attempts.

After applying changes with gpupdate /force, I ran gpresult /r on the workstation to confirm policy receipt. I then deliberately triggered the account lockout with repeated failed sign-in attempts, validating the lockout behavior in the lab. In production, user-side restrictions would be linked to the proper user OU or implemented with loopback processing where computer-targeted scope is required.

File sharing in a domain environment brings together everything built so far: users, groups, permissions, and the servers. I created a CompanyShare folder in the domain lab, shared it over the network, and configured layered share and NTFS permissions for the Toronto and Montreal security groups. Administrators retained Full Control.

From the workstation, I mapped Drive Z: using a domain user account and tested file access behavior to confirm the restrictions were applied.

DNS is the backbone of an Active Directory domain — without it, nothing resolves. I opened DNS Manager on the domain controller, reviewed the server's network interface bindings, and configured an external DNS forwarder to handle queries outside the lab namespace.

The final proof of a working domain is the workstation. I configured the Windows 11 VM (LAB-WS01) with DNS pointing to the domain controller, verified a successful ping to the DC, and ran nslookup to confirm name resolution. The domain join prompt required domain authentication — and returned the "Welcome to the lab domain" confirmation.

Post-join, the workstation received its DHCP-assigned IP, applied both computer and user GPOs (confirmed via gpresult /r), and successfully connected to the CompanyShare folder. Every service built throughout this case study — DHCP, DNS, AD DS, GPO, file sharing — was verified to be working end-to-end from a domain-joined client.