IT Help Desk Troubleshooting Guide: Common Issues and How to Fix Them

Common IT help desk issues fall into a few recurring categories. These categories include account and access problems, network and connectivity failures, slow performance, software errors, hardware issues, and security incidents. 

Password resets are among the highest-volume tickets. Gartner has estimated they make up 20 to 50 percent of all help desk calls.

The volume has not changed much over the years. What changed is the mix. Paper jams and scanner drivers used to fill the queue. Now it is blocked SSO logins, a VPN that drops, MFA pushes that do not arrive, and a laptop slow since the last update. Printer tickets are still there, just not the bulk of the work.

This guide is for L1 and L2 technicians, internal IT leads, service desk managers, and MSP support staff. It goes category by category, and each issue gets why it happens, the quick checks first, the deeper fix, and prevention. Use it as a runbook and jump to the category you need.

Each fix below follows the same order. The structured troubleshooting methodology is where that order comes from, so identify, theory, test, plan, implement, verify. It will help to have that in your head before working the list.

How to Use This Troubleshooting Guide?

Every issue below is laid out the same way. Why it happens, the quick checks you can run in under two minutes, the deeper fix in numbered steps, and prevention. There is an escalation line also, because knowing when to hand a ticket up is half of L1 work.

Each issue carries a tag as well, incident or service request. For example, a locked account is a service request, while the internet service down for the whole office is an incident. The tag matters at intake more than at resolution, because it sets the priority, the SLA clock, and who gets paged. The difference between a service request and an incident is mostly whether something is broken or someone is asking for something they do not have yet.

Account Access and Identity Issues

Account and access tickets are the biggest group of common help desk issues, and password lockout is the one that repeats the most. Five issues cover most of the category.

Forgotten or Expired Passwords

Why does it happen: Password policies might have set the passwords to expire after 60 or 90 days, and anyone using them might forget to update them. Furthermore,  a phone or a mapped drive holding the old password will keep replaying it after the change also.

Quick checks first

• Look up when the password was last changed, the directory shows you the date
• Expired and locked look identical to the user, so confirm which one it is before you do anything
• Private browsing window, to rule out a cached session showing the wrong error
• Did anyone else in the same group change passwords that week

Deeper fix

1. Verify identity first, using whatever your desk's policy says. A callback to a known number or a manager confirmation.
2. Reset in the directory, so Active Directory, Entra ID, Okta, or Google Workspace, and set the change-at-next-login flag.
3. Send the temporary credential through a different channel than the one the request came in on.
4. Sign the user out of every device, then sign back in on the primary machine before anything else.
5. Clear the saved credential in Windows Credential Manager or Keychain if the old password keeps reappearing.

Prevention: Self-service can help you reset the password reset request, making it one of the best use cases for help desk automation you will find. 

Escalate when the request when self-service fails to fulfil the customer's request within a few minutes. 

Classification tag: Service request.

Locked or Suspended Accounts

Why does it happen: Most lockouts are a threshold of failed attempts being hit, and the attempts are not just typing mistakes.

Quick checks first

• Pull event 4740 from the domain controller, it names the source machine
• Suspension is not lockout, and an HR-driven suspension will not unlock
• Ask whether they changed the password recently on one device only

Deeper fix

1. Unlock the account and confirm with the user that they can sign in.
2. Go to the source machine from the lockout event and clear the stored credential there.
3. Check for services, scheduled tasks, and mapped drives running under the account, then update the password on each.
4. Watch the account for the next hour. If it locks again, the source you cleared was not the only one.

Prevention: Users should be told to update the password on their phone and any mapped drives on the same day they change it, because that one habit removes most repeat lockouts.

Escalate when several accounts lock at the same time. That can be a brute force attempt, and it belongs with security, not with L1.

Classification tag: Typically a service request. It becomes an incident if lockouts are happening across many accounts at once.

MFA and 2FA Login Failures

Three different problems arrive as the same ticket here. The code gets rejected, the push never shows up, or the phone with the authenticator on it is gone.

Why does it happen: TOTP codes are generated from the clock on the device, so a phone that has drifted out of sync produces codes the server will not take. Push failures are usually the network or notification permissions on the phone.

Quick checks first

• Which method is enrolled, and is the user on the method they think they are on
• Automatic date and time turned on, this fixes rejected codes more often than anything else
• Notifications for the authenticator app, are they allowed
• Try a backup method before you start unenrolling anything

Deeper fix

1. Confirm the user's identity properly. MFA resets are the exact thing social engineering targets, so a verbal confirmation is not enough.
2. For a rejected code, have them force a time sync on the phone and try again.
3. For a missing push, get them onto data instead of Wi-Fi and reinstall the authenticator app if it still does not arrive.
4. For a lost or replaced device, remove the old enrollment in the identity provider and issue a temporary bypass with a short expiry.
5. Walk the user through re-enrolling on the new device while you are still on the call, then remove the bypass.

Prevention: Enrolling two methods at onboarding, so an authenticator app and a hardware key or a backup code set, means a lost phone stops being a ticket. 

Escalate when the user cannot be verified, or when MFA is failing for a group of people at once. The second one is usually an identity provider problem.

Classification tag: Typically a service request, though MFA issues affecting everyone are an incident.

SSO Login Loops

Why does it happen: The loop starts when the application will not accept the session the identity provider just issued, so it sends the user back to get another one, and that repeats. Clock skew between the two systems, an expired signing certificate, or an attribute in the assertion that changes are the usual causes.

Quick checks first

• One user or everyone on that app, this decides the whole approach
• Clear cookies for both the app domain and the identity provider domain, then retry
• Different browser and an incognito window, to rule out an extension holding an old session

Deeper fix

1. Reproduce it yourself if you can, and note whether the loop happens before or after the identity provider login page.
2. Check the signing certificate on the app's SSO configuration for expiry. Certificates are a common cause, and they expire quietly.
3. Compare the attribute the app expects, usually email or UPN, against what the user's directory record actually holds. A changed surname or a mailbox migration breaks this.
4. Look at the sign-in logs in the identity provider. A successful authentication with a failed application assignment tells you it is a licensing or group problem.
5. Remove and re-add the user's application assignment if the record looks correct, but the app still rejects it.

Prevention: Certificate expiry dates should be tracked somewhere the team actually looks, because this one is predictable and it still takes people by surprise every year. 

Escalate when the loop hits everyone on an application. That is a configuration or certificate failure, and it needs the identity owner, not more troubleshooting at L1.

Classification tag: Typically an incident if system-wide, a service request for a single user.

Access to Shared Drives, Folders, or Apps

Why does it happen: Access is granted through group membership in most places, so a permission error means either the user is not in the group, or they are in it, and their token has not picked it up yet.

Quick checks first

• Is the user in the right security group? Check the group and not the ticket
• Sign out and back in, group changes need a fresh token
• Can a colleague in the same role open it, which separates a user problem from a broken permission

Deeper fix

1. Find out what the user is actually trying to do, because read access and edit access get requested as the same thing.
2. Confirm who owns the resource. Approval comes from the data owner and not from the help desk.
3. Add the user to the group rather than granting direct permissions on the folder. Direct grants are what makes permissions unmanageable later.
4. Have the user sign out fully, then confirm access with them before you close.
5. For SaaS apps, check the license count also. A permission error is sometimes just no seats left.

Prevention: Access should be tied to role groups that get assigned at onboarding, so most of these requests never reach the desk. 

Escalate when the request is for something sensitive like finance or HR data, or when granting it would need an exception to policy.

Classification tag: Typically a service request.

Network and Connectivity Issues

Network tickets are the second big group of common help desk problems, and five issues cover most of what arrives. Most help desk troubleshooting on the network side starts with the same question, which is how wide the problem actually goes.

No Internet or Wi-Fi Connection

Why does it happen: The connection might be down at the device, at the access point, or at the circuit, and the user's report sounds the same in all three cases. Often it turns out to be a lease that did not renew, or the wrong SSID.

Quick checks first

• Is it one machine or the whole floor? Ask the people sitting around them
• Airplane mode and the physical Wi-Fi switch, which sounds obvious and still catches people out
• Which SSID they are actually joined to, guest networks get picked up by accident
• Ethernet cable into a different port, if there is one nearby

Deeper fix

1. Forget the network on the device and rejoin it with the credentials typed fresh.
2. Run ipconfig /release and then ipconfig /renew on Windows, or renew the DHCP lease from network settings on a Mac. A 169.254 address means DHCP is not answering.
3. Restart the network adapter, and roll back the adapter driver if it was updated recently.
4. Check the access point the user is nearest to. A single AP that has dropped looks like a user problem to everyone sitting under it.
5. If nothing on the network is getting an address, hand it to whoever runs the DHCP scope, as the lease pool might have run out.

Prevention: Watching AP health and lease pool usage in your monitoring can help to catch this before the tickets start arriving.

Escalate when more than one user in the same area reports it at the same time. That is a network incident, and it should not be worked on one ticket at a time.

Classification tag: Typically an incident.

Slow Internet or Wi-Fi

Why does it happen: Slow is a comparison, and the user is comparing it to yesterday, so the first job is turning that into a number. The bandwidth might be saturated, the device might be sitting on a distant access point, or only one application might be slow.

Quick checks first

• Run a speed test and put the number in the ticket
• Wired or wireless, and how many bars
• Everything slow, or just one app or one site
• Anything large downloading or syncing in the background right now

Deeper fix

1. Compare the speed test against what the site is supposed to have. Slow for one person on a fast circuit is a different problem than a saturated line.
2. Look at the signal strength and the band the device is on. A laptop stuck on 2.4 GHz next to a 5 GHz AP will feel slow all day.
3. Check what is running. Cloud backup, a Windows update, or a full OneDrive re-sync will take whatever is available.
4. Move the user onto Ethernet and test again, which tells you straight away whether it is the wireless or the circuit.
5. If the whole site is slow, look at the firewall and the ISP link before you look at any more laptops.

Prevention: Scheduling backups and the big update pushes outside working hours should remove a good part of this.

Escalate when the speed test is bad from a wired connection as well. That is circuit or firewall territory.

Classification tag: Typically an incident when the site is affected, a service request when it is one device.

VPN Won't Connect or Keeps Dropping

Why does it happen: A VPN that will not connect at all is usually credentials, MFA, or the client version. One that connects and then drops every few minutes is almost always the connection underneath it, so home Wi-Fi, a mobile hotspot, or an ISP with packet loss.

Quick checks first

• Which of the two is it, no connection at all or dropping after a while
• Client version against the build you are currently on
• Does it drop on a hotspot too, or only on their home Wi-Fi
• Any MFA prompt appearing at connect time

Deeper fix

1. Have the user reboot the router at home before anything else. It fixes more VPN drops than any change on the client side.
2. Update the VPN client, and uninstall the old version properly instead of installing over it.
3. Check that the certificate or profile on the device has not expired, since these are normally issued with a fixed life.
4. Try a different gateway or region if your setup has more than one, which tells you whether a single concentrator is struggling.
5. For repeated drops, pull the client logs and read the disconnect reason. An idle timeout is a policy setting and not a fault.

Prevention: VPN failures are among the most common help desk ticket examples in a remote-heavy team, so a standard set of intake questions saves a lot of back and forth. Pushing client updates through device management also keeps versions from drifting.

Escalate when several remote users drop at the same time. Check the concentrator before you touch any client.

Classification tag: Typically an incident, though a new setup is a service request.

DNS Resolution Failures

Why does it happen: The device is asking a resolver that either does not know the answer or is handing back an old one. Cached records, a VPN pushing its own DNS servers, or a public resolver hard-coded on the machine are the usual reasons one site fails while everything else loads.

Quick checks first

• Does the site load by IP address that alone tells you it is DNS
• nslookup the hostname and see which server answered
• Same site on a phone using mobile data
• Was the user on the VPN when it started

Deeper fix

1. Flush the cache, so ipconfig /flushdns on Windows or sudo dscacheutil -flushcache on macOS.
2. Check which DNS servers the adapter is set to. On a corporate network, they should be the internal ones and not 8.8.8.8.
3. Look at the hosts file. An old entry left over from a migration overrides everything, and it is easy to miss.
4. Query an external resolver directly with nslookup example.com 1.1.1.1. An answer there but not internally points at your own DNS.
5. For internal names, confirm the record still exists and that the zone is replicating between domain controllers.

Prevention: TTLs on anything being migrated should be lowered ahead of the change, so the old answer stops being cached for a day.

Escalate when internal name resolution is failing broadly. DNS problems on a domain break authentication and file shares along with browsing, so that is a major incident.

Classification tag: Typically an incident.

Wireless Signal Interference or Dead Zones

Why does it happen: Signal drops off with distance and with whatever is in between, so a meeting room behind a concrete wall or a corner desk at the edge of coverage will be weak, whatever the laptop does. Microwaves, cordless headsets, and neighboring networks on the same channel add to it 2.4 GHz.

Quick checks first

• Where exactly, this is a location problem, and it needs a location
• Does it happen to everyone in that spot
• Signal strength reading at the desk and again next to the AP
• Anything new in the space, a screen, a partition, a new machine

Deeper fix

1. Map it. Walk the area with a Wi-Fi analyzer app and note strength and channel as you go.
2. Look at channel overlap on 2.4 GHz. Three access points on the same channel will interfere with each other.
3. Check whether the client is holding on to a distant AP instead of switching to the near one. This is a sticky client, and it is common on older laptops.
4. Move or add an access point where the readings show a genuine gap. Turning the power up on the existing one usually makes things worse.
5. Give people in known dead zones an Ethernet run where that is possible, since it is cheaper than fixing the coverage.

Prevention: A survey after any office layout change can help, because new walls and furniture change coverage more than people expect.

Escalate when a genuine coverage gap needs hardware. That becomes a facilities and network project rather than a ticket.

Classification tag: Typically a service request.

Performance and System Issues

Performance tickets are the most common IT help desk problems after access and network, and they are also the ones users describe worst. The common IT problems and solutions in this category all start the same way, which is getting a specific symptom out of a vague complaint before you touch anything.

Slow Computer or Laggy Performance

Why does it happen: Slow is nearly always one of four things, so the memory is full, the disk is full or failing, too much starts with the machine, or something is running in the background that should not be. The age of the hardware sets a ceiling, but it is rarely the cause on its own.

Quick checks first

• Open Task Manager or Activity Monitor and sort by memory, then by CPU
• Free space on the system drive under 10 percent will slow down anything
• How long since the last restart, three weeks of uptime is common and it matters
• Slow all the time, or only inside one application

Deeper fix

1. Restart properly. Shut down and start again instead of closing the lid, because fast startup on Windows keeps the old session.
2. Look at what is holding the memory. A browser with forty tabs and Teams alongside it will take 8 GB by itself.
3. Trim the startup items from the Startup tab in Task Manager. Anything with a high startup impact that the user does not need at login can go.
4. Check the disk with the vendor tool or CrystalDiskInfo and read the SMART status, since a failing drive shows up as general slowness long before it fails properly.
5. Clear temp files and old user profiles, and look for a sync client or an antivirus scan running through the working day.
6. If the machine has 8 GB of RAM and the user runs design or development tools, the answer is more RAM and not more troubleshooting.

Prevention: A standard spec per role and a refresh cycle that is actually followed will stop most of these tickets from being written.

Escalate when SMART reports warnings or the drive is throwing errors. That becomes a hardware replacement, with a backup taken before anything else.

Classification tag: Typically a service request.

Application Errors and Crashes

Why does it happen: An application that crashes for one person and nobody else is usually a corrupt local profile, a bad update, or a conflict with something else on that machine. When it crashes for everyone at once, look at a release that went out or at a service the app depends on.

Quick checks first

• Does it crash on open, or at one particular action
• One user or several, ask in the team channel before you start digging
• Was the app or the OS updated in the last few days
• Same file or same action on another machine

Deeper fix

1. Get the exact error text or a screenshot. "It crashed" and "it says the file is in use" are two different tickets.
2. Open Event Viewer, then Windows Logs, then Application, and find the Application Error entry with the faulting module name. That name is usually the answer.
3. Start the app with add-ins disabled where it supports it. Office apps open in safe mode if you hold Ctrl while launching.
4. Repair the installation before you reinstall it, since a repair keeps the user's settings.
5. Rename the local cache or profile folder for that app so it rebuilds clean on the next launch.
6. Roll back the last app update if the crashes started with it, and hold that version until the vendor patches.

Prevention: Testing app updates on a small pilot group before a broad push keeps one bad release from turning into thirty tickets.

Escalate when the same crash reaches multiple users. Then it is an incident, and the app owner or the vendor needs it rather than L1.

Classification tag: Typically a service request, an incident when several users are hit.

Blue Screen of Death (BSOD)

Users still call it a blue screen, but on Windows 11 24H2 and later, the crash screen is black. Microsoft dropped the frowning face and the QR code, and the stop code now sits at the bottom with the faulting driver named next to it where Windows can identify one.

Why does it happen: A stop error means the kernel hit something it could not recover from, and a driver is behind most of them. Failing memory and a dying disk make up most of the rest.

Quick checks first

• Write down the stop code exactly, it is the most useful thing on that screen
• Note the faulting driver if one is shown, something like nvlddmkm.sys
• What changed recently, a driver, an update, new hardware, a docking station
• Does it crash at boot, at wake, or only under load

Deeper fix

1. Read the stop code as a direction and not as an answer. MEMORY_MANAGEMENT and PAGE_FAULT_IN_NONPAGED_AREA point at RAM or at a driver writing where it should not. DRIVER_IRQL_NOT_LESS_OR_EQUAL names a driver almost every time. CRITICAL_PROCESS_DIED and INACCESSIBLE_BOOT_DEVICE point at the disk or the storage driver. SYSTEM_SERVICE_EXCEPTION is usually a third-party driver or a security product.
2. Boot into safe mode. Hold Shift while clicking Restart, or interrupt the boot three times to land in WinRE, then Troubleshoot, Advanced options, Startup Settings, Restart, and F4 for safe mode or F5 for safe mode with networking.
3. Roll back whatever changed. Device Manager for a driver, or Uninstall Updates inside WinRE for a Windows update. If the crashes started the day a driver went on, treat that as the cause until it is ruled out.
4. Run Windows Memory Diagnostic for the memory-related codes, and reseat or swap the RAM sticks where the machine allows it.
5. Run chkdsk /f /r and read the SMART status for the storage codes.
6. If it is still crashing, take the minidump from C:\Windows\Minidump and open it in WinDbg or BlueScreenView. The !analyze -v output names the module and ends the guessing.

Prevention: Driver updates should go out through device management on a tested set, because vendor auto-updates cause a fair share of these.

Escalate when the same stop code shows up across several machines, especially after a patch cycle. That is a fleet problem, and the rollout needs stopping.

Classification tag: Typically an incident.

Browser Issues

Why does it happen: The browser holds a lot of state, so a cached file, a stale cookie, an extension, or a proxy setting is what usually breaks it. Certificate warnings and blocked pages tend to come from the network side and not from the browser at all.

Quick checks first

• Same page in an incognito window, which takes out extensions and cache together
• Another browser on the same machine
• Same page on a phone that is off the corporate network
• Exact error text, the ERR_ codes are specific and worth reading

Deeper fix

1. Clear cache and cookies for that one site instead of everything, since a full clear signs the user out of every tool they use.
2. Disable extensions and turn them back on one at a time. Ad blockers and security extensions break internal applications regularly.
3. Check the proxy setting and any PAC file at the system network level, not only inside the browser.
4. Update the browser and close every window. Chrome and Edge keep running the old version until the last one is shut.
5. Create a fresh browser profile if the crashes continue, which separates a corrupt profile from a genuine fault.
6. For certificate warnings, check the system clock and whether your firewall's inspection certificate is installed on that machine.

Prevention: Managing extensions through browser policy, so an allowlist instead of whatever people install, removes a lot of the repeat work here.

Escalate when a certificate or proxy problem is hitting everyone. That one belongs with the network or security.

Classification tag: Typically a service request.

Cloud Storage Sync Conflicts

Why does it happen: Two people edit the same file, or one person edits it on two devices while one of them is offline, and the client cannot work out which version should win, so it keeps both. Long file paths, a locked Office file, and a full local disk will stop the sync as well.

Quick checks first

• Read the sync client's status icon, it names the error better than the user will
• Free space locally, since sync stops quietly when the disk fills
• Is the file open in Office somewhere else, including on another device
• Path length and file name, OneDrive still struggles past 255 characters and with characters like : and *

Deeper fix

1. Find the conflicted copies. OneDrive appends the machine name, Dropbox writes "conflicted copy", and Google Drive keeps the older version in file history.
2. Compare the versions with the user before deleting anything. Do not pick one for them.
3. Close the file everywhere, then pause and resume sync so the client compares again from scratch.
4. Unlink and relink the account when the client is stuck, and let it re-index instead of deleting the local folder.
5. Rename the file or shorten the path where that is the cause, then confirm it syncs through.
6. Move genuinely shared documents into a shared library or a Team drive, where co-authoring handles simultaneous edits instead of the sync client trying to.

Prevention: Shared work should live in shared libraries with co-authoring on, and personal sync folders should hold personal files. That one distinction prevents most conflicts.

Escalate when sync fails for a whole team or a whole library. Check the service status page first, then the tenant.

Classification tag: Typically a service request.

Email and Communication Tool Issues

Email and the communication tools account for a good share of help desk common issues, and they are the ones users notice fastest. A bounce-back or a call that will not connect gets reported within minutes, so these tickets usually arrive with some urgency already attached.

Can't Send or Receive Email

Why does it happen: Sending and receiving fail for different reasons, so separate the two before anything else. Outbound failures are normally a rejection from the receiving side, and the bounce message states why. Missing inbound mail is usually a rule, a filter, or a message sitting in quarantine.

Quick checks first

• Read the bounce properly, the 5xx code and the text after it name the reason
• Webmail as well as the desktop client, which splits a mail problem from a client problem
• Rules and the junk folder, an old rule filing mail into a subfolder is common
• Quarantine in whatever mail security tool you run

Deeper fix

1. Read the code. 550 is a permanent rejection, so a bad address, a blocked sender, or a recipient policy. 421 and 451 are temporary, and the mail will normally retry on its own.
2. Run a message trace in Exchange Online or the Google Workspace admin console. It shows whether the message left, where it stopped, and what the receiving server said back.
3. Where a domain keeps rejecting you, check the SPF, DKIM, and DMARC records, since these sit behind most reputation-based rejections now.
4. Check whether the account has landed on the restricted senders list. That happens after a compromise or after sending too much in a short window.
5. For a client that will not connect at all, rebuild the mail profile instead of repairing it and let the mailbox download again.
6. For missing inbound mail, turn off rules one at a time and look at forwarding also, because forwarding set quietly is a sign of a compromised account.

Prevention: SPF, DKIM, and DMARC should be configured properly and then monitored, as these break silently and only surface later as bounces.

Escalate when several users cannot send to the same domain, or when mail flow stops altogether. That is an incident, and it needs checking at the tenant level.

Classification tag: Typically an incident.

Mailbox Full or Out of Storage Quota

Why does it happen: Quotas fill up from attachments, from shared mailboxes nobody manages, and from years of sent items nobody deletes. There is a warning stage first, then sending gets blocked, and most users only report it at the second stage.

Quick checks first

• Current mailbox size against the quota, taken from the admin console
• Which folders are large, usually Sent Items, Deleted Items, and the Recoverable Items folder the user cannot see
• Is an archive policy applied to this account at all
• Any PST or local archive already in place

Deeper fix

1. Confirm the real size in the admin center and not in the client, since the client under-reports.
2. Empty Deleted Items and Junk, then check Recoverable Items, which holds deleted mail for the retention period and still counts against the quota.
3. Sort by size and clear the large attachments. A handful of 40 MB files usually accounts for most of the problem.
4. Turn on the online archive and set a policy to move mail older than a year. This is the fix that actually holds.
5. Raise the quota if licensing allows it, but do that alongside the archive and not instead of it.
6. For a shared mailbox, agree with the owner before you clean it out, otherwise, it fills again in a few months.

Prevention: Archive policies applied by default at onboarding, and people sharing links instead of attaching files, keep mailboxes away from the limit.

Escalate when the quota cannot be raised without a license change. That turns into a purchasing decision and not a support one.

Classification tag: Typically a service request.

Calendar Sync Issues Across Devices

Why does it happen: A meeting showing on the laptop but not the phone means two clients holding different copies, and a stale cached calendar or an account added twice on the phone is normally why. Invites from outside the organization and calendars managed by a delegate are the other regular causes.

Quick checks first

• Which device is right, this decides everything after it
• Is the account added more than once on the phone
• Was the meeting organized externally, or accepted on behalf of by a delegate?
• Time zone setting on each device

Deeper fix

1. Compare against webmail, which holds the server copy and settles which device is wrong.
2. Remove and re-add the account on the device that is out of date, rather than forcing a refresh on it.
3. Check delegate permissions where an assistant manages the calendar, and clear any duplicate delegate entries.
4. Look for a second calendar app subscribed to the same account. The built-in iOS calendar and a third-party client both writing will duplicate items.
5. For duplicated meetings, have the organizer cancel and reissue the series instead of deleting single occurrences.
6. Confirm the time zone and the automatic time zone setting on both devices, because a mismatch shifts every meeting by the same amount.

Prevention: One calendar client per device, and delegate access reviewed whenever someone changes role, avoids most of this.

Escalate when calendars are out of step for a whole team or for a room resource. Room mailboxes need admin attention and not device work.

Classification tag: Typically a service request.

Video Conferencing Problems

Why does it happen: Camera and microphone failures are almost always the wrong device selected or another application holding it, since only one app can use a camera at a time on most systems. Echo comes from a microphone picking up speakers, and dropped calls come from the network underneath.

Quick checks first

• Which device is selected inside the app's own audio and video settings, not in Windows
• Is another meeting app running in the background, Teams and Zoom will both hold the camera
• Was the headset connected before the app opened, or plugged in afterwards
• Wired or wireless, and is anyone else in the house on a call at the same time

Deeper fix

1. Close every other conferencing app fully, including the ones still sitting in the system tray.
2. Set the device in the app settings and then run the app's own test call. Zoom, Teams and Meet each have one.
3. Check the OS privacy permissions, so Settings, Privacy, Camera and Microphone on Windows, or System Settings, Privacy and Security on macOS. A denied permission looks exactly like broken hardware.
4. For echo, get the person onto a headset. Echo is nearly always one participant on open speakers, and it is not always the person who reported it.
5. For drops, move the user onto Ethernet and check whether they are on the VPN, since routing meeting traffic through a VPN is a common cause of poor call quality.
6. Update the client, and reinstall where the camera is still not detected. These clients install their own drivers, and a broken install presents this way.

Prevention: A standard headset issued with every laptop, and split tunneling set so meeting traffic skips the VPN, should remove most of these calls.

Escalate when quality is poor across a team or a whole office. Then it is network capacity and not a client problem.

Classification tag: Typically a service request, an incident when many people are affected at once.

Slack or Teams Notifications Not Arriving

Why does it happen: Notifications can be suppressed at three separate points, so the app, the operating system, and the phone each have their own settings. A do-not-disturb schedule someone set months ago is the most common answer, and a muted channel is the second.

Quick checks first

• Do Not Disturb inside the app, and the schedule attached to it
• Notification settings for that specific channel, muted channels stay quiet
• OS notification permissions for the app
• Focus assist on Windows, or Focus mode on macOS and iOS

Deeper fix

1. Work down in order, so app settings, then OS settings, then the phone. Fixing one and skipping another is why this ticket keeps coming back.
2. Check desktop and mobile separately. Slack holds back mobile notifications while it believes the user is active on desktop.
3. Look at whether mention and keyword notifications are set the way the user expects. Plenty of people select "only mentions" and then wonder why channel messages are quiet.
4. Sign out and back in on the device that is not notifying, which re-registers it for push.
5. Reinstall the mobile app if push still does not arrive after that, because push tokens do get stuck.
6. For a whole workspace with no notifications, check the status page before you touch any device.

Prevention: A short note at onboarding on how notifications are configured, along with an agreed convention for which channels are urgent, stops people from muting everything and missing the ones that matter.

Escalate when notifications stop across a whole workspace or tenant. Check the vendor status page, then raise it with the vendor.

Classification tag: Typically a service request.

Software and Application Issues

Software tickets are the IT help desk problems and solutions people expect to be quick, and then they are not. An install that fails, a license that will not activate, or a SaaS app throwing errors all look like five-minute jobs until you find what is actually causing them.

Application Won't Install or Update

Why does it happen: Most failed installs come down to permissions, disk space, or a previous version that did not remove itself cleanly. On a managed device, the more likely reason is the deployment itself, so the package was never assigned or it failed on the way down.

Quick checks first

• Does the user have local admin rights, and should they
• Free disk space, since installers need room for temp files as well as for the app
• Was an older version there before, and did it uninstall properly
• Is the app in your company portal, or is the user downloading it themselves

Deeper fix

1. Read the actual error code. MSI 1603 is a generic failure and only tells you to go to the log, 1618 means another installation is already running.
2. Open the install log. Windows writes MSI logs into %temp%, and your deployment tool keeps its own record.
3. Close whatever else is installed. Windows Update running in the background will block an MSI without saying so.
4. Remove the old version with the vendor's cleanup tool where one exists, because leftover registry keys block reinstalls.
5. Install from the company portal instead of a downloaded file, so the version and the configuration match the rest of the fleet.
6. For an update that keeps failing, uninstall and install the current version fresh rather than updating over the top.

Prevention: Packaging applications centrally and pushing them through device management takes away the admin rights question and the version drifts at the same time.

Escalate when the package fails on more than one machine. That is a packaging or deployment fault, and it belongs with whoever owns software distribution.

Classification tag: Typically a service request.

Software License Activation Failures

Why does it happen: The license might not be assigned to that user, the seat count might be used up, or the app might be signed into a different account than the one holding the license. Activation also fails when the machine cannot reach the vendor's activation server, which happens behind strict firewall rules.

Quick checks first

• Which account is the app signed into, plenty of users have two
• Is a license assigned in the admin portal, and are there seats free
• Was the machine reimaged or the hardware changed, some licenses bind to it
• Can the machine reach the vendor's activation endpoint at all

Deeper fix

1. Confirm the license assignment in the vendor portal first. It is the answer more often than anything on the device is.
2. Sign the user out of the application completely, then back in with the licensed account.
3. Free up a seat where the count is full, usually by removing a leaver who was never deprovisioned.
4. Release the old activation from the admin console for a reimaged machine, since the license is still held by a device that no longer exists.
5. Check firewall and proxy rules against the vendor's activation domains, and allowlist them where they are being blocked.
6. Reset the local licensing cache where the vendor documents how, then activate again.

Prevention: Reviewing license assignments as part of the leaver process keeps seats available and stops you buying licenses you already own.

Escalate when activation fails across the organization after a renewal. That is a contract or tenant-level problem, and no amount of device work will fix it.

Classification tag: Typically a service request.

SaaS App Not Loading or Showing Errors

Why does it happen: The fault is either at the vendor, somewhere on the network in between, or in the browser session itself. Users report all three the same way, so the first job is working out which side is actually broken.

Quick checks first

• The vendor's status page, before you do anything else
• Does it load for anyone else, ask in the support channel
• Incognito window, which rules out cache and extensions in one step
• Off the corporate network, on a phone using mobile data

Deeper fix

1. Check the status page and the vendor's incident feed. There is no sense in troubleshooting a laptop during a vendor outage.
2. Where it works for other people, treat it as a session or permission. Sign out, clear cookies for that domain, and sign back in through SSO.
3. Open developer tools and read the console and network tabs. A blocked request or a CORS error tells you the problem is on the network path.
4. Look at whether a firewall rule, a DNS filter, or a security proxy is blocking part of the application. Apps that load halfway usually mean a blocked subdomain and not a blocked domain.
5. Confirm the user still holds the right role inside the app, because permission errors get presented as loading errors in a lot of SaaS products.
6. Raise a vendor ticket with the console output and a HAR file attached when you cannot find anything on your own side.

Prevention: Subscribing the team to status pages for the applications you depend on means you hear about an outage before the tickets do.

Escalate when the app is down for everybody. Confirm it, post one update to users, and run it as an incident instead of answering the same ticket forty times.

Classification tag: Typically an incident if system-wide, a service request for a single user.

Browser Extension or Plugin Conflicts

Why does it happen: Extensions run inside the page and can change what an application does, so an ad blocker, a password manager, or a security extension will break an internal tool with no warning at all. Office add-ins do the same thing to Outlook and Excel.

Quick checks first

• Clean profile or incognito, where extensions do not load by default
• What was installed or updated recently, extensions update themselves quietly
• Same behavior in a second browser
• For Outlook or Excel, does the app work in safe mode

Deeper fix

1. Disable everything, confirm the problem goes away, then enable one at a time until it returns.
2. Look at what the suspect extension is permitted to do. The ones with read and change access on all sites are usually behind it.
3. For Office, disable COM add-ins from File, Options, Add-ins, and restart the app between each one.
4. Remove rather than disable anything the user does not need, because disabled extensions get switched back on by updates.
5. Where a needed extension conflicts with a needed application, check the vendor release notes. These get fixed regularly, and the user is often on an old build.
6. Put the working set into browser policy so it stays the same across machines, and block installs outside that list.

Prevention: An extension allowlist managed through browser policy is the practical answer here, since users will keep installing things otherwise.

Escalate when an auto-updated extension breaks a business application for everyone using it. That needs a policy change centrally and not a fix on each machine.

Classification tag: Typically a service request.

Hardware and Peripheral Issues

Hardware still creates help desk problems, just less of the queue than it used to. Three groups cover nearly all of it now, and most of the fixes are short ones.

Keyboard, Mouse, and USB Device Problems

Why does it happen: Input devices fail at the connection far more often than in the device itself, such as a port, a cable, a dongle, or a flat battery. When Windows reports that a USB device is not recognized, it usually means the port stopped supplying power, or the driver enumerated incorrectly, and the device itself is rarely broken.

Quick checks first

• A different port, ideally one on the machine rather than on a hub or a dock
• Same device on another machine, which settles device against machine in one step
• Batteries and the power switch on wireless devices, and is the dongle seated properly
• Bluetooth turned on, and is the device already paired to something else nearby

Deeper fix

1. Unplug it, wait, and plug it into a different port. Repeated plugging and unplugging into the same port is what stops a device from enumerating.
2. Open Device Manager and look for the yellow warning icon. Uninstall the device there, then scan for hardware changes so the driver rebuilds itself.
3. Turn off USB selective suspend in the power plan, because power saving disconnects devices on laptops and the user experiences it as random.
4. Update chipset and USB drivers from the laptop vendor and not from Windows Update, since the generic ones cause this on newer machines.
5. Remove and re-pair Bluetooth devices, and delete the old pairing on whatever else it was connected to.
6. Test with a known-good device before ordering a replacement. Sticking keys and dead trackpads are real, they are just the minority.

Prevention: Keeping a small stock of spare keyboards, mice, and cables at the desk turns a lot of these into a swap instead of a ticket.

Escalate when ports fail across a batch of the same model. That is a hardware fault or a firmware issue, and it needs the vendor.

Classification tag: Typically a service request.

Printer and Scanner Issues

Why does it happen: Print problems land in three buckets, so connectivity, drivers, and consumables. A queue holding jobs is the most common of the three, and all the user sees is that nothing came out.

Quick checks first

• Is the printer online, and is anything sitting in the queue
• Correct printer selected, since defaults change on their own after updates
• Paper, toner, and whatever the panel is showing
• Can anybody else print to it

Deeper fix

1. Clear the queue and restart the print spooler, so services.msc, Print Spooler, restart.
2. Remove the printer and add it back by IP address rather than by discovery, which stops it moving when DHCP changes.
3. Install the vendor driver instead of the generic one where the printer has features the generic driver cannot reach.
4. Give network printers a reservation or a static address, because a printer that changed IP looks broken to everyone mapped to the old one.
5. Clear jams by following the panel and pulling in the direction the paper travels, then look for a torn piece left inside, as that is what causes the next jam.
6. For scanners, check the destination. Scan to email and scan to folder fail at the SMTP settings or the share permissions, not at the scanner.

Prevention: A print server or a cloud print service with drivers deployed centrally avoids the driver-per-machine work altogether.

Escalate when a shared or floor printer is down, and nobody can print. That is an incident even though it feels routine.

Classification tag: Typically a service request, an incident when a shared device is down.

External Display and Docking Station Failures

Why does it happen: A dock carries video, network, and power over one cable, so when it fails, everything attached fails together, and the user reports whichever part they happened to notice. Cable specification and dock firmware are behind most of it, particularly on USB-C, where a cable that charges will not always carry video.

Quick checks first

• Plug the monitor straight into the laptop and take the dock out of it
• Is the cable rated for the resolution being asked of it
• Windows key and P, or display settings on macOS, to see whether the display is detected but not extended
• Does the same dock work with a different laptop

Deeper fix

1. Power cycle the dock properly, so unplug it from the mains for thirty seconds and not just from the laptop.
2. Update the dock firmware from the vendor. Docks do have firmware, and nobody updates it until something breaks.
3. Update the graphics driver, and roll it back if the displays stopped working right after an update went on.
4. Detects displays manually in display settings, then check the resolution and refresh rate the cable can actually carry.
5. Reduce the load where two 4K monitors run through one dock, since bandwidth over a single connection is limited and the second display is the one that drops.
6. Swap the cable before you swap the dock. Cables fail more often, and they cost less.

Prevention: Standardizing on one dock model and one cable specification per laptop model removes most of the variation that causes these tickets.

Escalate when the same dock model starts failing across the fleet after a firmware or driver release. Stop deploying it and get the vendor involved.

Classification tag: Typically a service request.

Security and Data Issues

Security tickets sit apart from the rest of the common help desk issues and solutions in this guide, because getting one wrong costs a great deal more than a slow laptop does. The steps below matter. The escalation lines matter more.

Suspected Phishing Email

Phishing works because it looks routine, so a shared document, a password expiry notice, or an invoice. Two versions of this ticket arrive, and they are not the same job. Someone forwarding a suspicious message is a report. Someone who already clicked and typed their password is an incident, and the clock is running.

Why does it happen: Mail filtering catches most of it, and the messages that get through are the ones written well enough to pass. Users are the last control, which is why the reporting path needs to be easy.

Quick checks first

• Did they click, and did they enter credentials or approve an MFA prompt
• Was an attachment opened, and was macro content enabled
• Full message headers, not a screenshot of the email
• Has the same message landed anywhere else, search across the tenant

Deeper fix, where the message was reported and not clicked

1. Get the original as an attachment or through the report button, so the headers survive.
2. Read the sender's real address and the authentication results in the headers, since display names are spoofed easily.
3. Search the tenant and purge every copy, not only the one that was reported to you.
4. Block the sender, the domain, and any URLs at the mail gateway and the web filter.
5. Write back to the person who reported it and tell them what it was. People who get an answer will report the next one.

Deeper fix, where the user clicked

1. Reset the password and revoke active sessions straight away, because a session token stays valid after a password change on its own.
2. Re-register MFA if they approve a prompt or read out a code.
3. Look for mailbox rules and forwarding created in the last few days. These get set within minutes to hide the replies.
4. Review sign-in logs for unfamiliar locations, and check whether anything was sent from the account.
5. Isolate the machine and scan it where an attachment was opened.

Prevention: Reporting should be one click inside the mail client, and users should hear back afterwards. Awareness training helps, though an easy report button helps more.

Escalate when credentials were entered, when an MFA prompt was approved, or when the same campaign has reached several mailboxes. Those are security incidents from the first minute, and they should not be sitting in an L1 queue.

Classification tag: Typically an incident.

Virus or Malware Infection

Why does it happen: Most infections now arrive through something the user was persuaded to download and run, or through a browser prompt dressed up as a system message, rather than through an email attachment. Detection usually comes from the endpoint tool and not from the user noticing anything.

Quick checks first

• What the endpoint protection actually reported, the detection name tells you what you are dealing with
• When the behavior changed, and what was installed or downloaded around then
• Is the machine still on the network
• Is the same detection showing anywhere else

Deeper fix

1. Disconnect it from the network first, so pull the cable and turn off Wi-Fi. Leave it powered on, since shutting down loses whatever is in memory.
2. Take the detection details from the console, so the file path, the hash, and the detection name.
3. Run a full scan from the management console rather than locally, and let it quarantine what it finds.
4. Look for persistence, such as scheduled tasks, run keys, and services created recently.
5. Reset the user's credentials also, because anything with credential theft in it makes the account suspect too.
6. Reimage where it is ransomware, a rootkit, or where you cannot say with confidence what the thing did. Reimaging is faster than being wrong about it.

Prevention: Application control and taking away local admin rights stop most of this at the point of execution, and they do more than any amount of scanning does.

Escalate when files are encrypted, when the detection appears on more than one machine, or when a server is involved. Ransomware is a major incident and every minute of containment counts.

Classification tag: Typically an incident.

Data Loss or Accidental File Deletion

Why does it happen: Files go missing through deletion, through a sync client removing them everywhere after one device deleted them, or through a move the user does not remember making. Genuine loss is less common than people assume, and most of these tickets end with the file being found somewhere.

Quick checks first

• Where was it saved, a local disk, a network share, or a sync folder
• Recycle bin on the machine, and the online recycle bin in OneDrive or SharePoint as a separate place
• Search by file name and by content, including inside the sync client's own search
• Recent files list in whatever application created it

Deeper fix

1. Stop writing to the disk immediately where it was genuinely local with no backup, since continued use overwrites what you are trying to get back.
2. Check the second recycle bin. SharePoint and OneDrive keep a site collection recycle bin that holds files after the first one is emptied.
3. Use version history before you reach for recovery tools, because a file that was overwritten rather than deleted comes back in seconds from there.
4. Restore from backup at the closest point before the deletion, and restore into a different location so nothing current gets overwritten.
5. For a file share, check whether shadow copies are on, as previous versions from the properties tab recover this without a restore request.
6. Confirm with the user that the recovered version is the one they wanted before closing.

Prevention: Files should sit in synced or backed-up locations by default, and desktop folders should be redirected, because a laptop drive is the one place where no copy of anything exists.

Escalate when the data was local with no backup, or when the deletion looks deliberate. The second one is an HR and security matter, and it should not be handled quietly at the desk.

Classification tag: Typically a service request, an incident where business data has been lost.

Compromised Account

Why does it happen: Accounts get taken over through phishing, through a password reused on a site that was breached, or through MFA fatigue, where somebody approves a prompt just to make it stop. The first sign is normally a sign-in from a country nobody works in, or colleagues receiving mail the user never sent.

Quick checks first

• Sign-in logs, so location, IP, device, and whether MFA was actually satisfied
• Mailbox rules and forwarding, checked at the mailbox and not in the Outlook client
• Sent items, including the recently deleted ones
• Any consent granted to a third-party application

Deeper fix

1. Block sign-in and revoke every session immediately. A password reset by itself leaves valid tokens behind.
2. Reset the password, then re-register MFA from scratch.
3. Delete the rules, forwarding addresses, and app consents that were created, and check delegate access as well.
4. Work out what was reachable, so mail, files, and anything the account had SSO into.
5. Warn the people who received messages from the account before they act on them.
6. Give access back only once the account is clean, and tell the user what happened and what changed.

Prevention: Phishing-resistant MFA, such as hardware keys or passkeys, closes off most of this, and conditional access rules on impossible travel catch a good part of what gets through.

Escalate immediately. A compromised account is an incident from the point it is suspected and not from the point it is confirmed, so it should reach whoever owns security on the same call. Where the account holds admin rights or can reach customer data, the incident management process should be running alongside the containment steps and not after them.

Classification tag: Always an incident.

Tricky Scenarios L1 Techs Run Into

There are a few situations which do not really fall under any of the categories above, and they come up often enough that a new technician should know what to do with them, such as:

• When the user is telling you that something is broken but nothing on your side shows a problem, you should stop checking the monitoring, because usually it is the wording of the complaint which is wrong and not the system, so a "the whole system is down" ticket can easily turn out to be one page which is not opening for that one person, and a screen share will show you that within a minute or two.
• If you are clearing the same cache or resetting the same password every second day, then something is putting the machine back to that state again, and the real cause is still sitting there untouched, so all of those repeats should be logged on one recurring issue and then handed over to problem management.
• For a problem which only one person out of two hundred is having, the difference will be somewhere on their side, so their device, their group memberships, the version of the app, and whatever changed for them last week should be compared against a colleague who is doing the same job.
• Several people reporting the same thing inside a few minutes should be picked up as a major incident response and not worked as separate tickets, because the thing you want to avoid is three or four technicians each troubleshooting the same outage on their own while nobody has updated the rest of the company about it.

Where These Tickets Come From and Why Intake Matters

Every issue in this guide has to reach you somehow, and by now that happens through a portal, through email, through a Slack or Teams DM, through a chat widget, or through somebody walking over to your desk. The channel changes your first response more than people expect it to. A portal ticket arrives with the fields already filled in, so you know the user, the device, and the priority before you have read a word of it. A Slack message saying "my VPN is down" arrives with none of that, so the first thing you do is collect what the form would have collected, and you are doing it in a conversation where the person is sitting there waiting on you.

The bigger issue with informal channels is that the work does not get counted. A request fulfilled by an agent over the DM never enters the system, so you miss the volume figures, category breakdowns, and SLA reporting too. The reports then show a quiet week which the team did not actually have, and the same question can get answered ten separate times because nobody could see it had been answered already. Whichever channels you allow, each request should end up recorded in one place, which is the whole point of running a help desk ticketing system rather than letting the channel decide what gets tracked. Suptask handles this by creating the ticket from the Slack conversation itself, so a request raised in an IT channel is tracked without the user leaving Slack or filling in a separate portal.

How to Reduce Common Help Desk Issues Over Time

Most of the common help desk issues and solutions in this guide keep repeating because nothing was changed after the last time they came up. A few practices bring the volume down, and they are the following.

• A knowledge base should be written for the issues that keep arriving, and the articles need to be pushed into the support channel automatically when somebody asks that question, because otherwise people will not go looking for them on their own.
• Password resets, software installs, and access requests are the three categories worth automating first, since they follow the same steps every single time and together they take up a large part of the queue.
• You cannot reduce a volume you are not measuring, so ticket categories and resolution times should be tracked properly and then looked at every month to see which category has been growing.
• Predictable service requests can be pushed to self-service, and the agents should be kept for incidents, which is the work that actually needs a person on it.
• A fair number of these tickets are created by users themselves, so password habits and where people are saving their files are worth spending a bit of time on, and that time normally costs less than the tickets do.

Reducing the volume is only one part of running a desk, and the broader help desk best practices also cover staffing levels, escalation paths, and the way the queue gets worked through each day.

Frequently Asked Questions

What are the most common IT help desk issues?

The most common IT help desk issues are password resets and account lockouts, network and Wi-Fi problems, VPN failures, slow computers, application crashes, email delivery and mailbox problems, printer faults, and security tickets like phishing reports. Account and access problems make up the largest share in most organizations. The mix changes with how a company works, so a remote-heavy team will see more VPN and conferencing tickets than an office-based one.

What percentage of help desk tickets are password resets?

Gartner has estimated that password resets account for somewhere between 20 and 50 percent of all help desk calls. The range is wide because it depends heavily on whether self-service reset is in place and how strict the expiry policy is. Organizations with self-service password reset and single sign-on usually sit at the bottom of that range or below it.

How do you handle a difficult help desk ticket?

Deal with the person before you deal with the problem, so acknowledge the impact, confirm what you have understood, and give them a realistic next step instead of a promise you cannot keep. Keep the ticket updated even when there is no progress, since silence is what turns a frustrated user into a complaint. If the request is out of scope or against policy, say so plainly and explain what can be done instead.

What should an IT help desk fix first when multiple tickets come in at once?

Work by impact and urgency rather than by arrival order, so anything affecting many users or stopping business-critical work goes first. Check for a pattern before you start, because several tickets describing the same symptom are usually one incident and should be handled as one. Single-user requests that are quick to close can be cleared alongside, though they should not push a major issue down the queue.

What is the difference between L1, L2, and L3 help desk support?

L1 is the first point of contact and handles the high-volume, well-documented work such as password resets, access requests and basic troubleshooting, with a target of resolving most tickets without passing them on. L2 takes what L1 cannot resolve and has deeper technical access, so configuration changes, server and application work, and problems needing investigation. L3 is the specialist or engineering level, dealing with root cause analysis, code-level faults and vendor escalations, and it usually sits outside the help desk team itself.

How do you reduce help desk ticket volume?

Start by measuring which categories are actually driving the volume, because the answer is rarely what people assume. After that, automate the repeatable requests like password resets, software installs, and access requests, publish knowledge base articles for the issues that keep returning, and route users to them from the channel where they ask. Fixing recurring incidents at root cause rather than closing the same ticket repeatedly is what removes volume permanently.

Make the Right Fixes Faster

The issues in this guide do not change much from year to year. What changes is how quickly you can identify what is wrong, classify it correctly, and get it to the person who can fix it, and that comes down to having a runbook the team actually follows and a ticketing system that captures the request where it was raised.

Track and resolve every IT ticket directly inside Slack with Suptask.