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.
Case proof: compare identity boundaries separately
See how one public-safe case proved that hosted and cloud systems accepted different credential states without inventing which backend component caused the mismatch. Read case KT-000008
Case proof: compare the real printer workflow
See how a Windows test page and simple application worked while the PDF workflow still failed, then follow the queue and application comparison through verification. Read case KT-000010
Case proof: isolate the exact crashing component
See how an Office APPCRASH that survived repair and reinstall was narrowed with exact crash evidence and a version-compatible known-good component. Read case KT-000011
Case proof: compare local and remote camera behavior
See how physical hardware, local Windows, remote-session redirection, remote Windows, and conferencing behavior were tested in order without assuming one universal cause. Read case KT-000019
Case proof: follow failures across shared hardware
See how changing monitor, keyboard, and mouse failures, known-good peripherals, and a reduced-load test shifted one investigation toward the shared dock and USB-C path without claiming an exact failed component. Read case KT-000022
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
Put the comparison into the first-ten-minutes workflow
Use one meaningful known-good comparison to reduce the troubleshooting tree.
First 10 Minutes Checklist
Proof from the field
See how a path comparison changes the fault domain.
Compare an intermittent LAN/WAN path
Continuous monitoring compared internal and Internet targets before and after carrier remediation, then reclassified the remaining path without claiming one universal cause. Read case KT-000023
Proof from a product boundary
See how a healthy-workload comparison can prevent unnecessary endpoint changes.
Compare one failing product with a healthy endpoint
Normal setup and business applications remained healthy while one RMM installer repeatedly failed; logs and vendor confirmation moved the remaining work to the product vendor. Read case KT-000024
Proof from a recurrence comparison
See how a working business function can separate a recurring component from the system it appears beside.
Follow what can recreate the symptom
The printer remained functional while a utility prompt returned after local changes; synced content and a local trace exposed the known recurrence path without proving a permanent cure. Read case KT-000026
Proof from a playback-chain comparison
See how a second endpoint can narrow proprietary-format failure without changing the source evidence.
Compare the complete viewer package
Standard players, the bundled viewer, captured dependency errors, and another endpoint isolated the vendor playback chain without claiming the original export was corrupt. Read case KT-000032