Below are listed some questions or issues that you may face when working with ArcGIS Server, and some recommended solutions. If you don't find the problem you are looking for, you can also search for articles on the ESRI Support Site.
If you have set up a distributed system where the Web server, server object manager and server object containers are all on separate machines, ArcGIS Server will not function without the network. If, however, all these components are running on the same physical machine, ArcGIS Server will operate correctly as long as all data is referenced using local pathnames rather than shared network directories with UNC pathnames. For example, when you publish a resource such as a map document, publish it from your C:\ drive and ensure that all layers reference local data through local pathnames as well.
The SOM and SOC accounts are used internally by the GIS server and need only have limited permissions on the machine. Chances are you'll only encounter them when you're installing ArcGIS Server on other machines, or when you're giving the GIS server permissions to access your data. In most cases, it's sufficient to use the default account names suggested by the post install (ArcGISSOM and ArcGISSOC) and let the post install create the accounts for you. The post install creates local accounts, which are recommended over domain accounts for security reasons.
ArcGIS Server names cannot exceed 15 characters or you will encounter errors during the post install and when trying to connect to the server. This is a known limit related to a Microsoft specification for active directory names.
You can consume 9.1 services using ArcCatalog 9.2 and using existing Web applications that you have migrated directly from 9.1 to 9.2. However, Web applications that include the 9.2 Web controls can only connect to 9.2 services. You can follow the familiar publishing process to create 9.2 services patterned after the server objects you published at 9.1. See Moving to ArcGIS Server 9.2 to learn more about migration requirements and workflows.
To log into Manager, you must use an account that is an Administrator on the Web server machine, and a member of the agsadmin group on the server object manager (SOM) machine.
Logging in to Manager in Windows XP also requires that simple file sharing be disabled. In the simple file sharing model, all attempts to log on to the computer from across the network are forced to use the Guest account. Manager and Web ADF applications need to authenticate as the ArcGIS Web Services account, not the Guest account, therefore you will need to disable simple file sharing if it is not disabled already. To disable simple file sharing follow these steps:
Occasionally, the situation may arise that your data is on a machine with no components of ArcGIS Server installed and you are following the recommended practice of using local accounts for the SOC Account. You will need to use the operating system tools to create a local SOC Account on the machine containing your data. Create a local account on the machine hosting your data, and assign it the same name and password as the SOC Account on all of the other machines in your deployment. The GIS server will then be able to recognize that it has permissions to access your data.
To understand how to configure the correct permissions required for ArcSDE and other geodatabase layers, see Preparing resources for publishing.
If you see a blank Preview panel, with coordinate values appearing below as you move the mouse, it’s likely that the ArcCatalog can’t get the map image from the virtual directory you have associated with your output directory. In this situation, ArcCatalog has all of the information about the map except for the actual image, which is why you see the coordinates as you move the mouse. The best chance of fixing the problem is to check the virtual directory settings using your Web server administration software, making sure that the virtual directory is correctly pointing to the output directory on disk.
If you want to verify that the problem is with the output directory, adjust the map service’s properties so that the supported image return type is MIME only. This setting does not use an output directory. If you see the image with MIME only, and you don’t see it with MIME + URL, then you know there is a problem with the output directory and/or the virtual directory.
You can browse to the output directory on disk to make sure that the images are being created inside. If you see images being added to the output directory as you try to Preview the map service, then you know that the problem is with the virtual directory settings.
Failover and round robin are techniques used to provide a backup server in case one server in your configuration goes down. As you design your Web applications in Eclipse or Creator, you can specify additional GIS servers that the application will use, and whether they will act in a failover or round robin mode.
This may be due to impersonation behavior with Windows 2000 that Microsoft has documented here: http://support.microsoft.com/default.aspx?scid=kb;en-us;810204 You will need to give the ASPNET account “Act as part of the Operating System” privileges in order for your applications to work. To do this, follow these steps:
The .NET and Java versions of ArcGIS Server can co-exist on the same machine. If you do this, you will need to follow the procedure below to ensure that your server directories correctly map to the virtual directories appropriate for your IIS or Apache web server:
Searches against an ArcGIS Server map service can sometimes return more records than expected. This is because of the way the search works. When you define the Search Attributes task in Manager, you specify the layers to search and the fields in those layers to search. Although it appears in Manager that specific fields will be searched for specific layers, in reality you are simply defining a list of layers to search and a list of fields to search in. Thus, if two layers have the same field name, the field will be searched in both layers.
In some cases, Internet Explorer 6 does not correctly apply transparency to the PNG images that comprise the map cache. Therefore, one fused cache overlaying another may display in an unexpected way. A workaround is to blend the image at the Web tier by setting ImageBlendingMode=WebTier on the Map control. Note that this mode of blending may not perform as quickly as browser tier blending.
When you create a cache for a map service, ArcGIS Server must render map images that cover the full extent of the area you designated for the cache, at each scale level you indicated. In the case of a multilayer cache, it must repeat this process for each layer. Additionally, it must create the files and folder structure necessary to contain the cache.
The time needed to create the cache also depends on the scale levels you have chosen, the amount of server resources you have dedicated to building the cache, and the density of information in the map. Even using a powerful server, a large cache can sometimes take days or weeks to generate. In many cases, the performance benefit gained from using the cache still outweighs the long time necessary to create the cache.
When creating your cache, consider which layers constitute your base map. These are layers that are unlikely to change often and act as a background for the thematic layers of your map. Cache generation and display will complete more quickly if you used the fused cache option to cache all of your base map layers together.
When you create a multilayer cache, the server makes a set of cached images for each layer. When you display the map, the server must still blend together the tiles from each layer. The more layers you have in your multilayer cache, the longer the blending will take. If you attempt to use a multilayer cache with too many layers, you may lose the performance benefit of the cache. Additionally, the cache takes longer to create because each layer has to be rendered at all scale levels over the extent of the cache.
You may find it useful to test a small portion of your map with different caching scenarios to see if blending a fused cache with a non-cached service, or blending multiple fused caches, would be faster than using a multilayer cache.
When choosing the scale levels for your cache, remember that the closer you get to the map, the more tiles are required to cover the map extent. Therefore, the smaller the scale factor you choose, the longer it will take your cache to generate. Every time you divide the scale factor by two, it takes four times as many tiles to cover a square area of the map. For example, a square map at 1:500 scale contains four times more tiles than a map at 1:1,000 scale, and a square map at 1:250 contains 16 times more tiles than a map at 1:1,000 scale.
To get an idea of how quickly the number of tiles in a cache can increase, open your map in ArcMap. Zoom out so that you can see an area of the map in a space about 512 pixels wide by 512 pixels high. (This area will vary depending on your display settings. Chances are it’s about 5–6 inches (12.70–15.24 cm) on a side). At this scale, it would take one cache tile at default settings to cover the area. Now halve the scale factor of your map. (For example, if you were originally viewing the map at 1:40,000 scale, zoom in to 1:20,000.) At this scale it would take roughly four tiles to cover the area. Halve the scale factor again, and it would take about 16 tiles to cover the area. This table shows how the number of tiles needed to cover the original square area would increase with each halving of the scale factor. A hypothetical scale factor is shown starting at 1:16,000,000, about the area needed to cover the western United States in one 512 by 512 pixel tile.
| 1st level | 1:16,000,000 | 1 tile |
| 2nd level | 1:8,000,000 | 4 tiles |
| 3rd level | 1:4,000,000 | 16 tiles |
| 4th level | 1:2,000,000 | 64 tiles |
| 5th level | 1:1,000,000 | 256 tiles |
| 6th level | 1:500,000 | 1,024 tiles |
| 7th level | 1:250,000 | 4,096 tiles |
| 8th level | 1:125,000 | 16,384 tiles |
| 9th level | 1:62,500 | 65,536 tiles |
| 10th level | 1:31,250 | 262,144 tiles |
When you create a cache, you can indicate the number of MapServer instances that you want to work on the cache. The more instances you choose, the more server resources will be dedicated to building the cache, and the faster the cache will generate. A good starting point is three instance per server object container (SOC) CPU. As you increase the number of instances, you will reach a point where you are utilizing the full power of your server and you will not gain any performance benefit until you add more SOC computing power to your system.
When you create a map cache from a service, the server extends the service's usage timeout so that it can work with the service for as long as necessary to create the cache.
The cache size and time needed to create the cache are both affected by the density of information within the map. Areas of the map with many changing colors and patterns will yield larger-sized cache tiles than more homogenous areas. For example, maps with high resolution raster images will probably cause large tile sizes; not because of the original image size on disk, but because of the variation in color and pattern between the image pixels.
Similarly, maps that contain many layers and take relatively long amounts of time to render in ArcMap will typically require more time for creating a cache. This is because the server must repeatedly render the appropriate layers of the map as it creates the tiles for each scale level.
If you’re waiting for a cache to finish generating, you can view its progress by opening Windows Explorer and noting how many files and folders have been created in your cache directory. Remember that according to the formulas above, the last layers of your cache will take the longest to draw. The final layer alone could possibly take longer than all of the other layers combined, depending on the scale factors you have chosen for your cache.