8 Ways to More Quickly Resolve your Technical Support Case

Providing the key details for a Technical Support case upfront helps to improve the time it takes to resolve the case.  Learn what information you can provide when creating your Technical Support case to help the analyst get off to a running start.

It all starts at the beginning - starting your day with breakfast, a smile on your face when meeting someone new, or a handshake (pre-2020!) with your interviewer for a new job.  These all help you to start off on the right foot.  Bringing your Technical Support case to a quick resolution also starts at the beginning.  Providing correct and complete information up front can help an analyst narrow down their research and testing to put the case on the right path at the beginning, ultimately speeding up the resolution time.

Why would this speed up a case?  Eventually you’ll cover these details, right?

Well yes, eventually the analyst working on your case will likely ask you many of these details early on in the case.  When logging a case with a high-level description of the issue, an analyst will immediately consider a number of factors that could be at play to cause your issue.  Instead of the analyst sending you documentation or asking high-level questions to narrow the focus of the case in response, it’s more efficient to have this information up front.  This means that the analyst can use the time spent on your case to really look at the specific details that could be affecting you, instead of spending time narrowing things down.

However, if an analyst only has ‘x’ amount of hours to dedicate to investigating your case in a week, it’s more effective if they can narrow their focus on the specific details that may be at play for your issue.  This narrowed focus can only be accomplished when the details of the issue are identified.  Providing this information at the beginning limits the time spent on communications focused on gathering these details.

GIS professionals tend to be extremely investigative and generally already have this information from their own troubleshooting, however, we often don’t receive this information right away which delays the analyst’s investigations.

Let’s discuss some of these specific items that are helpful to note when logging a new case with Technical Support.

1 – Provide a detailed description of the problem

What is the issue you’re experiencing?  How did you encounter it?  What steps were completed prior to seeing the unexpected behaviour?

It’s all in the details.  Sometimes the tiniest detail can turn on the lightbulb for an analyst as to why you’re encountering an issue.  It may remind us of previous cases where we had seen a similar, but different issue, however we may make a connection that an underlying detail or setting was the same.

Are you just looking for more information on how to accomplish a task in the software?

The details are important here as well.  Even if we determine that a certain workflow may not be possible in the software, we may be able to offer alternative solutions to meet your business needs if we know what you are trying to accomplish and why.  We often don’t receive this information in cases, but it can really go a long way in finding you a solution for your business needs.

2 – Steps to reproduce the issue

In item 1, we mentioned that the steps leading up to the issue were important.  However, steps to consistently reproduce an issue are much more valuable.  Sometimes this is not always possible, as you may have made some changes that led to an issue and not quite remember what was changed.  In many cases though, there are reproducible steps that allow us to do more in depth testing right away.

This is especially beneficial in cases where we cannot reproduce the issue, as we can narrow our focus to other items in your environment as the cause of the issue, instead of the steps themselves.

In cases where reproducing an issue is not always consistent, any information on even a single component of reproducing the issue can help.  For example, you may see a sporadic issue on Android devices, but have never experienced the issue on and iOS device.  The issue being specific to Android would help narrow our focus on the case and in our testing.

3 – Testing completed to date

What testing have you already completed?  What were the results?

This information is key in helping Technical Support avoid spending time upfront asking you to test things you may have already tried.  Instead, we can narrow down the issue using the information you provide and provide more focused suggestions for testing right at the beginning of the case.

4 – Versions

Versions!  This is such an important piece of information on a case that gets missed when the case is being initially logged.  This is key in identifying if there is a bug or limitation at your current version.  If we are able to test the issue on our end, the version information also assists us with reproducing the problem more quickly, investigating why it’s happening, and possibly finding a workaround to the behaviour at your current version.

5 – Screenshots

This is one of my personal favourites.  Screenshots can be instrumental in decreasing the amount of time required for an analyst to narrow down the issue.

Error messages
Screenshots of error messages are often more beneficial than copying the error message text into the case summary.  The screenshot will show us the full error message, which might include some details that prove important when we’re investigating the issue, for example error codes.  They also show us what type of error is being thrown – sometimes it’s the application, while other times it’s the operating system throwing the error.  This key detail can help identify what the root cause of the error may be or where to spend time doing further investigations.

Display where the issue is occurring and any related settings
It’s also helpful to provide screenshots of any configurations that you feel may be contributing to the behaviour you’re experiencing.  Additionally, if there is a particular workflow that leads to an issue, screenshots of the steps you complete to reproduce it may help us more quickly reproduce the issue on our end and/or identify any details that could be impacting your results.

Background details
In many cases, I have had users provide screenshots for the above two points, only to see something in the background of the screenshots that I have been able to identify as the problem.  This often happens when receiving screenshots of error messages, where the application is seen in the background and happens to show a particularly relevant configuration.

6 – Error Messages

Errors present themselves in many different forms – a pop-up from the application, a pop-up from the operating system, within the application interface itself, in the browser developer tools (click F12 on your keyboard when the browser is open to activate this panel), or in the logs.

If an error is encountered, the error message is an important detail to include in your original case description.  As noted above, a screenshot is best when the whole error message is visible.  Sometimes this is not possible, in which case just the error text is still extremely useful to provide.

7 – Logs

Errors are often recorded in some form of log file.  Below are some key log files that we find useful in Technical Support cases and where to find them.

It should be noted that many times these files are too large to send in the original case description, however it’s useful to note that you have them ready to send to us should we require them or if you have seen the error in the logs already.  We will then be able to provide you with a location to upload these larger files to in the initial case communication.

A. ArcGIS Pro and ArcMap

The most common logs requested in Support for ArcGIS Desktop cases can be found in the following location.  Please note that the AppData folder is generally hidden so you may need to enable the “Hidden items” option in Windows Explorer in order to see it.

C:\Users\<UserName>\AppData\Local\ESRI\ErrorReports

More information on these log files can be found in the ArcGIS Pro documentation and the ArcMap documentation.

If the application is crashing as it launches, there is also a helpful Technical Article which discusses the steps to create an ArcMap startup log.

B. ArcGIS Server and Portal for ArcGIS

To capture effective ArcGIS Server or Portal for ArcGIS logs, ensure they are configured to use a detailed logging level, such as Debug, before reproducing the issue.  Once you are done reproducing the problem, set the logs back to their original logging level (usually Warning).  This will prevent excessive log storage on your server.  Below are the instructions to configure and view the logs, and also access the log files on disk to provide to Technical Support.

ArcGIS Server
To review the ArcGIS Server logs, you can use the Log Viewer in ArcGIS Server Manager and set the filter to show any Debug logs that were previously recorded.

To provide Technical Support with the logs, you can access the log files on disk by browsing to the logs directory and opening the most recent log file (ex; C:\arcgisserver\logs\<machine name>\server\server-20150101.095803-8596-0.0.log).

Portal for ArcGIS
To review the Portal for ArcGIS logs, you can use the ArcGIS Portal Directory and set the filter to show any Debug logs that were previously recorded.

To provide Technical Support with the logs, you can access the log files on disk, by browsing to the logs directory and opening the most recent log file (ex; <Portal for ArcGIS installation directory>/arcgisportal/logs/<machine name>/portal/portal-20150101.095803-8596-0.0.log).

C. IIS

Internet Information Services (IIS) log files also provide valuable information about web applications.  They can help to determine important aspects of web application usage such as when requests to servers were made, by whom, and other user traffic concerns.

The default location of IIS logs on a Windows server is %SystemDrive%\inetpub\logs\LogFiles.

D. Web Traces (ex; Fiddler logs or .har files for network issues)

Providing web traces, especially when there is an unexpected error or odd behaviour in web applications, can be extremely useful for troubleshooting.  They monitor the network traffic to see what requests are being made to an application and the related parameters, as well as the response from the server they are sending requests to.

Fiddler
One of the top recommended tools to run a web trace is Fiddler.  This is an application that you can install on your server to record the web traffic.  Once installed, you can use the steps in the Create a Session Archive Zip article to generate and record the web traffic in Fiddler.  This can then be packaged as a session archive to provide to Technical Support.

HAR File
Generating har files can be done in most browsers, however the steps will vary depending on the browser used.  The Generating a HAR file for troubleshooting article discusses the different ways to generate a .har file in each browser.

8 – Use the Esri Support App - Canada

The Esri Canada Support App can help with quickly logging cases, especially from the field.  There is no need to wait until you’re back in the office to report an issue, and it is available on both iOS and Android devices.

It allows you to log cases, contact Esri Canada Technical Support, and get the latest product news—all in one convenient location.  It also provides quick reference to Esri documentation and guidance on common workflows, all in an easy-to-use mobile interface.

The Esri Support App – Canada is available now in the App Store and on Google Play.

What about “How To” cases, where investigating technical issues is not necessary?

Not all cases involve troubleshooting technical issues.  How can you speed up a case where you simply need to know how to do something?

Below are some tips for logging the case that will help your Technical Support analyst better assist you.

• Be clear in what you are trying to accomplish.  If you’re not sure how to clearly communicate your goals, screenshots can always help us better understand.
• Providing a reason as to why you’re trying to accomplish a certain task in software is also helpful.  If there is a limitation in the exact workflow you are trying to accomplish, we may be able to provide an alternative workflow that can help you accomplish the same goal.
• Providing notes on the research and testing you have already completed with the results of the testing may be helpful.  By doing this, it keeps the Technical Support analyst from sending documentation that you may have already worked through but may not have helped in your particular scenario for reasons we are unaware of.  Details on your findings before logging the case are crucial.

It’s all in the details

At the end of the day, the more details you provide upfront will help Technical Support better focus their efforts in assisting you from the beginning of the case.  This prevents using time allocated to the Support case on non-necessary communication, and instead helps us guide you in narrowing down the issue sooner.  We want you to have a great experience with our Technical Support team and this is one way we can help achieve this goal.

This post was translated to French and can be viewed here.