Chapter 17Troubleshooting in ArcGIS Enterprise

Objectives

• Create an action plan to efficiently react to an unexpected issue.
• Learn the logging capabilities of ArcGIS Enterprise.
• Investigate behaviors through web tools.

Introduction

ArcGIS Enterprise can create many data connections to support mobile workers, offline GIS analysis, and map creation. Because of the level of complexity of these workflows, users may sometimes run into unexpected behaviors. Other factors, such as network changes, improper workflow design and application, or defective behavior, may cause users to experience unexpected issues in their day-to-day use of ArcGIS Enterprise.

This chapter will serve as a primer on how to gather information about an issue, understand the scope of the problem, and communicate the issue to key stakeholders. After establishing a base of understanding, we will also cover what types of triaging and troubleshooting methods are available to you as an administrator. Although this chapter will not cover every troubleshooting scenario, we will cover these basics:

• Establishing system history at the time of the error
• Gathering and reviewing logs from relevant locations
• Initial triaging of the error and checks on basic system functions

This chapter will also discuss how to work with Esri Technical Support, highlighting how to collaborate with support analysts and specialists and provide them with data that is relevant to your issue.

The chapter will conclude with an examination of tooling that’s been created to quickly gain key insights into your configuration of ArcGIS Enterprise and an exploration of alternative logging locations through the ArcGIS Enterprise portal administrative end point—and the ArcGIS Server administrative end point.

What to do when you encounter a technical issue

Throughout this book, we’ve introduced ArcGIS Enterprise as a system of federated software components to achieve a specific goal. In this system, many users find they can apply more than one solution to their use case. As solutions become complex or changes require iterations, you may find yourself running into different issues or workflow limitations. Other issues may be caused by external factors or defects within the software. Although the origins of these issues are diverse, an administrator can take similar steps to get more information about those issues.

How an ArcGIS Enterprise administrator deals with the unexpected and plans for the unknown makes the difference in the overall recovery time of the deployment. The most important thing to remember is not to panic or make major changes to the environment that are not completely understood. For example, in a scenario in which a high availability (HA) deployment is not properly promoting to a standby portal, you may be tempted to apply a backup to the failed machine and spin it back up. However, if the failure in the primary/passive switch is not understood, there is a chance that the deployment may be caught in a “split brain” state, with each Portal for ArcGIS instance believing that it’s the primary instance. This would lead to a more complicated solution that may add time to the overall recovery.

So, what should you do if you encounter an issue? Although each issue is different, let’s talk about what steps could be taken for an effective initial response.

Observing the issue

It may seem obvious, but the first step in solving the problem is understanding what the problem is. Getting on a call with the user and observing the problem is crucial here. For example, if a user is trying to edit a feature in ArcGIS Field Maps, get the basic information on what piece of content or service the user is trying to work with, along with what action is causing the problem. When you have the basic details, you can try to reproduce the problem on your end to make the investigation easier. We will dive deeper into how to investigate an issue later in this chapter.

Isolating the issue

In Esri Technical Support, analysts are trained on taking a problem as it is presented and paring it down to its most basic component. If a user is unable to edit a feature layer in Field Maps, you may ask if editing is possible in Map Viewer. If you are unable to edit the service in Map Viewer, you have removed Field Map’s relevancy from the equation, making troubleshooting slightly easier. Through a series of questions and logical answers, the exact location of the failure can be identified.

Categorizing severity

Through your investigation and isolation efforts, you should begin forming an idea of how disruptive the issue may be. Continuing with our example, let’s begin by investigating the Field Maps issue as it presents, meaning it directly affects one user. However, as you continue to investigate, you learn that multiple services from the same data store are also affected, expanding the pool of affected users to a working group. Your perspective on the severity of the issue should be reported because it is a valuable nuance to those who may help you resolve the issue.

Communicating the issue

Combining your understanding of the issue, isolating it to a particular workflow or group of users, and categorizing its severity, an ArcGIS Enterprise administrator should begin to communicate the problem to their key stakeholders. All affected users, other ArcGIS Enterprise administrators, and IT team members need to be briefed on the details of the issue. Setting an informational banner and updating it with your progress is a great idea to keep your user base informed of what is happening. If the issue is severe enough, other measures may be taken to limit changes happening to the environment as troubleshooting takes place, such as setting ArcGIS Enterprise to read-only mode.

.

This article includes important information relating to the requirements to run the tool, pre-requisites including Python, and ArcGIS Enterprise version requirements.

From the article, download the ConfigReport.zip file.

Extract the ConfigReport.zip file and open the ConfigReport folder.

Open the config.ini file in a text editor (Notepad or Notepad++ is recommended).

Add your target_portal URL (portal web adaptor URL), your administrator username, and password.

Enter the correct validateCertificate value:

• If the certificate is trusted, enter the value True.
• If the certificate is invalid or being accessed via the IP or host name instead of the name on the certificate, enter the value False.

Save the file and close it.

Open the Command Prompt as an administrator and change the directory to the location of the ConfigReporter.

Run the script, paying close attention to use the ArcGIS Server or ArcGIS Pro Python environment.

The output of the script is in arcgis_reporter-main > ConfigReport > generated_reports.

Navigate to the generated_reports folder and check the contents.

• What information do you see with respect to your deployment?

Summary

This chapter covered the basics on how to respond to a technical issue in your ArcGIS Enterprise organization. By observing the issue, you gained an understanding of the nature and reach of the behavior. Isolating the problem to a specific service or data store gave you key insights into what may be the root cause of the problem. Categorizing severity informed the level of effort you and your IT team may need to resolve the issue. And finally, communicating the problem to key stakeholders set up awareness and accountability within your organization.

We finished this chapter by reviewing the logging capability built into ArcGIS Enterprise, as well as additional tools that are commonly used to understand the underlying network traffic that is at play when actively troubleshooting a problem. Knowing where to look and analyzing the patterns found between logs may lead to a solution. However, Esri Community and Esri Technical Support are two resources to consider when working through a troubleshooting scenario.

Отправить