Skip To Content

Inside an ArcGIS Server site

ArcGIS Server, the work center of ArcGIS Enterprise, brings your organization's geographic information, analysis, and products to the web using infrastructure you manage.

Desktop products such as map documents, geoprocessing tools, and address locators are published to ArcGIS Server to become GIS services, available to your organization within its firewall and, optionally, to the greater internet. These services are consumable in web clients, from map viewers to mobile apps, and make it easy to share your resources across clients - even those without specialized GIS software.

This topic explains the structure and functions of ArcGIS Server from an administrator's perspective.

Federated and standalone sites

You can deploy ArcGIS Server as a standalone system to simply provide your users with GIS services, or integrate it with the ArcGIS Enterprise platform as a comprehensive Web GIS deployment in your infrastructure.

This integration is done by federating one or more ArcGIS Server sites with an ArcGIS Enterprise portal. In such a deployment, your users can build powerful, appealing products atop ArcGIS Server services and disseminate them easily using the ArcGIS Enterprise portal and native apps.

For example, your GIS professional might create a multilayered map in ArcGIS Pro and share it as a web map—powered by an ArcGIS Server map service—to your ArcGIS Enterprise portal; from there, they might create a web app from a few of the layers and embed it in your website as a public resource. In another case, your GIS department might equip its mobile workers with an Esri mobile app and have them add and update features on a common web map, powered by an ArcGIS Server feature service.

Security and access

When deployed as a standalone system, ArcGIS Server controls its sharing and security models. Administrators can modify settings such as access control, publishing privileges, and web traffic protocols within ArcGIS Server Manager, the browser-based application installed with ArcGIS Server, as well as programmatically through the ArcGIS Server Administrator Directory. Either the built-in ArcGIS Server identity store or your organization's external identity provider can be used to authorize and authenticate users to the standalone site.

When ArcGIS Server is federated with an ArcGIS Enterprise portal, it adopts the sharing and security models of the portal, though some security settings are still configurable from the ArcGIS Server tier.

See Integrate your server with ArcGIS Enterprise to learn more about federation and how federated ArcGIS Server sites operate.

Components of ArcGIS Server

An ArcGIS Server site consists of several components that can optionally be distributed across multiple machines to increase computing power. Each component in the site plays a specific role in the process of managing the resources that are allocated to a set of services.

The components of an ArcGIS Server site can be summarized as follows:

  • Web server—Hosts web applications and provides optional security and load balancing benefits to ArcGIS Server.
  • ArcGIS Web Adaptor—Integrates ArcGIS Server with your enterprise web server, forwarding incoming requests to your various ArcGIS Server machines.
  • ArcGIS Server—Responds to requests issued to the GIS web services. ArcGIS Server can draw maps, run tools, serve imagery, synchronize databases, project geometry, search for data, and perform many other operations offered by ArcGIS.

Web server

The web server hosts web applications and provides optional security and load balancing benefits to the ArcGIS Server site. ArcGIS Server is compatible with many popular web servers, including Internet Information Services (IIS), WebSphere, and WebLogic.

ArcGIS Web Adaptor

ArcGIS Web Adaptor is a web application that forwards requests from your web server to your ArcGIS Server. ArcGIS Web Adaptor keeps track of which machines have been added to (and removed from) your site and forwards transactions to them appropriately. ArcGIS Web Adaptor allows you to set your own name for your site, instead of using the default site name arcgis. ArcGIS Web Adaptor also allows you to leverage the native capabilities of your web server for security and can block outside connections to ArcGIS Server Manager and the ArcGIS Server Administrator Directory.

When a web service request is received, ArcGIS Web Adaptor forwards the request to one of the ArcGIS Server machines. If ArcGIS Web Adaptor determines an ArcGIS Server machine is unavailable, it stops forwarding requests to that server.

Other web gateway options

ArcGIS Web Adaptor is not the only way to configure a web gateway, or entry point, to your site. Other web gateway technologies include physical HTTP load balancer and network router devices, or third-party software designed for load balancing purposes. For example, in the Amazon Web Services (AWS) cloud environment, the Amazon Elastic Load Balancer (ELB) can act as a web gateway. If you already have technology in your organization that serves as a web gateway, it can be adapted to work with ArcGIS Server under most circumstances.

It is a security best practice that your users always use a web gateway, whether it be ArcGIS Web Adaptor or a third-party load balancer, to access your ArcGIS Server site. Users should never connect to ArcGIS Server directly using ports 6443 or 6080.

ArcGIS Server

Incoming web service requests for maps, address coordinates, geoprocessing jobs, and so on, are each assigned to an available ArcGIS Server machine in the site. That ArcGIS Server then draws the map, finds the address coordinate, runs the geoprocessing tool, and so on, and returns the result to the client. Essentially, ArcGIS Server machines are the work centers of your site.

You may need to configure your ArcGIS Server site to use multiple ArcGIS Server machines to protect against downtime if one of your machines becomes unavailable. When a machine goes offline (whether planned or unplanned), the Web Adaptor can continue to distribute incoming requests to the remaining ArcGIS Server machines in the site.

The above components of an ArcGIS Server site can reside on the same physical machine for development and testing purposes, or for supporting small deployments. See Deployment scenarios to learn about recommended architectures for small and large sites.

Configuration store

An ArcGIS Server site has a folder designated as the configuration store that contains all the properties of the site and its services. You specify the location for the configuration store when you create the site. In a multiple-machine site, the ArcGIS Server machines access the configuration store through a shared network directory. In a site with multiple ArcGIS Server machines, it's recommended that you keep the configuration store on its own fault-tolerant file server (separate from the ArcGIS Server machines).

Server directories

A server directory represents a physical directory on the network that is specially designated for an ArcGIS Server site to store and write certain kinds of information. There are server directories for storing caches, output, jobs, system files, uploads, input data, KML, and indexes. A set of server directories is created at a location you specify when you create the site. In a multiple-machine site, this must be a shared network directory.

For detailed descriptions of each server directory, see About server directories.

Server roles

ArcGIS Server can be licensed with a number of server roles. These unlock unique server architecture and features that enable specialized analysis and processing tasks. For example, ArcGIS GeoAnalytics Server distributes task processing among multiple server machines to hasten analysis of massive data sets. Server roles require no extra software installation - they are designated in your license files when you authorize ArcGIS Server.

Processes started by ArcGIS Server

You can expect to see the following operating system processes on any ArcGIS Server machine that is started and participating in a site:

  • One ArcGISServer.exe process
  • One ArcSOC.exe process for each running service instance. An exception is geoprocessing services, which have two ArcSOC.exe processes per running instance. Note that some of these processes are for internal system services, not services your users have published.
  • One rmid.exe process
  • One javaw.exe process. This provides basic application server functionality and the ability to host web services.
  • One conhost.exe process and one cmd.exe process. These are supplementary processes started by Windows to provide console services to ArcGIS Server processes.

You can tell that a javaw.exe process is associated with ArcGIS Server by looking at the Command Line column in Windows Task Manager. If the path includes the ArcGIS installation directory, you know it's a process associated with ArcGIS Server. You can derive further information about each process by examining its full command.

The Windows service ArcGIS Server represents ArcGIS Server itself. Stopping this service effectively stops ArcGIS Server on the machine and shuts down any running service instances.

The ArcGIS Server site

An ArcGIS Server site is an assemblage of individual machines configured to work together on equal terms. When first created, a site consists of one machine; using the Join Site or Register Machine operations, additional machines can be added to the site.

Each of a site's machines run all services published to the site, and if assigned a request to any service by the site's Web Adaptor or load balancer, each will be able to handle and process that request. An individual request will be handled entirely by the machine it is assigned to; if that machine is unable to complete the request, the initiative fails rather than passing the unfinished request to another machine in the site.

The exception to the "one request, one machine" pattern is with the ArcGIS GeoAnalytics Server and ArcGIS Image Server roles, which distribute the processing of service requests across multiple machines to tackle large analysis tasks.

Service instances

To process a service request, the assigned ArcGIS Server machine uses an instance of the Esri server process ArcSOC.exe. This process runs the request on the machine. For each machine in your ArcGIS Server site, you can view the instances of ArcSOC.exe currently running by viewing them in Task Manager on a Windows machine or system monitor on a Linux machine.

Note: Geoprocessing services use two ArcSOC.exe processes per running instance. All other service types use one.

ArcSOC service instances are organized by pools, the size of which can be adjusted to accommodate traffic. A service can have its own dedicated pool of instances that will only handle its requests. Beginning at 10.7, the ArcGIS Server site now has a shared pool of instances to which multiple services can be added. The size of an instance pool is governed by two settings—a minimum and a maximum number of instances—that administrators can set in ArcGIS Server Manager. The actual number of instances running at a given time will be within this set range, but it will vary depending on current traffic.

The shared instance pool offers a solution to conserve computer memory usage by ArcGIS Server, by reducing the number of unused ArcSOC instances running on the site's machines. It is intended to be used by services that do not receive constant requests or high numbers of simultaneous requests.

Prior to the introduction of the shared instance pool, the method to reduce unnecessary running instances was to set the minimum number of instances in a dedicated pool to zero. When this is done, a service that has not recently received a request will not have any ArcSOC instances running on the server site's machines, thus conserving memory usage. However, this presents a "cold start" problem—a delay in the response time for the next request to the service while it starts up a new ArcSOC instance. Using the shared instance pool eliminates the "cold start" problem, as there are always ArcSOC instances available for its services to use.

To learn more, see Shared and dedicated instances.