Windows & Networking Support Lab

Diagnose and fix enterprise agent connectivity failures on Windows Server.

Introduction

30 Second Summary

When an app at work suddenly can't connect to its server, someone has to figure out why. That person remotes into the affected machine, runs a series of diagnostic commands, and traces exactly where the connection breaks.

In this project, you will set up a Windows Server on AWS, simulate a broken enterprise software agent, and diagnose escalating connectivity failures using the same command-line tools real Technical Support Engineers use on customer machines every day.

What You'll Build

Imagine receiving an urgent support ticket, remoting into a customer's Windows Server, and methodically tracing a broken connection from DNS resolution through firewall rules until you pinpoint and fix the root cause.

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

A Windows Server on AWS that you can remote into and administer with PowerShell commands, just like you would on a real customer machine.
Diagnosed and fixed a DNS misconfiguration using nslookup and the Windows hosts file, restoring an agent's connection to its cloud Control Room.
Resolved a multi-layer failure combining a stopped Windows service and a blocked firewall port, proving you can handle stacked problems that trip up junior engineers.
Secret Mission: Tackle a triple-failure Ticket 3 that combines DNS, firewall, and service issues simultaneously with no hints provided.

Are there any prerequisites?

You need an AWS account and Microsoft Remote Desktop installed on your Mac. If you already have both, you are ready to start.

No prior Windows Server experience is required. This project teaches you the commands from scratch.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters. You're stepping into the role of a Technical Support Engineer diagnosing real connectivity failures on a Windows Server.

Launch Your Windows Server Lab

To practice real support diagnostics, you need a Windows Server you can break and fix without consequences. A local virtual machine would work, but an EC2 instance on AWS gives you the exact same environment enterprise customers use.

In this step, you will launch a Windows Server 2022 instance on AWS and connect to it from your Mac using Remote Desktop Protocol (RDP). By the end, you will have a live PowerShell prompt on a real Windows Server ready for diagnostics.

In this step, get ready to:

Launch a Windows Server 2022 EC2 instance on AWS.
Connect to your instance via Remote Desktop from your Mac.
Verify your environment with PowerShell commands.

Launch a Windows Server EC2 instance

Sign in to the AWS Management Console at https://console.aws.amazon.com.
In the search bar at the top, type EC2 and select EC2 from the results.
Click the orange Launch instance button.

The launch wizard opens as a single page with several sections to configure.

Under Name and tags, enter NovaBOT-Lab as the name.
Under Application and OS Images, click Quick Start, then select Windows.
Choose the Microsoft Windows Server 2022 Base AMI marked Free tier eligible.
Under Instance type, select t2.micro (also marked Free tier eligible).
Under Key pair (login), click Create new key pair.

A dialog appears asking for key pair details.

Enter novabot-lab-key as the key pair name.
Select RSA as the key pair type.
Select .pem as the private key file format.
Click Create key pair.

Where did my key file go?

Your browser automatically downloads a file called novabot-lab-key.pem to your Downloads folder. You will need this file in a few minutes to decrypt your Windows password. Do not delete or move it yet.

Under Network settings, confirm that Allow RDP traffic from is checked and set to My IP.
Leave all other settings at their defaults.
Click the Launch instance button in the Summary panel on the right.

You should see a success message confirming your instance is launching.

Click View all instances to return to the EC2 dashboard.
Wait for the Instance state column to show Running and the Status check column to show 2/2 checks passed.

This takes a few minutes

Windows Server instances typically take 3-5 minutes to fully initialize. You can click the refresh icon in the EC2 console to check progress. Wait until both status checks pass before continuing.

Instance stuck in Pending?

If your instance stays in Pending for more than 5 minutes, check that you selected t2.micro as the instance type. Larger instance types may not be available in all regions.

Help me troubleshoot my EC2 instance not launching.

Connect via RDP from your Mac

Your Windows Server is running, but you need to connect to its desktop. RDP lets you control the server as if you were sitting in front of it.

In the EC2 console, click the checkbox next to your NovaBOT-Lab instance to select it.
Click Connect at the top of the page.
Select the RDP client tab.
Click Get password.

Why does Get password need my key file?

AWS encrypts your Windows Administrator password with the public key from your key pair. Uploading the private .pem file lets AWS decrypt it and show you the password.

Click Upload private key file and select the novabot-lab-key.pem file from your Downloads folder.
Click Decrypt password.

Seeing a message that the password is not available yet?

AWS needs a few minutes after instance launch before the password is ready. Wait 3-5 minutes after your instance state shows Running, then try clicking Get password again.

Help me get my Windows RDP password from AWS.

You should now see three pieces of information you need for the connection.

Note the Public DNS value (this is the hostname for your connection).
Note the User name (it will be Administrator).
Note the decrypted Password (copy it to your clipboard).

Now open Microsoft Remote Desktop on your Mac.

Press Cmd+Space to open Spotlight search.
Type Microsoft Remote Desktop and press Enter to open it.
Click Add PC (or the + button).
In the PC name field, paste your Public DNS value from the AWS console.
Click Add.
Double-click the new PC entry to connect.
When prompted for credentials, enter Administrator as the username and paste the decrypted password.
Click Continue if you see a certificate warning (this is normal for EC2 instances).

After a few seconds, the Windows Server desktop appears in your Remote Desktop window.

Connection refused or timed out?

Check that your EC2 instance state is Running in the AWS console. Also confirm the security group allows RDP (port 3389) from your IP. If your IP has changed since launch (e.g. you switched networks), edit the inbound rules to allow your current IP.

Help me connect to my Windows EC2 instance via RDP.

Verify your environment

You are now on a live Windows Server. Before moving on, confirm you are on the right machine and check the network configuration you will rely on throughout this project.

Right-click the Start button (bottom-left of the Windows desktop).
Select Windows PowerShell (Admin) from the menu.
If prompted by User Account Control, click Yes.

A blue PowerShell window opens with administrator privileges. Before you run the first command, predict what you expect the hostname to be.

Confirm you are on the EC2 instance by running:

hostname

You should see an auto-generated Windows hostname (something like EC2AMAZ-XXXXXXX). This confirms you are running commands on the remote server, not your Mac.

Check your network configuration by running:

ipconfig /all

What should I see in ipconfig?

Look for the DNS Servers line in the output. AWS assigns its own DNS servers to your instance (typically in the x.x.x.2 range of your VPC subnet). In later steps, you will use nslookup to query these servers directly.

You will also see your private IPv4 address under the Ethernet adapter section. This is the internal IP AWS assigned to your instance within its VPC.

PowerShell not in the right-click menu?

Some Windows Server configurations show Windows Terminal or Command Prompt instead. Click the Start button, type PowerShell, right-click Windows PowerShell, and select Run as administrator.

Help me open PowerShell as admin on Windows Server.

Your Windows Server lab is live and you are connected. Next up, you will learn the five diagnostic commands that form the foundation of every connectivity troubleshooting session.

Master the Diagnostic Toolkit

You have a Windows Server running and you can type commands into it. But before you can diagnose broken environments, you need to know what healthy output looks like.

In this step, you'll run four core diagnostic commands against live, known-good targets. This builds the muscle memory you'll rely on when things break in later support tickets.

In this step, get ready to:

Practice DNS resolution with nslookup.
Test port connectivity with Test-NetConnection and netstat.
Query Windows service states with sc query.

Practice DNS resolution with nslookup

The nslookup command queries a DNS server directly to resolve domain names into IP addresses. It's the first tool you reach for when a machine can't find a server by name.

In your PowerShell (Admin) window, run this command to look up the IP address of google.com:

nslookup google.com

You'll see the DNS server your machine is using (an AWS-assigned address) and one or more IP addresses returned for google.com.

Run a reverse DNS lookup to see what hostname is associated with an IP address:

nslookup 1.1.1.1

This returns the hostname registered for that IP. Reverse lookups help you confirm whether an IP belongs to the server you expect.

Run this command to query a specific DNS server (Google's public DNS at 8.8.8.8) instead of your machine's default:

nslookup google.com 8.8.8.8

Notice that the Server line at the top now shows 8.8.8.8 instead of your local DNS server. You chose exactly which DNS server to ask.

Why nslookup matters for support

nslookup bypasses the local DNS cache and the Windows hosts file. It queries the DNS server directly.

If nslookup fails for a domain, the DNS server itself cannot resolve that name. If nslookup succeeds but the application still can't connect, the problem is somewhere else (like a firewall or a hosts file override).

Seeing a timeout or server failure?

If nslookup hangs or returns a timeout, your EC2 instance may not have internet connectivity. Check that the instance's security group allows outbound traffic.

help me troubleshoot nslookup timeouts on my EC2 Windows instance

Test port connectivity with Test-NetConnection and netstat

Test-NetConnection checks whether you can reach a specific port on a remote machine. netstat shows what connections already exist on your local machine. Together, they tell you whether traffic can flow.

Run this command to test if you can reach port 443 (HTTPS) on google.com:

Test-NetConnection -ComputerName google.com -Port 443

Look for the TcpTestSucceeded field at the bottom of the output. If it shows True, the port is reachable from your machine.

Run the same command with the -InformationLevel Detailed flag to see additional routing information:

Test-NetConnection -ComputerName google.com -Port 443 -InformationLevel Detailed

What are the extra fields?

The detailed output adds InterfaceAlias (which network adapter is used), SourceAddress (your machine's IP), and route information. These help you pinpoint whether a specific network interface or route is the problem.

Now use netstat to find your active RDP connection on port 3389:

netstat -ano | findstr :3389

You'll see at least one line showing ESTABLISHED with a process ID. That's your live RDP session happening right now.

Test-NetConnection vs netstat

Test-NetConnection tells you if a remote port is reachable. It's an outbound probe.

netstat tells you what connections already exist on the local machine. It shows both inbound and outbound sessions that are active right now.

TcpTestSucceeded shows False?

If Test-NetConnection returns False for port 443, your instance's security group or network ACL may be blocking outbound HTTPS. Check that outbound rules allow all traffic (the default for EC2 security groups).

help me fix Test-NetConnection failures on my EC2 instance

Query Windows service states with sc query

Windows services are background processes that run without a user being logged in. Enterprise agents run as services. If the service is stopped, the agent can't connect to anything.

Run this command to check the state of the Windows Time service (W32Time):

sc query W32Time

Look for the STATE field. It shows whether the service is RUNNING, STOPPED, or in another state.

Run this command to list all service names installed on the machine:

sc query state= all | findstr "SERVICE_NAME"

This outputs every registered service. In a real support scenario, you'd search this list for the agent's service name.

Run this PowerShell alternative to see the first 10 running services with cleaner output:

Get-Service | Where-Object {$_.Status -eq 'Running'} | Select-Object -First 10

What does sc query tell you?

sc query shows whether a Windows service is running, stopped, or in a transitional state. The STATE field is your go-to indicator.

If an agent service shows STOPPED, it cannot maintain any connections. You need to find out why it stopped and start it again before anything else will work.

Seeing 'The specified service does not exist'?

Make sure you typed W32Time exactly as shown. Service names are case-sensitive. If the Windows Time service is not installed on your instance, try sc query Dnscache instead to confirm the command works.

help me troubleshoot sc query on Windows Server

Confirm your diagnostic toolkit is working

Before you run the next command, predict: will Test-NetConnection to 1.1.1.1 on port 443 succeed or fail? Why do you think so?

Run this final check to confirm your tools are working:

Test-NetConnection -ComputerName 1.1.1.1 -Port 443

You should see TcpTestSucceeded: True in the output. This confirms your machine can reach the internet on port 443, and your toolkit is ready for real troubleshooting.

You now have four commands in your toolkit that can diagnose DNS failures, port blocks, existing connections, and stopped services. Next up, you'll build the NovaBOT simulation environment so you have something realistic to troubleshoot.

Build the NovaBOT Simulation

You now have a toolkit of diagnostic commands you can run against any target. The missing piece is a target worth diagnosing.

In this step, you will build a simulated NovaBOT Agent environment on your Windows Server. This means registering a Windows service, adding a DNS entry for the Control Room, and confirming the Agent can reach it over port 443. Once you see what "healthy" looks like, you will know exactly what is wrong when tickets start breaking things.

In this step, get ready to:

Register a NovaBOTAgent Windows service that simulates the automation agent.
Configure the hosts file so your machine resolves controlroom.novabot.local to a working IP.
Verify the full healthy baseline so you know what "working" looks like.

Create the NovaBOT Agent Windows service

In enterprise automation, the Bot Agent runs as a Windows service on the customer's machine. A service can start automatically at boot, run without a logged-in user, and be managed remotely. Your simulation registers a service entry so that later tickets can reference it by name, just like a real support case.

# Register a new Windows service pointing to a simulated agent binary
sc.exe create NovaBOTAgent binPath= "C:\NovaBOT\AgentService.exe" start= demand displayname= "NovaBOT Agent Service"

What does this command do?

sc.exe create registers a new service in the Windows Service Control Manager database.
binPath= points to where the agent binary would live on a real machine.
start= demand means the service only starts when explicitly told to (manual start).
displayname= sets the friendly name visible in the Services console.

You use sc.exe (not bare sc) because PowerShell aliases sc to Set-Content. The explicit .exe ensures you reach the real Service Controller utility.

You should see [SC] CreateService SUCCESS in the output.

Add a description to the service by running:

# Add a description so it looks like a real agent service
sc.exe description NovaBOTAgent "Connects to NovaBOT Control Room via HTTPS/WebSocket on port 443"

Confirm the service now exists by running:

# Check the service state
sc query NovaBOTAgent

You should see SERVICE_NAME: NovaBOTAgent with STATE showing STOPPED. The service is stopped because the binary at C:\NovaBOT\AgentService.exe does not actually exist. That is expected for the simulation.

Seeing a syntax error from sc.exe?

The sc.exe command has an unusual quirk: every parameter requires a space AFTER the equals sign. For example, binPath= "C:\..." is correct, but binPath="C:\..." (no space) fails.

Double-check that each = in your command is followed by a space before the value.

Help me fix my sc.exe create command

Configure DNS for the Control Room using the hosts file

Enterprise agents resolve their Control Room address via DNS. In production, a corporate DNS server handles this. For your simulation, you will add an entry in the Windows hosts file that maps controlroom.novabot.local to 1.1.1.1 (Cloudflare's public resolver, which accepts HTTPS connections on port 443).

Open the hosts file in Notepad by running this command:

notepad C:\Windows\System32\drivers\etc\hosts

In the Notepad window that opens, scroll to the very bottom of the file.
Add this line on a new line at the end:

1.1.1.1 controlroom.novabot.local

Press Ctrl+S to save the file, then close Notepad.

What is the hosts file?

The hosts file is a local text file that maps hostnames to IP addresses. Windows loads entries from this file into the DNS Client cache when the DNS Client service starts. Entries here override external DNS lookups for tools that use the Windows DNS Client resolver.

Flush the DNS cache so Windows picks up your new entry by running:

ipconfig /flushdns

You should see a confirmation message saying the DNS Resolver Cache was successfully flushed.

Test whether the hostname resolves by running nslookup first:

nslookup controlroom.novabot.local

You will likely see a response like "Non-existent domain." This is expected and correct.

Why does nslookup fail when the hosts file entry exists?

nslookup queries the DNS server directly and bypasses the hosts file entirely. It does not use the Windows DNS Client resolver.

Tools like ping and Test-NetConnection DO use the Windows DNS Client, which checks the hosts file first. Knowing which tools respect the hosts file and which bypass it is essential for diagnosing DNS issues in support tickets.

Verify the hosts file entry works by running ping (which does use the hosts file):

ping controlroom.novabot.local -n 1

You should see Pinging controlroom.novabot.local [1.1.1.1] in the output. The hostname resolved to the correct IP.

Confirm full port connectivity by running:

Test-NetConnection -ComputerName controlroom.novabot.local -Port 443

You should see TcpTestSucceeded : True in the output. Your simulated Agent can now reach the Control Room on port 443.

Test-NetConnection shows TcpTestSucceeded: False?

Check that the hosts file entry uses 1.1.1.1 (not a typo like 1.1.1.11 or 11.1.1.1). Also confirm there is at least one space between the IP and the hostname in the hosts file.

If the IP is correct but port 443 still fails, your EC2 instance's security group might be blocking outbound traffic. Check the security group in the AWS Console and ensure outbound rules allow all traffic (the default for new security groups).

Help me troubleshoot my Test-NetConnection failure

Verify the full healthy state as your baseline

In real support work, you always establish what "working" looks like before investigating what is broken. Run through the full checklist now to lock in your baseline.

Confirm the service exists by running:

sc query NovaBOTAgent

You should see SERVICE_NAME: NovaBOTAgent with STATE showing STOPPED. The service is registered and queryable.

Confirm DNS resolution by running:

ping controlroom.novabot.local -n 1

Confirm it resolves to 1.1.1.1.

Before you run the final connectivity check, predict: based on everything you have set up, do you expect Test-NetConnection to succeed on port 443?

Run the full connectivity test:

Test-NetConnection -ComputerName controlroom.novabot.local -Port 443

You should see TcpTestSucceeded : True. Your baseline is confirmed: the service exists, DNS resolves to the correct IP, and port 443 is reachable.

Why document this baseline?

When a support ticket arrives saying "the agent is broken," you need a reference point. If you know the three things that make a healthy agent (service registered, DNS correct, port reachable), you can systematically test each one until you find the failure.

This is the diagnostic methodology you will apply in the next steps.

Your simulation is fully operational. You have a registered service, a DNS entry resolving to the right IP, and confirmed connectivity on port 443. Next up, your first support ticket arrives and things start breaking.

Resolve Ticket 1 - Agent Cannot Reach Control Room

You have a working simulation with confirmed connectivity to the Control Room. Now the real work begins.

Your first support ticket just arrived. A customer reports their NovaBOT Agent cannot reach the Control Room. You do not know the root cause yet. Your job is to diagnose it systematically using the commands you practised in Step 2. This is where you shift from student to engineer.

In this step, get ready to:

Receive a simulated support ticket and intentionally break your environment to match the customer's symptoms.
Diagnose the root cause using only command-line tools.
Fix the issue and write a professional ticket resolution note.

Receive the ticket and simulate the failure

Here is the ticket that just landed in your queue:

Priority 2 Ticket

NovaBOT Agent on machine NovaBOT-Lab shows status DISCONNECTED. Agent was working yesterday. Customer reports no network changes. Please investigate.

To practice diagnosing this, you need to simulate the failure on your own machine. Pretend a colleague accidentally misconfigured the system.

Simulate a DNS misconfiguration by running this command in PowerShell:

powershell -Command "(Get-Content C:\Windows\System32\drivers\etc\hosts) -replace '1.1.1.1 controlroom.novabot.local','192.0.2.1 controlroom.novabot.local' | Set-Content C:\Windows\System32\drivers\etc\hosts"

What does this command do?

This replaces the correct IP address 1.1.1.1 in your hosts file with 192.0.2.1. The address 192.0.2.1 belongs to a reserved documentation range (RFC 5737) that is non-routable on the public internet. This simulates a misconfiguration where the hostname points to an unreachable IP.

Clear the DNS cache so the change takes effect immediately by running:

ipconfig /flushdns

The environment is now broken, just like it would be on a real customer machine. Time to investigate.

Before you test, predict: will Test-NetConnection to the Control Room succeed or fail right now?

Test the connection by running:

Test-NetConnection -ComputerName controlroom.novabot.local -Port 443

You should see TcpTestSucceeded: False. The agent cannot reach the Control Room. Your ticket symptoms are confirmed.

Diagnose the failure

You know the connection is failing. Now you need to find out WHY. Is it a DNS problem, a network problem, or both?

✔️ I'll give it a go!

Try diagnosing the root cause on your own using the commands from Step 2. Here is your investigation framework:

Can the machine reach the real Control Room IP directly? Test with Test-NetConnection -ComputerName 1.1.1.1 -Port 443.
Does the hostname resolve to the correct IP? Check with ping controlroom.novabot.local -n 1.
If the IP is wrong, where does Windows resolve hostnames locally? Think about the hosts file.

Once you have identified the root cause, move on to the fix below.

ⓧ Maybe a little help...

Work through these diagnostic steps one by one.

First, check if the network itself is working by testing the real Control Room IP directly:

Test-NetConnection -ComputerName 1.1.1.1 -Port 443

You should see TcpTestSucceeded: True. The network can reach port 443. The underlying connection is fine.

Next, check what IP the hostname resolves to:

ping controlroom.novabot.local -n 1

Look at the IP address in the ping output. It shows 192.0.2.1 instead of the expected 1.1.1.1. The hostname is pointing to the wrong IP.

Open the hosts file to confirm the misconfiguration:

notepad C:\Windows\System32\drivers\etc\hosts

You will see the entry reads 192.0.2.1 controlroom.novabot.local instead of 1.1.1.1 controlroom.novabot.local. That is your root cause.

Why use ping instead of nslookup here?

The command nslookup queries the DNS server directly and bypasses the hosts file entirely. The ping command uses the Windows DNS Client resolver, which checks the hosts file first. Since the problem is in the hosts file, only ping (or Test-NetConnection) will reveal the incorrect IP.

This distinction trips up even experienced support engineers. Always use the right tool for the layer you are investigating.

Fix the issue and close the ticket

You have identified the root cause: the hosts file is pointing controlroom.novabot.local at the wrong IP address. Time to fix it.

Open the hosts file in Notepad by running:

notepad C:\Windows\System32\drivers\etc\hosts

Find the line that reads 192.0.2.1 controlroom.novabot.local.
Change 192.0.2.1 to 1.1.1.1 so the line reads 1.1.1.1 controlroom.novabot.local.
Click File, then Save. Close Notepad.

Flush the DNS cache so Windows picks up the corrected entry by running:

ipconfig /flushdns

Now predict: after correcting the hosts file and flushing DNS, what do you expect Test-NetConnection to show?

Verify connectivity is restored by running:

Test-NetConnection -ComputerName controlroom.novabot.local -Port 443

You should see TcpTestSucceeded: True. The agent can reach the Control Room again.

Still seeing TcpTestSucceeded: False?

Make sure you saved the hosts file. If Notepad shows an access error, confirm you launched PowerShell as Admin (the Notepad process inherits Admin elevation from the PowerShell window).
Double check the hosts file entry is exactly 1.1.1.1 controlroom.novabot.local with no extra spaces or characters.
Confirm you ran ipconfig /flushdns after saving. Without flushing, the old cached entry may still be used.

Need more help? Why is Test-NetConnection still failing after I fixed the hosts file?

Writing your ticket resolution note

In real support work, you always document what you found and how you fixed it. Here is what your resolution note looks like for this ticket:

Root cause: Hosts file entry for controlroom.novabot.local pointed to incorrect IP 192.0.2.1. Corrected to 1.1.1.1. Agent connectivity restored.

Ticket 1 closed. You diagnosed a DNS misconfiguration using ping and the hosts file, then verified your fix with Test-NetConnection. Next up, a harder ticket with two failures stacked on top of each other.

Resolve Ticket 2 - Agent Service Crashed, Cannot Reconnect

You solved Ticket 1 by tracing a DNS misconfiguration in the hosts file. Now the escalation queue has something harder waiting for you.

This ticket has TWO failures stacked on top of each other. Fixing only one will not restore connectivity. You must find both, just like in real-world enterprise support where problems rarely come alone.

In this step, get ready to:

Simulate a multi-layer failure combining a stopped service and a firewall block.
Diagnose both root causes independently using command-line tools.
Fix the issues and write a professional resolution note documenting both findings.

Receive the ticket and break the environment

A new ticket has just landed in your queue. Read it carefully before you touch anything.

Priority 1 Ticket - URGENT

NovaBOT Agent on machine NovaBOT-Lab is completely unresponsive. Agent service appears down. Customer has already rebooted the machine but agent still will not connect. Escalated from Tier 1.

To simulate this failure, you will introduce two problems. Pretend a colleague misconfigured the machine during a maintenance window.

Confirm the NovaBOTAgent service is already stopped (it should be from the simulation) by running:
This is failure 1. The service is not running, so the agent cannot communicate.

sc query NovaBOTAgent

You should see STATE showing STOPPED. This confirms failure 1 is already in place.

Simulate failure 2 by adding a firewall rule that blocks all outbound traffic on port 443:

netsh advfirewall firewall add rule name="YOURTICKET-BLOCK443" dir=out action=block protocol=tcp remoteport=443

What does this command do?

This creates a Windows Firewall rule named YOURTICKET-BLOCK443 that blocks all outbound TCP connections on port 443.

Since the NovaBOT Agent connects to the Control Room over HTTPS port 443, this rule cuts off its network path entirely.

Verify the break by testing connectivity to the Control Room:

Test-NetConnection -ComputerName controlroom.novabot.local -Port 443

You should see TcpTestSucceeded: False. The environment is now broken with two distinct failures.

Now investigate. Try to figure out both problems yourself before reading the guided diagnosis below.

Diagnose the failures

In real support, you would not know what broke. You only have the ticket text and your diagnostic commands.

✔️ I'll give it a go!

Use the commands you learned in Step 2 to find both root causes.

Check the service state with sc query.
Check network connectivity with Test-NetConnection.
If the network fails, determine whether DNS or the firewall is the cause.
Look for outbound block rules using netsh advfirewall firewall show rule.

Once you have identified both issues, skip ahead to the fix section below.

ⓧ Maybe a little help...

Follow these guided diagnostic steps to find both root causes.

Check the service first by running:

sc query NovaBOTAgent

The STATE field shows STOPPED. The agent service is not running.

Try to start it:

sc start NovaBOTAgent

You will see an error because the binary path C:\NovaBOT\AgentService.exe does not exist. This indicates a corrupted or missing installation.

Now check network connectivity:

Test-NetConnection -ComputerName controlroom.novabot.local -Port 443

TcpTestSucceeded shows False. So there is also a network problem.

Is it DNS or something else? Check if the hostname resolves correctly:

ping controlroom.novabot.local -n 1

The ping resolves to 1.1.1.1 correctly. DNS is fine, so the problem is somewhere else.

Test whether you can reach a different port on the same IP:

Test-NetConnection -ComputerName 1.1.1.1 -Port 80

Port 80 might succeed while port 443 fails. This points to something specifically blocking port 443.

Check for outbound block rules in the firewall:

netsh advfirewall firewall show rule name=all dir=out | findstr "BLOCK"

You should see YOURTICKET-BLOCK443 in the output. This firewall rule is blocking all outbound TCP port 443 traffic.

What are the two root causes?

Root cause 1: The NovaBOTAgent service is stopped and its binary is missing from the expected path. The service cannot start without a reinstallation.

Root cause 2: A Windows Firewall rule named YOURTICKET-BLOCK443 is blocking all outbound TCP connections on port 443. Even if the service were running, it could not reach the Control Room.

Fix both issues and close the ticket

You now know both root causes. Time to fix what you can and document what requires further action.

Remove the firewall block rule by running:

netsh advfirewall firewall delete rule name="YOURTICKET-BLOCK443"

What does this command do?

The netsh advfirewall firewall delete rule command removes the named firewall rule entirely. Once deleted, outbound TCP 443 traffic flows freely again.

Before you verify, predict: what do you expect Test-NetConnection to show now that the firewall rule is removed?
Verify network connectivity is restored by running:

Test-NetConnection -ComputerName controlroom.novabot.local -Port 443

You should see TcpTestSucceeded: True. The network path to the Control Room is open again.

What about the service?

In a real scenario, you would reinstall the NovaBOT Agent to restore the binary at C:\NovaBOT\AgentService.exe. For this simulation, note the finding and recommend reinstallation in your ticket resolution.

Confirm the service still exists (even though it cannot start) by running:

sc query NovaBOTAgent

You should see the service listed with STATE: STOPPED. The registration is intact but the binary is missing.

Write your ticket resolution note. A professional note for this ticket would look like:

Ticket resolution note template

Root cause 1: Windows Firewall rule 'YOURTICKET-BLOCK443' was blocking all outbound TCP 443 traffic. Rule removed.

Root cause 2: NovaBOT Agent service binary missing from expected path. Recommend agent reinstallation. Network connectivity to Control Room confirmed restored.

Test-NetConnection still showing False?

Make sure you ran the delete command with the exact rule name YOURTICKET-BLOCK443 including the quotes. You can verify the rule is gone by running netsh advfirewall firewall show rule name="YOURTICKET-BLOCK443" and confirming it says no rules match.

If the rule was already deleted but connectivity still fails, check that the hosts file still contains 1.1.1.1 controlroom.novabot.local and run ipconfig /flushdns.

help me troubleshoot why Test-NetConnection is still failing after I deleted the firewall rule

Two root causes found, one fixed, one documented for the install team. That is exactly how multi-layer support tickets work in the real world. Next up, the Secret Mission challenges you with a triple failure and zero hints.

Secret mission

Ticket 3 - "Multiple Sites Down After Network Change"

Your hardest ticket yet. Three failures hit simultaneously after a network maintenance window. DNS, firewall, and service configuration are all broken. No hints this time. Can you find all three?

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses an EC2 Windows Server instance that consumes your AWS Free Tier hours (or credits) while running.

Cost warning

If you are past your AWS Free Tier period, a running t2.micro Windows instance costs approximately $0.0116/hour (around $8.50/month). Always stop or terminate when not in use.

If your account is still within the Free Tier (accounts created before July 15, 2025 get 750 hours/month of t2.micro for one year), you will not be charged as long as total running hours stay below 750/month.

Resources you used:

EC2 Windows Server instance (NovaBOT-Lab, t2.micro, running).
EC2 key pair (novabot-lab-key) stored in AWS.
Local private key file (novabot-lab-key.pem) on your Mac.
Microsoft Remote Desktop PC entry for this instance.

Keep everything running

No action needed. Choose this if you are still actively practicing commands or plan to revisit the lab soon.

Your EC2 instance continues to run and consume Free Tier hours (750 hours/month for eligible accounts).
Your RDP connection in Microsoft Remote Desktop stays configured and ready.
You can reconnect anytime using the same Administrator credentials.

Pause - I'll come back to this later

Stop the instance to pause compute billing. Your data and configuration are preserved on the EBS volume. You can restart anytime.

Switch back to the AWS Management Console in your browser.
In the navigation pane, click Instances.
Select the NovaBOT-Lab instance.
Click Instance state, then Stop instance.
Click Stop to confirm.
Wait for the instance state to show Stopped. This pauses compute charges. The EBS volume remains (covered by Free Tier storage).
To resume later, select the instance, click Instance state, then Start instance. Note that the Public DNS will change after restart, so update your Microsoft Remote Desktop entry with the new address.

Delete - I don't want to use this again

Remove all project resources permanently. This stops all charges and deletes your lab data.

Switch back to the AWS Management Console in your browser.
In the navigation pane, click Instances.
Select the NovaBOT-Lab instance.
Click Instance state, then Terminate (delete) instance.
Click Terminate (delete) to confirm. The instance and its EBS volume are permanently deleted.
In the navigation pane under Network & Security, click Key Pairs.
Select novabot-lab-key, click Actions, then Delete.
Type Delete in the confirmation field and click Delete.
On your Mac, delete the local private key file by opening Terminal and running:

rm ~/Downloads/novabot-lab-key.pem

If you saved the file elsewhere, delete it from that location instead.
In Microsoft Remote Desktop, right-click the NovaBOT-Lab PC entry and select Delete to remove it from your saved connections.

Nice Work!

You just completed a full Technical Support Engineer simulation. You built a Windows Server lab on AWS, diagnosed escalating connectivity failures, and fixed them using the same tools real support engineers use every day.

Here's what you learned:

Built a Windows Server lab environment on EC2 and connected via RDP from your Mac.
Mastered five core diagnostic commands: nslookup, Test-NetConnection, sc query, netstat, and ipconfig /flushdns.
Resolved escalating support tickets by diagnosing DNS misconfigurations, stopped Windows services, and Windows Firewall blocks using a systematic troubleshooting methodology.
Secret Mission: Resolved a triple-failure Ticket 3 combining DNS, firewall, and service configuration issues with no hints provided.

Ready to quiz yourself?