Document production helpdesk troubleshooting scenarios for Windows, networking, Linux, and user support ; demonstrating the diagnostic methodology, root cause analysis, and remediation process used in enterprise IT environments.
Environment: Simulated multi-user production environment | Windows 10/11, Active Directory, ServiceNow
- User reports browser shows "No Internet" or pages fail to load
- Other users on the same network are unaffected
- Device shows network connection as "Connected"
ipconfig: check IP address, subnet mask, default gateway, DNSping: test connectivity to gateway and external hosts (8.8.8.8)nslookup: verify DNS resolution is workingtraceroute/tracert: identify where packets are dropping- Windows Network Settings / Network Troubleshooter
- Run
ipconfig /all: confirm device has a valid IP (not 169.254.x.x APIPA) - Run
ping 127.0.0.1: verify local TCP/IP stack is functional - Run
ping <default gateway>: test connectivity to router - Run
ping 8.8.8.8: test external IP connectivity (bypasses DNS) - Run
nslookup google.com: test DNS resolution - If DNS fails, set DNS manually to 8.8.8.8 or 1.1.1.1 to isolate the issue
- Run
ipconfig /releasethenipconfig /renewto refresh DHCP lease - Run
netsh winsock resetif all above pass but browser still fails - Check if issue is browser-specific (try different browser or incognito)
- Escalate to network team if gateway is unreachable
Problem: User unable to access the internet despite showing as "Connected."
Investigation:
- Verified physical connectivity : cable seated, switch port active
- Ran
ipconfig /all: device showed APIPA address (169.254.x.x), confirming no valid DHCP lease - Pinged gateway — timed out, confirming network layer failure
- Confirmed DHCP server was temporarily unreachable during lease renewal window
Root Cause: Expired DHCP lease resulted in automatic APIPA self-assignment (169.254.x.x), preventing all network communication.
Resolution: Ran ipconfig /release and ipconfig /renew. Device obtained valid IP from DHCP server. Internet access restored immediately.
Preventive Action: Documented DHCP lease duration settings and verified DHCP scope had sufficient available addresses. Logged incident and resolution in ServiceNow.
During testing, ICMP connectivity to external IP addresses was successful using:
ping 8.8.8.8
However, DNS resolution testing with:
nslookup google.com
returned:
*** Unknown can't find google.com: No response from server
This indicates that basic network connectivity was functional, but DNS name resolution experienced issues communicating with the configured DNS server.
- Verified IPv4 connectivity
- Reviewed configured DNS servers using
ipconfig /all - Tested external connectivity with ICMP
- Confirmed issue was isolated to DNS resolution
Successful network connectivity does not always guarantee successful DNS resolution. Troubleshooting should isolate connectivity issues from name resolution failures.
- User receives "Network path not found" or "Access denied" when accessing shared drive
- Other users on the same team can access the folder without issues
- User was able to access it previously
ping: verify network connectivity to file servernslookup: confirm DNS resolution of server hostname- Windows Credential Manager : check stored credentials
- Active Directory Users and Computers : verify group membership and permissions
- Event Viewer : check for authentication or access errors
net use: view and manage mapped network drives
- Confirm the shared path is correct : ask user for exact path they are using
- Run
ping <server hostname>: verify network connectivity to file server - Run
nslookup <server hostname>: confirm DNS is resolving correctly - Try accessing the share via IP address instead of hostname — isolates DNS vs. access issue
- Check Windows Credential Manager — remove stale/cached credentials for the server
- Verify user is still a member of the correct AD security group (Active Directory Users and Computers)
- Check share permissions AND NTFS permissions — both must allow access
- Check Event Viewer on the server for Event ID 5140 (share access) or 4625 (failed logon)
- Re-map the drive using
net useor Group Policy if permissions are confirmed correct - Escalate to sysadmin if NTFS/share permissions require changes beyond helpdesk scope
Problem: User received "Access Denied" on a previously accessible shared network folder.
Investigation:
- Pinged file server : successful, confirmed network connectivity intact
- Attempted access via IP : same "Access Denied" error, ruled out DNS issue
- Checked Active Directory : user had been removed from the
FinanceTeamsecurity group during a routine quarterly access review - Confirmed share and NTFS permissions were correctly configured for the group
Root Cause: User was inadvertently removed from the Active Directory security group controlling access to the shared folder during a quarterly access review process.
Resolution: Re-added user to the FinanceTeam AD security group. User logged off and back on to refresh group membership token. Share access restored within 5 minutes.
Preventive Action: Flagged access review process for improvement ; recommended a verification step before removing users from production groups. Documented in ServiceNow and escalated recommendation to IT manager.
Loss of access to shared financial documents prevented the user from completing time-sensitive reporting tasks. Swift resolution within SLA avoided escalation to management. Process improvement recommendation submitted to reduce recurrence risk across the team.
Additional scenarios in progress: Password Reset & Account Lockout | Slow PC Performance | Printer Not Found | VPN Connectivity Failure