Summary
These ticket scenarios are the operational core of the project. They are written to feel like small support workflows rather than simple build steps. Each ticket shows the user request or symptom, the admin goal, the checks that matter, the change that was made, the expected result, the evidence to capture, and the escalation boundary.
The point is not to imitate a real ticketing system perfectly. The point is to teach the logic of support work in a form that a beginner can still explain honestly.
Ticket 1 - Joiner
Why This Ticket Exists
The joiner ticket matters because user setup is often treated as trivial when it is actually the foundation of later support work. A badly prepared user account makes every later device and sign-in problem harder to understand.
User Problem / Request
A new starter named Alex Wright needs a Microsoft 365 account, a licence, and baseline access so the account is ready for endpoint onboarding.
Admin Goal
Create the account, assign the trial licence, add Alex to SG-Intune-Pilot, and confirm the account is ready for the Windows 11 OOBE join path.
Steps
- Create
alex.wright@<tenant-domain>. - Assign the trial licence in
Licenses and apps. - Add Alex to
SG-Intune-Pilot. - Confirm the UPN and sign-in details are correct.
- Record the account state before endpoint work begins.
Checks
The important checks are simple but critical: the user must exist, the licence must be assigned, Alex must be in SG-Intune-Pilot, and the sign-in details must be recorded correctly. If those checks are weak, the onboarding stage becomes harder to troubleshoot.
Expected Result
Alex is ready to sign in during OOBE and receive Intune-targeted settings after enrollment.
Evidence To Capture
Capture the user overview, the licence assignment, the group membership, and a short ticket closure note that says the account is ready for device onboarding.
Common Failure Points
The usual mistakes here are using the wrong UPN during sign-in, forgetting the licence, or putting the user in the wrong group. These are basic errors, but they create very real downstream confusion.
What Would Be Escalated
Escalate only if the issue moves beyond normal support checks, such as trial or licensing failures, unexpected tenant-wide sign-in problems, or domain or identity issues outside normal user setup work.
Ticket 2 - Endpoint Onboarding
Why This Ticket Exists
The endpoint onboarding ticket matters because it connects identity to the device. Without this step, the lab would be mostly an account-administration project rather than an endpoint-support project.
User Problem / Request
Alex has received a Windows 11 device that must be joined, enrolled, and prepared for managed use.
Admin Goal
Join W11-M365-ENDP01 to Microsoft Entra ID during OOBE, let Intune auto-enrollment complete, and confirm the endpoint receives one policy, one profile, and one app deployment.
Steps
- Build
W11-M365-ENDP01from the Windows 11 Enterprise evaluation ISO. - During OOBE, select
Set up for work or school. - Sign in as Alex.
- Complete Microsoft Entra join and allow Intune auto-enrollment to finish.
- Confirm the device appears in Intune.
- Confirm
CP-W11-Basic-Complianceis assigned. - Confirm
CFG-W11-Edge-Office-Startis assigned. - Confirm
APP-W11-Company-Portalis assigned and installed.
Checks
The device should appear in both Entra and Intune, the primary user should be Alex, the compliance result should be visible, Edge should behave as expected, and Company Portal should be installed. If only one of those checks is true, the onboarding story is not complete.
Expected Result
The endpoint is joined, enrolled, and visibly managed through the chosen policy, profile, and app deployment.
Evidence To Capture
Capture Windows Access work or school, the Entra device record, the Intune device record, the compliance state, the configuration profile status, and the app installation result.
Common Failure Points
The common failure points are an OOBE path blocked by enrollment restrictions, a device that is only registered instead of joined, or assignment delays caused by slow check-in timing. These are good examples of why support work requires patience as well as action.
What Would Be Escalated
Escalate persistent enrollment failures, repeated IME or assignment issues, or tenant restrictions that block the chosen lab path even after the standard support checks have been completed.
Micro-Mover Note
After onboarding and before the leaver flow, Alex receives a small role update. Update the department and job title, add Alex to SG-M365-Operations, and record the before-and-after state.
This is intentionally small. It exists to show a believable access-change step without opening a whole fifth ticket stream that would add more narrative complexity than learning value.
Ticket 3 - Failed Sign-In
Why This Ticket Exists
The failed sign-in ticket matters because a project without troubleshooting is too easy to keep shallow. Setup alone does not prove support reasoning. Troubleshooting does.
User Problem / Request
Casey Ellis reports that they cannot sign in to Microsoft 365.
Admin Goal
Use basic account checks and Microsoft Entra sign-in logs to identify a low-risk cause, apply the smallest appropriate fix, and validate the result.
Steps
- Confirm the exact symptom.
- Check the UPN used during sign-in.
- Check whether the account is enabled.
- Review any relevant licence or assignment state.
- Open
Entra admin center > Identity > Monitoring & health > Sign-in logs. - Filter by Casey and inspect the failed event.
- Apply one low-risk fix supported by the evidence.
- Re-test sign-in.
- Record the cause, change, and validation result.
Checks
The key checks are the account enabled state, the recent failed sign-in event, the visible failure reason in the logs, and the successful retest after the change. If the failure reason is not captured first, the story becomes much weaker.
Expected Result
The failed sign-in is explained by evidence from the logs and resolved without random changes.
Evidence To Capture
Capture the failed sign-in list entry, the relevant sign-in details, the fix applied, and the retest result.
Common Failure Points
The most common mistakes are changing multiple things before reading the logs, choosing a cause that really belongs to Conditional Access or federation, or fixing the issue before capturing the failing state properly.
What Would Be Escalated
Escalate MFA or Conditional Access issues, repeated unexplained failures after standard account checks, or tenant-wide sign-in anomalies.
Ticket 4 - Leaver
Why This Ticket Exists
The leaver ticket matters because support is not only about giving access. It is also about removing access carefully and leaving behind a clean record of what was done.
User Problem / Request
Alex is leaving and access must be removed in a controlled, support-appropriate way.
Admin Goal
Block sign-in, revoke sessions, remove extra access, remove the licence after evidence capture, and record what remains outside junior support scope.
Steps
- Confirm the correct user.
- Block sign-in for Alex.
- Revoke active sessions.
- Remove Alex from
SG-M365-Operations. - Capture final state evidence.
- Remove the licence after evidence capture.
- Record any remaining device handling as a handoff item.
Checks
The important checks are that sign-in is blocked, sessions are revoked, extra group access is removed, the licence is removed only after evidence capture, and a handoff note exists for anything outside normal junior support scope.
Expected Result
Alex can no longer sign in, extra access is removed, and the offboarding note is clean and defensible.
Evidence To Capture
Capture the blocked sign-in state, the session revocation step or note, the updated group membership, the licence removal, and the final closure note.
Common Failure Points
Typical mistakes are removing the licence before capturing evidence, deleting the account instead of blocking sign-in, or forgetting to document device association and next-step ownership.
What Would Be Escalated
Escalate mailbox retention, legal hold, device recovery, wipe or retire decisions, and any HR or security actions outside normal support scope.