| Previous | Table of Contents | Next |
If you’ve read the manual, checked the databases, and you’re still stumped, it’s time to call the vendor. Whether you pay as you go for what seems to be a hopeless problem or have a support contract, a couple of strategies exist that will help maximize your encounter with a professional technical support person.
Primary in your efforts will be how well you’ve documented the problem during your troubleshooting efforts. If you’ve used SOAP notes during the problem, you probably already have exactly what a tech support person is wanting:
If you cannot reproduce a problem, neither can the folks at the other end of the phone. However, if you can reproduce the problem on a different workstation or a server, you’re that much closer to convincing technical support that your problem is a legitimate problem and not just a product of your network environment.
People who call tech support before they gather this crucial information typically receive the brush-off. (The irony is that once you’ve done the requisite research and documentation, the culprit is usually apparent, thus canceling your need to call technical support in the first place.) One brush-off technique is the finger-pointing game. Because you, a nonexpert, can’t prove that a problem is unrelated to a different vendor, it can be difficult to refute technical support’s claim that the problems lies with the other guy.
You can combat this by insisting on documented proof that you can submit to the maligned vendor—the vendor doing the maligning can tell you how to collect this proof—or by administering a test on your own. As you’ll see in Hour 21, “Tell Me About Your Network: Network Analyzers & Bits & Bytes,” you don’t have to be a network expert to be able to submit network traces to technical support. Network traces are basically blow-by-blow accounts of what’s happening on the wire, and they can be very useful to the network analyst on the other end of the line.
You can also combat finger-pointing by trying the same type of operation “manually,” without the influence of the item being pointed at. In other words, if a program complains that it cannot write a file to a server but you think it should be able to, try writing the same kind of file by yourself under the same login and session circumstances (don’t reboot or log out). Therefore, if the setup program says this:
Can’t copy “FOO.EXE” from D:\setup\foo to G:\myapp ñ Retry?
You might want to get to a DOS prompt and try typing the following:
C:\> COPY D:\setup\foo\FOO.EXE G:\myapp
Alternatively, you can use Windows Explorer to copy FOO.EXE from d:\setup\foo to g:\myapp.
| Finger-Pointing Fun
I once had a bizarre problem with a server—certain applications simply would not install. The common thread was that the install program involved complained that it could not write certain files to a certain directory. The application vendors said, “It installs fine on thousands of other servers just like yours!” The server vendor’s response was that these programs must be doing something odd while they’re installing. “No,” I protested, “more than one program is doing this—it must be the server!” The problem was set aside, until one of my technicians had the idea of performing a manual file copy of the files involved. In other words, one of the applications I was trying to install failed while it was copying the file KBSTUFF.SYS, so I simply typed
f:\> copy d:\setup\kbstuff.sys f:
and sure enough, I got an error—even though I could copy differently named files to that directory (and even though I had file permissions to write to the directory). I called the server vendor’s technician back, who said, “I’ve gotta see this!” The technician requested that I capture the network traffic in between the workstation and the server (the network equivalent of a wiretap). Sure enough, one day after submitting traces to the server vendor, we were told that, yes, the server was replying wrongly to the workstation. The vendor asked, “Do you have virus protection on the server? Software licensing software?” I did, and after removing the virus protection package, I no longer had problems installing any of the applications. Apparently, some sort of interaction problem existed with the various applications I had installed on the server—not the least of which were the vendor’s bug-fix patches! The virus protection package was reasonably old, so it hadn’t been tested with the latest patches—an upgrade to the virus protection package was in order, but at least I had tracked down the problem. |
A given vendor may supply wonderful tech support in addition to a killer Web site. I’ve been fortunate to deal with some of these vendors—unfortunately, though, they’re sort of rare. If you find one, buy its product as much as you can and offer up prayers that it sticks around forever. Seriously, good tech support technicians can be major help, so you certainly don’t want to rule out calling them.
Sometimes, the best way to solve a problem is to find out if anybody else has had the problem. Internet search engines, Internet forums, mailing lists, and CD-ROM knowledge bases are excellent ways to extend your troubleshooting efforts. Technical support should be saved as a last resort; if you approach tech support with a documented reproducible problem, you’re much more likely to be treated with respect. Brush-offs, such as finger-pointing, can be combated with good notes and a reproduction of the problem without the component that the vendor is pointing its finger at. Working knowledge of diagnostic gear, such as network analyzers, can really help to gather data that ends the finger-pointing game as well.
| Previous | Table of Contents | Next |