Same user
Different device
If the same user and account work on another device, identity and backend access become less likely. Focus on the original workstation, local client, cached credentials, or device configuration.
Everyday IT · Troubleshooting Method
Compare with something known to work.
When the symptom is vague, a known-good comparison can isolate the failing layer faster than another repair attempt.Change one variable. Compare the result. Keep the evidence.
Four comparisons that solve a lot of tickets
The goal is not to copy a working setup blindly. The goal is to identify what differs.
Same device
Different user
If another approved user succeeds on the affected device, hardware and general connectivity are probably functioning. Compare identity, group membership, licensing, profile state, and user-specific settings.
Same account
Different client
Browser versus desktop is especially useful for Microsoft 365. If the web path works while the desktop client fails, move toward the local application, profile, token, cache, or workstation.
Same device
Different network or location
If a service works from one network and not another, focus on reachability, DNS, firewall path, routing, ISP behavior, or location-specific policy before changing the account.
Compare configuration, not just symptoms
A known-good peer is useful when the environment is supposed to be role-based.
Access
Compare the approved group path
For a user who cannot reach a share, site, mailbox, or application, compare with a working user in the same role. Identify the group or entitlement that creates access instead of granting one-off permissions.
Resource
Compare the exact destination
Use a working user's UNC path, SharePoint library, VPN gateway, printer queue, or application endpoint to prove that both users are trying to reach the same thing.
Device
Compare the path to the hardware
For scanners, printers, docks, and USB devices, compare ports, cables, drivers, and connection paths before concluding the hardware itself failed.
State
Compare what changed
If the setup worked yesterday, compare password changes, group changes, Office sign-in, updates, network location, device replacement, and other recent differences.
Do not turn comparison into cloning
Known-good is evidence, not permission to copy everything.
Avoid
Copying every permission
A working user's access may include exceptions, old assignments, or responsibilities the affected user should not inherit. Identify the intended role-based path.
Avoid
Changing several variables together
If you reset the password, rebuild the profile, reinstall the client, and change permissions at the same time, you lose the evidence that would tell you what actually fixed the issue.
Verify
Re-test the original workflow
After isolating and correcting the failing layer, test the exact action that originally failed. A successful intermediate test is not always the same as a resolved user workflow.
Known-good comparison is not “make them identical.” It is “find the meaningful difference.”
Scope the problem, compare one variable, identify the failing layer, then make the smallest justified change.
Related Guides
Turn the comparison into one controlled next action.
Re-scope the problem
If the comparison changes the suspected blast radius, update the scope before acting. Scope the result
Plan the change and rollback
Use the isolated layer to define a targeted, reversible change. Prepare the change
Escalate with evidence
If the result points to a shared or unsafe layer, carry the comparison and unresolved question forward. Preserve the evidence