Build a WSUS Patch-Control Lab

Build a pilot WSUS control plane with Active Directory and Group Policy on AWS.

Introduction

30 Second Summary

Updating every server at once can turn one bad change into a company-wide outage. Testing with a small group first limits how many machines can be affected.

In this project, you will build a three-server Windows Server 2022 lab on Amazon EC2 using Active Directory Domain Services, Windows Server Update Services, and Group Policy. You will prove pilot-only policy scope plus endpoint reachability without synchronizing or approving updates.

What You'll Build

You connect from your Mac to PILOT01 to show a pilot-only update policy reaching WSUS01 while the rest of the lab stays outside its scope.

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

A live role-separated lab where you can connect to DC01, WSUS01, and PILOT01 on Amazon EC2.
A visible pilot ring with PILOT01 scoped through the WSUS-Pilot organizational unit to the Pilot-Ring WSUS computer group.
A set of repeatable policy and network checks you can run to distinguish domain trust, policy scope, DNS resolution, and TCP reachability.
Secret Mission: Point the pilot at a controlled bad WSUS endpoint, prove that policy can still apply, then restore the working path.

Are there any prerequisites?

You need AWS lab access with permission to create EC2 instances, security groups, key pairs, and EBS volumes plus Windows App for Mac. The three Windows EC2 instances can accrue pay-as-you-go charges while running.

Before We Start

This first checkpoint locks in your goal of building a pilot-scoped WSUS lab for controlled Windows Server patching. It also commits you to troubleshooting the policy path before any hands-on work begins.

Provision the Patch Lab

A patch-control plane needs separate machines before central identity or update policy has any value. You also need an unmanaged baseline so every later policy change has something meaningful to prove.

You'll use the AWS Management Console to create the network boundary. Amazon EC2 will host three Windows Server 2022 machines with distinct lab roles.

You'll connect through Remote Desktop Protocol using Windows App on your Mac. The future pilot's Group Policy results will prove that it begins without WSUS control.

In this step, get ready to:

Create a shared access boundary for the lab.
Launch three servers with role-specific compute and storage.
Prove that the future pilot begins unmanaged.

Create shared access controls

A VPC keeps the three instances inside one network. A shared security group permits private communication while restricting RDP access to your public IP address.

An EC2 key pair encrypts the initial Windows Administrator passwords. Its private key stays on your Mac so you can decrypt those passwords later.

Sign in to the AWS Management Console with your lab account.
Select one AWS Region from the console navigation bar.
Record the selected Region as your selected AWS Region.

The console header now shows your selected AWS Region. Every resource in this step stays in that Region.

Use the console search bar to open Amazon EC2.
Choose Key Pairs under Network & Security in the navigation pane.
Choose Create key pair.
Enter a memorable value in Name: your key pair name.

The new key-pair form now shows the name that all three instances will share.

Select RSA for Key pair type.
Select pem for Private key file format.
Choose Create key pair.

Your browser downloads the private key file immediately. This is the file that unlocks the initial Windows passwords for your lab.

Protect the private key

The downloaded .pem file is a credential. Store it somewhere private on your Mac because AWS cannot provide the private half of this key pair again.

Choose Security Groups under Network & Security in the EC2 navigation pane.
Choose Create security group.
Enter wsus-lab-sg as the security-group name.
Enter WSUS patch-control lab as the description.

The form now identifies the security boundary as wsus-lab-sg.

Select the VPC whose ID is your selected VPC ID in the VPC field.
Choose Add rule under Inbound rules.
Select RDP as the rule type.
Confirm that the protocol is TCP.
Confirm that the port range is 3389.
Select My IP as the source.
Choose Create security group.

The first inbound rule now limits RDP access to the public IPv4 address of your Mac.

Select wsus-lab-sg from the security-group list.
Choose the Inbound rules tab.
Choose Edit inbound rules.
Choose Add rule.
Select All traffic as the rule type.
Select Custom as the source type.
Select wsus-lab-sg as the source security group.
Choose Save rules.

What do these rules protect?

The RDP rule accepts connections on TCP port 3389 only from your current public IP address. The self-referencing rule permits private traffic between instances attached to wsus-lab-sg.

This separation gives your Mac one narrow entry point. The three servers can still communicate across the lab network.

Your access boundary is ready. The security group now shows one RDP rule from your IP plus one all-traffic rule from itself.

Can't create the access controls?

Confirm that the key pair and security group are being created in your selected AWS Region.
Confirm that wsus-lab-sg belongs to your selected VPC ID.
Confirm that the source of the all-traffic rule is the security group itself.

Need another pair of eyes? Help me troubleshoot my EC2 key pair or wsus-lab-sg configuration.

Launch three Windows servers

Each server gets resources that match its future role. The WSUS server receives more memory and storage because its update-service role is heavier than the other two roles.

Server launch profiles

DC01 uses t3.medium with a 30 GiB gp3 root volume.
WSUS01 uses t3.large with an 80 GiB gp3 root volume.
PILOT01 uses t3.medium with a 30 GiB gp3 root volume.

Choose Instances in the EC2 navigation pane.
Choose Launch instance.
Enter DC01 under Name and tags.
Select the latest Windows Server 2022 English Full Base image under Application and OS Images.

The launch summary now identifies the future domain controller. Its image corresponds to /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-Base.

Select t3.medium under Instance type.
Select your key pair name under Key pair.

The DC01 summary now shows the required instance size plus your shared key pair.

Select your selected VPC ID under Network settings.
Enable automatic public IPv4 assignment under Network settings.

DC01 can now receive an RDP connection from your Mac through the selected VPC.

Choose the existing wsus-lab-sg security group.
Set the root volume size to 30 GiB under Configure storage.
Set the root volume type to gp3.

The DC01 summary now matches the required compute, network, and storage profile.

Know what starts billing

Launching these instances starts variable AWS charges for Windows EC2 compute, EBS storage, and public IPv4 addresses. The cleanup section shows how to stop or delete the lab when you finish.

Choose Launch instance to create DC01.

The Instances page now lists DC01. Its state moves to Running as AWS provisions the server.

Choose Launch instance again.
Enter WSUS01 under Name and tags.
Select the same Windows Server 2022 English Full Base image.
Select t3.large under Instance type.

The second launch summary now identifies the future WSUS server with its larger instance type.

Select your key pair name under Key pair.
Select your selected VPC ID under Network settings.
Enable automatic public IPv4 assignment.
Choose the existing wsus-lab-sg security group.

WSUS01 now shares the same access path and private network as DC01.

Set the root volume size to 80 GiB under Configure storage.
Set the root volume type to gp3.
Choose Launch instance to create WSUS01.

The Instances page now lists WSUS01 with the larger storage profile needed for its future role.

Choose Launch instance again.
Enter PILOT01 under Name and tags.
Select the same Windows Server 2022 English Full Base image.
Select t3.medium under Instance type.

The third launch summary now identifies the future pilot server.

Select your key pair name under Key pair.
Select your selected VPC ID under Network settings.
Enable automatic public IPv4 assignment.
Choose the existing wsus-lab-sg security group.

PILOT01 now shares the same network boundary as the other two servers.

Set the root volume size to 30 GiB under Configure storage.
Set the root volume type to gp3.
Choose Launch instance to create PILOT01.

All three instances now appear on the Instances page. AWS needs several minutes to finish the first Windows boots and status checks.

Wait until DC01 shows Running with passed status checks.
Wait until WSUS01 shows Running with passed status checks.
Wait until PILOT01 shows Running with passed status checks.

The infrastructure layer is live. You now have three role-separated Windows servers using the same key pair and security group.

Instance not becoming ready?

Confirm that the instance state is Running before checking its connection status.
Confirm that each instance uses wsus-lab-sg in your selected VPC ID.
Confirm that automatic public IPv4 assignment was enabled for each launch.

Still stuck? Help me diagnose why one of my Windows EC2 instances is not becoming reachable.

Capture the unmanaged baseline

The EC2 names identify each machine's future role. Their operating-system hostnames remain unchanged until the next step.

The initial Administrator password can take up to 15 minutes to become available after launch. That wait is part of the first Windows boot, so a temporarily unavailable password does not mean the instance failed.

Select DC01 on the Instances page.
Choose Connect.
Choose the RDP client tab.
Select Administrator as the username.
Choose Get password.

Choose Upload private key file.
Select the downloaded .pem file for your key pair name.
Choose Decrypt password.
Copy the revealed Administrator password into a secure password manager.

The decrypted password belongs only to DC01. Treat it as a live credential and keep it out of screenshots.

Choose Download remote desktop file.
Open the Downloads folder in Finder.
Open the downloaded .rdp file with Windows App.
Enter the decrypted Administrator password when Windows App requests it.
Continue only after confirming that the connection address matches DC01.

You'll see the Windows Server desktop for DC01. This confirms that the key pair, RDP rule, public address, and Windows App path work together.

Repeat the password and RDP-file workflow for WSUS01 until you see its Windows Server desktop.
Repeat the password and RDP-file workflow for PILOT01 until you see its Windows Server desktop.
Leave all three operating-system hostnames unchanged.

Remote desktop not connecting?

Confirm that the instance has passed its status checks before retrying the RDP file.
Confirm that the wsus-lab-sg RDP rule still uses My IP as its source.
Confirm that you used the private key attached to the selected instance.

Need help narrowing it down? Help me troubleshoot my Windows App connection to a Windows EC2 instance.

PILOT01 has no domain or update-service policy yet. Its computer-scope policy report should therefore omit WSUS-Pilot-Control.

Select Start inside the PILOT01 session.
Type Windows PowerShell into the search field.
Run Windows PowerShell as an administrator.

Before you run the baseline check, do you expect a pilot-specific WSUS policy to appear on this fresh server?

Display PILOT01's computer-scope Group Policy summary by running this command:

gpresult /scope computer /r

What does this command check?

The /scope computer option limits the report to policies that affect the server itself.
The /r option displays a summary of the Resultant Set of Policy.
The Applied Group Policy Objects section shows which computer policies currently apply.

The report does not list WSUS-Pilot-Control under Applied Group Policy Objects. That absence is the unmanaged baseline you need before central policy exists.

Can't read the policy baseline?

Confirm that you ran the command inside the PILOT01 session.
Confirm that the command uses the computer scope.
Scroll upward in Windows PowerShell to find Applied Group Policy Objects.

Still unsure about the output? Help me interpret the computer-scope gpresult output from PILOT01.

Lab checkpoint

DC01 is a running Windows Server 2022 English Full Base instance from /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-Base. It uses t3.medium with a 30 GiB gp3 root volume. Its operating-system hostname remains unchanged.
WSUS01 is a running Windows Server 2022 English Full Base instance from the same image reference. It uses t3.large with an 80 GiB gp3 root volume. Its operating-system hostname remains unchanged.
PILOT01 is a running Windows Server 2022 English Full Base instance from the same image reference. It uses t3.medium with a 30 GiB gp3 root volume. Its operating-system hostname remains unchanged.
All three instances use your key pair name plus wsus-lab-sg in your selected VPC ID.
PILOT01's computer-scope baseline does not list WSUS-Pilot-Control.

Your three-server lab is reachable with a clean unmanaged baseline. Next, you'll give each machine its permanent name before installing the identity and update-service roles.

Install the Windows Control Plane

Your three Amazon EC2 servers are reachable through Windows App. The unmanaged baseline on PILOT01 proves that Windows Server Update Services has no control over it yet.

The machines now need central identity before they can share a trusted management boundary. DC01 provides that foundation.

WSUS01 also needs the update-service role. PILOT01 stays unmanaged while you build those two control-plane layers.

In this step, get ready to:

Give each server its permanent operating-system name.
Build the patchlab.example.com directory structure on DC01.
Install Windows Server Update Services on WSUS01.

Rename the three servers

Clear operating-system names make each server's role visible. Windows PowerShell applies those names before any role installation begins.

Switch back to each server session in Windows App.
Select Start in each session.
Search for Windows PowerShell in each session.
Select Run as administrator in each session.
Approve the administrator confirmation on each server.

Each rename command restarts its server immediately. A temporary Windows App disconnect is expected.

Rename each server from its matching elevated Windows PowerShell window by running only the labeled command for that session:

# Run on the future domain controller
Rename-Computer -NewName "DC01" -Restart

# Run on the future WSUS server
Rename-Computer -NewName "WSUS01" -Restart

# Run on the future pilot server
Rename-Computer -NewName "PILOT01" -Restart

What Do These Commands Do?

The Rename-Computer cmdlet updates the local Windows computer identity.
The -NewName parameter assigns the role-based name to that server.
The -Restart parameter restarts Windows so the new identity takes effect.

The restart can take a few minutes. The disconnected sessions show that Windows is applying the new computer names.

Wait for all three EC2 status checks to return to their healthy state.
Reconnect to each server session in Windows App.
Select Local Server in each Server Manager window.
Confirm Computer name shows DC01 in the future domain-controller session.
Confirm Computer name shows WSUS01 in the update-server session.
Confirm Computer name shows PILOT01 in the pilot session.

Good progress. Each Windows desktop now carries the role name you will use throughout the lab.

Still Seeing an Old Computer Name?

Confirm that you ran the matching command in the correct server session.
Run the rename command again from an elevated Windows PowerShell window if the earlier window lacked administrator access.

Still stuck? Help me troubleshoot why Rename-Computer did not apply the expected server name.

Build the directory control plane

Active Directory Domain Services turns DC01 into the identity authority for the lab. Its forest gives the domain a shared boundary.

The WSUS-Pilot organizational unit creates the scope for the pilot server. Later, that scope keeps patch policy focused on PILOT01.

Return to the DC01 session in Windows App.
Select Start.
Search for Windows PowerShell.
Select Run as administrator.
Approve the administrator confirmation.
Install Active Directory Domain Services with its management tools by running:

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

What Does This Command Do?

The Install-WindowsFeature cmdlet adds a Windows Server role.
The AD-Domain-Services value selects the directory role needed to create the forest.
The -IncludeManagementTools parameter installs the consoles used to manage directory objects plus Group Policy.

Wait for the role installation to finish.
Confirm that the installation output reports success.

Did the Directory Role Installation Fail?

Confirm that the Windows PowerShell title bar indicates an administrator session.
Check that you are running the command on DC01.

Need help with the role installation? Help me diagnose why the Active Directory Domain Services feature did not install on DC01.

The forest setup asks for a protected Directory Services Restore Mode password. This credential protects recovery access to the directory.

Prepare a strong Directory Services Restore Mode password in your password manager.
Create the forest by running:

Install-ADDSForest -DomainName "patchlab.example.com"

What Does This Command Do?

The Install-ADDSForest cmdlet promotes DC01 into the first domain controller in a new forest.
The patchlab.example.com value becomes the forest name plus the domain name.
The installation adds DNS for the new domain before restarting DC01.

Enter your Directory Services Restore Mode password when PowerShell requests it.
Re-enter the same password when PowerShell requests confirmation.
Approve the installation confirmation if PowerShell requests it.

DC01 restarts automatically after the forest is created. The Windows App session disconnects while the server becomes the domain controller.

Reconnect to DC01 with Windows App after the server accepts connections again.

Forest Setup Did Not Complete?

Confirm that DC01 finished the Active Directory Domain Services role installation before you created the forest.
Use the same protected password at both password prompts.

Need help reading the promotion output? Help me troubleshoot why Install-ADDSForest did not create patchlab.example.com on DC01.

Select Start in the reconnected DC01 session.
Search for Windows PowerShell.
Select Run as administrator.
Approve the administrator confirmation.
Create the pilot organizational unit by running:

New-ADOrganizationalUnit -Name "WSUS-Pilot" -Path "DC=patchlab,DC=example,DC=com"

What Does This Command Do?

The New-ADOrganizationalUnit cmdlet creates a policy scope inside Active Directory.
The WSUS-Pilot value gives the new organizational unit its visible name.
The DC=patchlab,DC=example,DC=com path places the organizational unit directly beneath the new domain.

Select Tools in Server Manager on DC01.
Select Active Directory Users and Computers.
Expand the patchlab.example.com domain.
Confirm that WSUS-Pilot appears beneath the domain.

DC01 now hosts the lab's identity boundary. The dedicated pilot scope is ready for PILOT01 in the next stage.

Cannot Find the Pilot Organizational Unit?

Refresh Active Directory Users and Computers after running the creation command.
Confirm that the command uses the DC=patchlab,DC=example,DC=com path.

Still missing the organizational unit? Help me find why WSUS-Pilot is absent from Active Directory Users and Computers.

Install the WSUS server role

WSUS01 needs the update-service role plus its management console. The role stays separate from DC01 so identity infrastructure remains distinct from patch infrastructure.

This installation can take several minutes before the server restarts. A quiet Windows PowerShell window during role installation is expected.

Return to the WSUS01 session in Windows App.
Select Start.
Search for Windows PowerShell.
Select Run as administrator.
Approve the administrator confirmation.
Install the WSUS role with its management tools by running:

Install-WindowsFeature -Name UpdateServices -IncludeManagementTools -Restart

What Does This Command Do?

The UpdateServices value selects the WSUS server role.
The -IncludeManagementTools parameter adds the WSUS management console.
The -Restart parameter restarts WSUS01 if the role installation requires it.

Wait for WSUS01 to finish restarting.
Reconnect to WSUS01 through Windows App.

Post-installation configuration remains pending. No update metadata has been synchronized.

WSUS01 Did Not Return After Installation?

Check the WSUS01 instance status in the Amazon EC2 console.
Wait for both EC2 status checks to return to their healthy state before reconnecting.

Still unable to reconnect? Help me troubleshoot WSUS01 after installing the UpdateServices role and restarting.

Before you check, which management tools should now appear on each role server?

Return to the DC01 session in Windows App.
Select Tools in Server Manager.
Confirm that Active Directory Users and Computers appears in the menu.
Confirm that Group Policy Management appears in the menu.
Return to the WSUS01 session in Windows App.
Select Tools in Server Manager.
Confirm that Windows Server Update Services appears in the menu.

That is the control plane installed. DC01 now provides directory management while WSUS01 provides the update-management console.

Your identity and update roles are ready. Next, you will connect the member servers to the domain while keeping the pilot free from WSUS policy.

Join and Stage the Pilot

DC01 now anchors your lab's Active Directory identity layer. WSUS01 has Windows Server Update Services installed.

Domain membership depends on DNS because each member must locate DC01. In this step, you'll point both servers at DC01 before joining them to the domain.

Joining gives PILOT01 centralized identity. It still does not define the server's update path.

In this step, get ready to:

Configure the active IPv4 interfaces on WSUS01 and PILOT01 to use DC01 for DNS.
Join WSUS01 and PILOT01 to patchlab.example.com.
Verify domain trust plus pilot placement while confirming that no WSUS Group Policy has reached PILOT01.

Point both servers to DC01 for DNS

A domain member uses DNS to find services hosted by a domain controller. WSUS01 and PILOT01 therefore need DC01's private address before either server can join the domain.

Return to DC01's instance details in the Amazon EC2 console from earlier.
Record the listed private IPv4 address here: DC01 private IPv4 address.

Finding the active adapter can be fiddly because Windows lists several interfaces. Focus on the connected IPv4 interface that carries the server's network traffic.

Switch back to the WSUS01 session in Windows App.
Use Windows search to start Windows PowerShell with administrator privileges.
List the network interfaces on WSUS01 by running:

Get-NetIPInterface

What does this command show?

The command lists the server's network interfaces. The active IPv4 interface has the index needed by the DNS configuration command.

You'll see a table containing IPv4 and IPv6 interfaces. Locate the active IPv4 interface before continuing.

Record the active IPv4 interface index here: active IPv4 IfIndex on WSUS01.
Configure that interface to use DC01 for DNS by running:

Set-DnsClientServerAddress -InterfaceIndex [[WSUS01_IFINDEX="active IPv4 IfIndex on WSUS01"]] -ServerAddresses [[DC01_PRIVATE_IPV4="DC01 private IPv4 address"]]

What does this command change?

The -InterfaceIndex value targets WSUS01's active IPv4 interface.
The -ServerAddresses value makes DC01 the DNS server for that interface.

Confirm that Windows PowerShell returns to the prompt without reporting an error.

DNS command reporting an error?

Confirm that you recorded the connected IPv4 interface's index. An index belonging to another interface changes the wrong adapter.

Confirm that Windows PowerShell has administrator privileges. Help me troubleshoot the DNS configuration on WSUS01.

WSUS01 now knows where to look for the domain. PILOT01 needs the same DNS dependency before its domain join can succeed.

Switch back to the PILOT01 session in Windows App.
Use Windows search to start Windows PowerShell with administrator privileges.
List the network interfaces on PILOT01 by running:

Get-NetIPInterface

What are you looking for?

This list shows the interfaces available on PILOT01. Identify the connected IPv4 interface that handles the server's network traffic.

Record the active IPv4 interface index here: active IPv4 IfIndex on PILOT01.
Configure that interface to use DC01 for DNS by running:

Set-DnsClientServerAddress -InterfaceIndex [[PILOT01_IFINDEX="active IPv4 IfIndex on PILOT01"]] -ServerAddresses [[DC01_PRIVATE_IPV4="DC01 private IPv4 address"]]

What changes on PILOT01?

The command assigns DC01 as the DNS server for PILOT01's active IPv4 interface. PILOT01 can now use the domain's DNS service during its join request.

Confirm that Windows PowerShell returns to the prompt without reporting an error.

PILOT01 DNS command failing?

Confirm that the interface index came from PILOT01. The index recorded on WSUS01 may refer to a different adapter.

Confirm that you used DC01's private IPv4 address. Help me troubleshoot the DNS configuration on PILOT01.

Join both servers to the domain

A domain join creates a trusted relationship between a member server and patchlab.example.com. WSUS01 joins in the default computer location while PILOT01 joins directly inside the dedicated pilot OU.

Each command asks for domain Administrator credentials. Each join also restarts its server, so a temporary Windows App disconnect is expected.

Switch back to the elevated Windows PowerShell session on WSUS01.
Join WSUS01 to the domain by running:

Add-Computer -DomainName "patchlab.example.com" -Credential (Get-Credential) -Restart

What does this command do?

The -DomainName value selects patchlab.example.com as the domain to join.
The -Credential parameter opens a protected credential prompt for the domain Administrator account.
The -Restart parameter restarts WSUS01 after the join completes.

Enter the domain Administrator credentials in the protected prompt.
Wait until WSUS01 accepts a new Windows App connection.

Windows App disconnects as WSUS01 restarts. A restart can take a few minutes while Windows finalizes the domain membership.

WSUS01 not joining the domain?

Confirm that the DNS configuration command completed without an error. A member server must reach DC01 through domain DNS before the join can succeed.

Confirm that you entered domain Administrator credentials. Help me troubleshoot the WSUS01 domain join.

Switch back to the elevated Windows PowerShell session on PILOT01.
Join PILOT01 directly to the pilot OU by running:

Add-Computer -DomainName "patchlab.example.com" -Credential (Get-Credential) -OUPath "OU=WSUS-Pilot,DC=patchlab,DC=example,DC=com" -Restart

Why does this join use an OU path?

The -OUPath value places the PILOT01 computer account directly inside WSUS-Pilot. This gives the pilot a dedicated scope for the policy created later.

Enter the domain Administrator credentials in the protected prompt.
Wait until PILOT01 accepts a new Windows App connection.

Windows App disconnects as PILOT01 restarts. The restart finalizes its domain membership plus its placement in the pilot OU.

PILOT01 not joining the pilot OU?

Confirm that OU=WSUS-Pilot,DC=patchlab,DC=example,DC=com matches the existing OU path exactly. A missing component points the join at a location that does not exist.

Confirm that PILOT01 still uses DC01 for DNS. Help me troubleshoot the PILOT01 domain join.

Verify trust, placement, and policy state

A successful sign-in does not prove that a member server has a healthy trust channel. The secure-channel check asks each member directly whether its relationship with the domain works.

Reconnect to WSUS01 in Windows App with domain Administrator credentials.
Use Windows search to start Windows PowerShell with administrator privileges.

Before you run this, predict whether WSUS01's secure channel will return True.

Test the WSUS01 secure channel by running:

Test-ComputerSecureChannel

What does this result prove?

The command tests WSUS01's trust relationship with the domain. A True result confirms that the secure channel works.

You'll see True in Windows PowerShell. WSUS01 can now authenticate as a member of patchlab.example.com.

WSUS01 returning False?

Confirm that WSUS01 completed its restart after the domain join. Confirm that its active IPv4 interface still uses DC01 for DNS.

Help me diagnose a failed WSUS01 secure channel.

Reconnect to PILOT01 in Windows App with domain Administrator credentials.
Use Windows search to start Windows PowerShell with administrator privileges.

Before you run this, predict whether PILOT01's secure channel will return True.

Test the PILOT01 secure channel by running:

Test-ComputerSecureChannel

What does this second result prove?

This check tests PILOT01's trust relationship with the domain. A True result confirms that PILOT01 can communicate as a domain member.

You'll see True in Windows PowerShell. That's a key milestone because both member servers now trust DC01.

PILOT01 returning False?

Confirm that PILOT01 completed its restart after the domain join. Confirm that its active IPv4 interface still uses DC01 for DNS.

Help me diagnose a failed PILOT01 secure channel.

The trust checks prove that both joins work. Now confirm that PILOT01 landed inside the dedicated pilot scope.

Switch back to the DC01 session in Windows App.
Use the Tools menu in Server Manager to start Active Directory Users and Computers.
Select the WSUS-Pilot organizational unit.

You'll see the PILOT01 computer account inside WSUS-Pilot. This confirms that the pilot has a dedicated organizational-unit scope.

The final check reads the computer's Resultant Set of Policy. Domain membership is working, but no WSUS policy has been created for the pilot yet.

Before you run this, predict whether joining the domain also added WSUS-Pilot-Control.

Switch back to PILOT01's elevated Windows PowerShell session.
Check the computer-scope policy result by running:

gpresult /scope computer /r

What does this policy report show?

The command displays the computer-scope policy summary for PILOT01. The applied-policy section distinguishes domain membership from an update policy that actually targets this server.

The Applied Group Policy Objects section does not contain WSUS-Pilot-Control. This intended gap proves that joining a domain does not define the pilot's update-service path.

Your member servers now trust the domain, and PILOT01 sits inside its dedicated OU. Next up, you'll configure the WSUS control plane without starting synchronization.

Configure the WSUS Control Plane

Your servers now share the patchlab.example.com domain. PILOT01 sits inside the dedicated WSUS-Pilot OU.

The Windows Server Update Services role exists on WSUS01. Its control plane still needs an upstream source.

This step creates the synchronization boundary. It also creates the pilot group without starting a metadata synchronization.

In this step, get ready to:

Finish the WSUS post-installation setup.
Set a manual synchronization boundary with no products selected.
Create the Pilot-Ring computer group.

Complete WSUS post-installation

Post-installation prepares the local WSUS components that support the administration console. Completing it gives you a stable control surface for the configuration choices that follow.

Switch back to your WSUS01 session in Windows App.
Select the notification flag in the top-right corner of Server Manager.
Select Launch Post-Installation tasks.

The post-installation task can sit quietly for a few minutes while WSUS prepares its local components. A quiet screen during this stage is expected.

Wait for the post-installation task to finish.

You'll see Configuration successfully completed in the notification details. You have cleared the first setup checkpoint.

Select Tools in Server Manager.
Select Windows Server Update Services.

You'll see the WSUS Administration Console. The WSUS Configuration Wizard opens for the initial configuration.

What did post-installation complete?

Post-installation prepares the WSUS database components used by the administration console. Update synchronization remains under your control.

Post-installation still running?

Select the notification flag to check the current task status.
Confirm your account on WSUS01 has local administrator rights.

Need help with the stalled task?

Configure a safe synchronization boundary

The wizard defines where WSUS gets catalog data from Microsoft Update. It also controls what a later synchronization can collect.

This lab uses a deliberately narrow configuration. You keep synchronization manual while leaving every product unselected.

Continue in the WSUS Configuration Wizard until you reach Choose Upstream Server.
Select Synchronize from Microsoft Update.
Continue to Specify Proxy Server.
Leave Use a proxy server when synchronizing cleared.
Continue to Connect to Upstream Server.
Select Start Connecting.
Wait for the connection to complete.

The initial connection usually takes only a few minutes. WSUS uses this stage to retrieve the available configuration choices.

Continue to Choose Languages.
Select Download updates only in these languages.
Select English.
Clear every other language.

What does Start Connecting do?

This connection retrieves information about available updates. It also retrieves the product and classification choices needed by the remaining wizard pages.

Initial synchronization remains a separate action. You keep that action disabled throughout this project.

Continue to Choose Products.
Clear every product checkbox.
Continue to Choose Classifications.
Clear every selected classification.
Select Security Updates.
Continue to Set Sync Schedule.
Select Synchronize manually.
Continue to Finished.

Why leave every product unselected?

Current canonical WSUS documentation does not identify a verified product-category label for Windows Server 2022. An empty product selection keeps that unverified choice outside your control plane.

The lab can still demonstrate computer groups and policy scope. Update synchronization belongs in a later project with a validated product selection.

Leave Begin initial synchronization unchecked.
Select Finish.

The WSUS Administration Console returns without starting synchronization. Your synchronization boundary is now in place.

Upstream connection not completing?

Confirm WSUS01 can reach the internet.
Confirm the proxy option remains cleared for this lab.
Retry Start Connecting after confirming connectivity.

Help me troubleshoot the WSUS upstream connection.

Create the pilot computer group

Client-side targeting lets a future Group Policy tell each computer which WSUS group to join. The Pilot-Ring group must exist before that policy can target it.

Select Options beneath WSUS01 in the WSUS Administration Console.
Select Computers.
Select Use Group Policy or registry settings on computers.
Select OK.

How will computers join the pilot ring?

Client-side targeting reads a group name from policy on each managed computer. WSUS places that computer into the matching group after the client reports to the server.

The next step gives PILOT01 the policy value that points to Pilot-Ring.

Expand Computers beneath WSUS01.
Right-click All Computers.
Select Add Computer Group.
Enter Pilot-Ring in the Name field.
Select Add.

The Pilot-Ring group now appears beneath Computers. Your WSUS server can now represent a separate pilot population.

Before you verify the console, which safeguards do you expect to find in the final configuration?

Return to Options.
Select Products and Classifications.
Open the Products tab.
Review the product checkboxes.
Open the Classifications tab.
Review the selected classifications.
Return to Options.
Select Synchronization Schedule.

You should see every product checkbox cleared. You should see only Security Updates selected under classifications.

You should also see Synchronize manually selected.

Return to the left navigation pane.
Select Synchronizations.
Review the synchronization history.
Expand Computers.
Review the listed computer groups.

You should see no completed synchronization in the history. You should see Pilot-Ring beneath Computers.

Pilot-Ring missing from Computers?

Expand the correct WSUS01 server node.
Confirm Pilot-Ring was entered exactly in the computer-group dialog.
Refresh the Computers node.

Help me find my WSUS computer group.

Your WSUS control plane now has a manual synchronization boundary and a dedicated pilot group. Next, you'll route only PILOT01 through that control plane with an OU-scoped policy.

Route the Pilot Through WSUS

The WSUS service now has a Pilot-Ring computer group. PILOT01 still has no update-service policy.

This step uses a narrowly scoped Group Policy Object to direct PILOT01 through WSUS01. The OU link keeps DC01 outside the pilot scope. WSUS01 also stays outside the pilot scope.

In this step, get ready to:

Create WSUS-Pilot-Control and link it only to the WSUS-Pilot OU.
Configure notification behavior, the WSUS service location, and pilot group targeting.
Verify the applied policy through a live WSUS endpoint test.

Create and link the pilot GPO

An organizational unit link gives the GPO a precise boundary. Only computers inside WSUS-Pilot receive the settings.

Switch back to DC01 in the Windows App session from earlier.
In Server Manager on DC01, select Tools.

The Tools menu shows the administration consoles installed with Active Directory Domain Services.

Select Group Policy Management.

You should see the Group Policy Management console with the patchlab.example.com forest in the left pane.

Expand the forest tree to reveal the patchlab.example.com domain.
Select the patchlab.example.com domain.

The domain tree should show Group Policy Objects and the WSUS-Pilot OU.

Right-click Group Policy Objects.
Select New.

A dialog opens for the new GPO name.

Enter WSUS-Pilot-Control as the GPO name.
Confirm the dialog to create the GPO.

You should see WSUS-Pilot-Control under Group Policy Objects.

Right-click the WSUS-Pilot OU.
Select Link an Existing GPO.

The link dialog lists the GPOs available in the domain.

Select WSUS-Pilot-Control.
Confirm the dialog to create the link.

You should see WSUS-Pilot-Control linked beneath the WSUS-Pilot OU.

Select the WSUS-Pilot OU to inspect its linked GPOs.

Confirm that WSUS-Pilot-Control is the only GPO linked to this OU. This scope leaves DC01 outside the pilot policy.

Configure the pilot update settings

A client policy must define notification behavior. It must also identify the update service and pilot group.

How the three controls fit together

Configure Automatic Updates controls how PILOT01 responds when updates become available.
Specify intranet Microsoft update service location directs the pilot to WSUS01.
Client-side targeting assigns the pilot to Pilot-Ring inside WSUS.

Right-click WSUS-Pilot-Control under Group Policy Objects.
Select Edit.

The Group Policy editor opens for WSUS-Pilot-Control.

Expand Computer Configuration.
Expand Policies.

The computer policy tree now shows the available policy categories.

Expand Administrative Templates.
Expand Windows Components.

The Windows component policies are now visible.

Select Windows Update.

The right pane should display the Windows Update policy settings.

Automatic update behavior is the first control. The notification option keeps each download under user control.

Open Configure Automatic Updates.
Select Enabled.

The automatic update options become available.

Choose 2 - Notify for download and auto install.
Save the policy setting.

You should see Configure Automatic Updates marked as enabled. Installation now waits for user action.

The intranet service location tells PILOT01 where to request update metadata. Both service fields point to the same WSUS endpoint.

Open Specify intranet Microsoft update service location.
Select Enabled.

The two intranet update-service fields become available.

Enter http://WSUS01.patchlab.example.com:8530 in the first server box.
Enter http://WSUS01.patchlab.example.com:8530 in the second server box.

Both fields should now contain the same WSUS01 URL.

Save the intranet update-service setting.

You should see Specify intranet Microsoft update service location marked as enabled.

The final setting maps PILOT01 to the computer group you created earlier. The group name must match Pilot-Ring exactly.

Open Enable client-side targeting.
Select Enabled.

The target group field becomes available.

Enter Pilot-Ring as the target group.
Save the client-side targeting setting.

You should see Enable client-side targeting marked as enabled.

Close the Group Policy editor.

The GPO now contains all three pilot controls. No update metadata has been synchronized.

Keep HTTP inside this lab

This isolated lab uses HTTP on port 8530 to fit the project boundary. Microsoft recommends TLS for WSUS metadata.

Do not copy this transport design into production. A production design needs certificate-backed TLS.

Force policy and test the endpoint

Policy settings on DC01 become effective only after PILOT01 refreshes its computer policy. A separate endpoint test proves that the configured service is reachable.

Switch back to PILOT01 in Windows App.
Use the Windows Start menu to start Windows PowerShell with administrator privileges.

You should see an elevated PowerShell prompt on PILOT01.

Before you refresh the policy, do you expect PILOT01 to pick up the OU-linked GPO immediately?

Refresh every Group Policy setting by running this command:

gpupdate /force

What does this command do?

The gpupdate command refreshes Group Policy on PILOT01.
The /force option reapplies every policy setting.

You should see confirmation that computer policy processing completed.

Restart PILOT01 if Windows requests it.
Return to PILOT01 in Windows App after the restart.

Policy refresh fails?

Confirm that PILOT01 still uses DC01's private IPv4 address for DNS.
Return to the secure-channel check from the previous step if the refresh reports a domain connection problem.

Need help tracing the refresh failure? Help me troubleshoot Group Policy refresh on PILOT01.

Before you inspect the result, do you expect the computer-scope report to list the new pilot GPO?

Inspect the applied computer policy by running this command:

gpresult /scope computer /r

What does this command show?

The gpresult command reads Resultant Set of Policy data from PILOT01.

The /scope computer option limits the report to computer settings. The /r option produces a summary.

The computer-scope results should list WSUS-Pilot-Control as an applied GPO.

GPO missing from the results?

Confirm that the PILOT01 computer account remains inside the WSUS-Pilot OU on DC01.
Confirm that WSUS-Pilot-Control remains linked to the WSUS-Pilot OU.
Refresh computer policy again after correcting the scope.

Still missing the GPO? Help me trace why WSUS-Pilot-Control is not applying to PILOT01.

Before you test the endpoint, do you expect the configured computer name and service port to succeed?

Test the WSUS01 endpoint from PILOT01 by running this command:

Test-NetConnection -ComputerName "WSUS01.patchlab.example.com" -Port 8530

What does this test prove?

The computer name asks DNS to resolve WSUS01's domain address.
The -Port 8530 option checks whether the WSUS service is reachable over TCP.
The TcpTestSucceeded result separates endpoint reachability from policy application.

You should see TcpTestSucceeded set to True.

PILOT01 has resolved the WSUS01 address. TCP port 8530 is also reachable.

You have now proven the full pilot path from OU-scoped policy to the WSUS endpoint.

TCP test does not succeed?

Confirm that the endpoint uses WSUS01.patchlab.example.com.
Confirm that PILOT01 still uses DC01's private IPv4 address for DNS.
Confirm that the WSUS service remains available on WSUS01.
Confirm that wsus-lab-sg still allows private traffic from itself.

Need help separating DNS from TCP failure? Help me diagnose why PILOT01 cannot reach WSUS01 on port 8530.

Update metadata remains unsynchronized. No updates have been approved.

Secret mission

Break and Repair the Policy Path

Temporarily direct the pilot policy to a controlled bad WSUS hostname. Use an RSoP report plus a TCP test to separate policy processing from endpoint reachability. Finish with the pilot back on its verified WSUS path.

Clean Up Your Resources

Your three running Windows Server 2022 Amazon EC2 instances can accrue compute charges. Choose Keep to continue now, Pause to return later, or Delete when the lab is finished.

Cost warning

Running DC01, WSUS01, and PILOT01 continues EC2 instance-usage charges. Stopping them ends those instance-usage charges.

Attached Amazon EBS volumes continue storage charges while the instances are stopped. Choose Pause or Delete if you are not continuing immediately.

Resources you used:

The DC01 instance uses a 30 GiB gp3 root EBS volume. It stores the patchlab.example.com Active Directory forest. It also stores the WSUS-Pilot OU and WSUS-Pilot-Control Group Policy Object.
The WSUS01 instance uses an 80 GiB gp3 root EBS volume. It stores the WSUS role. It also stores the manual synchronization configuration and Pilot-Ring computer group.
The PILOT01 instance uses a 30 GiB gp3 root EBS volume. It stores the generated RSoP report at C:\wsus-policy.html.
The wsus-lab-sg security group limits RDP access to your public IP address. A separate rule allows private communication among the lab instances.
The EC2 key pair is attached to DC01, WSUS01, and PILOT01.

Keep everything running

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

Keep DC01, WSUS01, and PILOT01 running.
Retain wsus-lab-sg for private communication between the servers.
Retain the EC2 key pair for future Administrator password retrieval.
Use Windows App for Mac to reconnect when you continue.
Expect EC2 instance-usage charges and EBS storage charges to continue.

Pause - I'll come back to this later

Pausing preserves the server disks and AWS network configuration for later. EBS storage charges continue while the instances are stopped.

In the Amazon EC2 console from earlier, stop PILOT01 first.
Stop WSUS01 after the pilot has stopped.
Stop DC01 last.
Confirm that all three instances are stopped.
Start DC01 first when you resume the lab.
Wait until DC01 passes its status checks.
Start WSUS01 after DC01 passes its checks.
Start PILOT01 after DC01 passes its checks.

Each instance retains its private IPv4 address across stop and start.

Delete - I don't want to use this again

Deleting the lab is permanent. The steps below target the three named instances and their supporting EC2 resources.

Termination Is Permanent

The Windows servers hold the lab's identity and policy state. Terminating the instances removes that state once their root volumes are deleted.

Save any screenshots or notes that you want to keep.
In the Amazon EC2 console from earlier, select DC01, WSUS01, and PILOT01 from the instance list.
Terminate the three selected instances.
Wait for termination to finish for all three instances.
Check the Amazon EC2 EBS volume list for the root volumes previously attached to the lab instances.
Delete any remaining 30 GiB or 80 GiB lab root volume.
Delete wsus-lab-sg from the Amazon EC2 security group list after instance termination finishes.
Delete the EC2 key pair from the Amazon EC2 key pair list if you no longer need it.
Confirm that no lab instance or attached root EBS volume remains in a billable state.

Deleting the root volumes removes all server-side lab state. No synchronized WSUS metadata or update approvals need separate cleanup.

Nice Work!

You did it! You built a role-separated Windows Server 2022 patch-control lab on Amazon EC2.

You've learned how to:

Build the patchlab.example.com forest with Active Directory. Scope PILOT01 through the WSUS-Pilot organizational unit.
Configure Windows Server Update Services with manual synchronization plus the Pilot-Ring computer group. Keep product selection empty so update metadata remains unsynchronized and unapproved.
Apply WSUS-Pilot-Control through Group Policy only to the pilot OU. Diagnose the client-to-WSUS path with PowerShell. Confirm applied policy through Resultant Set of Policy reports.
Secret Mission: Proved that WSUS-Pilot-Control could apply while WSUS-BROKEN.patchlab.example.com failed endpoint reachability. Restored WSUS01.patchlab.example.com. Verified that TCP reachability succeeded again.

Ready to quiz yourself?