Everyday IT · Troubleshooting Paths

Start with the symptom. Find the failing layer.

You do not need to know the final fix before you begin. Do not ask which product is broken first. Ask which layer failed.Scope first. Compare second. Then choose the path.

Use the first 10 minutes checklistFollow the full methodBack to Everyday IT

The troubleshooting lifecycle

Keep the order visible so each test reduces uncertainty and every change has a clear verification target.

03 · Layer

Identify the shared dependency that failed

Separate identity, client, network, service, policy, permissions, and data before choosing a product fix.

Before you choose a product

Two short tests can remove half the troubleshooting tree before you touch a setting.

Scope

How broad is the failure?

One user, one device, one location, one resource, or everyone? Scope changes where you look next. Scope the problem

Compare

What changes the result?

Use the same user on another device, another user on the same device, browser vs desktop, or another network. Run a known-good comparison

Choose the problem you actually have

Each path starts broad, then narrows toward the guide that answers the next useful question.

File access

User cannot reach a drive or folder

Find the real resource first, then test path, connectivity, identity, groups, and permissions. Mapped Drives & File Access

Remote work

VPN does not work

Work through client, gateway, reachability, credentials, MFA, backend authentication, and the resource. VPN Troubleshooting

Scanner

The scanner is not detected

Prove power, cable, USB path, Windows detection, vendor software, and a real scan. Scanner Troubleshooting

Scan workflow

Scan to email or folder fails

Decide whether the failure is device communication, folder access, Microsoft 365 delivery, authentication, or filtering. Scan to Email Scan to Folder

Follow the evidence, not the product name

The strongest troubleshooting paths often cross products because the symptom belongs to a shared layer.

Browser works

Move toward the local client

If the same account and data work in a browser, avoid rebuilding the cloud service first. Check profile, cache, saved identity, application state, and device-specific policy.

Several users fail

Move toward the shared dependency

Multiple users or devices failing together point toward infrastructure, policy, service, network, mail filtering, or another common layer.

One user fails

Compare with known-good

Use a working user, device, path, group, or workflow as evidence, but verify the design before copying settings blindly.

Connected but unusable

Test the actual resource

VPN connected, OneDrive signed in, or Outlook opened are checkpoints. Validate the business workflow the user actually needs.

Common next-step chains

These are natural troubleshooting sequences already represented in the Everyday IT library.

Finish the investigation deliberately

Every troubleshooting path should end in proof or a smaller, evidence-backed escalation.

Plan / Rollback

Know how to get back

Before changing permissions, profiles, sync, servers, policy, or data, understand the blast radius and recovery path. Plan the change safely

Workaround / Resolution

Name the actual outcome

Restoring productivity is useful, but it is not always the same as controlling the cause. Classify the outcome

Prevent Recurrence

Improve the next response

After the fix, decide whether monitoring, documentation, standards, or maintenance should change. Prevent recurrence

Escalate

Preserve the investigation

If risk, privilege, infrastructure, data, or uncertainty moves the work beyond the ticket, hand off the evidence and exact unresolved question. Escalate with evidence

Scope → Compare → Layer → Plan/Rollback → Change → Verify → Workaround/Resolution → Prevent Recurrence.

At any unsafe or unresolved point, escalate with evidence.

When the path stops being routine

Recurring failures, several affected users or systems, shared-service impact, and risky changes deserve a deliberate handoff.

If the problem keeps returning, affects several users or systems, or the next step is risky enough that rollback matters, stop guessing.

That is a good point to bring in an experienced second set of eyes.

Identity policy path

When a password succeeds but Conditional Access blocks the sign-in, use the exact policy result to choose the next test.