Episode Transcript:
Hello PANCasters. Today’s episode is actually in response to some feedback we received on our PANCast ideas forum page about engaging with Support which is a great topic.
John Arena is a Professional Services Consultant with a background in Technical Support for Palo Alto Networks and a passion for educating and sharing knowledge with customers.
So let’s start with the basics. Opening a case. You open a case online through the Customer Support Portal (CSP for short). There are a number of benefits of opening a case online. Firstly, based on your problem description you will be offered to review related guides and articles that may help with your query. I know you may be thinking this won’t help you but you would be surprised how many TAC cases are actually resolved with documentation that is already available. That’s not to say this will be helpful in every single case but there is a high chance that that error you received when doing a commit, or the fact your SAML auth is not working, has already been experienced by someone else and the fix is documented.
If after reviewing the suggested articles you still need to proceed then let’s discuss the details you should be providing but before I do, a quick note on the product and feature when you open a case. It is important that this is correct. We have specialist teams in TAC so if you don’t take care to ensure these are correct, the case may initially get routed to a different team and can delay your case being worked on.
Back to the actual information provided, in summary, the more information the better. A case opened with simply “GlobalProtect is not connecting” will obviously need more information gathered before any investigation or research can be done so this then requires some additional communication between yourself and TAC which sometimes can delay the actual troubleshooting. Let’s compare that to a case opened that has the same summary but in the description is the specific details of the issue like this was working ok but stopped over the weekend, it is affecting all users and there were no changes made to the configuration. Along with that the client logs have been uploaded to the case and with a specific timestamp of when the issue was seen. What happens now? As soon as the engineer is assigned to the case, they actually have a lot of information and can start working on the case straight away.
Now I’m sure for all our existing customers, at some point you will have been asked to upload a tech support file as a first response to opening a case. This isn’t just a standard response and having the details in the tech support file can also help the engineer start working on and hopefully finding a resolution as quickly as possible. The tech support file has a lot of useful data and logs which can be reviewed based on the reported issue. In some cases this can quickly identify either the actual issue or if not at least where to focus the troubleshooting to find the root cause. And this covers a great deal of different possible issues.
So this covers opening the case and all of this is really to minimize any delays in getting you the right support that you need. Now we’ll talk about the case lifecycle.
Palo Alto Networks TAC is a 24/7 operation with a wide global presence to be able to support our customers and there are a couple of things to note with handling your cases.
Firstly is an understanding that we have engineers based in different time zones and the time you open a case could affect the region that the assigned engineer is based in. This should normally not be an issue but there are a couple of reasons you should be aware of this. Firstly is if the case will need a remote session. It would be great if suggested resolutions and providing info to the engineer always resolved the issue but there are times that a remote session is needed. In this case it certainly makes sense to be working with an engineer close to your local time zone. If this is the case, you can always request for the case to be assigned to an engineer in your local time zone. The second is for critical cases which need continuous troubleshooting. Nothing really is required on your part so this is more for awareness, but what may happen is the case is continuously worked on but will be transferred to engineers across the different regions. Of course in this case we do also need the customer to be available, or at least someone be contactable if TAC or engineering needs to collect more data. I do also want to mention that critical priority should really be for critical issues. Unfortunately this is sometimes used to try and get a faster response when the actual issue is not really critical. All this does is delay responses to other cases, including ones which are genuine critical emergencies.
Now, let’s go back to the start of this process. Before a TAC case is even raised. You now know that you will be offered suggested resolutions when you start to create a TAC case based on the description but what about beforehand? Well, there is a vast amount of information readily available which covers troubleshooting, when you might see specific errors and even detailed configuration guides that can all help before even raising a TAC case. Between our admin guides, knowledge base articles and live community there is a wealth of information which may just have what you are looking for. We also have status pages for our cloud based services where you can check for any widespread issues. Finally I hope some PANCast episodes have the same result where you remember hearing something about say, URL filtering, and before opening a case you decide to do some research on your own to see if you can find the resolution.
TAC will always be required and play a very important role and I also understand that each year as new features come out, the complexity increases. But just remember in some cases, you may be able to resolve your issue without even engaging TAC.
Before I go, one last comment. TAC really is a break fix organization. As I just said the complexity, and therefore support, is increasing with every new feature that comes out but the primary focus for TAC should be fixing things when they don’t work. Why do I mention this? Well, a lot of TAC cases are still raised for what would be either initial configuration or just ongoing configuration, which is not really break fix.
So there you have it. A quick summary of how you can help TAC help you.
That’s a wrap for today. As always you can get the transcript and any relevant links on live.paloaltonetworks.com and remember you can listen to PANCast on most popular podcast platforms. Bye for now.
Check out the full PANCast YouTube playlist: PANCast: Insights for Your Cybersecurity Journey.
Related Content:
