Build a Windows Help Desk Report

Create a PowerShell diagnostic report for Windows help desk tickets.

Introduction

30 Second Summary

A support request often starts with one vague sentence. The next technician needs clear evidence before they can decide what to check next.

In this project, you will build a local Windows help desk tool with Windows PowerShell. Your script turns ticket context plus read-only system checks into a structured diagnostic report.

What You'll Build

Picture opening HelpDeskReport.txt after a support check and seeing the ticket context, computer details, disk warnings, network configuration, overall result, and a cautious next step laid out for review.

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

  • A reusable diagnostic script that you can run for practice tickets to capture the reported issue alongside read-only CIM evidence from your computer.
  • A readable help desk report showing the diagnostic timestamp, computer identity, Windows details, installed memory, disk capacity, and network configuration.
  • Clear PASS or WARN review signals that help you document Tier 1 triage with an overall result plus a cautious next step.
  • Secret Mission: Add a technician-selected ICMP reachability check that records a cautious result without treating a failed ping as proof that the destination is down.

Are there any prerequisites?

You need a device running Windows 10 or later. No scripting experience, cloud account, subscription, or administrator access is required.

Before We Start

Before you begin collecting evidence, define the practice support issue you want to investigate. This gives every diagnostic check a clear purpose for the next technician.

Set Up the Help Desk Workspace

Your practice issue now gives every diagnostic check a purpose. You need a verified toolset before the report can collect evidence.

Windows PowerShell 5.1 runs the diagnostic script. Notepad gives you a simple place to edit it.

One project folder keeps the script with its future report. A process-scoped execution policy allows local code in the current PowerShell window.

In this step, get ready to:
  • Verify Windows PowerShell 5.1 plus Notepad.
  • Prepare the project files in one folder.
  • Run the starter script in the current PowerShell session.
Verify Windows PowerShell and Notepad

The version check confirms that this project uses the built-in Windows PowerShell edition expected on Windows 10 or later. Its version table reports the running PowerShell version without changing the device.

  • Press the Windows key to open Start search.
  • Type Windows PowerShell in the search field.
  • Select Windows PowerShell from the results.
  • Check the running PowerShell version by entering this command:
$PSVersionTable.PSVersion

What does this command show?

The $PSVersionTable automatic table describes the current PowerShell session. Its PSVersion item provides the version used by this window.

✔️ The version matches

The output shows a major value of 5. It shows a minor value of 1.

That confirms Windows PowerShell 5.1 is ready for the project.

ⓧ I see a different version

Another PowerShell edition may have opened from the search results. The project path uses Windows PowerShell 5.1.

  • Close the current PowerShell window.
  • Press the Windows key to return to Start search.
  • Type Windows PowerShell in the search field.
  • Select Windows PowerShell from the results.
  • Repeat the version check above.

ⓧ Windows PowerShell is missing

Windows PowerShell 5.1 is included with Windows 10 or later. A missing Start result can indicate a device restriction or a damaged Windows component.

  • Repeat the Start search using the full name Windows PowerShell.
  • Review the official Windows PowerShell 5.1 documentation for the supported Windows edition.
  • Contact your device support team if Windows PowerShell remains unavailable.
  • Press the Windows key to open Start search.
  • Type Notepad in the search field.
  • Select Notepad from the results.

You should see a blank Notepad editing window. This confirms the editor is available for your script.

  • Close the blank Notepad window.
Build the starter workspace

The project folder gives the script a predictable location under your Windows home directory. PowerShell can then run the file from that location.

  • Create $HOME\WindowsHelpDeskReport and make it the current PowerShell location by running these commands:
New-Item -Path "$HOME\WindowsHelpDeskReport" -ItemType Directory -Force
Set-Location -Path "$HOME\WindowsHelpDeskReport"

What do these commands do?

  • New-Item creates the WindowsHelpDeskReport folder under your Windows home directory.
  • -Force lets the command continue if that folder already exists.
  • Set-Location makes the new folder the current PowerShell location.

Your PowerShell prompt should now end with WindowsHelpDeskReport. That path confirms future files land in the correct folder.

Folder path looks different?

Check that both commands use $HOME\WindowsHelpDeskReport exactly. Run the two commands again if the prompt still shows another folder.

Still stuck? Help me troubleshoot my WindowsHelpDeskReport folder commands.

  • Open the starter file from the current folder in Notepad by running this command:
notepad.exe .\support-check.ps1

What does this command do?

notepad.exe launches Notepad with support-check.ps1 as its target file. The relative path keeps the file inside the current WindowsHelpDeskReport folder.

Notepad opens support-check.ps1 as a blank file. PowerShell remains open behind the editor.

  • Add the starter output line by entering the code below:
Write-Host "Help desk project ready"

What does this code do?

  • Write-Host sends display-only output to the PowerShell window.
  • Help desk project ready gives you a concrete signal when the script runs.
  • Select File in Notepad.
  • Select Save As.
  • Confirm the destination is the WindowsHelpDeskReport folder.
  • Enter support-check.ps1 in the File name box.
  • Complete the save.

Notepad should now show support-check.ps1 as the file name. The file is stored at $HOME\WindowsHelpDeskReport\support-check.ps1.

✔️ Awesome, I've got everything!

Your starter file now contains the complete code for this step.

ⓧ I'd like to double check the full code

  • Compare your saved support-check.ps1 with this complete file:
Write-Host "Help desk project ready"

File saved with the wrong name?

Check that the Notepad title shows support-check.ps1. A different extension prevents the PowerShell command from finding the script.

Return to PowerShell and repeat the Notepad launch command above if the file opened in another folder.

Need help? Help me save my PowerShell script with the correct file name.

Run the starter safely

Changing an execution policy can feel risky. This process-scoped setting applies only to the current Windows PowerShell window.

PowerShell may ask you to confirm the change. Approve the process-scoped change if prompted.

  • Allow local scripts in this PowerShell process by running this command:
Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned

Why use Process scope?

Process scope stores the setting only for this PowerShell session. Windows deletes that process-level preference when you close the window.

Group Policy can override this setting on a managed device. Your organization's policy remains authoritative.

Execution policy change blocked?

A managed device may prevent this process-level change through Group Policy. Follow your organization's policy instead of changing a broader execution-policy scope.

Need help understanding the restriction? Help me interpret why this process-scoped execution policy command was blocked.

Before you run the starter, what message do you expect the script to print?

  • Run the saved starter script from the current project folder with this command:
.\support-check.ps1

What should I see?

The console prints Help desk project ready. That output proves PowerShell found the saved script and executed its starter line.

Your workspace is ready. The project folder now contains a runnable PowerShell script that produces visible output.

Starter message missing?

Confirm the PowerShell prompt ends with WindowsHelpDeskReport. The script command looks for support-check.ps1 in that current folder.

Check that Notepad contains the exact starter line from the full-code tab. Save the file before running it again.

Still stuck? Help me troubleshoot why my PowerShell starter script does not print its message.

The help desk workspace is proven. Next, you will use Windows queries to collect raw system evidence.

Collect Raw Diagnostic Evidence

Your workspace now has a runnable starter script. That success confirms Windows PowerShell can execute local code from the project folder.

A technician needs evidence before automation can organize it. In this step, you'll query the computer directly to decide whether the raw results are ready for a support ticket.

In this step, get ready to:
  • Collect local system inventory through CIM queries.
  • Inspect fixed-disk records plus IP-enabled network adapter records.
  • Evaluate the four raw outputs from a ticketing perspective.
Inspect operating system and computer details

The Common Information Model (CIM) exposes structured Windows management data. Get-CimInstance reads local records without changing the computer's configuration.

Before you run these two queries, do you think their raw output will already read like a technician's ticket note?

  • Collect the operating-system object plus the computer-system object by running these commands:
Get-CimInstance -Class Win32_OperatingSystem
Get-CimInstance -ClassName Win32_ComputerSystem

What do these queries return?

  • The Win32_OperatingSystem class supplies Windows details such as Caption, Version, OSArchitecture, and LastBootUpTime.
  • The Win32_ComputerSystem class supplies the computer name, manufacturer, model, and installed memory value.

You'll see a Win32_OperatingSystem object followed by computer-system data. The console presents the values as separate records.

  • Locate the Windows information in the operating-system output.
  • Locate Name, Manufacturer, Model, and TotalPhysicalMemory in the computer-system output.

Don't see the system details?

  • Confirm that you are using the Windows PowerShell 5.1 window from the previous step.
  • Check each class name against the commands above.
  • Follow your organization's policy if local CIM access is restricted.

Need help with the query? Help me diagnose why my local CIM query returned no system data.

Inspect disk and network details

A support investigation also needs storage capacity plus network configuration. These records provide another view of the computer's current state.

  • Collect local fixed-disk records by running this command:
Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DriveType=3"

What does the disk query show?

  • The DriveType=3 filter limits the results to local fixed disks.
  • The DeviceID property identifies each disk.
  • The FreeSpace property reports available capacity in bytes.
  • The Size property reports total capacity in bytes.

You'll see one record for each local fixed disk returned by Windows.

  • Identify the DeviceID, FreeSpace, and Size fields in the disk output.
  • Collect IP-enabled network adapter records by running this command:
Get-CimInstance -Class Win32_NetworkAdapterConfiguration -Filter IPEnabled=$true

What does the network query show?

  • The IPEnabled=$true filter limits the results to adapters with IP enabled.
  • The IPAddress, DefaultIPGateway, and DNSServerSearchOrder properties can each contain multiple values.
  • The DHCPEnabled property reports the adapter's DHCP state.

You'll see detailed configuration for each IP-enabled adapter returned by Windows.

  • Identify the IPAddress, DefaultIPGateway, DNSServerSearchOrder, and DHCPEnabled fields in the network output.

Missing disk or network records?

  • Check that the disk command contains the exact DriveType=3 filter.
  • Check that the adapter command contains the exact IPEnabled=$true filter.
  • Confirm that each class name matches the command shown above.

Still missing records? Help me troubleshoot my fixed-disk or IP-enabled adapter query.

Assess the raw evidence

You now have four accurate views of the same computer. A support ticket needs those facts to tell one coherent investigation story.

  • Compare the system, computer, disk, and network outputs still visible in your PowerShell window.
  • Check whether the outputs include a ticket number or reported issue.
  • Check whether the outputs use consistent formatting or review signals.
  • Check whether the outputs suggest a next action.

Your comparison exposes the intended gap. The data is useful, but it lacks ticket context, consistent formatting, review signals, and a next action.

Before you repeat the final check, what kind of Windows object do you expect the console to return?

  • Verify the operating-system query by running it again:
Get-CimInstance -Class Win32_OperatingSystem

What does this final check prove?

The command requests the local operating-system instance again. The returned object confirms that your evidence query works from the project session.

You'll see a Win32_OperatingSystem object containing Windows information. You've now collected the raw evidence that the next stage can organize.

Final query not returning an object?

  • Confirm that the class name is exactly Win32_OperatingSystem.
  • Run the command from the same Windows PowerShell window used for the earlier queries.

Need another check? Help me find why the final operating-system query returned no object.

✔️ Awesome, I've got everything!

Great. Your starter script remains unchanged while the raw queries provide the diagnostic evidence for this step.

ⓧ I'd like to double check the full code

  • Switch back to support-check.ps1 from earlier to compare it with this unchanged starter file:
Write-Host "Help desk project ready"

That's the evidence-gathering foundation in place: you can now pull local system, disk, and network facts on demand. Next, you'll turn those scattered records into a ticket report.

Turn Evidence into a Ticket Report

Your raw CIM queries exposed the computer details a technician needs. They also revealed why disconnected console objects are difficult to attach to a ticket.

Scattered output cannot support consistent ticket documentation. You will shape a report in Notepad that Windows PowerShell writes as a local file.

In this step, get ready to:
  • Collect a practice ticket number plus the reported issue.
  • Format local operating-system details into a structured report.
  • Write the report to a UTF-8 text file for inspection.
Capture the ticket context

A diagnostic report needs to identify the support request it belongs to. The Read-Host prompts collect that context before Get-Date records when the evidence was gathered.

  • Switch back to support-check.ps1 in Notepad.
  • Select the existing Write-Host "Help desk project ready" starter line.
  • Replace the selected content by pasting the code below:
$ticketNumber = Read-Host "Enter a practice ticket number"
$reportedIssue = Read-Host "Describe the reported issue in one sentence"
$runTime = Get-Date

What does this code do?

  • The $ticketNumber variable stores the practice ticket number entered at the first prompt.
  • The $reportedIssue variable stores the issue sentence entered at the second prompt.
  • The $runTime variable stores the current date plus time for the report.
  • Save support-check.ps1 in Notepad.

The script pauses twice for the scenario you defined earlier. The first prompt takes your practice ticket number while the second takes the reported issue.

  • Test the new prompts by running this command:
.\support-check.ps1

What should I see?

You will see Enter a practice ticket number first. You will see Describe the reported issue in one sentence after entering the ticket number.

Seeing both prompts confirms that the script now collects ticket context before gathering system evidence.

Prompts not appearing?

Confirm that you saved support-check.ps1 after replacing the starter line. Unsaved changes leave the earlier version on disk.

Check that the current PowerShell location is still $HOME\WindowsHelpDeskReport.

Still stuck? Help me troubleshoot why my PowerShell script does not show its Read-Host prompts.

Build the system overview

The operating-system object supplies Windows details. The computer-system object supplies the device identity plus physical memory in bytes.

The report converts memory into whole gigabytes before placing the selected properties inside an expandable here-string. Variables inside that template resolve to values from the local computer.

  • Find the $runTime = Get-Date line in support-check.ps1.
  • Add the report-building code directly below that line by pasting the following block:
$os = Get-CimInstance -Class Win32_OperatingSystem
$computer = Get-CimInstance -ClassName Win32_ComputerSystem
$memoryGB = [int]($computer.TotalPhysicalMemory / 1GB)

$report = @"
WINDOWS HELP DESK DIAGNOSTIC REPORT
===================================
Ticket: $ticketNumber
Reported issue: $reportedIssue
Collected: $runTime

SYSTEM OVERVIEW
Computer name: $($computer.Name)
Manufacturer: $($computer.Manufacturer)
Model: $($computer.Model)
Windows: $($os.Caption)
Windows version: $($os.Version)
OS architecture: $($os.OSArchitecture)
Last boot: $($os.LastBootUpTime)
Installed memory: $memoryGB GB
"@

$report | Out-File -FilePath ".\HelpDeskReport.txt" -Encoding utf8
Write-Host "Report created: .\HelpDeskReport.txt"

How is the report assembled?

  • The $os object provides the Windows caption plus version. It also provides the architecture plus last boot time.
  • The $computer object provides the computer name plus manufacturer. It also provides the model plus physical memory.
  • The $memoryGB calculation converts the physical-memory value from bytes into whole gigabytes.
  • The $report here-string gives every ticket the same headings plus field order.
  • The Out-File line writes the finished text to HelpDeskReport.txt using UTF-8 encoding.
  • The Write-Host line confirms the report path in the console.
  • Save support-check.ps1 in Notepad.
  • Confirm that Notepad now shows the SYSTEM OVERVIEW heading below the ticket fields.

Missing part of the report template?

Make sure the opening @" appears directly after $report =. Make sure the closing "@ starts at the beginning of its line.

Check that the output lines sit below the closing "@ marker.

Need help comparing the sections? Help me find the misplaced line in my PowerShell report template.

Run and inspect the report

The completed script turns the same local evidence into a repeatable ticket artifact. Running it again proves that the prompts plus system queries now feed one readable file.

Before you run the complete script, which ticket details plus system fields do you expect to find in the report?

  • Generate the first structured report by running this command:
.\support-check.ps1

What should I see?

Enter your practice ticket number at the first prompt. Enter the reported issue sentence at the second prompt.

When the script finishes, you will see Report created: .\HelpDeskReport.txt in the console. That message confirms the report was written in the current project folder.

  • Switch back to Notepad from earlier.
  • Open HelpDeskReport.txt from $HOME\WindowsHelpDeskReport using Notepad's file-opening control.
  • Compare the ticket number plus reported issue with the answers you entered.
  • Confirm that the report shows the collection timestamp plus computer name.
  • Confirm that the system overview shows the manufacturer plus model.
  • Confirm that the system overview shows the Windows caption plus version.
  • Confirm that the system overview shows the operating-system architecture plus last boot time.
  • Confirm that the system overview shows installed memory in gigabytes.

You should see one structured report with ticket context followed by the local system overview. That is a meaningful shift from scattered console objects to evidence another technician can review.

Report missing or incomplete?

If the file is missing, confirm that the console reached Report created: .\HelpDeskReport.txt. A script error before that message can stop the file from being written.

If a field label appears without a value, compare the property name in support-check.ps1 with the full code below.

Need another pair of eyes? Help me troubleshoot my missing or incomplete HelpDeskReport.txt file.

✔️ Awesome, I've got everything!

Your support-check.ps1 file now contains the complete basic-report script.

ⓧ I'd like to double check the full code

$ticketNumber = Read-Host "Enter a practice ticket number"
$reportedIssue = Read-Host "Describe the reported issue in one sentence"
$runTime = Get-Date

$os = Get-CimInstance -Class Win32_OperatingSystem
$computer = Get-CimInstance -ClassName Win32_ComputerSystem
$memoryGB = [int]($computer.TotalPhysicalMemory / 1GB)

$report = @"
WINDOWS HELP DESK DIAGNOSTIC REPORT
===================================
Ticket: $ticketNumber
Reported issue: $reportedIssue
Collected: $runTime

SYSTEM OVERVIEW
Computer name: $($computer.Name)
Manufacturer: $($computer.Manufacturer)
Model: $($computer.Model)
Windows: $($os.Caption)
Windows version: $($os.Version)
OS architecture: $($os.OSArchitecture)
Last boot: $($os.LastBootUpTime)
Installed memory: $memoryGB GB
"@

$report | Out-File -FilePath ".\HelpDeskReport.txt" -Encoding utf8
Write-Host "Report created: .\HelpDeskReport.txt"

Your first ticket report now preserves the practice issue plus a clear system snapshot. Next, you will add disk checks plus network details that highlight evidence requiring review.

Add Disk and Network Triage

Your basic Windows PowerShell report now captures ticket context. It also records system identity.

A technician still has to interpret raw storage values manually. Raw network values create the same burden. This step adds visible review signals with a cautious next action.

In this step, get ready to:
  • Evaluate local fixed disks against the project threshold.
  • Turn network configuration into gateway-aware review lines.
  • Produce an overall triage result with a recommended next step.
Add fixed-disk review signals

Disk capacity becomes easier to review when each local fixed disk has a consistent status line. The less-than-20-percent-free rule is a project threshold for practising triage logic.

What does WARN mean here?

A WARN result marks evidence for technician review. It does not diagnose a failing disk.

  • Switch back to support-check.ps1 in Notepad.
  • Find the $memoryGB assignment below the two CIM queries.
  • Replace that line with the disk collection logic below:
$disks = Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DriveType=3"

$memoryGB = [int]($computer.TotalPhysicalMemory / 1GB)
$warningCount = 0
$diskLines = @()

foreach ($disk in $disks) {
    if ($disk.Size -gt 0) {
        $sizeGB = [int]($disk.Size / 1GB)
        $freeGB = [int]($disk.FreeSpace / 1GB)
        $freePercent = [int](($disk.FreeSpace / $disk.Size) * 100)

        if ($freePercent -lt 20) {
            $diskStatus = "[WARN]"
            $warningCount = $warningCount + 1
        }
        else {
            $diskStatus = "[PASS]"
        }

        $diskLines += "$diskStatus Drive $($disk.DeviceID): $freeGB GB free of $sizeGB GB ($freePercent% free)"
    }
}

if ($diskLines.Count -eq 0) {
    $diskLines += "[WARN] No local fixed-disk information was returned."
    $warningCount = $warningCount + 1
}

$diskText = $diskLines -join "`r`n"

What does this code do?

  • The fixed-disk query collects local disks with a drive type of 3.
  • The loop converts disk size values from bytes into whole gigabytes.
  • The percentage calculation measures the remaining free space on each disk.
  • The conditional adds a WARN status below the project threshold.
  • The fallback records a warning when Windows returns no local fixed-disk information.
  • Scroll to the bottom of the report here-string.
  • Find its current final two lines:
Installed memory: $memoryGB GB
"@

What are you locating?

These lines currently finish the system overview. The closing "@ ends the expandable report text.

  • Replace those two lines with the expanded report ending below:
Installed memory: $memoryGB GB

DISK CHECKS
Project warning threshold: less than 20% free space
$diskText
"@

How does the report change?

The new section states the project threshold. It inserts every formatted disk line beneath that threshold.

  • Save support-check.ps1.
  • Switch back to the Windows PowerShell window from earlier.

Before you run the script, do you expect your local fixed disks to receive PASS or WARN results?

  • Generate the updated report by running this command:
.\support-check.ps1

What happens when this runs?

The script asks for the two ticket values. It then writes the updated report to HelpDeskReport.txt.

  • Enter the same practice ticket number you used earlier.
  • Enter the same reported issue you used earlier.

You will see Report created: .\HelpDeskReport.txt in the console. That confirmation shows the disk calculations completed without stopping the script.

  • Switch back to Notepad.
  • Select File from the menu.
  • Select Open.
  • Browse to $HOME\WindowsHelpDeskReport.
  • Select HelpDeskReport.txt.
  • Click Open.

You will see a DISK CHECKS section. Each local fixed disk has a PASS or WARN line with its capacity details.

Missing the disk section?

Confirm that $diskText appears inside the report here-string below the threshold line.

Check that the opening and closing braces around both disk conditions match the reference code.

Still stuck? Help me troubleshoot my PowerShell disk triage section.

Add network configuration checks

A network adapter can report several IP addresses. Gateway and DNS values can also contain multiple entries. Joining each array produces one readable ticket line per adapter.

A missing default gateway receives a review warning. Specialized adapters can legitimately omit one, so the report avoids presenting that warning as a fault.

  • Return to support-check.ps1 in Notepad.
  • Find this query block near the top of the file:
$computer = Get-CimInstance -ClassName Win32_ComputerSystem
$disks = Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DriveType=3"

$memoryGB = [int]($computer.TotalPhysicalMemory / 1GB)

Why edit this block?

The existing queries gather computer details and fixed-disk details. The adapter query belongs beside them because each query collects local evidence before the formatting logic runs.

  • Replace that block with the version below:
$computer = Get-CimInstance -ClassName Win32_ComputerSystem
$disks = Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DriveType=3"
$adapters = Get-CimInstance -Class Win32_NetworkAdapterConfiguration -Filter IPEnabled=$true

$memoryGB = [int]($computer.TotalPhysicalMemory / 1GB)

What does the new query collect?

The adapter query returns local network configurations where IP support is enabled. Those objects provide the address, gateway, DNS, DHCP, and adapter description values used in the report.

  • Find the $diskText assignment above $report.
  • Replace that assignment with the network formatting logic below:
$networkLines = @()

if ($adapters) {
    foreach ($adapter in $adapters) {
        $ipAddresses = if ($adapter.IPAddress) { $adapter.IPAddress -join ", " } else { "Not reported" }
        $defaultGateways = if ($adapter.DefaultIPGateway) { $adapter.DefaultIPGateway -join ", " } else { "Not reported" }
        $dnsServers = if ($adapter.DNSServerSearchOrder) { $adapter.DNSServerSearchOrder -join ", " } else { "Not reported" }

        if ($defaultGateways -eq "Not reported") {
            $adapterStatus = "[WARN]"
            $warningCount = $warningCount + 1
        }
        else {
            $adapterStatus = "[PASS]"
        }

        $networkLines += "$adapterStatus $($adapter.Description): IP=$ipAddresses; Gateway=$defaultGateways; DNS=$dnsServers; DHCP=$($adapter.DHCPEnabled)"
    }
}
else {
    $networkLines += "[WARN] No IP-enabled network adapter was returned."
    $warningCount = $warningCount + 1
}

$diskText = $diskLines -join "`r`n"
$networkText = $networkLines -join "`r`n"

What does this code do?

  • Each join operation converts an array into a comma-separated value for the report.
  • Missing arrays become Not reported so the ticket line stays readable.
  • An adapter without a reported default gateway increases $warningCount.
  • The fallback records a warning when the query returns no IP-enabled adapters.
  • The final two assignments prepare the disk lines and network lines for the report.
  • Save support-check.ps1.
  • Switch back to Windows PowerShell.
  • Check the new network logic for syntax errors by running the script:
.\support-check.ps1

What should this check prove?

The script asks for the same two ticket values. A completion message confirms that the adapter loop finished without a syntax error.

  • Enter your practice ticket number.
  • Enter your reported issue.

You will see Report created: .\HelpDeskReport.txt after the adapter logic finishes.

  • Switch back to support-check.ps1 in Notepad.
  • Find the current ending of the report here-string:
DISK CHECKS
Project warning threshold: less than 20% free space
$diskText
"@

What is missing from the report?

The script now formats network values in $networkText. The current here-string still ends after the disk section.

  • Replace that ending with the disk and network sections below:
DISK CHECKS
Project warning threshold: less than 20% free space
$diskText

NETWORK CONFIGURATION
$networkText
"@

How does this change help?

The report now prints each formatted adapter line under a dedicated heading. A technician can compare IP, gateway, DNS, and DHCP values without searching through raw object output.

  • Save support-check.ps1.
  • Switch back to Windows PowerShell.

Before you run the script, do you expect every IP-enabled adapter to report a default gateway?

  • Generate the report with its network section by running:
.\support-check.ps1

What happens during this run?

The script collects fresh disk and network evidence. It then writes both sets of formatted lines into HelpDeskReport.txt.

  • Enter your practice ticket number.
  • Enter your reported issue.
  • Use File in Notepad to reopen HelpDeskReport.txt.

You will see a NETWORK CONFIGURATION section. Each adapter line shows its description, IP addresses, gateway, DNS servers, and DHCP state.

Network lines missing or incomplete?

Confirm that $networkText appears beneath the NETWORK CONFIGURATION heading.

Check each property name against the reference code. A spelling difference can leave a value empty.

Need help? Help me troubleshoot my PowerShell network configuration section.

Calculate the overall triage result

Individual warning lines help a technician find evidence that needs attention. An overall result makes the report easier to scan during documentation or escalation.

The recommendation stays cautious because these checks do not establish a full diagnosis. A REVIEW result directs the technician back to the reported symptom.

  • Return to support-check.ps1 in Notepad.
  • Find the adjacent $diskText and $networkText assignments.
  • Replace those two assignments with the status logic below:
if ($warningCount -eq 0) {
    $overallStatus = "PASS"
    $nextStep = "No disk or network configuration warning was detected. Continue reproducing the reported symptom and document what happens."
}
else {
    $overallStatus = "REVIEW"
    $nextStep = "Review each WARN line, confirm the symptom with the user, and attach this evidence if escalation is required."
}

$diskText = $diskLines -join "`r`n"
$networkText = $networkLines -join "`r`n"

How is the overall result chosen?

  • A warning count of zero produces an overall PASS result.
  • One or more warnings produce an overall REVIEW result.
  • Each result receives a next step that keeps the reported symptom central to the investigation.
  • Scroll to the final lines inside the report here-string.
  • Find the current network section ending:
NETWORK CONFIGURATION
$networkText
"@

Where will the summary go?

The overall status belongs after the evidence sections. The recommended next step closes the report with an action for the technician.

  • Replace that ending with the final report sections below:
NETWORK CONFIGURATION
$networkText

OVERALL STATUS
$overallStatus
Warnings to review: $warningCount

RECOMMENDED NEXT STEP
$nextStep
"@

What does the final section add?

The report now shows the overall result beside the warning count. It finishes with a recommendation that supports continued troubleshooting or escalation.

✔️ Awesome, I've got everything!

  • Save support-check.ps1 in Notepad.

ⓧ I'd like to double check the full code

$ticketNumber = Read-Host "Enter a practice ticket number"
$reportedIssue = Read-Host "Describe the reported issue in one sentence"
$runTime = Get-Date

$os = Get-CimInstance -Class Win32_OperatingSystem
$computer = Get-CimInstance -ClassName Win32_ComputerSystem
$disks = Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DriveType=3"
$adapters = Get-CimInstance -Class Win32_NetworkAdapterConfiguration -Filter IPEnabled=$true

$memoryGB = [int]($computer.TotalPhysicalMemory / 1GB)
$warningCount = 0
$diskLines = @()

foreach ($disk in $disks) {
    if ($disk.Size -gt 0) {
        $sizeGB = [int]($disk.Size / 1GB)
        $freeGB = [int]($disk.FreeSpace / 1GB)
        $freePercent = [int](($disk.FreeSpace / $disk.Size) * 100)

        if ($freePercent -lt 20) {
            $diskStatus = "[WARN]"
            $warningCount = $warningCount + 1
        }
        else {
            $diskStatus = "[PASS]"
        }

        $diskLines += "$diskStatus Drive $($disk.DeviceID): $freeGB GB free of $sizeGB GB ($freePercent% free)"
    }
}

if ($diskLines.Count -eq 0) {
    $diskLines += "[WARN] No local fixed-disk information was returned."
    $warningCount = $warningCount + 1
}

$networkLines = @()

if ($adapters) {
    foreach ($adapter in $adapters) {
        $ipAddresses = if ($adapter.IPAddress) { $adapter.IPAddress -join ", " } else { "Not reported" }
        $defaultGateways = if ($adapter.DefaultIPGateway) { $adapter.DefaultIPGateway -join ", " } else { "Not reported" }
        $dnsServers = if ($adapter.DNSServerSearchOrder) { $adapter.DNSServerSearchOrder -join ", " } else { "Not reported" }

        if ($defaultGateways -eq "Not reported") {
            $adapterStatus = "[WARN]"
            $warningCount = $warningCount + 1
        }
        else {
            $adapterStatus = "[PASS]"
        }

        $networkLines += "$adapterStatus $($adapter.Description): IP=$ipAddresses; Gateway=$defaultGateways; DNS=$dnsServers; DHCP=$($adapter.DHCPEnabled)"
    }
}
else {
    $networkLines += "[WARN] No IP-enabled network adapter was returned."
    $warningCount = $warningCount + 1
}

if ($warningCount -eq 0) {
    $overallStatus = "PASS"
    $nextStep = "No disk or network configuration warning was detected. Continue reproducing the reported symptom and document what happens."
}
else {
    $overallStatus = "REVIEW"
    $nextStep = "Review each WARN line, confirm the symptom with the user, and attach this evidence if escalation is required."
}

$diskText = $diskLines -join "`r`n"
$networkText = $networkLines -join "`r`n"

$report = @"
WINDOWS HELP DESK DIAGNOSTIC REPORT
===================================
Ticket: $ticketNumber
Reported issue: $reportedIssue
Collected: $runTime

SYSTEM OVERVIEW
Computer name: $($computer.Name)
Manufacturer: $($computer.Manufacturer)
Model: $($computer.Model)
Windows: $($os.Caption)
Windows version: $($os.Version)
OS architecture: $($os.OSArchitecture)
Last boot: $($os.LastBootUpTime)
Installed memory: $memoryGB GB

DISK CHECKS
Project warning threshold: less than 20% free space
$diskText

NETWORK CONFIGURATION
$networkText

OVERALL STATUS
$overallStatus
Warnings to review: $warningCount

RECOMMENDED NEXT STEP
$nextStep
"@

$report | Out-File -FilePath ".\HelpDeskReport.txt" -Encoding utf8
Write-Host "Report created: .\HelpDeskReport.txt"

How to use this reference

Compare the file from top to bottom. Match every variable name, brace, quote, and report heading before saving.

  • Save support-check.ps1 after your file matches the reference.

Before you run the completed script, do you expect the overall result to show PASS or REVIEW on your computer?

  • Switch back to Windows PowerShell.
  • Generate the complete diagnostic report by running:
.\support-check.ps1

What should this final run produce?

The script collects fresh evidence from the local computer. It evaluates every disk and adapter before writing the completed report.

  • Enter your practice ticket number.
  • Enter your reported issue.
  • Use File in Notepad to reopen HelpDeskReport.txt.

You will see DISK CHECKS and NETWORK CONFIGURATION sections. You will also see an OVERALL STATUS section with PASS or REVIEW.

The report ends with RECOMMENDED NEXT STEP and a cautious action. That completes your reusable Tier 1 triage report.

Final report missing a section?

Confirm that every heading appears between $report = @" and the closing "@.

Check that $overallStatus and $nextStep are assigned before the report here-string begins.

Still seeing a problem? Help me troubleshoot my completed PowerShell help desk report.

That is the main-path report complete. Your script now turns local evidence into review signals that another technician can scan quickly.

Secret mission

Add an On-Demand Reachability Test

Extend your diagnostic report with a technician-selected reachability test for a permitted hostname or IP address. Record a clear result while preserving the cautious interpretation expected in a support ticket.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep the files, pause your work, or delete the folder. Every resource stays on your Windows device with no ongoing cost.

Resources you used:

  • The $HOME\WindowsHelpDeskReport\support-check.ps1 diagnostic script.
  • The $HOME\WindowsHelpDeskReport\HelpDeskReport.txt file containing local device details and network configuration.
  • The current Windows PowerShell 5.1 session with its process-scoped execution policy set to RemoteSigned.

Keep everything running

No action needed. Choose this if you want to reuse the script for future practice tickets.

  • Keep the $HOME\WindowsHelpDeskReport folder so the script and generated report remain available.
  • Leave the current Windows PowerShell window open while you continue using its temporary process-scoped policy.

Pause - I'll come back to this later

Shut down the current tools to end the temporary policy setting. Your two local files stay in $HOME\WindowsHelpDeskReport.

  • Close Notepad if it is still open.
  • Close the current Windows PowerShell window.

The process-scoped RemoteSigned setting ends when the PowerShell window closes. The script and report remain available for later use.

Delete - I don't want to use this again

This option permanently removes the project script and its generated report. The report contains local device details and network configuration.

  • Review $HOME\WindowsHelpDeskReport\HelpDeskReport.txt from earlier for any ticket notes you want to retain.
  • Close Notepad if it is still open.
  • Close the current Windows PowerShell window.
  • Press the Windows key to open Start search.
  • Search for File Explorer.
  • Select File Explorer from the search results.
  • Navigate to the Windows user folder that contains WindowsHelpDeskReport.
  • Select the WindowsHelpDeskReport folder.

Final Deletion Check

The next action requests permanent deletion. The selected folder contains the script and report from this project.

  • Press Shift+Delete.
  • Confirm the permanent deletion when Windows asks.

The WindowsHelpDeskReport folder no longer appears in your Windows user folder. Your project files are now removed.

Nice Work!

Nice Work!

Mission complete! You built a reusable Windows help-desk diagnostic script with Windows PowerShell 5.1. It turns local device evidence into a structured report for Tier 1 triage.

You've learned how to:

  • Collect operating-system, computer, disk, and network evidence with read-only CIM queries.
  • Turn scattered technical output into a structured help-desk report with ticket context inside HelpDeskReport.txt.
  • Add PASS/WARN review signals with an overall status plus a cautious recommendation for escalation.
  • Secret Mission: Extended the report with a technician-selected ICMP reachability check that avoids treating a failed response as proof that a host is unavailable.

Ready to quiz yourself?