Server configuration files
Release 9.3 E-mail This Topic Printable Version Give Us Feedback

The Server.dat file maintains the server's properties. The server object manager (SOM) reads the contents of this file at its startup. The server reports a successful start once this file has been successfully read and any initialization detailed in it completed. If there are errors in the file, the SOM logs an error and attempts to start using default values for the missing or invalid properties.

When the SOM is first installed on a machine, the Server.dat file does not exist. Server.dat is created after the SOM is started, and either a server object container (SOC) machine or a server directory is added to the GIS server.

The following is an example of a Server.dat file for a GIS server with a single container machine (cup) and a single output directory (\\padisha\images) whose logging level is 3.

<Server>
  <SecurityEnabled>false</SecurityEnabled>                  
  <ServerMachines>
    <Machine>
      <Name>padisha</Name>
      <Description>Server container machine 1</Description>   <Capacity>-1</Capacity>
    </Machine>
  </ServerMachines>
  <ServerDirectories>
    <Directory>
          <Path>\\padisha\arcgisserver\arcgiscache</Path>
          <URL>http://padisha/arcgiscache</URL> 
          <Description>Cache location</Description>
          <Type>cache</Type>
    </Directory>
    <Directory>
          <Path>\\padisha\arcgisserver\arcgisjobs</Path>
          <URL>http://padisha/arcgisjobs</URL>
          <Description>Geoprocessing jobs location</Description> 
          <Type>jobs</Type>
          <Cleaning>sliding</Cleaning>
          <MaxFileAge>21600</MaxFileAge>
      </Directory>
      <Directory>
          <Path>\\padisha\arcgisserver\arcgisoutput</Path>
          <URL>http://padisha/arcgisoutput</URL>
          <Description>Output directory location</Description>
          <Type>output</Type>
          <Cleaning>sliding</Cleaning>
          <MaxFileAge>600</MaxFileAge>
      </Directory>
  </ServerDirectories>
  <Properties>
    <LogPath>C:\Program Files\ArcGIS\Server\user\log\</LogPath>
    <LogSize>10</LogSize>
    <LogLevel>3</LogLevel>
    <ConfigurationStartTimeout>300</ConfigurationStartTimeout>
    <EngineContextTimeout>600</EngineContextTimeout> <AISServer>127.0.0.1:3982</AIServer>
  </Properties>
</Server>

Server.cfg tags

The following are the tags, their meanings, and example values in a Server.dat file.

<SecurityEnabled>

Determines whether security rules that you've set on your services will be enforced. By default, this tag is set to false. Enabling security for services in Manager sets this tag to true. The only way to set it back to false is to manually edit the Server.dat file and restart the ArcGIS Server Object Manager service.

<CrashDetectorFrequency>

The SOM periodically pings the SOC processes to see if they are still responsive. After the CrashDetectorFrequency elapses, the SOM pings every SOC process. The time for this check to finish depends on the number of SOC processes running on all of the SOC machines. When the check finishes, the SOM will wait this interval before starting the check again. This interval defaults to 5 seconds.

<ServerMachines>

The list of server object container machines. This tag contains <Machine> subtags for each server machine.

<Machine>

A server object container machine. This tag contains three subtags: <Name>, <Description>, and <Capacity>.

<Name>

A string that represents the name of the server object container machine. If this tag is missing, the rest of the <Machine> tag is ignored. On startup, the SOM does not validate that the value of this tag is a valid server object container machine. If it's invalid, errors will be logged as the SOM attempts to create services on it. The machine names must be unique. Duplicate machines will be ignored.

<Description>

An optional string that describes the server object container machine.

<Capacity>

An integer representing the maximum number of service instances that can run on the machine. When setting this property, be aware that the server already runs two background instances that are used for logging and managing server directories. Setting the capacity too low could cause these mechanisms to work incorrectly if they have to compete for space with services.

The following is an example of the <ServerMachine> tag, <Machine> tag, and its subtags.

  <ServerMachines>
    <Machine>
      <Name>padisha</Name>
      <Description>Server container machine 1</Description>
      <Capacity>25</Capacity>
    </Machine>
    <Machine>
      <Name>melange</Name>
      <Description>Server container machine 1</Description>
      <Capacity>25</Capacity>
    </Machine>
  </ServerMachines>

<ServerDirectories>

The list of server directories. This tag contains <Directory> subtags for each server directory.

<Directory>

A server directory. This tag contains the required subtag <Path> and a number of optional subtags.

<Path>

A string that represents the path of the server directory. This property is required and must be unique to each server. Directories with duplicate <Path> tags will be ignored. Note, however, that if a single location has multiple paths--for example, two shares with different names--the SOM will not recognize those as being the same directory.

<URL>

An optional string that represents the URL of a virtual directory that points to the physical location specified in the <Path> tag. The URL will be in the form http://padisha/images.

<Description>

An optional string that is a description of the server directory.

<Type>

A string that denotes whether the directory will be used for server cache, jobs, or output.

<Cleaning>

An optional string that specifies the server directory's cleaning mode. Valid values are off, sliding, or absolute. If <Cleaning> is off, then the server will not clean up its files in the directory. If <Cleaning> is sliding, then the server will delete files for which the time specified by the <MaxFileAge> tag has elapsed since they were last accessed. If <Cleaning> is absolute, then the server will delete files for which the time specified by the <MaxFileAge> tag has elapsed since they were created. If this tag is missing, the default value is sliding.

The <Cleaning> tag is only used with server jobs and output directories. It is not used with server cache directories.

<MaxFileAge>

An optional positive integer that represents the amount of time in seconds that needs to elapse since a file was last accessed (sliding) or created (absolute) before the file is deleted. If this tag is missing, the default is 10.

The <MaxFileAge> tag is only used with server jobs and output directories. It is not used with server cache directories.

The following is an example of the <ServerDirectory> tag, <Directory> tag, and its subtags.

  <ServerDirectories>
    <Directory>
      <Path>\\padisha\arcgisserver\arcgiscache</Path>
      <URL>http://padisha/arcgiscache</URL>
      <Description>Cache location</Description>
      <Type>cache</Type>
    </Directory>
    <Directory>
      <Path>\\padisha\arcgisserver\arcgisjobs</Path>
      <URL>http://padisha/arcgisjobs</URL>
      <Description>Geoprocessing jobs location</Description>
      <Type>jobs</Type>
      <Cleaning>sliding</Cleaning>
      <MaxFileAge>21600</MaxFileAge>
    </Directory>
    <Directory>
      <Path>\\padisha\arcgisserver\arcgisoutput</Path>
      <URL>http://padisha/arcgisoutput</URL>
      <Description>Output directory location</Description>
      <Type>output</Type>
      <Cleaning>sliding</Cleaning>
      <MaxFileAge>600</MaxFileAge>
    </Directory>
  </ServerDirectories>

<Properties>

The list of properties of the GIS server, including the logging properties and service creation time-out. All the subtags of Properties are optional.

<AISServer>

An optional tag that appears only when you've registered an ArcGIS Image Server with ArcGIS Server. The tag structure is <Image Server IP address>:<port>

<ConfigurationStartTimeout>

An optional integer that represents the time in seconds that the GIS server will wait for a service instance to start. If a service takes longer to start than <ConfigurationStartTimeout>, then it will time out and an error will be logged. The default time-out is 300.

<CrashDumpDir>

The path on disk to which ArcGIS Server error reports will be written. For the error reports to be generated, the <CrashDumpMode> tag must be set to a value of 2.

The path you list here can be either a local path or a UNC path to a shared location (recommended for multiple-machine deployments). The SOM and SOC accounts must have Read and Write permissions to the directory you reference in this path.

Learn more about ArcGIS Server error reports.

<CrashDumpMode>

Specifies whether ArcSOC.exe processes will be allowed to crash and what the server should do when a crash occurs. The default value of 0 means that ArcSOC.exe processes cannot crash. A value of 1 allows ArcSOC.exe processes to crash with a message written to the log file. A value of 2 allows ArcSOC.exe processes to crash with a message written to the log file and an error report written to the location specified in the <CrashDumpDir> tag.

Learn more about ArcGIS Server error reports.

<EngineContextTimeout>

An optional integer that represents the maximum amount of time in seconds a client can hold on to a service that is no longer in use (empty server context) before it is automatically released. The default is 600.

<LogLevel>

An optional integer that indicates the level of detail to which the server writes in the log files. The levels are as follows:

0 (None)

1 (Error)

2 (Normal)

3 (Info:Simple)

4 (Info:Standard)

5 (Info:Detailed)

6 (Verbose)

The default log level is 2, or Normal. For more detailed descriptions of the log levels, see Interpreting log files.

<LogPath>

An optional string representing the path to the location on disk to which log files are written. The default is <install_location>\server\user\log. Note that the GIS server account must have write access to this location.

<LogSize>

An optional integer representing the size to which a single log file can grow (in MB) before a new log file is created. The default is 10.

<MachinePingAttempts>

An optional tag specifying the number of attempts to try to reach the SOC machine if a ping attempt fails. The SOM periodically pings its SOC machines every n milliseconds, n being the value of the MachinePingInterval tag. If a SOC machine does not respond, the SOM will continue trying to ping that SOC until MachinePingAttempts is reached, at which point the SOC will be marked as disabled. Disabled SOCs are still pinged, and if they are determined to be alive later, they are validated and added back into the group of SOCs available to take requests from the SOM.

The default value of MachinePingAttempts is 2.

<MachinePingDelay>

An optional tag specifying the time in milliseconds between subsequent attempts to ping the SOC machine if the first ping attempt fails. See the definitions for MachinePingInterval, MachinePingTimeout, and MachinePingAttempts in this help topic for more information.

Below is an example of the <Properties> tag of Server.dat with its subtags.

  <Properties>
    <LogPath>/cup1/arcgis/server/user/log/</LogPath>
    <LogSize>10</LogSize>
    <LogLevel>3</LogLevel>
    <ConfigurationStartTimeout>300</ConfigurationStartTimeout>
    <EngineContextTimeout>600</EngineContextTimeout> <AISServer>127.0.0.1:3982</AIServer> <MachinePingInterval>10000</MachinePingInterval> <MachinePingTimeout>2000</MachinePingTimeout> <MachinePingAttempts>3</MachinePingAttempts> <MachinePingDelay>500</MachinePingDelay>
  </Properties>

<MachinePingInterval>

The SOM periodically pings its SOC machines to determine if they're still available. This tag specifies the time in milliseconds that will elapse between the SOM's attempts to determine whether its SOC machines are still connected. Unresponsive machines may be marked as disabled. The default MachinePingInterval is 3000 (3 seconds); in other words, this is the value the SOM uses if you do not add this tag.

<MachinePingTimeout>

An optional tag specifying time in milliseconds to wait for a response from a SOC machine before considering the attempt a failure. The default is 1000 (1 second). If the attempt fails, the SOM will continue pinging the SOC n number of times, n being the value you specify in the MachinePingAttempts.