Everyone has their own frame of reference when it comes to how we perceive network performance and suspected problems. From the network provider, administrator, and helpdesk perspectives, it’s important to recognize a couple of key points:
- All network problems “feel” as though they are wireless issues to the general Wi-Fi user.
- The same problem may be described in multiple ways depending on the client.
With these points in mind, our charge is to help end users have as few problems as possible and to foster an effective communications environment so users can and will report problems with the most essential information to help us find a resolution quickly.
An Ounce (or Two) of Prevention
In a perfect world, end users simply wouldn’t have network problems. As nice as that sounds, even the best environments experience conditions that cause end users to perceive issues on occasion. If we do our jobs right, we build logical frameworks that both factor potential problems out and give us good data when trouble is reported. Hopefully the network was designed and implemented by skilled staff. Ideally, client devices are onboarded uniformly using a mechanism like Aruba ClearPass. And finally, we would have access to strong performance instrumentation like ArubaNetInsight to help us see problems before they manifest with users.
And When Problems Do Occur?
You want users to report problems – real or imagined. Timely response preserves reputational credibility for both the network and those who support it, and sometimes little issues mask big problems. However you get there, aim for a non-threatening climate and a clear process to report problems. Also make sure you collect good data along the way. Depending on your client device mix, BYOD factor, and skills of those people using the network, you might not get every bit of data you’d like in a trouble ticket. Ideally, users will provide as much of the below information as possible:
- Device MAC address
- User name (if applicable)
- SSID connected to, if multiple present
- IP address, if one was given
- Physical location
- Timestamp
- The best description of the problem they can give
- Is there a comparative device having/not having the same symptoms?
I’m a firm believer in growing a culture where the network is highly trusted, and both users and support staff are educated in suspecting individual client devices before they blame the network. It’s not easy getting there, but once you do, the information provided on trouble reports gets exponentially better than vague reports of “The Wi-Fi dropped yesterday, please fix it.”
Name Dropping Is Inevitable, Don’t Fall into the Trap
Anyone in the network support game for any amount of time has faced this unpleasant situation: Someone with a lofty title experienced network issues. Maybe they are on the warpath, or perhaps their staff is. Regardless, the message is often “You will change something on your end so this never happens again.” Diplomacy is also important in troubleshooting. Do what’s necessary to get the VIP squared away, but don’t panic and start making configuration changes that actually cause problems for others. All client devices get wonky on occasion, regardless of whom they belong to.
While users may perceive problems differently than you and I do, having the infrastructure in place and necessary data available to deal with said issues is key. And, the more we can train users and clients to provide as much detail as possible, the happier we all will be in the end.
Read My Other Blogs
Look in the Right Places to Troubleshoot Networks
Good Wireless Network Support Requires a Solid Tool Strategy
More Dashboards Do Not Equal Better Performance
