Making your data accessible to ArcGIS Server
ArcGIS Server makes your data, such as maps, tools, imagery, locators, and so on, available to many other computers in your organization and potentially the entire Internet. However, your GIS server machines need to be able to freely access your data in order to expose it effectively. There are three main things you need to do to make your data accessible to ArcGIS Server:
- Store your data where all GIS server machines can see it.
- Grant the ArcGIS Server account permissions to your data. The ArcGIS Server account is the operating system account you specified when you installed ArcGIS Server, not the primary site administrator specified when the ArcGIS Server site was created.
- Register your data with the server.
This topic covers all of the above requirements. First, it's helpful to understand how ArcGIS Server stores and references the data behind its services.
How ArcGIS Server stores and accesses data
When you publish an item as a service, that item is placed on the server. Thus, if you publish a locator as a geocode service, a copy of the locator ends up on the server where ArcGIS Server has sufficient permissions to access it.
Sometimes, you might publish an item that references additional data. For example, a map might reference various feature classes stored throughout your file system. This data is only moved to the server if you do not register the data with the server when publishing. Alternatively, if you do not want the data to be copied to the server at the time of publishing, you need to explicitly take the steps below to ensure ArcGIS Server can see and access your data.
Storing your data where all GIS server machines can see it
Each GIS server machine in your deployment needs to be able to read your GIS resources and all the data they reference. For example, when you publish a map as a service, all the data for the map's layers must be visible to all GIS server machines. Following are some approaches for how you can store the data.
Storing the data locally on each GIS server machine
When you save your data to a local path, for example, C:\data and create a service from it, other GIS server machines are not able to work with the service unless they have their own copies of the data residing at C:\data. Loading an identical copy of your data into an identical path on each GIS server machine can be beneficial for performance, but it may not be a practical solution for large or frequently changing datasets.
Storing the data in a shared directory
Another way to make your data available to all GIS server machines is to use the operating system tools to share the directory in which the data is stored. Shared directories are commonly referred to with Universal Naming Convention (UNC) paths, which contain the name of the server (for example, \\myServer\data). When you use UNC paths to reference your data, all GIS server machines will look to the correct machine for the data.
If you store your GIS resources in shared directories, remember that all data source paths within the resource must also use UNC paths or relative paths. For example, if your map document contains layers from three feature classes, the paths to those feature classes must be UNC or relative paths.
Although shared network folders are convenient for referencing data, they require network traffic and can introduce performance bottlenecks that would not otherwise exist when accessing the data through local paths.
Storing the data in a database accessed through ArcSDE
Many GIS shops store large data collections in a relational database management system (RDBMS) such as SQL Server or Oracle. Esri ArcSDE provides a way to conveniently organize and use spatial data from an RDBMS in ArcGIS.
ArcSDE geodatabases are convenient and powerful, but often don't yield as fast of performance as you would see when accessing the data locally. In some cases, you may be able to use ArcSDE to replicate to other formats that are easy to store locally, such as file geodatabases. You can then place the data on each GIS server machine for optimum performance. See Data storage considerations for an ArcGIS Server site to learn about whether this approach is right for you.
Grant the ArcGIS Server account permissions to your data
When you log in to your own computer, the account name you use gives you access to all your files and folders on the computer. No one else can access your data unless you allow them to. The same holds true for your GIS data. The ArcGIS Server account needs to have at least read permissions to any data that you use in your services. In some scenarios where edits are occurring, it may also need to have write permissions.
When do you need to apply permissions?
The items you publish are copied to the server where the ArcGIS Server account has already been granted permissions. However, the data referenced in those items (for example, the layers in a map or globe) may or may not have the correct permissions applied, depending on whether you chose to register the containing folder or database with the server when publishing:
If you chose to have the server automatically copy data to the server, there is no need to set any additional permissions. All the data is copied to the server where the ArcGIS Server account already has permissions. If your source data is file-based and you are publishing a feature or transaction-enabled WFS (WFS-T) service, the source data is copied into a geodatabase that you have registered with the server, called ArcGIS Server's Managed Database. You do not need to grant permissions to the ArcGIS Server account to access the source data that is copied to the server.
To learn more, see Copying data to the server automatically when publishing.
If you chose to register the containing folder or database with the server, you need to explicitly give the ArcGIS Server account permissions to read from that folder or database. For example, when you publish a globe service, you don't need to give the ArcGIS Server account permissions to read your 3DD file (because this is always copied to the server). However, you need to explicitly give the ArcGIS Server account permissions to the data referenced by the layers of that 3DD document.
This process is described in the remaining sections of this topic.
Granting permissions for file-based data
If your data is file based, such as shapefiles and image files, you'll need to work with the operating system to set access to the folders that contain your data. The ArcGIS Server account must have at least read access to the data and write access if the data will be edited. Here are some scenarios:
- If your data resides on the GIS server machine (or one of the GIS server machines in the event you have more than one), grant the ArcGIS Server account read (and optionally write) access to the folders containing your data.
- If the data doesn't reside on the GIS server machine and you specified a local account as the ArcGIS Server account, you will first need to create an identical local account (having the same user name and password) on the machine that hosts your data. Then grant that local account read (and optionally write) access to the folders containing your data. As long as the local accounts on the machine with data and the GIS server machine are identical, the GIS server machine will be able to access the data.
- If the data doesn't reside on the GIS server machine and you specified a domain account as the ArcGIS Server account, simply grant the domain account read (and optionally write) access to the folders containing your data.
You should be aware of your operating system's security mechanisms and hierarchies. For example, if you are working from a shared directory in Windows, you will have to give the ArcGIS Server account share permissions for the folder, then you will have to switch to the Security tab of the folder properties and grant NTFS (file) permissions to the ArcGIS Server account for the folder. If you do not grant both types of permissions (share and file), you will not be able to access the resource, since the operating system gives precedence to the more restrictive of the two.
Granting permissions to data in a geodatabase
When you create a service that references data in a geodatabase, you need to ensure that the server has the appropriate permissions to access the geodatabase. The type of permissions you need to grant depends on what type of geodatabase you are using and, in the case of ArcSDE, what type of authentication you are using to connect.
If your service accesses data from a file geodatabase, you should use the operating system to give the ArcGIS Server account read permissions to the folder containing the geodatabase.
ArcGIS 10.1 for Server does not support personal geodatabases.
The way you grant access to an ArcSDE geodatabase depends on whether your GIS resource uses database authentication or operating system (OS) authentication to connect to ArcSDE. How can you tell which type of authentication is being used? If the geodatabase is in SQL Server Express, it uses OS authentication. If the geodatabase is in an enterprise RDBMS (Oracle, SQL Server, DB2, Informix), you can view the connection properties in ArcCatalog or the Catalog window in ArcMap to find out whether it uses database authentication or OS authentication.
Using database authentication
When using database authentication, check your spatial database connection properties in the Catalog tree and make sure you've checked the option to save the user name and password. If you create a map or globe document that uses data through that connection, the name and password will be saved in the map or globe document, and your service should be able to get the data successfully.
If you are publishing something as a service directly from the geodatabase, such as a locator or raster dataset, copy the database connection file to a location accessible to all GIS server machines.
Using OS authentication
If your ArcSDE data will be accessed through OS authentication, you'll need to add the ArcGIS Server account to the geodatabase, then grant it permissions to the resource that it needs to access. When the service runs, it will log in to the DBMS as the ArcGIS Server account. The way that you add the ArcGIS Server account and grant it permissions varies depending on what type of ArcSDE geodatabase you are using:
If you're working with an ArcSDE geodatabase at the enterprise level, the way that you add the ArcGIS Server account as a valid user of the database varies depending on the DBMS that you are using. You may find it helpful to consult your DBMS documentation to learn how to grant access to an operating system account. Once you've added the ArcGIS Server account, you need to grant it SELECT permissions to the resource that you are going to publish. Additional permissions may be necessary if you will be editing data.Note:
It's important to copy the database connection file to a location accessible to all GIS server machines.
If you're working with an ArcSDE for SQL Server Express geodatabase, you need to perform the following steps in ArcCatalog or the Catalog window to give the ArcGIS Server account the necessary permissions:
- Double-click Database Servers in the Catalog tree.
- Right-click the database server containing the geodatabase and click Permissions.
- Click Add User and add the ArcGIS Server account. Click OK.
- Double-click the same database server.
- Right-click the geodatabase, click Administration, then click Permissions.
- Click the ArcGIS Server account to select it and choose the level of permissions you want it to have. You'll need at least read permissions to see the data and write permissions for editing. See A quick tour of permissions for database servers in the ArcGIS Help if you need further help deciding which permissions would be necessary for your ArcGIS Server account.
Registering your data with the server
After you have granted the ArcGIS Server account the appropriate permissions to the folders and databases that contain your data, you need to register them with the server using ArcGIS Server Manager or ArcGIS for Desktop. Data registration gives you the most control over how your server will access data and helps you ensure that the data are truly accessible by the server.
For full instructions, see the following topics: