Get the most bang for your vendor-support buck

My ideal reality-based TV show, When Exchange Servers Attack, would tell you what to do when your server suddenly turns against you. How can you get the best support possible from an Exchange Server-related product vendor? Should you call Microsoft Product Support Services (PSS)? Here are some tips for what to do—and what not to do—when calling for technical support.

Tip 1: Do Your Homework
The typical vendor's technical support staff receives a wide range of calls. Some calls are from calm and collected folks; other calls are from panicky administrators desperately grabbing for lifelines. The first (and easiest) step that you can take to place yourself in the first category is to do your homework and try to identify the problem before you call technical support.

Think back to high school. You either kept up with long-term assignments such as term papers or tried to jam in the work at the last minute. You face the same choice regarding the Exchange Server-related products you install. Ideally, before you encounter a problem that requires you to call a vendor, you're already up-to-date on the contents of that vendor's technical support database. Does the product work on Windows 2000 (Win2K)? Do you need to fix any security vulnerabilities? If you stay current with the products you use, you can head off many major problems.

You can also get useful information from peer forums. My favorite forum is Swynk.com's Exchange list (http://www.swynk.com). Talking to other administrators is a great way to get the unvarnished (sometimes painfully direct) truth about a particular product, installation, or configuration. Most lists and newsgroups offer searchable archives—a great way to benefit from the community's accumulated wisdom.

Tip 2: Get Your Ducks in a Row
When you go to your doctor, he or she asks you what is wrong. Questions about your symptoms help your doctor gather the information he or she needs to identify the problem. When you call a software vendor, be prepared to go through a similar process. At a minimum, you need to know—and be able to clearly communicate—the answers to the following questions:

  • What software version, including any patches, fixes, or updates, have you installed?
  • What version of the OS (e.g., Win2K, NT 4.0) have you installed? Do you have any service packs or hotfixes on your machine?
  • What other software have you installed? Are the third-party products on your machine compatible with one another?
  • Have you already tried to fix the problem? What steps have you taken?

Other helpful information includes your computer's BIOS revision level and any disk or peripheral controllers you've installed. In particular, PSS often asks you whether your hardware is on the Windows Hardware Compatibility List (HCL). In addition, if you're calling PSS about a previously opened or related support case, be sure to have the case numbers (or SRX numbers in Microsoft lingo) handy when you call. And be prepared to explain the previously suggested fixes that you've already tried so that you don't reinvent the wheel.

Tip 3: Remember the Four Ps
When you're dealing with vendor support systems, remember the four Ps: Be patient, be polite, be persistent, and be powerful. The need for patience and politeness is self-evident—technical support staffers are people too, and you've no reason to rant at them (they probably didn't write the software).

Persistence is important because most companies structure their technical support in tiers. The frontline support technicians answer calls and resolve (or attempt to resolve) the easy problems. If these staffers can't handle your call, they pass you up to more experienced staff at the next level. If the first technician who takes your call can't help you, don't be afraid to insist that the technician pass on the call (do remain polite).

What about the fourth P? You derive your power from being the customer. Most companies at least act as if they value your business; some companies will go out of their way to help you, even when their software isn't causing your problem.

Tip 4: Pay Attention
Pay attention to what the vendor tells you. By carefully listening, you can determine whether the support technician truly understands your problem. The technician's understanding is fundamental to a working solution.

I find that taking notes during a call is helpful. At a minimum, I always take the name of the person I spoke to, as well as some notes about the call (e.g., how long I had to wait on hold, my call's case number). I also try to keep track of the conversation's general direction. These notes can be useful if I need to refer back to a call and invaluable if I want to contact the vendor and report a good or bad support experience.

Tip 5: Follow Instructions
When you troubleshoot a problem over the telephone, you can immediately carry out technical support instructions. Remember that you can question the instructions; don't follow them if you sense that something is wrong (for example, if support tells you to stop the Information Store—IS—service and delete priv.edb). If you get advice that you think is wrong, ask the technician to forward your call to the next support level. However, in the absence of these concerns, do what the technician asks you to do. To revisit my medical analogy, failing to take the advice of the vendor is like refusing to take the medicine your doctor prescribes.

Tip 6: Beware of Vendors Pointing Fingers
You'll probably run into situations in which more than one vendor's product seems to be at fault. Doing your homework can pay off in this type of situation. If you're familiar with the products, you might be able to quickly find the problem's cause and solution without calling support.

What if you do call a company's support line, only to have a vendor tell you that another product is at fault? Assessing the accuracy of such statements can be extremely difficult; after all, most vendors don't cooperate with their competitors, so I can't imagine that vendor A's technician is an expert on vendor B's products and can accurately say the competing products are to blame. You might need to call each vendor—a time-consuming but sometimes unavoidable solution. Bear the possibility in mind, remember the four Ps, and be prepared.

Tip 7: Understand PSS
PSS is the umbrella organization responsible for providing technical support for Microsoft products ranging from Exchange 2000 Server to Microsoft Bob. Groups within PSS are dedicated to each major Microsoft product, but all the groups generally work the same way.

When you call PSS, a call screener answers your call. You need to give the screener a credit card number, support contract number, or Premier Support ID. The screener asks you for contact information, opens your call, and transfers you to an engineer. The engineer works with you to identify the problem. Your conversation typically leads to one of the following outcomes:

  • The engineer identifies your problem as a flaw within Exchange Server or the underlying OS, for which a fix is currently unavailable. (This flaw might be an actual defect, or it might be a product limitation.)
  • The engineer identifies your problem as a previously known problem for which a hotfix or service-pack fix exists.
  • The PSS engineer leads you through a procedure (e.g., when you call to get help with a procedure such as disaster recovery).
  • The PSS engineer tries to answer your question (e.g., when you call to ask a question or get information). The engineers can't answer every question, but their batting average is good.

In the first two cases, PSS won't charge you because the flaw is Microsoft's. In the other two cases, you'll probably need to pay the $195 per-call fee (unless you speak with a generous engineer or have a support agreement). Although $195 seems high, it's a small price to pay to get your Exchange server running again. Also, PSS has access to unique resources and can probably save you a lot of time.

As with most third-party vendor support calls, your initial PSS call goes to someone who might not have much experience with the product. However, PSS engineers have access to the Microsoft Knowledge Base, which contains a wealth of information. You can access that data through Microsoft's Web site (remember my point about doing your homework), but the PSS folks are extremely skilled at finding useful needles in the megahaystack of Knowledge Base articles. PSS also has access to internal information that isn't on the Web site and can direct problems to the people who wrote the original code—defect-squashing hotfixes have resulted from PSS calls to Exchange Server developers.

PSS also has an arsenal of useful tools, such as Exmerge (which lets you move users between servers in different sites or organizations) and Isscan (which lets you scan for and remove messages containing macro viruses or other forbidden content). A call to PSS often introduces you to a tool you never knew existed.

Have No Fear
Now that you know how to get the most from your interactions with vendors and PSS, I hope you don't have to use these skills too often. Exchange Server is a remarkably stable and robust product, provided that you administer it properly. But if you do run into trouble, don't be afraid to call for help.

\[Editor's Note: Daniel Chenault, support engineer for PSS, provided input for this article.\]