How configuration files work
The server maintains configuration properties for both the GIS server and its services in a collection of configuration files. When the server object manager (SOM) starts, it reads these configuration files. These files use XML to define such things as the set of server object container machines, server directory locations, and other properties of service configurations. There are three types of configuration files:
- The server configuration file, Server.dat, is located in the <ArcGIS install location>\Server\system folder on the SOM machine on Windows. On Linux/Solaris, this file is located under <ArcGIS Server Installation directory>/arcgis/server/system folder.
- Service configuration files are maintained in <service name>.<service type>.cfg files, which reside in the <ArcGIS install location>\Server\user\cfg folder on Windows. On Linux/Solaris, it's located under <ArcGIS Server Installation directory>/arcgis/server/user/cfg folder. For example, the configuration file for the map service configuration Yellowstone would be Yellowstone.MapServer.cfg.
- Security configuration files contain permissions rules for a service. These are stored in <ArcGIS install location>\server\user\cfg on Windows and <ArcGIS Server Installation directory>/arcgis/user/cfg on Linux/Solaris. They follow the same naming convention as the service configuration file but end with the .sec extension instead of .cfg.
When you modify the properties of the server or its services (either through an administrative interface such as Manager or programmatically with the server API), these changes are reflected in the appropriate configuration file.
Although you can modify configuration files manually using a text editor, it is recommended that you edit their contents using an administrative interface such as Manager or ArcCatalog, or the ArcObjects Server API. Before you edit the configuration files, you must stop the ArcGIS Server Object Manager service.
If there are errors in the server configuration file, the SOM logs an error and attempts to use defaults for the missing or invalid values. If the SOM encounters a corrupted service configuration file, it logs a warning and ignores the configuration.