With this task, I configured the Active Directory environment on the EDM-SVR1 virtual machine by creating and organising Organisational Units (OUs) and security groups. I began by creating an OU named IT and a personalized administrative account called Leonard-IT within that OU. After successfully logging into the domain controller using this new account, I used it exclusively throughout the rest of the project to maintain proper administrative role segregation. I then created additional OUs at the domain root—Administration, Shipping, Finance, and Sales—to logically organise users and groups.

Next, I created a Global Security Group for each OU, appending “Group” to each OU’s name to ensure consistency and clarity (e.g., IT Group, Finance Group). To validate the creation and visibility of these groups, I opened an administrative PowerShell prompt and used the Get-ADGroup cmdlet with specific formatting to display all groups ending in “Group.” I then captured screenshots to document the configuration and results. These steps established group-based access control structures, which are essential for scalable and secure domain management.

Finally, I created template accounts for each OU with names beginning with -- (e.g., --Finance-Template). Each template account was assigned to its respective group and disabled by default, setting the groundwork for efficient user provisioning in the future. Using PowerShell, I listed all template accounts and confirmed their membership and disabled status. However, since EDM-SVR1 is a Read-Only Domain Controller (RODC) connected to EDM-DC1, I noted that any PowerShell queries run on EDM-SVR1 only reflected data replicated from the primary domain controller, and not any local changes. This clarified the operational limitations and reinforced my understanding of RODC behaviour within a Windows Server domain infrastructure.