Azure Infrastructure for Enterprise Telecom

Deploy a Windows Server in Azure and host a secure telecom dashboard over HTTPS.

Introduction

30 Second Summary

Every enterprise network has servers that need to be deployed, secured, and managed remotely. In telecom environments, engineers access cloud infrastructure from their desks to monitor systems, apply certificates, and control who gets access to what.

In this project, you will deploy a Windows Server in Azure, install IIS to host a Telecom System Status Dashboard, secure it with HTTPS using a self-signed certificate, and establish SSH access from your home lab.

What You'll Build

By the end of this project, you can open a browser and see your dashboard served over encrypted HTTPS, then SSH into your cloud server from your home desktop just like an enterprise admin managing remote infrastructure.

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

  • A Windows Server 2022 VM running in Azure with IIS serving a Telecom System Status Dashboard over both HTTP and HTTPS.
  • Network Security Group rules controlling exactly which ports are open and to whom, protecting your server like a real enterprise firewall.
  • Working SSH connectivity from your on-prem home lab to the Azure server for remote command-line management.
  • Secret Mission: Configure Azure Monitor with a CPU usage alert and set up auto-shutdown to save money.

Are there any prerequisites?

You need an Azure account (CloudSeam tenant) and a Windows desktop with an SSH client. You do not need Azure free credits. This project uses pay-as-you-go resources that cost approximately $2-5 total if you delete everything when finished.

Before We Start

Before you dive into deploying infrastructure, take a moment to lock in what you are about to build and why it matters. This project mirrors the kind of work you would do as an enterprise telecom engineer managing remote cloud servers.

Create Azure Resources

Before you can configure a web server or secure anything with certificates, you need the underlying infrastructure. This step builds your "data center" in Azure: a resource group to organize everything, a virtual network to control traffic, and a Windows Server VM to host the services.

By the end of this step you will have a running server in the cloud that you can connect to from your home desktop, just like managing a remote machine in an enterprise environment.

In this step, get ready to:
  • Create a resource group and virtual network in Azure.
  • Deploy a Windows Server 2022 VM with RDP access enabled.
  • Connect to your new VM from your Windows desktop.
Create the resource group and virtual network

A resource group is a container that holds related Azure resources so you can manage them as a unit. A virtual network segments traffic the same way a physical network does in a data center.

  • Open your browser and navigate to portal.azure.com.
  • Sign in with your CloudSeam account credentials.
  • In the search bar at the top of the portal, type Resource groups and select Resource groups from the results.
  • Click + Create.
  • Enter rg-telecom-lab in the Resource group field.
  • Select East US as the Region.
  • Click Review + create.
  • Click Create.

You should see a notification that the resource group was created successfully. You now have an empty container ready to hold your networking and compute resources.

What is a resource group?

Think of a resource group as a labeled folder that holds all the Azure resources for a specific project. When you delete the resource group later, everything inside it gets deleted too. This makes cleanup simple.

  • In the search bar at the top of the portal, type Virtual networks and select Virtual networks from the results.
  • Click + Create.
  • On the Basics tab, select rg-telecom-lab in the Resource group dropdown.
  • Enter vnet-telecom in the Name field.
  • Select East US as the Region.
  • Click Next to proceed to the Security tab.
  • Click Next to proceed to the IP Addresses tab.
  • In the address space box, change the IPv4 address space to 10.10.0.0/16.

What does the /16 mean?

The /16 notation defines how large your network is. A /16 gives you over 65,000 possible IP addresses within the 10.10.x.x range. You will carve a smaller subnet out of this space for your servers.

  • In the Subnets section, select the default subnet to edit it.
  • Change the Name to sn-servers.
  • Set the Starting address to 10.10.1.0.
  • Set the Subnet size to /24 (256 addresses).
  • Click Save.
  • Click Review + create at the bottom of the screen.
  • Once validation passes, click Create.

Wait for the deployment to complete. You should see a "Your deployment is complete" message confirming the virtual network is ready.

Deploy the Windows Server VM

Now you will deploy a virtual machine into the network you just created. This VM will run Windows Server 2022 and host everything else in this project.

  • In the portal search bar, type Virtual machines and select Virtual machines from the results.
  • Click + Create and select Azure virtual machine.
  • On the Basics tab, select rg-telecom-lab as the Resource group.
  • Enter vm-iis-01 in the Virtual machine name field.
  • Select East US as the Region.
  • For Image, select Windows Server 2022 Datacenter: Azure Edition - x64 Gen 2.
  • For Size, select Standard_B2s.
  • Under Administrator account, enter a username you will remember.

Remember your credentials

Write down the username and password you choose. You will need them to connect to this VM via RDP and later via SSH. If you forget them, resetting credentials on an Azure VM requires extra steps.

  • Enter a strong password and confirm it.
  • Under Inbound port rules, choose Allow selected ports.
  • In the Select inbound ports dropdown, select RDP (3389).
  • Click the Networking tab at the top of the page.
  • In the Virtual network dropdown, select vnet-telecom.
  • In the Subnet dropdown, select sn-servers.
  • Leave all other defaults and click Review + create.
  • Review the summary, then click Create.

Deployment takes 2-4 minutes. Wait for the "Your deployment is complete" message.

What about cost?

The Standard_B2s VM size costs approximately $0.05 per hour while running. You will configure auto-shutdown in the Secret Mission to keep costs low. If you delete the resource group at the end, all charges stop immediately.

  • Once deployment finishes, click Go to resource.
  • On the VM overview page, confirm the Status shows Running.
  • Note the Public IP address shown in the overview. You will need it next.
Connect to the VM via RDP

Remote Desktop Protocol (RDP) lets you connect to a Windows machine over the network and see its full desktop, just as if you were sitting in front of it. Enterprise admins use RDP to manage servers without being physically present.

  • On your home Windows desktop, press the Windows key to open your search bar.
  • Type Remote Desktop Connection and press Enter to open it.
  • In the Computer field, paste the public IP address from the VM overview page.
  • Click Connect.

What about the certificate warning?

You will see a warning that the remote computer's identity cannot be verified. This is normal for a brand new server that does not yet have a trusted certificate. Click Yes to continue.

  • Click Yes on the certificate warning.
  • Enter the username and password you created during VM setup.
  • Click OK to log in.

Before the desktop loads, what do you expect to see? You deployed a fresh Windows Server with no customization yet.

You should see the Windows Server 2022 desktop with Server Manager opening automatically. This confirms your Azure VM is running and you have remote access from your home lab.

Can't connect via RDP?

  • Make sure you are using the public IP address from the Azure portal, not the private 10.10.x.x address.
  • Confirm the VM status is Running in the portal. If it says Starting, wait a moment and refresh.
  • Check that the Network Security Group allows RDP (port 3389). Navigate to your VM > Networking > Network Settings and verify an inbound rule for port 3389 exists.

Help me troubleshoot my RDP connection to an Azure VM.

Your cloud infrastructure is live. You have a running Windows Server VM in Azure, segmented in its own virtual network, accessible from your home lab via RDP. Next up, you will install IIS and deploy the Telecom Status Dashboard.

Install IIS and Deploy the Status Dashboard

Your VM is running, but right now it is just an empty Windows Server. To turn it into something useful, you need a web server that can host internal applications.

In enterprise telecom environments, IIS (Internet Information Services) is the web server that hosts internal management portals, status dashboards, and admin tools. In this step, you will install IIS and deploy a Telecom System Status Dashboard so your server has something real to serve.

In this step, get ready to:
  • Install IIS on your Windows Server VM using PowerShell.
  • Deploy a custom Telecom Status Dashboard page to IIS.
  • Verify the dashboard loads in a browser inside the VM.
Install IIS with PowerShell

IIS is a Windows feature that is available on your server but not turned on by default. You enable it with a single PowerShell command.

  • Inside your VM (via the RDP session from Step 1), right-click the Start button.
  • Select Windows PowerShell (Admin).
  • If prompted by User Account Control, click Yes.
  • Install IIS and its management tools by running this command:
Install-WindowsFeature -name Web-Server -IncludeManagementTools

What does this command do?

This installs the IIS web server role on your Windows Server.

  • `Web-Server` is the feature name for IIS in Windows Server.
  • `-IncludeManagementTools` adds the IIS Manager GUI and PowerShell modules you will use later to configure HTTPS.

The command takes about 30-60 seconds. When it finishes, you will see a table showing Success as the exit code and True under the Restart Needed column (but no restart is actually required for IIS).

  • Confirm IIS is running by opening a browser inside the VM and navigating to http://localhost.

You should see the default IIS welcome page with a blue background and the IIS logo.

Don't see the IIS welcome page?

  • Make sure the install command finished with Success before opening the browser.
  • Try typing http://localhost exactly (not just localhost) to avoid the browser defaulting to a search.
  • Run Get-Service W3SVC in PowerShell. The status should show Running.

Still stuck? Help me troubleshoot why IIS isn't responding on localhost after installation.

Replace the default page with your dashboard

IIS is serving a generic welcome page. You will replace it with a Telecom System Status Dashboard that simulates the kind of internal monitoring portal telephony teams use to track system health.

  • In your PowerShell window (still running as Administrator), delete the default IIS page by running:
Remove-Item -Path "C:\inetpub\wwwroot\iisstart.htm"
  • Create a new index.html file and open it in Notepad by running:
notepad C:\inetpub\wwwroot\index.html

Notepad will ask if you want to create a new file. Click Yes.

Now you will paste the dashboard HTML into this file. The content is split into sections below so you can see what each part does. Paste them in order, one after another.

  • Paste the following as the beginning of your file. This sets up the document structure and page-level styles:
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>CloudSeam Telecom - System Status</title>
    <style>
        body {
            font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
            background-color: #1a1a2e;
            color: #e0e0e0;
            margin: 0;
            padding: 20px;
        }
        .header {
            background-color: #16213e;
            padding: 20px;
            border-radius: 8px;
            margin-bottom: 20px;
            border-left: 4px solid #0f3460;
        }
        .header h1 {
            margin: 0;
            color: #4fc3f7;
        }
        .header p {
            margin: 5px 0 0 0;
            color: #90a4ae;
        }

What does this section do?

This creates the HTML skeleton and defines the dark background theme. The .header styles create the top banner area where the dashboard title will appear.

  • Directly below what you just pasted (no blank lines between), continue with the grid and card component styles:
        .grid {
            display: grid;
            grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
            gap: 15px;
        }
        .card {
            background-color: #16213e;
            border-radius: 8px;
            padding: 20px;
            border-left: 4px solid #4caf50;
        }
        .card.warning {
            border-left-color: #ff9800;
        }
        .card.offline {
            border-left-color: #f44336;
        }
        .card h3 {
            margin: 0 0 10px 0;
            color: #ffffff;
        }
        .status {
            display: inline-block;
            padding: 3px 10px;
            border-radius: 12px;
            font-size: 12px;
            font-weight: bold;
        }

What do these styles do?

The .grid creates a responsive card layout. Each .card represents a system component (PBX, recording server, etc.) with color-coded left borders: green for online, orange for warning, red for offline.

  • Continue pasting the status indicator styles and closing style/head tags:
        .status.online {
            background-color: #1b5e20;
            color: #a5d6a7;
        }
        .status.degraded {
            background-color: #e65100;
            color: #ffcc02;
        }
        .status.down {
            background-color: #b71c1c;
            color: #ef9a9a;
        }
        .detail {
            margin-top: 10px;
            font-size: 13px;
            color: #90a4ae;
        }
        .footer {
            margin-top: 20px;
            text-align: center;
            color: #546e7a;
            font-size: 12px;
        }
    </style>
</head>

What are these status classes?

These color the status badges. Green (.online) means healthy, orange (.degraded) means partially working, and red (.down) means offline. This mirrors how real enterprise monitoring dashboards use color to signal urgency at a glance.

  • Now paste the page body. This is the header banner and first three system cards:
<body>
    <div class="header">
        <h1>CloudSeam Telecom - System Status</h1>
        <p>Enterprise Telephony Infrastructure Monitor | Domain: local.cloudseam</p>
    </div>
    <div class="grid">
        <div class="card">
            <h3>PBX Core (Avaya CM)</h3>
            <span class="status online">ONLINE</span>
            <div class="detail">Uptime: 47 days | Active Calls: 142<br>Last Health Check: 2 min ago</div>
        </div>
        <div class="card">
            <h3>IIS Web Server (vm-iis-01)</h3>
            <span class="status online">ONLINE</span>
            <div class="detail">CPU: 12% | Memory: 3.2 GB / 8 GB<br>HTTPS: Enabled | Cert Expires: 365 days</div>
        </div>
        <div class="card warning">
            <h3>WFM/WFO Platform</h3>
            <span class="status degraded">DEGRADED</span>
            <div class="detail">Agent sync delayed 5 min<br>Schedules publishing: Active</div>
        </div>

What are these cards?

Each card represents a telecom infrastructure component. The PBX Core handles phone calls, the IIS card is your own server, and WFM/WFO manages workforce scheduling. Notice the WFM card uses class="card warning" to flag it as degraded.

  • Finally, paste the remaining three cards, the footer, and the closing tags:
        <div class="card">
            <h3>Call Recording Server</h3>
            <span class="status online">ONLINE</span>
            <div class="detail">Storage: 2.1 TB / 10 TB (21%)<br>Active Recordings: 89</div>
        </div>
        <div class="card">
            <h3>DNS / AD Services</h3>
            <span class="status online">ONLINE</span>
            <div class="detail">Domain: local.cloudseam<br>DC: Pending deployment (Project 2)</div>
        </div>
        <div class="card offline">
            <h3>CMS Reporting</h3>
            <span class="status down">OFFLINE</span>
            <div class="detail">Scheduled maintenance window<br>ETA: Back online 0600 tomorrow</div>
        </div>
    </div>
    <div class="footer">
        CloudSeam Enterprise Telecom | Hosted on Azure | Secured with TLS
    </div>
</body>
</html>

What is the CMS Reporting card showing?

CMS (Call Management System) handles reporting on call center metrics. It is intentionally marked OFFLINE with a maintenance window message. In real environments, not every system is green at all times. This teaches you to read a dashboard for both healthy and unhealthy states.

  • In Notepad, click File then Save (or press Ctrl+S).
  • Close Notepad.

✔️ Awesome, I've got everything!

Great. Make sure you saved the file before closing Notepad.

ⓧ I'd like to double check the full code

Your index.html file should contain all five sections you pasted above, in this order:

  • Section 1: DOCTYPE, head opening, body/header styles (ends with .header p closing brace).
  • Section 2: Grid and card component styles (ends with .status closing brace).
  • Section 3: Status color styles, detail, footer styles, closing </style></head>.
  • Section 4: Body opening, header div, first 3 cards (PBX Core, IIS Web Server, WFM/WFO).
  • Section 5: Last 3 cards (Call Recording, DNS/AD, CMS Reporting), footer div, closing </body></html>.

Scroll through your file in Notepad and confirm each section is present with no gaps or duplicated lines.

Verify the dashboard loads in the browser

Before you open the browser, what do you expect to see at http://localhost now that you have replaced the default page?

  • Open a browser inside the VM (Edge is pre-installed) and navigate to http://localhost.

You should see your Telecom System Status Dashboard. It has a dark background with a blue title bar reading "CloudSeam Telecom - System Status" and six cards showing system components with green, orange, and red status badges.

What just happened?

IIS automatically serves any index.html file placed in C:\inetpub\wwwroot as the default page. When you deleted iisstart.htm and replaced it with index.html, IIS started serving your dashboard on port 80 (HTTP) with no restart needed.

This confirms your web server is working. The page is only accessible inside the VM right now. In the next step, you will try to reach it from your home desktop and discover why it is blocked.

Still seeing the old IIS welcome page?

  • Press Ctrl+F5 to hard-refresh the browser and bypass the cache.
  • Confirm iisstart.htm no longer exists in C:\inetpub\wwwroot. Run dir C:\inetpub\wwwroot in PowerShell and verify only index.html is listed.
  • Make sure you saved the file as index.html (not index.html.txt). Notepad sometimes appends .txt silently.

Still stuck? Help me figure out why my custom index.html is not loading in IIS on localhost.

Your web server is live and serving a real dashboard inside the VM. Next up, you will try to access this dashboard from your home desktop and discover how Azure's Network Security Group controls who can reach your server.

Open External Access via NSG Rules

Your Telecom Status Dashboard works perfectly inside the VM. But a dashboard only you can see from a remote desktop session is not useful to a team.

In this step, you will try to access your dashboard from your home desktop and discover that Azure's Network Security Group is blocking the traffic. Then you will deliberately open the ports you need. This is exactly how enterprise firewalls work. You never leave all ports open.

In this step, get ready to:
  • Attempt to reach your dashboard from your home browser and see the connection blocked.
  • Add NSG inbound rules to allow HTTP and HTTPS traffic.
  • Verify external access works and observe the "Not Secure" warning.
Try accessing your dashboard from home

Right now, only RDP (port 3389) is allowed through the NSG. Your web server listens on port 80 inside the VM, but nothing from the outside internet can reach it.

Before you try this, what do you think will happen when you enter the VM's public IP in your home browser?

  • On your home Windows desktop (not inside the RDP session), open a browser.
  • Navigate to http:// followed by your VM's public IP address (the one you noted in Step 1).

The page times out or refuses the connection. Nothing loads.

Why did it fail?

This is the NSG doing its job. When you created the VM, you only allowed RDP (port 3389) inbound. Every other port is blocked by the default DenyAllInBound rule at priority 65500.

In enterprise environments, this is exactly what you want. A firewall blocks everything by default, and you explicitly allow only the traffic you need. This prevents unauthorized access to services that should not be internet-facing.

Add inbound port rules for HTTP and HTTPS

You need to tell Azure's firewall to let web traffic through. You will add two rules: one for HTTP (port 80) and one for HTTPS (port 443) so the server is ready when you configure encryption later.

  • Switch back to the Azure portal in your home browser.
  • Navigate to your VM by typing vm-iis-01 in the top search bar and selecting it from the results.
  • In the left pane, expand Networking and select Network settings.
  • Click Create port rule, then select Inbound port rule.

Configure the first rule for HTTP traffic with these values:

  • Set Service to HTTP. This auto-fills port 80 and TCP protocol.
  • Set Priority to 300.
  • Set Name to Allow-HTTP.
  • Click Add.

Wait a few seconds for the rule to save. Now add the second rule for HTTPS traffic.

  • Click Create port rule, then select Inbound port rule again.
  • Set Service to HTTPS. This auto-fills port 443 and TCP protocol.
  • Set Priority to 310.
  • Set Name to Allow-HTTPS.
  • Click Add.

What do these rules do?

Each rule tells Azure's firewall: "Allow inbound traffic on this port from any source." The priority number determines the order Azure evaluates rules. Lower numbers are checked first.

Your rules at priority 300 and 310 override the default DenyAllInBound rule at priority 65500 because they are evaluated first.

Don't see the Create port rule button?

Make sure you selected Networking > Network settings in the left pane, not just the VM overview page. The port rule options appear on the Network settings blade.

help me find the Network settings blade for my VM

Verify external access from your home browser

With both rules in place, your VM now accepts web traffic from the internet. Before you test, what do you expect to see this time when you refresh?

  • On your home desktop, go back to the browser tab where the page timed out earlier.
  • Refresh the page (http:// followed by your VM's public IP).

Your Telecom System Status Dashboard loads. You are now accessing your Azure-hosted web server from your home network.

Now look at the browser address bar. It says "Not Secure" next to the URL. This means traffic between your browser and the server is completely unencrypted. Anyone on the network path could read it. In a DoD environment, this is unacceptable.

Why does the browser say Not Secure?

You are using HTTP (port 80), which sends data in plain text. HTTPS (port 443) encrypts the connection using a TLS certificate. Without a certificate bound to the server, browsers warn you that the connection is not private.

In the next step, you will create a self-signed certificate and bind it to IIS so your dashboard is served over encrypted HTTPS.

Still timing out after adding the rules?

Wait 30-60 seconds after adding each rule. NSG changes can take a moment to propagate.

Confirm that both rules show Allow under the Action column in your inbound rules list. Also verify you are using http:// (not https://) since no certificate is bound yet.

help me troubleshoot why my NSG rules are not letting traffic through

Your dashboard is now reachable from outside the VM. But that "Not Secure" warning means anyone between your browser and the server can read the traffic in plain text. Next up, you will fix that by creating a TLS certificate and enabling HTTPS.

Secure IIS with HTTPS Using a Self-Signed Certificate

Your dashboard loads from your home browser, but the address bar shows Not Secure. That means every byte of data between your browser and the server travels in plain text. Anyone on the network path could read it.

A TLS certificate encrypts that connection. In production environments (especially DoD), certificates come from a trusted Certificate Authority. For now, you will create a self-signed certificate to learn exactly how certificates work. Project 3 replaces it with a proper CA-issued cert from your own PKI.

In this step, get ready to:
  • Create a self-signed TLS certificate and bind it to IIS on port 443.
  • Verify HTTPS works inside the VM and from your home desktop.
  • Understand why a self-signed cert triggers a browser warning and what replaces it in enterprise environments.
Create a self-signed certificate

A certificate is like a name tag for your server. It tells browsers who they are talking to and enables encryption. You will generate one using PowerShell and store it in the Windows certificate store.

  • Inside your RDP session to vm-iis-01, switch back to PowerShell (running as Administrator).
  • Create a C:\scripts folder to store your configuration script by running this command:
New-Item -ItemType Directory -Path "C:\scripts" -Force
  • Generate a self-signed certificate for your server by running these commands:
# CloudSeam Enterprise Telecom - HTTPS Configuration Script
# This script creates a self-signed certificate and binds it to IIS
# In Project 3, this will be replaced with a CA-issued certificate from your PKI

# Step 1: Create a self-signed certificate
# -DnsName: The name that goes on the certificate (like a name tag for your server)
# -CertStoreLocation: Where Windows keeps certificates (the "filing cabinet")
# -NotAfter: When the cert expires (1 year from now)
$cert = New-SelfSignedCertificate `
    -DnsName "vm-iis-01.local.cloudseam" `
    -CertStoreLocation "Cert:\LocalMachine\My" `
    -NotAfter (Get-Date).AddYears(1) `
    -KeyAlgorithm RSA `
    -KeyLength 2048

# Step 2: Get the certificate thumbprint (its unique fingerprint)
$thumbprint = $cert.Thumbprint
Write-Host "Certificate created with thumbprint: $thumbprint" -ForegroundColor Green

You should see a green message showing the certificate thumbprint (a long hexadecimal string that uniquely identifies your certificate).

What does this code do?

  • New-SelfSignedCertificate generates a certificate with the DNS name vm-iis-01.local.cloudseam. This name goes on the cert like a label identifying your server.
  • Cert:\LocalMachine\My is the personal certificate store on the server. Think of it as a filing cabinet where Windows keeps certificates.
  • The thumbprint is a unique fingerprint for the certificate. You use it in the next command to tell IIS which certificate to use for HTTPS.
Bind the certificate to IIS on port 443

The certificate exists in the store, but IIS does not know about it yet. You need to create an HTTPS binding on port 443 and attach the certificate to it.

  • Run these commands in the same PowerShell session to bind the certificate to IIS:
# Step 3: Import the WebAdministration module (IIS management tools for PowerShell)
Import-Module WebAdministration

# Step 4: Create an HTTPS binding on the Default Web Site (port 443)
New-WebBinding -Name "Default Web Site" -IPAddress "*" -Port 443 -Protocol "https"

# Step 5: Bind the certificate to the HTTPS port
# This tells IIS: "When someone connects on port 443, use THIS certificate"
(Get-WebBinding -Name "Default Web Site" -Port 443 -Protocol "https").AddSslCertificate($thumbprint, "My")

Write-Host "HTTPS binding configured successfully!" -ForegroundColor Green
Write-Host "Test by navigating to https://localhost in a browser." -ForegroundColor Yellow
Write-Host ""
Write-Host "NOTE: You will see a certificate warning because this is self-signed." -ForegroundColor Yellow
Write-Host "In Project 3, your enterprise CA will issue a trusted certificate." -ForegroundColor Yellow

You should see green and yellow messages confirming the HTTPS binding was configured successfully.

What does this code do?

  • Import-Module WebAdministration loads PowerShell tools for managing IIS.
  • New-WebBinding creates an HTTPS listener on port 443 for the Default Web Site.
  • AddSslCertificate attaches your certificate to that listener using the thumbprint. Now when a browser connects on port 443, IIS presents this certificate to encrypt the connection.

Seeing an error about the binding or certificate?

  • If you see a "thumbprint" error, make sure you ran both command blocks in the same PowerShell session. The $thumbprint variable from the first block must still be in memory.
  • If you get a module error for WebAdministration, confirm IIS was installed with management tools in Step 2. Run Get-Module -ListAvailable WebAdministration to check.
  • If the binding already exists, a previous attempt may have partially succeeded. Run Get-WebBinding -Name "Default Web Site" -Port 443 to verify.

Still stuck? Help me troubleshoot my IIS HTTPS binding

  • Save both command blocks as a reusable script by running:
notepad C:\scripts\configure-https.ps1
  • Notepad opens with a blank file. Paste the full combined content of both command blocks you just ran (the certificate creation commands followed by the IIS binding commands).
  • Press Ctrl+S to save the file, then close Notepad.

Why save the commands as a script?

Enterprise admins keep configuration scripts so they can reproduce a server setup reliably. If you ever rebuild this VM, you can run C:\scripts\configure-https.ps1 to reconfigure HTTPS in one step instead of retyping everything.

Verify HTTPS from inside the VM and from home

Before testing from your home network, confirm HTTPS works locally on the server itself.

  • Open a browser inside the VM (Edge or Internet Explorer on the taskbar).
  • Navigate to https://localhost in the address bar.

You will see a certificate warning page. This is expected because the certificate is self-signed and your browser does not trust the issuer.

  • Click Advanced on the warning page.
  • Click Continue to localhost (unsafe) to proceed.

Your Telecom System Status Dashboard loads with a padlock icon in the address bar. The padlock may show a warning triangle because the cert is self-signed, but the connection is encrypted.

Why does the browser show a warning?

Browsers maintain a list of trusted Certificate Authorities. A self-signed certificate was created by the server itself, not by a recognized authority. The browser warns you because it cannot verify who issued the certificate.

The connection is still encrypted. The warning is about trust (who are you talking to?), not about encryption (can anyone eavesdrop?). In Project 3, your own Root CA will issue a trusted certificate, eliminating this warning entirely.

Now for the real test. Switch to your home Windows desktop (not the RDP session) and open your browser.

Before you navigate, predict what will happen. Will the page load immediately, or will something appear first?

  • Navigate to https://your VM public IP address in the address bar.

The same certificate warning appears. Your browser does not trust the self-signed certificate, just like inside the VM.

  • Click Advanced, then click Continue (or Proceed depending on your browser) to accept the risk.

Your Telecom System Status Dashboard loads over HTTPS with a padlock icon in the address bar. The connection between your home browser and the Azure server is now encrypted.

What changed compared to HTTP?

  • HTTP (port 80) sent your dashboard in plain text. Anyone between your browser and the server could read it.
  • HTTPS (port 443) encrypts everything using TLS. Even if someone intercepts the traffic, they see scrambled data.
  • In DoD environments, all web traffic must use HTTPS with certificates issued by a trusted CA. Your self-signed cert proves the mechanism works. Project 3 adds the trust layer.

Page does not load from your home browser?

  • Confirm you are using https:// (not http://) in the address bar.
  • Check that the Allow-HTTPS NSG rule (port 443) is still active in the Azure portal under your VM's Networking settings.
  • If you see a timeout, the VM may have stopped. Verify it shows status Running in the Azure portal.

Still stuck? Help me access my HTTPS dashboard from home

✔️ Awesome, I've got everything!

Great. Confirm you saved your script at C:\scripts\configure-https.ps1 and that your dashboard loads over HTTPS from both inside the VM and from your home browser.

ⓧ I'd like to double check the full script

Your C:\scripts\configure-https.ps1 file should contain both blocks you ran, in order:

  • Block 1 (certificate creation): Starts with the header comments and ends with the Write-Host thumbprint line.
  • Block 2 (IIS binding): Starts with Import-Module WebAdministration and ends with the yellow Write-Host lines about Project 3.

Scroll up to confirm each block is present in your file with no extra content between them.

Your dashboard is now served over encrypted HTTPS. Next up, you will enable SSH so you can manage this server from your home lab command line, just like an enterprise admin managing remote infrastructure.

Enable SSH and Connect From On-Prem

Your dashboard is live and encrypted. But right now, the only way to manage this server is by opening a full Remote Desktop session. Enterprise telecom engineers manage dozens of servers across different sites.

SSH gives you command-line access to a remote server without launching a full graphical desktop. In this step, you will install an SSH server on your Azure VM and connect to it from your home Windows desktop. This is exactly how enterprise admins manage remote infrastructure.

In this step, get ready to:
  • Install OpenSSH Server on your Azure VM.
  • Open port 22 in the Network Security Group, restricted to your home IP only.
  • SSH into your Azure server from your home desktop PowerShell.
Install OpenSSH Server on the VM

Windows Server 2022 does not come with an SSH server installed by default. You need to add it as an optional Windows capability, then start the service.

  • Switch back to your RDP session on vm-iis-01.
  • Open PowerShell as Administrator (right-click the Start menu, select Windows PowerShell (Admin)).
  • Install OpenSSH Server by running this command:
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

What does this command do?

This adds the OpenSSH Server capability to Windows. It is the same SSH protocol that Linux servers use, letting you connect to this Windows box from any SSH client.

The install takes about 30 seconds. Once it finishes, you will see a message showing the install state as Installed.

  • Start the SSH service and set it to launch automatically on boot by running these commands:
Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'
  • Verify the service is running by running:
Get-Service -Name sshd

You should see the Status column showing Running. Your VM is now listening for SSH connections on port 22.

What is SSH?

SSH (Secure Shell) is a protocol that gives you an encrypted command-line session on a remote machine. It runs on port 22 by default.

Unlike RDP, which streams an entire graphical desktop, SSH sends only text commands and their output. This makes it faster, lighter, and the standard way enterprise admins manage servers at scale.

Service not starting?

If Start-Service sshd fails, make sure the install command completed fully. Run Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 again and confirm it shows Installed.

help me troubleshoot OpenSSH Server not starting on Windows Server 2022

Open port 22 in the Network Security Group

The SSH service is running inside the VM. But just like HTTP was blocked in Step 3, the Network Security Group is still blocking port 22 from the outside. You need to add a rule that allows SSH traffic from your home IP only.

  • Return to the Azure portal in your browser.
  • Navigate to your VM (vm-iis-01).
  • In the left menu, click Networking, then click Network Settings.
  • Click Create port rule, then select Inbound port rule.
  • Set Source to My IP address. This auto-detects your home public IP address.
  • Set Service to SSH. This automatically fills in port 22.
  • Set Priority to 320.
  • Set Name to Allow-SSH-Home.
  • Click Add.

After a few seconds, the new rule appears in your inbound rules list. You should see Allow-SSH-Home with port 22 and your home IP as the source.

Why restrict SSH to your IP only?

By setting the source to My IP address, only your home network can reach port 22. Everyone else on the internet gets blocked. This follows the security principle of least privilege. Open only what is needed, to only who needs it.

Compare this to the HTTP/HTTPS rules from Step 3 which allow traffic from any source. A public-facing web page needs to be reachable by everyone. SSH management access does not.

Connect via SSH from your home desktop

Everything is in place. The SSH service is running inside the VM, and the NSG now allows your home IP through on port 22. Time to connect.

  • On your home Windows desktop (not inside the RDP session), press the Windows key to open your search bar.
  • Type PowerShell and press Enter to open it.

Before you run the next command, think about what you expect to happen. Do you think the connection will succeed on the first try, or will something block it?

  • Connect to your Azure VM via SSH by running this command:
ssh [[VM_USERNAME="your VM username"]]@[[VM_PUBLIC_IP="your VM public IP address"]]
  • You will see a message asking if you want to continue connecting and showing a host key fingerprint. Type yes and press Enter. This only happens the first time you connect to a new server.
  • Enter your VM password when prompted. The cursor will not move as you type. Press Enter when done.

Your prompt changes to show the remote server name. You are now inside your Azure VM from your home desktop, over an encrypted SSH connection.

  • Confirm you are on the remote machine by running:
hostname

You should see vm-iis-01 in the output. You are managing your Azure cloud server from your home lab, just like an enterprise admin managing remote infrastructure.

What just happened?

Your home desktop sent an encrypted SSH connection over port 22, through the internet, through Azure's NSG (which verified your home IP matches the rule), and into the OpenSSH Server running on your VM.

This is hybrid connectivity. Your on-premises home lab is now connected to your cloud infrastructure. In enterprise telecom, this is how engineers manage servers across multiple sites without physically being at each one.

Connection timed out or refused?

  • Double check the NSG rule: go back to your VM's Network Settings and confirm Allow-SSH-Home shows port 22 with your IP as the source.
  • Verify the sshd service is still running inside the VM. In your RDP session, open PowerShell and run Get-Service -Name sshd to check.
  • If your home IP changed (common with residential internet), delete the SSH rule and recreate it. Azure will pick up your new IP when you select My IP address again.

help me troubleshoot SSH connection to my Azure Windows Server VM timing out

Secret mission

Azure Monitor Alert and Auto-Shutdown

Enterprise infrastructure requires monitoring and cost management. In this secret mission, you will configure Azure Monitor with a CPU usage alert that notifies you when your server is under heavy load, and set up auto-shutdown to save money when you are not using the VM.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses Azure pay-as-you-go resources that incur charges while they exist.

Cost warning

Your VM costs ~$0.05/hour while running. The OS disk costs ~$5.50/month even when the VM is stopped. The public IP costs ~$0.005/hour while allocated.

If you are not continuing to Project 2 immediately, choose Pause or Delete below to avoid unnecessary charges.

Resources you used:

  • Windows Server 2022 VM (vm-iis-01) with IIS, OpenSSH, and self-signed certificate.
  • Virtual Network (vnet-telecom) with subnet sn-servers.
  • Network Security Group with inbound rules for RDP, HTTP, HTTPS, and SSH.
  • Public IP address assigned to the VM.
  • OS Disk (127 GB Standard HDD).
  • Azure Monitor alert rule and Action Group (Secret Mission).
  • Resource Group rg-telecom-lab containing all of the above.

Keep everything running

No action needed. Choose this if you are continuing to Project 2 (Active Directory integration) soon.

  • Leave all resources in rg-telecom-lab as they are.
  • Auto-shutdown is already configured at 11:00 PM your timezone, so the VM will stop itself each night.
  • Estimated ongoing cost: ~$6/month with auto-shutdown configured (disk + limited compute hours + public IP).

Pause - I'll come back to this later

Deallocate the VM to stop compute charges. You still pay for disk storage, but compute costs drop to zero.

  • In the Azure portal, navigate to Virtual Machines and select vm-iis-01.
  • Click Stop in the top toolbar.
  • Wait for the VM status to show Stopped (deallocated). This confirms compute billing has stopped.
  • Estimated ongoing cost: ~$5.50/month (disk storage only).
  • When you are ready to resume, select vm-iis-01 and click Start. Your public IP may change after deallocation.

Delete - I don't want to use this again

Remove all project resources in one action by deleting the resource group. This is irreversible and removes everything instantly. Cost drops to $0.

  • In the Azure portal, search for Resource groups in the top search bar and select it.
  • Select rg-telecom-lab from the list.
  • Click Delete resource group at the top of the page.
  • Type rg-telecom-lab in the confirmation field to confirm deletion.
  • Click Delete. Azure removes the VM, virtual network, NSG, public IP, disk, alert rule, and action group.
  • You will recreate these resources if you start Project 2 later.

Nice Work!

Nice Work!

You just built and secured enterprise cloud infrastructure from scratch. You have a Windows Server 2022 VM running in Azure, serving an HTTPS-encrypted Telecom System Status Dashboard, and you can manage it remotely from your home lab via SSH.

You've learned how to:

  • Deploy a Windows Server 2022 VM in Azure with proper network segmentation (VNet, subnet, and Network Security Group rules controlling exactly which ports are open).
  • Install IIS and secure it with HTTPS using a self-signed TLS certificate, understanding why DoD environments replace these with CA-issued certificates.
  • Establish SSH connectivity from your on-prem home lab to an Azure server, simulating how enterprise telecom engineers manage remote infrastructure.
  • Secret Mission: Configured Azure Monitor CPU alerting and auto-shutdown for cost control and proactive infrastructure monitoring.

Ready to quiz yourself?