Guidelines for configuring ArcGIS Server components

An ArcGIS Server system is comprised of many parts, such as the server object manager (SOM) and server object container (SOC), the Web and Mobile ADFs, a Web server, and an administration interface, such as Manager. In order for the system to work, each component must be able to communicate with the other components in the correct way. You'll also want to wisely distribute the components so as to make most efficient use of your hardware. This topic provides information on how the ArcGIS Server system components interact with each other and the relative amount of resources they consume. You'll also find options for high availability configurations, so that a hardware failure does not disable your applications.

When reviewing this information, be aware that ArcGIS Server Workgroup licensing allows for the deployment of ArcGIS Server components on just one machine. To deploy ArcGIS Server components on multiple machines, you must have the Enterprise level.

Suggestions for SOM machines

The server object manager (SOM) is a component of ArcGIS Server that manages the services distributed across one or more SOC machines. The SOM runs as a background process (in Windows, a service called ArcSOM.exe) and handles the load distribution of incoming requests. It also keeps track of which services are running on which SOCs. Using this information, the SOM delivers a request to the appropriate service.

Choosing a machine for the SOM

The ArcSOM.exe process uses relatively little memory, and does not need to run on a dedicated machine; it can coexist with the Web server or reside on a SOC machine. For information on installing the SOM, consult the ArcGIS Server Install Guide by opening install.htm on your install CD's, or by navigating to the <ArcGIS install directory>\Documentation\install_guides folder on your computer.

Using a failover or round robin configuration

In deployments with multiple web servers and SOC machines, the SOM can be a single point of failure, meaning that if there is only one SOM, it could stop the whole system by going offline. For this reason, you may want to set up multiple SOMs for use in a failover or round robin configuration. In a failover configuration, all requests for services are sent to one SOM. If that SOM fails, a designated backup SOM continues fielding the requests. In a round robin configuration, by contrast, requests are distributed evenly among all available SOMs in the configuration. If a SOM in a round robin configuration goes offline, the remaining servers continue fielding requests.

ArcGIS Server allows you to configure failover or round robin when you add services to a Web application, either at design time or programmatically. The Developer Help contains information on how to do this, in the section "Using the Connection Library".

The SOM account

When you run the GIS server post install, you are prompted to enter a name and password for the SOM Account. This account runs the Server Object Manager service. The server account is automatically granted permissions to the default log directory so that it can write the log messages. If you ever change the log directory, you need to make sure that the SOM machine can access to the directory, usually via a UNC path, and that the server account is granted permissions for the new directory.

Adding users to the agsadmin and agsusers groups

The agsadmin and agsusers user groups specify the privileges that a user will have when making a local connection to the GIS server. These groups are automatically created on the SOM machine when you install ArcGIS Server, but it is your responsibility to populate them. You should add yourself to the agsadmin group, as well as anyone else who will need to administer the server. Then you can add anyone else who will use the GIS server into the agsusers group.

Suggestions for SOC machines

Server object container (SOC) machines host services and the processes that do things with those services In this way, the SOC is the work center of the GIS server. SOC processes are started and stopped by the SOM.

SOC machines and ArcGIS Server licensing

All SOC machines associated with a SOM must have the same edition (Basic, Standard, or Advanced) of ArcGIS Server installed. For example, if a SOM has three SOC machines associated with it, all three of those SOCs must have the same edition of ArcGIS Server.

To create a new configuration of SOM and SOCs in your ArcGIS Server system, you can add a new instance of ArcGIS Server. Instances are explained in How the GIS server works.

Adding and removing SOC machines

Adding or enhancing SOC machines is the most direct way to boost the performance of your ArcGIS Server system. You can add new SOC machines, or additional CPUs to SOC machines already on the system. It's important to note that the server object manager (SOM) assumes that all SOC machines have the same configuration (speed of CPUs and amount of RAM) when it balances the load across the system. The SOM also assumes the same licensing exists across all SOCs, meaning if your system makes use of functionality provided by one of the ArcGIS Server options (Spatial, 3D or StreetMap), then it's assumed that all SOC machines are licensed for that functionality.

Note that you must have the Enterprise level of ArcGIS Server in order to install ArcGIS Server components on more than one machine.

Occasionally you may need to remove a SOC machine. When you remove a SOC machine from your system, the GIS server will more heavily utilize the resources of the remaining SOC machines in your system, which may affect performance of the GIS server as a whole. The services that had been running on the machine you remove will be reallocated to other machines.  

Granting permissions to the SOC account

When you run the GIS server post install, you are prompted to enter a name and password for the SOC Account. When the server object manager starts a container process, the container process runs as this account. Since you do not know the SOC machine on which any given process will be started, its important that you specify the same name and password for the SOC account for each machine on which you run the GIS server post install.

The post install gives you the choice of specifying an existing account, or letting the software create the account for you. If you choose to let the post install process create the SOC account for you, it is only granted privileges to launch container processes and write to the system temp directory. This means that you have to manually grant permissions for the SOC account to access any data and directories used by your services. Failure to grant adequate permissions to the SOC account is a common cause of services not displaying as expected.

The SOC account must have at least read access to any GIS resources (maps, locators, data) that your services require to do their work. This includes all of the data referenced in the resource. For example, in order to publish a map document as a service, the map document and all of the data for its layers must be in locations to which the SOC account has permissions. To ensure that all SOC machines reference the data in the same way, you can either use UNC paths or store a local copy of the data at an identical path on each SOC machine. The latter option is impractical for large or frequently changing datasets.

If a service makes use of a server output directory, ensure that the container account has read/write permissions to the directory. If your application will query the server log files using the Server API, make sure the container account has permissions to the log directory.

Entering the SOC name

When adding a SOC machine to your server, be sure to type the exact name of the machine; do not use "localhost".

Suggestions for Web servers

The Web server hosts the Web services and applications that you create with the ADF. It receives requests from clients and relays appropriate tasks to the GIS server. Because there are different flavors of Web servers, you should consult your own Web server's documentation for specific details on its setup and troubleshooting.

Each Web server in your configuration must have the ADF Runtime installed, and must have access to the Web application or Web service that you want to run. The SOM and SOC components of the GIS server can also reside on the same machine as the Web server. This is especially useful in small developer configurations, or where hardware is limited.

Your ArcGIS Server system can include more than one Web server. Reasons for using multiple Web servers include increased computing power for handling traffic to your site, and the ability to keep your site online in case one of the Web servers goes down. Network load balancing techniques can help you distribute requests evenly between the Web servers. Some sites that require constant availability maintain Web servers in more than one geographic location, so that a natural disaster or power failure does not take all of their Web servers offline.

Accounts and permissions

The diagram below displays which post installs, accounts, and permissions are required for each machine in your ArcGIS Server configuration. Each machine in the diagram contains some green text denoting which post install you must run on that machine. Items in blue are accomplished by the post install. Items in red are things that you must do. Note especially that you must manually add the ArcGIS Web services account on each dedicated SOC machine.

If you're installing ArcGIS Server across multiple machines, the SOM, SOC, and ArcGIS Web Services accounts must use the same names and passwords on each machine. For example, if you run the post install on a machine and you accept the default name of ArcGISSOC for the SOC account, you must use the name ArcGISSOC for the SOC account on any other machine that you run the post install. The passwords must similarly match.

Further reading

ESRI maintains a System Design Strategies document that contains recommendations for system configuration and sizing. This document contains sections relevant to ArcGIS Server, as well as other ESRI products. You can find the document at