A small lab.
A repeatable process.

What has actually been checked

A dedicated KVM guest now runs Microsoft Windows 11 Enterprise Evaluation, version 10.0.26300, build 26300. Secure Boot and the virtual TPM were verified inside Windows. The lab has four virtual CPUs, 8 GiB of memory, a separate 100 GiB disk, and distinct administrator and standard-user accounts.

The original VM and its disk were preserved. The new guest uses a dedicated NAT network for setup and a separate isolated network is available for local fault injection. See the verified environment record for the current state.

The following guide explains the setup process and how to repeat it. Windows Update remains a pre-lab step. Microsoft 365 and Intune tenant setup, and all five incident exercises, are still pending.

1. Inventory and protect the existing guest

1. Confirm which disk belongs to the existing VM and whether it contains personal files. Save its configuration and a powered-off backup to the separate data drive.
2. Use a dedicated new guest or a full, independent clone for the lab; give it its own name, disk, and network identity. Check that it never shares a writable system disk with the original.
3. On the dedicated guest, inspect the actual Windows edition, build, activation status, available storage, and installed tools. Record what is observed, and check support and update status before connecting it to the internet.
4. If a supported Windows 11 practice guest is needed, create it on a separate disk with the correct firmware and virtual TPM. An old BIOS guest does not become Windows 11 ready by changing its display name or turning on a firmware switch.

2. Prepare the Windows 11 baseline

A practical starting allocation is 4 virtual CPUs, 8 GiB of memory, and an 80 GiB virtual disk, adjusted after observing performance. This is a lab sizing suggestion; check Microsoft’s current Windows 11 requirements and host compatibility.

Use a valid Windows license or an eligible Windows 11 Enterprise evaluation. The evaluation is time limited; record its expiry and terms when setting up the guest. The Windows Enterprise evaluation has been installed on the dedicated lab guest using media verified against Microsoft’s published SHA-256. No Microsoft 365 or Intune subscription has been created for this project.

1. Install and update Windows in the dedicated lab guest. Record its edition, build, hostname, network configuration, and evaluation or activation state.
2. Create a separate local administrator for maintenance and a standard disposable account, lab.employee, for employee scenarios. Use fictional data.
3. Open Windows Settings, Task Manager, Event Viewer, Device Manager, and 64-bit Windows PowerShell. Find the tools before introducing a fault.
4. Take a clean baseline checkpoint or powered-off backup. Include virtual TPM and firmware state in the recovery plan; a disk snapshot alone may not capture them.

3. Separate practice from everything else

Use a dedicated virtual network. During fault injection, prefer an isolated network with no forwarding, no bridged adapter, and no shared host folders. Use controlled outbound NAT only when updates or cloud exercises need it. NAT permits outbound connectivity and is not complete isolation from your home network.

Keep remote desktop and administrative ports off the public internet. Leave the website VPS, game VPS, personal accounts, and original VM outside the fault-injection environment. All changes in the incident exercises apply to the dedicated lab guest or its test tenant.

4. Add Microsoft 365 and identity practice later

Begin with local Windows exercises. For cloud practice, arrange a separate, authorized Microsoft 365 test tenant with the licenses required for the specific applications. Use fictional users, separate administrator and employee accounts, and the tenant’s default domain.

A developer sandbox depends on Microsoft’s eligibility rules; it is not guaranteed access for general help desk training. Do not start a trial until you are ready to use its limited duration and have reviewed the subscription terms.

Practice account creation, group membership, least-privilege roles, licensing, identity verification, and authorized password-reset workflows. Learn the differences between a local Windows account, an on-premises domain account, and a Microsoft Entra work account. A cloud-only lab does not demonstrate Active Directory domain administration.

5. Add one Intune device

Follow Microsoft’s Intune evaluation guide once tenant access is available. Check current prerequisites, licensing, and supported enrollment for the guest. Enroll only the disposable lab device, use a dedicated test group, and choose one harmless setting to validate.

Record enrollment, assignment, check-in time, portal status, and the setting on the device. Keep device wipes, broad policy assignments, and real users out of this practice exercise.

6. Work each ticket like a support request

1. Capture the user’s problem, affected scope, impact, and exact error. Assign a priority based on impact and urgency.
2. Reproduce the symptom and collect a baseline. Write a hypothesis and explain what each check will prove or rule out.
3. Make one authorized change at a time. Record the change and a recovery path.
4. Verify the original task as the affected standard user. Include a negative test when permissions are involved.
5. Write a plain-language user update, restoration notes, and a reason to close or escalate. Restore the lab baseline before the next exercise.

Evidence that makes a useful portfolio

For each incident, keep a sanitized symptom screenshot, relevant diagnostic output, the change made, and a successful verification. Record actual dates, tool versions, and elapsed times. Remove passwords, recovery codes, tokens, personal messages, tenant identifiers, and public addresses from published material.

Use HD-001-before.png, HD-001-checks.txt, and HD-001-after.png as a simple naming convention. Keep raw originals private. Publish only the reviewed copies, linked from the matching ticket.

A completed case study should explain why the chosen fix followed from the evidence, what the user confirmed, and when the case would need escalation. Screenshots of successful setup alone do not demonstrate troubleshooting.

A ten-hour learning cycle

That keeps 70% of initial study on Windows, Microsoft 365, and identity, with 30% on networking, ticket practice, and Intune. Track what you practiced rather than treating time spent as proof of proficiency.

How to describe the work

Use the heading Independent IT Support Lab in a projects section. At the current stage, say: “Published a Windows and Microsoft 365 support lab plan with five documented incident exercises.” After completing the work, replace that with the tools actually used, the verified incidents, and a link to the evidence. Reserve employment dates and job titles for real employment.

Keep applying while learning. Use a completed ticket to explain your troubleshooting approach, communication, least-privilege choices, and escalation judgment in an interview.

Download the ticket template ↓