Build a Windows Server Two-Tier Lab

Provision two domain-joined Windows Server tiers with IIS, DNS, and snapshots.

Introduction

30 Second Summary

A service can look healthy on one machine while a missing network link keeps every other machine out. A clean foundation makes each part testable before real application data arrives.

In this project, you will build two domain-connected Windows Server 2025 virtual machines in VMware Workstation Pro. You will open a Helpdesk page from DB01 through a friendly service address hosted by APP01.

What You'll Build

From DB01, you will enter http://helpdesk.cloudseam.tech/index.html and see the Helpdesk foundation page served by APP01.

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

Two separate member servers where you can sign in through the cloudseam.tech Active Directory domain.
A working Helpdesk page that you can open from DB01, proving IIS, DNS, and Windows Defender Firewall agree on the route.
A recoverable VMware baseline with named snapshots, ready to restore before database installation begins.
Secret Mission: Add support.cloudseam.tech as a DNS alias with a matching IIS binding.

Are there any prerequisites?

Your existing lab needs VMware Workstation Pro plus an operational cloudseam.tech Active Directory domain with two Windows Server 2025 domain controllers.

You also need domain administrator credentials, host capacity for two additional 4 GB virtual machines, and two unused IPv4 addresses on the server subnet.

Before We Start

Before the hands-on work begins, this checkpoint locks in what you are building and why the two server roles stay separate. The design positions APP01 as the IIS application tier while DB01 remains reserved for the future database tier to support least-privilege connectivity.

Set Up Two Windows Server Member VMs

The application role needs its own virtual machine. The future database role needs a separate identity on the same trusted lab network.

You'll match the domain controllers' network in VMware Workstation Pro 26H1 before creating both member servers. Windows PowerShell will give each server a stable address before you join it to Active Directory.

In this step, get ready to:

Verify the virtualization tools before recording the existing lab network.
Create two Windows Server member virtual machines with matching hardware.
Configure static networking before joining both servers to the domain.

Verify the tools and map the lab network

Your new servers must use the same VMware network as the working domain controllers. Recording that configuration first prevents the virtual machines from landing on an isolated network.

Press the Windows key on your host computer to open search.
Type VMware Workstation into the search box.
Press Enter to start Workstation Pro.
Use the product's About window to identify the installed release family.

✔️ I see version 26H1 or higher

Good. VMware Workstation Pro is ready to create the two member servers.

ⓧ I see an older version

The project uses features and labels from the 26H1 release family. Upgrade your installed copy before creating the virtual machines.

Download the current Windows installer from the official VMware Workstation Pro documentation.
Double-click the downloaded installer on your Windows host.
Follow the installer prompts to upgrade Workstation Pro.
Restart the host if the installer requests it.
Start Workstation Pro again after the upgrade completes.

ⓧ Workstation Pro is not installed

Workstation Pro 26H1 is available without a license key. The Windows release is a 64-bit application.

Download the Windows installer from the official VMware Workstation Pro documentation.
Sign in to the Windows host with an account that has local administrator rights.
Double-click the downloaded installer.
Follow the installer prompts to complete the installation.
Restart the host if the installer requests it.
Start Workstation Pro after the installation completes.

Having trouble with Workstation Pro?

Confirm that you downloaded the 64-bit Windows installer for the 26H1 release family. Run the installer from an account with local administrator rights.

If setup still fails, ask for help with the installer message.

The guest installations also need the official Windows Server 2025 Evaluation ISO. Workstation Pro uses this file as the virtual installation disc for each server.

Confirm that the Windows Server 2025 Evaluation ISO is available on your host computer.
Download the Windows Server 2025 | 64-bit ISO from the Microsoft Evaluation Center if the file is missing.
Record the ISO location as path to your Windows Server 2025 ISO.

Why use the evaluation ISO?

The Microsoft evaluation ISO contains Standard and Datacenter editions. It also offers Server with Desktop Experience for the graphical environment used in this project.

The evaluation expires after 180 days. It must be activated over the internet within 10 days to avoid automatic shutdown.

The domain controllers provide the working reference for both VMware placement and Windows networking. Copying their network shape keeps the new member servers on the path to the domain.

Select one existing domain controller in the Workstation Pro Library.
Click VM in the top menu bar.
Select Settings.
Open the Hardware tab.
Select the virtual network adapter.
Record the displayed connection type or VMnet as your domain controllers' VMware network.

Switch to the selected domain controller's console.
Sign in with an administrative account.
Start an elevated Windows PowerShell session.
Display the domain controller's current network configuration by running:

Get-NetIPConfiguration

What does this command show?

The command displays each network interface plus its current IPv4 settings. The active interface gives you the prefix length and gateway used by the working server subnet.

Its DNS server list identifies the domain controllers that the new member servers must query. Domain DNS is what allows the join process to locate cloudseam.tech.

Record the active interface's prefix as your subnet prefix length.
Record the gateway as your default gateway if one is listed.
Record the first domain-controller DNS address as your first domain-controller DNS address.
Record the second domain-controller DNS address as your second domain-controller DNS address.
Check the second domain controller's network configuration if only one DNS address appears.

Choose an unused address from the same server subnet for APP01.
Record it as your unused APP01 address.
Choose a different unused address from the same server subnet for DB01.
Record it as your unused DB01 address.

Protect the address plan

Use addresses that your lab documentation or DHCP exclusions confirm are free. A static address that overlaps a lease can make a server disappear from the network without warning.

Create APP01 and DB01

Each role gets a fresh operating-system installation. The matching hardware keeps later performance comparisons focused on the application and database workloads.

Return to the Workstation Pro window on your host.
Click File in the top menu bar.
Select New Virtual Machine.
Select Typical as the virtual machine configuration.
Select Use an ISO image as the installation source.
Browse to path to your Windows Server 2025 ISO.
Set the virtual machine name to APP01.

Why use a fresh installation?

Two fresh installations avoid copied machine identities. They also keep each server's operating-system history independent before the application and database roles diverge.

Set the virtual disk capacity to 60 GB.
Click Customize Hardware.
Set the virtual machine memory to 4 GB.
Set the processor allocation to 2 virtual CPUs.
Set the network adapter to your domain controllers' VMware network.
Close the hardware customization window.
Finish the wizard to create APP01.

You should now see APP01 as a separate virtual machine in the Workstation Pro Library. Its summary should show the configured processor count and memory.

Power on APP01.
Select Server with Desktop Experience during Windows Server setup.
Set a local Administrator password that you can retrieve securely.
Complete the operating-system installation.

The installation can sit quietly while files expand. Several automatic restarts are expected.

Sign in to APP01 with the local Administrator account.
Confirm that you reach the Windows desktop.

That is the first server running. APP01 now has its own Windows installation and virtual hardware boundary.

Return to the Workstation Pro host window.
Start another virtual machine wizard from the File menu.
Select Typical as the virtual machine configuration.
Select Use an ISO image as the installation source.
Browse to path to your Windows Server 2025 ISO.
Set the virtual machine name to DB01.
Set the virtual disk capacity to 60 GB.

Keep the hardware matched

DB01 uses the same processor count and memory as APP01. The only intentional difference at this stage is the server identity.

Click Customize Hardware.
Set the virtual machine memory to 4 GB.
Set the processor allocation to 2 virtual CPUs.
Set the network adapter to your domain controllers' VMware network.
Close the hardware customization window.
Finish the wizard to create DB01.
Power on DB01.
Select Server with Desktop Experience during Windows Server setup.

Set a local Administrator password that you can retrieve securely.
Complete the operating-system installation.
Sign in to DB01 with the local Administrator account.
Confirm that you reach the Windows desktop.

VMware Tools improves how Workstation Pro manages the Windows guest. Easy Install normally adds it after the operating system finishes.

Select APP01 in the Workstation Pro Library.
Open the VM menu.
Select Install VMware Tools if that option is available.
Switch to the APP01 desktop.
Open File Explorer if the installer does not start automatically.
Double-click D:\setup64.exe if autorun did not start the installer.
Follow the VMware Tools installer prompts.
Restart APP01 when requested.

Repeat the VMware Tools check for DB01.
Select Install VMware Tools from its VM menu if the option is available.
Run D:\setup64.exe inside DB01 if autorun does not begin.
Follow the VMware Tools installer prompts.
Restart DB01 when requested.
Confirm that Workstation Pro reports VMware Tools running for each VM.

VMware Tools not installing?

Confirm that the selected virtual machine is powered on before using Install VMware Tools. The action mounts a Tools ISO in the guest's virtual CD drive.

If the installer does not appear, check the guest's CD drive for setup64.exe. Restart the guest after installation finishes.

If the installer still fails, ask for help with VMware Tools.

Configure networking and join the domain

A domain join depends on reliable DNS. Each member server will use a fixed address plus both domain controllers as its DNS servers before it contacts the domain.

Configure APP01 first. Its successful join gives you a working pattern for DB01.

Switch back to the signed-in APP01 desktop.
Start an elevated Windows PowerShell session.
Inspect APP01's active network interface by running:

Get-NetIPConfiguration

What should you identify?

Find the interface connected to the same VMware network as the domain controllers. Its interface index tells the networking commands which virtual adapter to configure.

Record the active interface index as APP01 interface index.
Choose the tab that matches whether your working domain-controller configuration listed a gateway.

Gateway is present

Apply APP01's static IPv4 settings by running:

New-NetIPAddress -InterfaceIndex [[APP01_INTERFACE_INDEX="APP01 interface index"]] -IPAddress [[APP01_IP="your unused APP01 address"]] -PrefixLength [[PREFIX_LENGTH="your subnet prefix length"]] -DefaultGateway [[DEFAULT_GATEWAY="your default gateway"]]
Set-DnsClientServerAddress -InterfaceIndex [[APP01_INTERFACE_INDEX="APP01 interface index"]] -ServerAddresses ("[[DC1_DNS="your first domain-controller DNS address"]]","[[DC2_DNS="your second domain-controller DNS address"]]")
Get-NetIPConfiguration

What do these commands do?

The first command disables DHCP on the selected interface by assigning APP01's static address.
The second command points APP01 at both domain-controller DNS servers.
The final command displays the resulting configuration for comparison.

You should see APP01's selected IPv4 address plus the recorded gateway. Both domain-controller DNS addresses should appear for the active interface.

APP01 network settings rejected?

Check that the interface index belongs to the connected Ethernet adapter. Confirm that APP01's address is unused inside the recorded subnet.

The gateway must belong to the same subnet as APP01's address. Ask for help checking the APP01 network values.

No gateway is present

Apply APP01's static IPv4 settings without a default gateway by running:

New-NetIPAddress -InterfaceIndex [[APP01_INTERFACE_INDEX="APP01 interface index"]] -IPAddress [[APP01_IP="your unused APP01 address"]] -PrefixLength [[PREFIX_LENGTH="your subnet prefix length"]]
Set-DnsClientServerAddress -InterfaceIndex [[APP01_INTERFACE_INDEX="APP01 interface index"]] -ServerAddresses ("[[DC1_DNS="your first domain-controller DNS address"]]","[[DC2_DNS="your second domain-controller DNS address"]]")
Get-NetIPConfiguration

What do these commands do?

The first command assigns APP01's static address without creating a default route.
The second command points APP01 at both domain-controller DNS servers.
The final command displays the resulting configuration for comparison.

You should see APP01's selected IPv4 address without a default gateway. Both domain-controller DNS addresses should appear for the active interface.

APP01 network settings rejected?

Check that the interface index belongs to the connected Ethernet adapter. Confirm that APP01's address is unused inside the recorded subnet.

Compare the prefix length with the working domain controller. Ask for help checking the APP01 network values.

The next command opens a secure credential prompt. Your domain administrator password stays out of the command history.

Authenticate with your domain administrator credentials when the secure prompt appears.
Rename APP01 before joining it to the domain by running:

Rename-Computer -NewName "APP01" -Force
Add-Computer -DomainName "cloudseam.tech" -Credential (Get-Credential) -Options "JoinWithNewName","AccountCreate" -Restart

What happens during the join?

The first command stages the computer name APP01. The second command creates the corresponding computer account while joining cloudseam.tech.

The restart activates the new computer name and domain membership in one cycle. This avoids an extra reboot between the rename and join.

Wait for APP01 to restart.
Sign in to APP01 with your domain administrator credentials.
Confirm that the Windows desktop loads.

APP01 did not join the domain?

Confirm that APP01 lists both domain controllers as DNS servers. Domain membership fails when the server sends the lookup to a public DNS service.

Check that the domain administrator credentials are valid. Ask for help diagnosing the domain join.

APP01 now provides a proven network pattern. Apply the same pattern to DB01 with its own address and interface index.

Switch back to the signed-in DB01 desktop.
Start an elevated Windows PowerShell session.
Inspect DB01's active network interface by running:

Get-NetIPConfiguration

What should you identify?

Find the interface connected to the copied VMware network. DB01 can have a different interface index from APP01 even though the virtual hardware matches.

Record the active interface index as DB01 interface index.
Choose the same gateway scenario that matched APP01.

Gateway is present

Apply DB01's static IPv4 settings by running:

New-NetIPAddress -InterfaceIndex [[DB01_INTERFACE_INDEX="DB01 interface index"]] -IPAddress [[DB01_IP="your unused DB01 address"]] -PrefixLength [[PREFIX_LENGTH="your subnet prefix length"]] -DefaultGateway [[DEFAULT_GATEWAY="your default gateway"]]
Set-DnsClientServerAddress -InterfaceIndex [[DB01_INTERFACE_INDEX="DB01 interface index"]] -ServerAddresses ("[[DC1_DNS="your first domain-controller DNS address"]]","[[DC2_DNS="your second domain-controller DNS address"]]")
Get-NetIPConfiguration

What do these commands do?

The first command assigns DB01's selected static address and the lab gateway.
The second command gives DB01 the same domain DNS path as APP01.
The final command displays the resulting configuration for comparison.

You should see DB01's selected IPv4 address plus the recorded gateway. Both domain-controller DNS addresses should appear for the active interface.

DB01 network settings rejected?

Confirm that you used DB01's interface index and DB01's selected address. Reusing APP01's address creates an address conflict.

Compare the prefix and gateway with APP01. Ask for help checking the DB01 network values.

No gateway is present

Apply DB01's static IPv4 settings without a default gateway by running:

New-NetIPAddress -InterfaceIndex [[DB01_INTERFACE_INDEX="DB01 interface index"]] -IPAddress [[DB01_IP="your unused DB01 address"]] -PrefixLength [[PREFIX_LENGTH="your subnet prefix length"]]
Set-DnsClientServerAddress -InterfaceIndex [[DB01_INTERFACE_INDEX="DB01 interface index"]] -ServerAddresses ("[[DC1_DNS="your first domain-controller DNS address"]]","[[DC2_DNS="your second domain-controller DNS address"]]")
Get-NetIPConfiguration

What do these commands do?

The first command assigns DB01's static address without creating a default route.
The second command gives DB01 the same domain DNS path as APP01.
The final command displays the resulting configuration for comparison.

You should see DB01's selected IPv4 address without a default gateway. Both domain-controller DNS addresses should appear for the active interface.

DB01 network settings rejected?

Confirm that you used DB01's interface index and DB01's selected address. Reusing APP01's address creates an address conflict.

Compare the prefix length with APP01. Ask for help checking the DB01 network values.

DB01 uses another secure credential prompt for the domain join. The prompt keeps your domain password out of PowerShell history.

Authenticate with your domain administrator credentials when the secure prompt appears.
Rename DB01 before joining it to the domain by running:

Rename-Computer -NewName "DB01" -Force
Add-Computer -DomainName "cloudseam.tech" -Credential (Get-Credential) -Options "JoinWithNewName","AccountCreate" -Restart

What happens during the join?

The first command stages the computer name DB01. The second command creates DB01's computer account while joining cloudseam.tech.

The automatic restart applies both identity changes. DB01 remains a clean member server without a database engine.

Wait for DB01 to restart.
Sign in to DB01 with your domain administrator credentials.
Confirm that the Windows desktop loads.

DB01 did not join the domain?

Confirm that DB01 lists both domain controllers as DNS servers. Compare its VMware network with APP01 if the domain remains unreachable.

Check that the domain administrator credentials are valid. Ask for help diagnosing the DB01 join.

Before you check both servers, do you expect their computer names to differ while the Domain value matches?

Switch to Server Manager on the APP01 desktop.
Select Local Server.
Confirm that the computer name is APP01.
Confirm that the Domain value is cloudseam.tech.
Switch to the DB01 desktop.
Select Local Server in Server Manager.
Confirm that the computer name is DB01.
Confirm that the Domain value is cloudseam.tech.

You now have two distinct member servers on the trusted lab network. Both can authenticate through the existing domain.

Your application and database tiers now have separate Windows foundations. Next, you'll turn APP01 into a visible web tier by putting the first Helpdesk page online.

Put the First Helpdesk Page Online

Your APP01 server is now a domain member on the lab network. DB01 is ready beside it.

A visible local page proves IIS can host content before later service naming enters the path. This keeps the first web-tier test focused on APP01.

In this step, get ready to:

Install the IIS Web Server role on APP01.
Publish the Helpdesk foundation page through IIS.
Scope inbound HTTP access to the local subnet.

Install IIS on APP01

The IIS Web Server role gives APP01 the software needed to answer HTTP requests. Its management tools let you configure the service in later steps.

Switch back to APP01 in VMware Workstation Pro.
Press the Windows key to open search.
Type Windows PowerShell in the search field.
Right-click Windows PowerShell in the search results.
Select the option that opens Windows PowerShell with administrator privileges.
Approve the permission prompt if Windows displays one.
Install the Web Server role plus its management tools by running this command:

Install-WindowsFeature Web-Server -IncludeManagementTools

What does this command do?

The Web-Server feature installs the IIS components that receive web requests.
The -IncludeManagementTools option adds the tools needed to manage IIS.
Running the command in an elevated Windows PowerShell session gives the installation permission to change server roles.

Wait for the installation command to finish.

You should see a result reporting that the installation succeeded. The IIS role is now ready to serve content from APP01.

IIS installation not succeeding?

Confirm that the Windows PowerShell title bar indicates administrator privileges. Close the session if it does not.

Return to Windows search if needed. Open Windows PowerShell with the administrator option before running the command again.

Help me troubleshoot the IIS role installation on APP01.

Build the Helpdesk foundation page

The HTML gives your page its visible structure. The CSS turns that structure into a status card you can recognize immediately.

Minimize the elevated Windows PowerShell session from earlier.
Press the Windows key to open search.
Type Notepad in the search field.
Right-click Notepad in the search results.
Select the option that opens Notepad with administrator privileges.
Approve the permission prompt if Windows displays one.
Create the first runnable version of the Helpdesk page by pasting this markup into Notepad:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>CloudSeam Helpdesk Foundation</title>
</head>
<body>
  <main>
    <span class="status">ONLINE</span>
    <h1>CloudSeam Helpdesk Foundation</h1>
    <p>The web tier is ready for the application and database integration projects.</p>
    <dl>
      <dt>Web tier</dt>
      <dd>APP01</dd>
      <dt>Database tier</dt>
      <dd>DB01 reserved</dd>
      <dt>Domain</dt>
      <dd>cloudseam.tech</dd>
      <dt>Service name</dt>
      <dd>helpdesk.cloudseam.tech</dd>
    </dl>
  </main>
</body>
</html>

What does this markup do?

The document title identifies the page as the CloudSeam Helpdesk foundation.
The main element groups the visible status content into one section.
The description list pairs each infrastructure role with its current value.
The page identifies APP01 as the web tier. It reserves DB01 for the database tier.

Select File in Notepad.
Select Save As.
Enter C:\inetpub\wwwroot\index.html in the File name box.
Set Save as type to All files (*.*).
Select Save.
Select the web browser icon on APP01's taskbar.
Enter http://localhost/index.html in the browser address bar.
Load the page.

You should see the Helpdesk heading with an online status. You should also see the web tier, reserved database tier, domain, and service name.

Still seeing the default IIS page?

Confirm that the browser address ends with /index.html. The default IIS page can still appear at the site root.

Check that Notepad saved the file as index.html. A file named index.html.txt does not replace the web page.

Help me find why IIS is not serving my index.html file.

The page now proves that IIS can read your file. Styling the outer document next gives the page a dark background with a centered layout.

Return to Notepad.
Find the </head> line.
Add the page-level styles directly above that line by pasting this code:

  <style>
    :root {
      color-scheme: dark;
      font-family: "Segoe UI", Arial, sans-serif;
    }

    body {
      min-height: 100vh;
      margin: 0;
      display: grid;
      place-items: center;
      background: #08111f;
      color: #eaf2ff;
    }

  </style>

What do these styles change?

The :root selector gives the page a dark color scheme plus the Segoe UI font stack.
The body selector fills the browser height with a dark background.
The grid layout places the page content in the center of the browser.

Save C:\inetpub\wwwroot\index.html.
Return to the browser from earlier.
Refresh the page.

You should see the content centered on a dark blue background. The text should now use a light color.

Page still using a white background?

Confirm that the <style> block sits inside the <head> section. Check that every opening brace has a matching closing brace.

Help me debug the page-level CSS in my Helpdesk page.

The centered content still needs a clear boundary. A card gives the service status its own visual surface.

Return to Notepad.
Find the closing </style> line.
Add the card styles directly above that line by pasting this code:

    main {
      width: min(680px, calc(100% - 48px));
      padding: 32px;
      border: 1px solid #2b4a72;
      border-radius: 16px;
      background: #10223b;
      box-shadow: 0 20px 50px rgba(0, 0, 0, 0.35);
    }

What does the card style do?

The responsive width keeps the card inside narrow browser windows.
The padding creates space between the content and the card edge.
The border, background, rounded corners, and shadow separate the status card from the page.

Save C:\inetpub\wwwroot\index.html.
Return to the browser.
Refresh the page.

You should see the Helpdesk content inside a rounded blue card. A soft shadow should appear behind it.

Card not appearing?

Confirm that the main selector sits before </style>. Check that its closing brace appears after the shadow property.

Help me debug the main card styles in my Helpdesk page.

The status word is the fastest signal on the page. A pill treatment makes that state stand out from the infrastructure details.

Return to Notepad.
Find the closing </style> line.
Add the online-status styles directly above that line by pasting this code:

    .status {
      display: inline-block;
      padding: 6px 10px;
      border-radius: 999px;
      background: #123d2b;
      color: #8df0b7;
      font-weight: 700;
    }

What does the status style do?

The inline-block display keeps the background close to the status text.
The large border radius produces the pill shape.
The green background plus light text makes the online state easy to spot.

Save C:\inetpub\wwwroot\index.html.
Return to the browser.
Refresh the page.

You should see ONLINE inside a rounded green status pill near the top of the card.

Status pill missing?

Confirm that the markup uses class="status". Check that the CSS selector includes the leading period in .status.

Help me debug the status pill in my Helpdesk page.

The final styles organize the heading plus infrastructure details. The two-column layout makes each role easy to match with its value.

Return to Notepad.
Find the closing </style> line.
Add the detail-layout styles directly above that line by pasting this code:

    h1 {
      margin-bottom: 8px;
    }

    dl {
      display: grid;
      grid-template-columns: 130px 1fr;
      gap: 12px;
      margin-top: 28px;
    }

    dt {
      color: #9ab6d9;
    }

    dd {
      margin: 0;
      font-weight: 600;
    }

What do these detail styles do?

The heading margin keeps the introductory sentence close to its title.
The description list uses a two-column grid for labels plus values.
The muted labels separate categories from their heavier values.

Save C:\inetpub\wwwroot\index.html.
Return to the browser.
Refresh the page.

You should see the server details arranged in two columns. Each value should align with its matching label.

Details not lining up?

Confirm that the dl selector uses a grid. Check that every dt label is followed by one dd value.

Help me debug the description-list layout in my Helpdesk page.

✔️ Awesome, I've got everything!

Great. Confirm that C:\inetpub\wwwroot\index.html is saved before you continue.

ⓧ I'd like to double check the full code

Compare your complete C:\inetpub\wwwroot\index.html file with this version:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>CloudSeam Helpdesk Foundation</title>
  <style>
    :root {
      color-scheme: dark;
      font-family: "Segoe UI", Arial, sans-serif;
    }

    body {
      min-height: 100vh;
      margin: 0;
      display: grid;
      place-items: center;
      background: #08111f;
      color: #eaf2ff;
    }

    main {
      width: min(680px, calc(100% - 48px));
      padding: 32px;
      border: 1px solid #2b4a72;
      border-radius: 16px;
      background: #10223b;
      box-shadow: 0 20px 50px rgba(0, 0, 0, 0.35);
    }

    .status {
      display: inline-block;
      padding: 6px 10px;
      border-radius: 999px;
      background: #123d2b;
      color: #8df0b7;
      font-weight: 700;
    }

    h1 {
      margin-bottom: 8px;
    }

    dl {
      display: grid;
      grid-template-columns: 130px 1fr;
      gap: 12px;
      margin-top: 28px;
    }

    dt {
      color: #9ab6d9;
    }

    dd {
      margin: 0;
      font-weight: 600;
    }
  </style>
</head>
<body>
  <main>
    <span class="status">ONLINE</span>
    <h1>CloudSeam Helpdesk Foundation</h1>
    <p>The web tier is ready for the application and database integration projects.</p>
    <dl>
      <dt>Web tier</dt>
      <dd>APP01</dd>
      <dt>Database tier</dt>
      <dd>DB01 reserved</dd>
      <dt>Domain</dt>
      <dd>cloudseam.tech</dd>
      <dt>Service name</dt>
      <dd>helpdesk.cloudseam.tech</dd>
    </dl>
  </main>
</body>
</html>

Allow local-subnet HTTP traffic

The local page proves that IIS works inside APP01. A scoped Windows Defender Firewall rule prepares the server to accept HTTP requests from the trusted lab subnet.

Return to the elevated Windows PowerShell session from earlier.
Create the scoped inbound HTTP rule by running this command:

New-NetFirewallRule -Name "CloudSeam-Helpdesk-HTTP-In" -DisplayName "CloudSeam Helpdesk HTTP from Local Subnet" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 80 -RemoteAddress LocalSubnet -Profile Domain

How is this rule scoped?

The rule allows inbound TCP traffic on port 80.
The LocalSubnet source limits access to the local subnet.
The Domain profile limits the rule to the trusted domain network profile.
The stable rule name makes the configuration easy to retrieve later.

Confirm that the firewall rule exists by running this command:

Get-NetFirewallRule -Name "CloudSeam-Helpdesk-HTTP-In"

What does this check prove?

The command retrieves the rule through its stable internal name. Seeing the matching rule confirms that Windows Defender Firewall stored the configuration.

You should see the CloudSeam Helpdesk HTTP rule in the command output. Its state should show that the rule is enabled.

Firewall rule not appearing?

Confirm that you created the rule in an elevated Windows PowerShell session. A standard session cannot make this firewall change.

Check that the rule name uses the exact spelling CloudSeam-Helpdesk-HTTP-In in both commands.

Help me troubleshoot the scoped HTTP firewall rule on APP01.

Before you refresh the page, do you expect the new inbound rule to change what localhost displays?

Return to the browser on APP01.
Confirm that the address is http://localhost/index.html.
Refresh the page.

You should still see CloudSeam Helpdesk Foundation with APP01 shown as the web tier. The local page remains available while the firewall rule prepares port 80 for scoped subnet traffic.

That is your first visible win: APP01 is serving the Helpdesk foundation page through IIS.

Your web tier now has visible content plus a scoped HTTP path. Next, you will give the Helpdesk service its own application pool and friendly host binding.

Add the Service Binding and Test DNS

Your Helpdesk page already loads locally on APP01 through IIS. The next goal is to give that site its own application pool boundary plus a service-specific host-header binding.

A friendly service name depends on cooperation between IIS and DNS. You will test whether the web configuration alone makes the name reachable from DB01.

In this step, get ready to:

Create a dedicated Helpdesk application pool on APP01.
Configure Default Web Site for the Helpdesk service name.
Test the service name from DB01.

Create the Helpdesk application pool

An application pool gives a site its own worker-process boundary. HelpdeskAppPool prepares the Helpdesk site for its future application settings.

Switch to APP01 in VMware Workstation Pro.
Return to the elevated Windows PowerShell session from the previous step.
Import the IIS administration module and create the application pool by running these commands:

Import-Module "WebAdministration"
New-WebAppPool -Name "HelpdeskAppPool"

What Do These Commands Do?

The Import-Module command loads the IIS administration commands into the current PowerShell session.
The New-WebAppPool command creates the dedicated HelpdeskAppPool worker-process boundary.
The dedicated pool lets future Helpdesk code use its own runtime settings.

Confirm the PowerShell result includes HelpdeskAppPool.

Good progress. HelpdeskAppPool is ready to host the site.

Application Pool Not Created?

Confirm the IIS management tools finished installing if the WebAdministration module does not import.
Keep the existing HelpdeskAppPool if PowerShell reports that the pool name already exists.

Ask for help with the exact output you see: Help me troubleshoot why HelpdeskAppPool was not created in IIS on APP01.

Configure the site for the Helpdesk name

Default Web Site needs to run through the new application pool. The host-header binding tells IIS which site should handle requests addressed to helpdesk.cloudseam.tech.

Assign Default Web Site to the Helpdesk pool and add its host-header binding by running these commands:

Set-ItemProperty "IIS:\Sites\Default Web Site" -Name applicationPool -Value "HelpdeskAppPool"
New-WebBinding -Name "Default Web Site" -IPAddress "*" -Port 80 -HostHeader "helpdesk.cloudseam.tech"

How Does the Site Configuration Work?

The Set-ItemProperty command assigns Default Web Site to HelpdeskAppPool.
The New-WebBinding command adds an HTTP binding on port 80 for helpdesk.cloudseam.tech.
The wildcard IP setting lets IIS accept the service name through any IP address assigned to APP01.

Switch back to the browser you used on APP01.
Select the browser address bar.
Enter http://localhost/index.html.
Press Enter.

You should still see CloudSeam Helpdesk Foundation with APP01 listed as the web tier.

Local Page Not Loading?

Compare the application-pool name in the Set-ItemProperty command with HelpdeskAppPool.
Confirm the New-WebBinding command uses helpdesk.cloudseam.tech.

Ask for help with the PowerShell output or browser behavior: Help me diagnose why the IIS page stopped loading after I assigned HelpdeskAppPool and added the host-header binding.

Test the service name from DB01

The Resolve-DnsName command asks DB01's configured DNS servers for the service address. The -DnsOnly option prevents other name-resolution methods from masking the result.

Switch to DB01 in VMware Workstation Pro.
Press the Windows key to open the search bar.
Type Windows PowerShell.
Press Enter.

Before you run the query, do you think the IIS binding has made the service name resolvable?

Query the Helpdesk A record using DNS only by running this command:

Resolve-DnsName -Name helpdesk.cloudseam.tech -Type A -DnsOnly

The DNS Gap Is Now Visible

You will see a name-resolution failure. This is the intended shortfall.

The web server is ready for the host name. Domain DNS has no A record for it yet.

Keep the failed query visible in Windows PowerShell.

Switch back to APP01 in VMware Workstation Pro.
Switch back to the browser on APP01.
Select the browser address bar.
Enter http://localhost/index.html.
Press Enter.

You should still see the Helpdesk foundation page served by APP01. This confirms that IIS remains healthy while the friendly name waits for DNS.

You have isolated the missing layer without disturbing the working web page. Next, you will publish the Helpdesk name in DNS and test the complete path from DB01.

Publish the Helpdesk Name in DNS

Your IIS binding now recognizes helpdesk.cloudseam.tech. DB01 still has no address for that name.

The failed lookup exposed the boundary between IIS and Windows Server DNS. You'll publish an A record that maps the Helpdesk service name to APP01.

In this step, get ready to:

Create the Helpdesk A record on the DNS server that DB01 uses first.
Verify that DB01 resolves the service name to APP01.
Open the Helpdesk page from DB01 through its service URL.

Create the Helpdesk A record

The A record gives helpdesk.cloudseam.tech a destination inside the existing cloudseam.tech zone. DB01 can then ask its usual DNS server for APP01's address.

You are adding one scoped host record to the existing zone. No domain controller settings or existing records are changed.

Switch to the console of the domain controller whose address appears first in DB01's recorded DNS server list.
Sign in with your domain administrator credentials.
Press the Windows key to open Windows search.
Type Windows PowerShell into the search field.
Use the administrator launch option for the Windows PowerShell search result.
Approve the permission prompt if Windows displays one.
Replace <APP01-IP> in the command below with the static address recorded for APP01.
Create the DNS record by running the completed command:

Add-DnsServerResourceRecordA -Name "helpdesk" -ZoneName "cloudseam.tech" -IPv4Address "<APP01-IP>" -TimeToLive 01:00:00

What does this command do?

The -Name "helpdesk" value creates the service label inside the zone.
The -ZoneName "cloudseam.tech" value places the record in your existing domain zone.
The -IPv4Address value points the service name to APP01's static address.
The -TimeToLive 01:00:00 value gives the record a one-hour lifetime in DNS caches.

When the command completes successfully, Windows PowerShell returns control to the prompt. The new record is ready for a client-side query.

Record creation not completing?

Confirm that the Windows PowerShell window has administrator privileges.
Check that your account has permission to manage the existing DNS zone.
Confirm that <APP01-IP> was replaced with APP01's actual IPv4 address.

Get help with the command by sharing the non-sensitive failure details with AI support.

Resolve the name from DB01

A published record matters when the intended client can retrieve it. DB01 is the right test point because it represents the future database tier crossing the network to APP01.

Return to the Windows PowerShell session on DB01 from the previous step.

Before you run the query, pause and decide which address you expect the service name to return.

Query the new A record through DNS by running:

Resolve-DnsName -Name helpdesk.cloudseam.tech -Type A -DnsOnly

What does this query check?

The -Name helpdesk.cloudseam.tech value requests the complete Helpdesk service name.
The -Type A value limits the query to the IPv4 host record.
The -DnsOnly option prevents other name-resolution methods from hiding a DNS problem.

You should see helpdesk.cloudseam.tech resolve to the actual address recorded as APP01-IP. Your friendly service name now has a network destination that DB01 can retrieve.

Name still not resolving?

Confirm that you created the record on the domain controller listed first in DB01's DNS configuration.
Check that the record name is helpdesk.
Check that the zone name is cloudseam.tech.

Ask for guided DNS troubleshooting with AI support.

Open the Helpdesk page from DB01

The DNS query proves that DB01 can find APP01. A browser request tests the rest of the path through the HTTP firewall rule and the IIS host-header binding.

Before you load the URL, pause and decide whether every layer in the request path is ready.

Use Windows search on DB01 to launch its installed web browser.
Enter http://helpdesk.cloudseam.tech/index.html in the browser's address bar.
Press Enter to load the page.

You should see the CloudSeam Helpdesk Foundation heading. The page should identify APP01 as the web tier.

You now have the complete tier path working from DB01 to the Helpdesk page on APP01.

What did this browser test prove?

DNS resolution maps the friendly service name to APP01.
The Windows Defender Firewall rule admits HTTP traffic from the local subnet on the Domain profile.
The IIS host-header binding accepts the request for helpdesk.cloudseam.tech.
The Helpdesk page returns across the future application-to-database tier boundary.

Page not loading from DB01?

Confirm that the DNS query from the previous substep still returns APP01-IP.
Return to APP01 to confirm that the existing IIS binding uses helpdesk.cloudseam.tech on port 80.
Confirm that the existing firewall rule remains enabled for the Domain profile and LocalSubnet.

Work through the request path with AI support.

The Helpdesk name now reaches APP01 from DB01 through the complete web path. Next up, you'll capture snapshots of both VMs before the database layer changes them.

Capture the Working Baseline

The Helpdesk page now crosses the future tier boundary from DB01 to APP01. The next project adds a database engine plus service identities to this working foundation.

A VMware Workstation Pro snapshot gives each VM a known-good rollback point before those higher-risk changes. In this step, you capture both member servers while they are idle.

In this step, get ready to:

Prepare APP01 plus DB01 for consistent snapshots.
Capture a named snapshot of each member server.
Confirm both snapshots in Snapshot Manager without reverting either VM.

Prepare both VMs for capture

A quiet VM gives the snapshot a clear baseline state. Finish any active work before Workstation Pro captures the machines.

What Does a Snapshot Protect?

A snapshot captures the VM state that Workstation Pro needs for rollback. Reverting restores that captured state.

Save any open file on the APP01 desktop from earlier.
Close any active installer window on APP01.
Confirm APP01 shows no update task or file-copy task in progress.
Switch back to the DB01 desktop from earlier.
Save any open file on DB01.
Close any active installer window on DB01.
Confirm DB01 shows no update task or file-copy task in progress.
Return to VMware Workstation Pro from earlier.

Both member servers are now idle. Their working service state is ready to capture.

Capture the two snapshots

Each VM needs its own snapshot because Workstation Pro stores each machine as a separate virtual system. Matching names make the two rollback points easy to identify as one baseline.

Select APP01 in the Workstation Pro VM list.
Click VM in the Workstation Pro menu bar.
Select Snapshot.
Select Take Snapshot.

Workstation Pro now asks for the details that identify the APP01 rollback point.

Enter Two-tier foundation complete as the snapshot name.
Enter domain-joined state with the Helpdesk DNS and IIS path working. as the snapshot description.
Click Take Snapshot.
Wait for Workstation Pro to finish the APP01 snapshot operation.

The application server now has a rollback point for the working Helpdesk path.

The database server needs a separate capture. Its snapshot preserves the clean member-server state before a database engine is installed.

Select DB01 in the Workstation Pro VM list.
Click VM in the Workstation Pro menu bar.
Select Snapshot.
Select Take Snapshot.

Workstation Pro now asks for the details that identify the DB01 rollback point.

Enter Two-tier foundation complete as the snapshot name.
Enter domain-joined state with the Helpdesk DNS and IIS path working. as the snapshot description.
Click Take Snapshot.
Wait for Workstation Pro to finish the DB01 snapshot operation.

You now have matching captures for both sides of the two-tier foundation.

Snapshot Option Unavailable?

Confirm the intended VM is selected before opening the VM menu.
Finish any active Workstation Pro task before retrying the snapshot.

Ask for help with the state shown in Workstation Pro: Help me troubleshoot why I cannot capture this VMware Workstation Pro snapshot.

Verify both snapshot trees

Snapshot Manager also holds controls that can roll a VM back to a captured state. This check only inspects each snapshot tree.

Predict whether the same snapshot name appears in both VM trees.
Select APP01 in Workstation Pro.
Click VM in the menu bar.
Select Snapshot.
Select Snapshot Manager.

You should see Two-tier foundation complete in the APP01 snapshot tree.

Select DB01 in Workstation Pro.
Click VM in the menu bar.
Select Snapshot.
Select Snapshot Manager.

You should see Two-tier foundation complete in the DB01 snapshot tree. Both VMs remain in their current states because you only inspected the trees.

That is the safety net in place. Both servers now have a recoverable baseline for the database work that follows.

Secret mission

Add a Second Service Alias

Give the Helpdesk a second friendly address while keeping its existing page and primary A record. You will coordinate a DNS CNAME with a matching IIS binding, then prove the alias works from DB01.

Clean Up Your Resources

Choose whether to keep this lab available, pause it for later, or remove it completely. The software path costs $0.

Evaluation Time Limits

Windows Server 2025 Evaluation must be activated over the internet within the first 10 days to avoid automatic shutdown. The evaluation expires after 180 days.

Run Windows Update on both member servers to install the latest servicing package before you use this foundation in later projects.

Resources you used:

Two Windows Server 2025 virtual machines named APP01 and DB01 in VMware Workstation Pro 26H1, each with a growing 60 GB virtual disk.
Two Active Directory computer accounts named APP01 and DB01 in cloudseam.tech.
An IIS website on APP01 with C:\inetpub\wwwroot\index.html, the HelpdeskAppPool application pool, and host-header bindings for both service names.
A Windows Defender Firewall rule named CloudSeam-Helpdesk-HTTP-In that allows local-subnet HTTP traffic on the Domain profile.
A DNS A record named helpdesk and a CNAME record named support in the cloudseam.tech zone.
A snapshot named Two-tier foundation complete for each VM, which consumes additional host storage as the VMs change.

Keep everything running

No action needed. Choose this if you are continuing directly into the database-engine project.

Leave APP01 and DB01 available in VMware Workstation Pro.
Keep the helpdesk A record and the support CNAME record in the cloudseam.tech DNS zone.
Retain the APP01 and DB01 computer accounts in Active Directory.
Keep both Two-tier foundation complete snapshots as rollback points.

Pause - I'll come back to this later

Shut down the member servers to free host memory while keeping every VM file, service record, computer account, and snapshot intact.

Return to the APP01 desktop from earlier.
Shut down APP01 cleanly from the Windows power menu.
Return to the DB01 desktop from earlier.
Shut down DB01 cleanly from the Windows power menu.
Confirm both VMs show a powered-off state in VMware Workstation Pro.
Leave the DNS records, computer accounts, VM files, and snapshots untouched.
Power on APP01 when you return to the project.
Power on DB01 when you return to the project.

After both servers start, open http://helpdesk.cloudseam.tech/index.html from DB01. You should see the CloudSeam Helpdesk Foundation page again.

Delete - I don't want to use this again

Remove the two member servers plus every service record created for them. This cleanup is permanent.

Protect the Existing Domain Controllers

This cleanup targets only APP01 and DB01. Your two existing domain-controller VMs keep the cloudseam.tech lab available for future projects.

Leave both existing domain-controller VMs in place.

The service records live in DNS outside the member VMs. Remove those records before deleting the VM files.

Return to the DNS server used earlier.
Open the cloudseam.tech forward lookup zone in the DNS management console.
Delete the support CNAME record from the cloudseam.tech zone.
Delete the helpdesk A record from the cloudseam.tech zone.
Confirm neither service record remains in the zone.

The domain also stores a computer account for each member server. Remove both accounts so the directory no longer carries identities for deleted machines.

Return to the domain controller used earlier.
Open the Active Directory computer-account management console from Server Manager.
Locate the computer account named APP01.
Delete the APP01 computer account.
Locate the computer account named DB01.
Delete the DB01 computer account.
Confirm neither computer account remains in Active Directory.

The external records are now clear. Shut down each member server before removing its files.

Return to the APP01 desktop.
Shut down APP01 cleanly from the Windows power menu.
Return to the DB01 desktop.
Shut down DB01 cleanly from the Windows power menu.

The final deletion removes each VM from host storage. The on-disk deletion also removes its snapshot files.

Switch back to VMware Workstation Pro.
Select APP01 in the VM library.
Use the VM management menu to delete APP01 from disk.
Select DB01 in the VM library.
Use the VM management menu to delete DB01 from disk.
Confirm neither VM remains in the VMware Workstation Pro library.

You should no longer see either member VM in VMware Workstation Pro. Their Two-tier foundation complete snapshots should be gone with the deleted VM files.

Nice Work!

Outstanding work! You built a recoverable two-tier foundation in VMware Workstation Pro with two domain-joined Windows Server 2025 member VMs. DB01 now reaches the Helpdesk page on APP01 through the protected Internet Information Services (IIS) path.

You've learned how to:

Provisioned APP01 and DB01 as separate member servers on the trusted lab network. Joined both servers to cloudseam.tech with static IPv4 settings.
Published a visible Helpdesk page through IIS on APP01. Applied scoped inbound HTTP access to the Domain profile for the local subnet. Kept Windows Defender Firewall enabled.
Exposed the planned DNS gap by testing the friendly service name before its record existed. Added the helpdesk A record to complete the route from DB01. Captured recoverable snapshots named Two-tier foundation complete for both working VMs.
Secret Mission: added support.cloudseam.tech as a DNS CNAME. Matched the alias with a second IIS host-header binding. Confirmed DB01 reaches the same Helpdesk page through the alias.

Ready to quiz yourself?