Summary
The final shape of this project is intentionally narrow. It is one tenant, one Windows 11 endpoint, two users, two groups, one compliance policy, one visible configuration profile, one app deployment, four ticket scenarios, and two knowledge base articles.
That scope is not just a convenience choice. It is the design decision that makes the project realistic, finishable, and defensible.
Title
Ticket-Driven Microsoft 365 Endpoint Support Lab
Target Roles
This scope is best aligned to Junior IT Support, Microsoft 365 Support, Endpoint Support, Modern Workplace Support, and service desk roles with M365, Entra, or Intune exposure.
It is not designed to imitate an endpoint engineering or security architecture role.
Locked Scope
The project stays locked to:
1Microsoft 365 / Intune tenant1Windows 11 VM namedW11-M365-ENDP012users:alex.wrightandcasey.ellis2groups:SG-Intune-PilotandSG-M365-Operations1enrollment1compliance policy:CP-W11-Basic-Compliance1configuration profile:CFG-W11-Edge-Office-Start1app deployment:APP-W11-Company-Portal4ticket scenarios2troubleshooting knowledge base articles
The project should not drift outside those boundaries unless there is an explicit, justified decision to change the design.
Exact Design Choices
The primary licensing path is a Business Premium trial, with an Intune trial as fallback. That keeps the project near-zero-cost while still grounded in real Microsoft admin paths.
The main lifecycle user is alex.wright. That choice matters because it keeps the joiner, onboarding, micro-mover, and leaver story on one traceable account. The troubleshooting user is casey.ellis, which keeps the failed sign-in case separate and easier to explain without breaking the main lifecycle sequence.
The target group SG-Intune-Pilot exists so enrollment, policy, profile, and app targeting can stay simple and visible. SG-M365-Operations exists only to support one small mover-style access change. It is intentionally small, because a little access-change evidence is useful, but a whole separate mover workstream would only bloat the project.
The compliance policy uses Defender AV and Firewall because those settings are easy to explain, safe for a VM, and easy to validate. The configuration profile makes Edge open https://www.office.com because a visible result teaches more than a hidden setting. The app deployment uses Company Portal through Microsoft Store app (new) because it is realistic, Microsoft-native, and easier to defend than deeper packaging work.
What Stays
The following elements stay because they are central to the value of the project:
- the joiner flow, because it proves account readiness is more than user creation
- the endpoint onboarding flow, because it connects the user story to an actual managed device
- the failed sign-in case, because support work needs troubleshooting and not only setup
- the leaver flow, because access removal is as real as access delivery
- the micro-mover note, because one small access-change example adds realism without opening a new workstream
- the evidence standard, because the project becomes much stronger when results are provable
- the knowledge base articles, because documentation is one of the most practical differentiators for a junior
What Is Removed
Autopilot is removed from the core scope because it would change the shape of the project from support workflow into provisioning design. Conditional Access design is removed because it shifts the center of gravity toward security engineering. Multiple devices, multiple app deployments, broader security hardening, scripting-heavy automation, and Teams or SharePoint as core workstreams are removed because they add complexity faster than they add learning value.
These cuts are what keep the project honest.
Optional Extra
Only one small optional extension remains acceptable: a short note explaining where Teams or OneDrive support could fit into the same broader support landscape.
Anything larger than that weakens the design by widening it faster than the owner can defend it.
Why Each Chosen Element Matters
Joiner
The joiner matters because it teaches that a user is not “done” when the account exists. The account also needs the correct licence state, the correct targeting state, and a clean path into the next stage of the workflow.
Endpoint Onboarding
The onboarding flow matters because it proves the project does not stop at identity. It connects the user to a real endpoint and brings that endpoint into Microsoft-managed state.
Compliance Policy
The compliance policy matters because it teaches that managed devices are not only enrolled. They are also evaluated against expected standards.
Configuration Profile
The configuration profile matters because it proves that a centrally managed setting can be assigned, applied, and visibly validated.
App Deployment
The app deployment matters because software delivery is one of the most normal tasks in endpoint support and managed desktop work.
Failed Sign-In
The failed sign-in matters because a project without troubleshooting is too easy to keep shallow. This ticket forces log-based reasoning and controlled change discipline.
Leaver
The leaver matters because it proves the project understands control, cleanup, and handoff, not only setup.
Knowledge Base Articles And Evidence
The KB articles and evidence pack matter because they show that the owner is not only doing the work. The owner is also recording it in a way that another person could use.