What 15+ Years in IT Support Taught Me About Microsoft 365, Users and Solving the Right Problem
The most useful question I learned to ask was not “How do I close this ticket?” It was “What actually broke — and will it break again?”
At the University of Copenhagen, I learned support face to face: a person needed to get back to work, and it was my job to make sense of the machine, account or connection in front of us. At a growing ISP, a single complaint could lead past the desk into the network and the systems behind it. Later, in enterprise support, the environments grew more layered again. Over 15+ years, my view of support changed from fixing what the user could see to tracing what actually caused it. The ticket matters. It just rarely tells the whole story.
The ticket is rarely the whole story
“I cannot get into Teams” is a symptom, not a diagnosis. The next step is not automatically to reinstall Teams. I want to know what changed, whether the issue follows the user or the device, and whether it happens on another connection. Only then does it make sense to follow the evidence through the sign-in, permissions, client, network and service layers.
That is the part of support I still enjoy: turning a vague complaint into a testable question. Sometimes the answer is small. Sometimes it crosses three teams. The important thing is not to confuse the first visible error with the underlying cause. If you have ever fixed the same “one-off” issue every Tuesday, you know why.
How Microsoft 365 changed what support means
Support used to be easier to picture as a single machine and a single application. Today the work can involve Microsoft 365, identity, devices, security policies, networking and collaboration settings in one investigation. The user sees an interrupted meeting or a missing document. The support specialist needs to understand the chain behind it.
That does not mean every engineer needs to own every platform. It means we need enough breadth to isolate the layer at fault, enough depth to investigate our part properly and enough judgement to involve the right specialist when the boundary is crossed. My guide to IT administration and Microsoft 365 goes deeper into those day-to-day platform responsibilities; this is the lesson behind them.
Identity, endpoints and user experience are one system now
A sign-in failure can be an Entra ID access decision, an account state, a stale permission or an Intune compliance signal. A device that looks “fine” to its owner can still fail a policy check. A slow cloud app can be affected by the local connection. The right diagnosis starts by separating these possibilities, not picking a favourite product to blame.
Identity
Check the account, sign-in and access decision before blaming the app.
Endpoint
Look at device health, drivers and compliance, not just the error on screen.
Connection
Verify the network path and the service configuration before resetting everything.
It is why my work with Entra ID and access and Intune and managed endpoints belongs in the same conversation as user support. Neither identity nor device health is an abstract architecture diagram when a person cannot do their job.
What building support operations taught me about ownership
At the ISP, I helped build Technical Support from scratch. We introduced ticketing and ITIL-style workflows, helped run 24/7 support, and I recruited and managed a team of around 10 people. My work crossed support, networking and systems operations; a tidy ticket category did not make those boundaries disappear. That experience changed how I think about responsibility. A queue is useful because work must be visible; it is not a substitute for someone knowing who owns the next step.
During one DDoS incident affecting IPv4 service, a temporary IPv6 workaround helped maintain connectivity while IPv4 service was restored. To the person reporting lost connectivity, it was a support issue. The investigation and recovery were also an infrastructure issue. That is why I try not to promise a quick desktop fix before I know which part of the path has failed.
Good escalation does not mean throwing an issue over a wall. It means providing the evidence gathered, the business impact, what was ruled out and what the receiving team needs to decide. Good ownership also includes telling the user what happens next. I wrote a more detailed operating model in how to build and scale a technical support organization; here, the human lesson is simpler: a handoff is only complete when the next person can actually move forward.
What enterprise support added to that picture
At Lenovo, my work included 2nd- and 3rd-line-style troubleshooting for enterprise customers. A problem could cross the hardware, its drivers, Windows, identity or configuration, and the customer environment. I could not assume that the first device error was the whole answer. The useful part of having seen both network operations and enterprise support is knowing when to keep testing locally and when the evidence points elsewhere.
When support should stop fixing and start removing root causes
There is a point where another workaround is no longer helpful. With a recurring audio-driver issue in enterprise support, I worked toward an automated remediation approach rather than repeating the same manual fix each time. The driver did not become more interesting on the 47th ticket. If an access problem returns, I look at the underlying policy or process in the same way; if people repeatedly request the same manual change, I ask whether it can be safely standardized or automated.
Automation is not permission to make a bad process run faster. First establish the cause, define a safe and repeatable fix, test it, document the rollback and keep a human accountable for the result. This is especially important when an identity or device policy can affect many people at once.
Why communication still matters as much as technical skill
People do not need a tour of every log file. They need to know that someone understands the impact, what is being checked, what they can do meanwhile and when they will hear back. I learned this in customer-facing work as much as in technical work: silence makes a manageable incident feel larger. A clear update costs less than the next three “any news?” messages.
When an investigation moves into 2nd- or 3rd-line support, the explanation should not vanish with it. Deep technical work and plain language are not opposites. The strongest engineers can move between both without making the user feel like a problem to be routed away.
What I now consider a strong IT Support Specialist
Someone who asks better questions than the ticket asks. Someone who can read the signals from identity, endpoint, Microsoft 365 and network systems before deciding what to change. Someone who knows when to escalate, documents the reasoning, and stays responsible for the outcome. Someone who sees a repeat issue as a chance to improve the environment instead of another quick closure.
That is different from a procurement checklist or a job description. If you are hiring for the role, ask how a candidate distinguished a symptom from its cause and what they did when a fix did not last. For a broader view of my actual roles and projects, see my experience.
Closing thought: the right problem is worth finding
After 15+ years, the technology has changed enormously. The part I enjoy most has not: someone has a problem, the obvious answer is not always the right one, and I get to figure out why. That is still how I approach IT support work in Copenhagen today, whether the trail leads through Microsoft 365, an endpoint, identity or the network.
For businesses seeking IT support in København, those layers matter for a simple reason: people need their work to work. I would rather ask one more useful question than close a ticket that will be back tomorrow.