Troubleshooting Scoping


 In order to even start troubleshooting a problem we must understand HOW the issue is affecting the customer. This is not WHY (or root cause, IE not trying to determine HOW COME) the issue is affecting the customer. But we need to understand how widely the damage being done by the issue is. This is why it is called SCOPING.


 ANY AND ALL NEW ISSUES, we must understand the scope of the problem. Though some of this you MAY be able to determine because of the initial problem statement from customer, if you cannot directly answer the questions from the problem statement, then you need to ask explicitly.

You’ll also find that once you start digging for this info, customers will volunteer more information that may clue us into the WHY, because of your digging.


What version OS?

What model device?

What deployment type? (EG is this firewall cluster? If CP or PAN then does it have a separate management server?)

How many users are affected?

When was issue first observed?

Is this a new issue or has it occurred in the past? (First time = preference to resolve; Multiple occurrence with known temporary resolution = preference to investigate for permanent resolution)

How intermittent is issue? (IE from completely random to 100% consistent)

Follow up to intermittency: Can you reproduce the issue by specific steps? What steps?

Why do you suspect the supported (or managed) device? What troubleshooting has occurred so far? What were their results?

Was this article helpful?

Related Articles

Leave A Comment?

You must be logged in to post a comment.