dmwasielewski

Microsoft 365 Endpoint Support

6 min read

Summary

This project is a deliberately small Microsoft 365 endpoint support lab built for learning, portfolio use, and interview discussion. It is not meant to imitate a full enterprise environment. It is meant to show that one person can build, understand, explain, and document a realistic junior-level support workflow using Microsoft 365, Microsoft Entra ID, Microsoft Intune, and one Windows 11 endpoint.

The core idea is simple. A user is created, prepared, and onboarded onto one managed Windows 11 device. That device is joined, enrolled, checked for compliance, given one visible settings profile, and given one app deployment. A separate sign-in problem is then investigated with real Entra sign-in logs, and the main user is later offboarded in a controlled way. Everything is written in a ticket-driven way so the project feels like support work rather than a portal tour.

What This Project Is For

This lab is designed for roles such as Junior IT Support, Microsoft 365 Support, Endpoint Support, Modern Workplace Support, and service desk roles with M365, Entra, or Intune exposure. It maps well to junior work because it stays focused on the kinds of tasks beginners can honestly practise and later explain: user preparation, licence awareness, group targeting, device onboarding, sign-in troubleshooting, low-risk policy verification, and basic offboarding discipline.

This project is not for pretending to be a senior architect, a security lead, or an enterprise endpoint engineer. If it starts to sound like that, it has drifted away from its purpose.

Why This Lab Has Practical Value

The value of this lab is not that it contains a large number of Microsoft products. The value is that it teaches connected support logic.

You are not only learning where buttons live. You are learning how identity, licensing, groups, devices, policies, apps, logs, and documentation fit together inside one support story. That is useful because real junior work often happens in that space between a user request, a device state, and an admin decision.

This is also why the project stays intentionally small. A narrow workflow that you truly understand is much more useful than a broad lab full of features you cannot defend.

Locked Scope

This lab stays within the following fixed scope:

  • 1 Microsoft 365 / Intune tenant
  • 1 Windows 11 VM named W11-M365-ENDP01
  • 2 test users: alex.wright and casey.ellis
  • 2 groups: SG-Intune-Pilot and SG-M365-Operations
  • 1 enrollment
  • 1 compliance policy: CP-W11-Basic-Compliance
  • 1 configuration profile: CFG-W11-Edge-Office-Start
  • 1 app deployment: APP-W11-Company-Portal
  • 4 ticket scenarios
  • 2 knowledge base articles

That scope is not accidental. It is small enough to finish, small enough to explain, and large enough to produce real learning value.

Lab Design

The primary build path uses a Microsoft 365 Business Premium trial. If that trial is not available, the fallback path is an Intune trial, but the core learning story remains the same: cloud identity, one managed Windows endpoint, one basic policy set, one app, one sign-in issue, one offboarding story.

The main lifecycle user is alex.wright@<tenant-domain>. Alex carries the joiner, onboarding, micro-mover, and leaver story. The troubleshooting user is casey.ellis@<tenant-domain>, which keeps the failed sign-in scenario clean and easy to explain without disrupting the main lifecycle flow.

The management target group is SG-Intune-Pilot. The small access-change group is SG-M365-Operations. The compliance policy requires Microsoft Defender Antimalware and Windows Firewall. The configuration profile makes Microsoft Edge open https://www.office.com, because that result is visible and easy to validate. The app deployment uses Company Portal through Microsoft Store app (new), because it is realistic, support-relevant, and simple enough for a beginner to defend.

Ticket Flow

1. Joiner

Alex is created, licensed, placed in the pilot group, and prepared for endpoint onboarding. This proves that user existence, licence readiness, and targeting are part of the same support story.

2. Endpoint Onboarding

W11-M365-ENDP01 is built, joined to Microsoft Entra ID during OOBE, automatically enrolled into Intune, and checked across Windows, Entra, and Intune. This proves that the device is more than a VM. It is a managed endpoint with identity, policy, and app state.

3. Failed Sign-In

Casey is used to generate one simple failed sign-in that can be investigated in Entra sign-in logs. This proves that troubleshooting is based on evidence rather than random changes.

4. Leaver

Alex is later blocked from signing in, sessions are revoked, extra access is removed, and the licence is removed after evidence capture. This proves that good support work includes access cleanup and handoff discipline, not only setup.

Micro-Mover Note

Between onboarding and leaver, Alex receives one small access-change step through SG-M365-Operations and a role-detail update. This keeps the JML story honest without bloating the project into a separate fifth ticket.

How To Use This Project Pack

If you want the fastest overview of the project, read this page, then Final Project Scope, then Ticket Scenarios.

If you are actually building the lab and want to learn from it rather than copy it, treat Beginner Build Guide as the main handbook. Read Part 1 once, work through Part 2 while building, and keep Evidence Checklist and the two knowledge base articles nearby while you are testing and documenting.

Day-by-Day Build Plan is not the main learning spine. It is the private execution schedule you use after the handbook has already made the workflow understandable.

If you are preparing for interview, do that last. Read this page, then Verdict, UK Role Alignment, Interview Pack, and CV Bullets only after the build, notes, and evidence are already real.

Evidence Standard

Every ticket in this project should show six things clearly: the request or symptom, the checks performed, the admin action taken, the validation result, the evidence captured, and the escalation boundary.

That evidence standard matters because it keeps the project honest. A lab without evidence is easy to overclaim. A lab with evidence is much easier to defend.

What This Project Intentionally Does Not Try To Be

This lab is not an Autopilot project. It is not a Conditional Access design project. It is not a hybrid identity build. It is not a server project. It is not a Teams or SharePoint governance project. It is not a security engineering showcase. It is not a claim of commercial experience.

Those are not random exclusions. They are deliberate cuts that protect the project from becoming inflated, unfocused, or dishonest.

Public Project Pages

Private Working Notes

These files are intentionally kept private in the vault because they are build and teaching aids rather than portfolio pages:

  • documentation/03-day-by-day-build-plan.md
  • documentation/08-beginner-build-guide.md
  • AGENTS.md

0 items under this folder.