As an ArcGIS Server administrator or a publisher in your organization, you have the option to register your on-premises data stores and cloud stores. In doing so, you are registering data folders, databases, and geodatabases with the ArcGIS Server site so that services you publish can reference the data in those folders, databases, and geodatabases. Data registration provides ArcGIS Server a list of locations to access. Data registration also helps ArcGIS Server adjust data paths when publishing across machines.
Suppose you're an ArcGIS Server administrator and you have a department of GIS analysts who publish services to your ArcGIS Server site from different client machines. Using tools in ArcMap, ArcGIS Pro, or ArcGIS Server Manager, you can register a set of approved data store locations with the site and communicate these locations to your analysts. Publishers can also register approved folders, databases, enterprise or workgroup geodatabases, cloud stores, and raster stores with the site. Registering these data stores with the ArcGIS Server site decreases the number of incidents where your analysts encounter permissions problems and cannot publish. The publisher can create services that reference the data in the registered data stores.
Data sources you can register
The next five sections describe the data stores that publishers and ArcGIS Server administrators can register with an ArcGIS Server site.
If your data locations change, update your registered data locations using ArcGIS Server Manager, ArcMap, or ArcGIS Pro.
Databases
You can register any database management system that ArcGIS supports by referencing the database connection file (.sde). The database you connect to can contain a geodatabase, but it doesn't have to.
If you use a database-authenticated user to connect, the user account information must be saved with the .sde file, and that user must have the necessary privileges to the data to be published. For example, if you publish a feature service that you want people to use for updating and adding features, the user saved with the registered connection file must have update and create privileges on the data in the database.
If you use operating system authentication, you must add the ArcGIS Server primary server account to the database and grant it the privileges necessary to access the data.
Note:
If the database you register contains a versioned geodatabase, ArcGIS Server accesses the version of that data present in the geodatabase version you set for the connection file. If you want ArcGIS Server to access different versions, you must register separate connection files to connect to these geodatabase versions. For example, you may need to register one connection file that accesses the Default geodatabase version and one that accesses a child version.
Note:
OLE DB data sources cannot be registered with ArcGIS Server (Linux). The default behavior is that the data is always copied to the ArcGIS Server machine and converted to file geodatabase tables. To learn more, see Copying data to the server automatically when publishing.
Folders
You can register local and shared operating system folders with the ArcGIS Server site that includes data files you want to publish. These folders can contain shapefiles, file geodatabases, locator files, imagery (raster) files, and big data files.
When you register a folder, its subfolders are also registered. Do not register an entire drive with ArcGIS Server due to security considerations.
Big data file shares
Big data file shares are shared operating system folders, Hadoop Distributed File Systems (HDFS), Apache Hive, or cloud stores containing collections of delimited files or shapefiles used as input for GeoAnalytics Tools.
To use a cloud store as a big data file share, you must first register the cloud store. Big data file shares support Amazon Simple Storage Service (S3) buckets, Microsoft Azure Blob storage containers, and Microsoft Azure Data Lake Stores.
See Get started with big data file shares for information on registering big data file shares.
Raster stores
Raster stores are an output data store; they contain the imagery layers created when you run raster analysis tools. Raster stores can be either a file share or a cloud store.
To use a cloud store as a raster store, you must first register the cloud store. Raster stores support Amazon S3 buckets and Azure Blob storage. At 10.6.1, you can also use Alibaba Cloud Object Storage Service (OSS).
See Configure and deploy ArcGIS Enterprise for raster analytics in the Portal for ArcGIS administrator guide for information on registering a raster store.
Cloud stores
You can register an Amazon S3 bucket or Microsoft Azure Blob storage container to use as a raster store, big data file share, or to store map and image caches. At 10.6.1, you can register an Alibaba OSS as a cloud store for map and image service caches or to use as a raster store. Also at 10.6.1, you can register a Microsoft Azure Data Lake store as a cloud store to be used for big data file shares
You should only use a cloud store for map and image service caches if your ArcGIS Server site is running on that same cloud platform. For example, only use Azure Blob storage for map and image service caches if your ArcGIS GIS Server and ArcGIS Image Server sites are running on Microsoft Azure.
Before registering data
Registering your data does not grant the ArcGIS Server site permissions to access your data. Before registering your data, you'll need to ensure that the ArcGIS Server account has at least read permissions to the data stored in folders, workgroup geodatabases, or in databases or enterprise geodatabases that are accessed using operating system authentication. For databases or enterprise geodatabases that are accessed using database authenticated users, that user must be granted permissions to the data. To learn more about this process, see Make your data accessible to ArcGIS Server.
If you'll be registering an enterprise geodatabase or database (a .sde or .odc file) with the ArcGIS Server site, you'll also need to ensure that the 64-bit version of the database's client software is installed on each ArcGIS Server machine in your site. For example, if you plan to register a SQL Server database, you must install SQL Server client on each ArcGIS Server machine in your site. Keep in mind that once you've installed the client software, you'll need to restart ArcGIS Server.
The following links describe the client software needed for each database, how to grant the ArcGIS Server account data access privileges, and how to connect to the database:
- Register ALTIBASE with ArcGIS Server
- Register a Dameng database with ArcGIS Server
- Register a Db2 database with ArcGIS Server
- Register a Netezza database with ArcGIS Server
- Register an Oracle database with ArcGIS Server
- Register a PostgreSQL database with ArcGIS Server
- Register SAP HANA with ArcGIS Server
- Register a SQL Server database with ArcGIS Server
- Register a Teradata database with ArcGIS Server
You cannot register Informix databases or Db2 on z/OS databases with an ArcGIS Server site. Instead, create a service definition file that references the data in the database and publish the service definition file.
Scenarios for registering your data
Before registering your data, examine the following scenarios and consider how your workflows relate:
A) The publisher's machine and the ArcGIS Server site reference the same database
If the publisher's machine and the ArcGIS Server site will reference the data in the same database, workgroup geodatabase, or enterprise geodatabase, import the publisher's database connection and set the ArcGIS Server site's database connection to Same as publisher's connection when registering your data.
When to use this scenario
Use this scenario if you want to avoid having a copy of the data placed on the ArcGIS Server machines. For example, suppose you want to publish a map service to ArcGIS Server from ArcMap or publish a map image layer to one of your portal's federated servers from ArcGIS Pro using data from an on-premises enterprise geodatabase. To avoid having a copy of the data referenced by your map document placed in a folder on one of the ArcGIS Server machines, import the publisher's database connection and set the ArcGIS Server site's database connection to Same as publisher's connection. After you publish, the map document continues to reference the data stored in your enterprise geodatabase.
When not to use this scenario
- If your data resides in a file geodatabase or file directory. Instead, use the next scenario.
- If you want to maintain a separate copy of the data in your enterprise geodatabase for web use.
B) The publisher's machine and the ArcGIS Server site reference the same folder
If the publisher's machine and the ArcGIS Server site will reference data in the same folder, specify the publisher's folder path and set the ArcGIS Server site's folder path to Same as publisher's path when registering your data. This scenario is just like the previous one, except it uses folders, not databases.
When to use this scenario
Use this scenario if you want to avoid having a copy of the data placed on one of the ArcGIS Server machines. For example, suppose you want to publish a geoprocessing service to ArcGIS Server using data from a network directory. To avoid having a copy of the geoprocessing service's data copied to one of the ArcGIS Server machines, specify the publisher's folder path and set the ArcGIS Server site's folder path to Same as publisher's path. After you publish, the geoprocessing service continues to reference the geoprocessing model, inputs, outputs, scripts, and project data stored in your network directory.
This scenario is also beneficial if you have a Linux-based ArcGIS Server site that manages all of your data and you've set up Samba to allow file sharing between Windows and Linux. For example, if you want to publish a map document that references the data on your Linux machine, register the Samba directory (\\net\data) as the publisher's folder and register the Linux directory (/net/data) as the ArcGIS Server site's folder. When you publish, the map document is automatically modified to reference the directory on the Linux machine.
Note:
When using a Samba directory to share data between Windows and Linux, you should disable opportunistic locking in your Samba configuration settings before publishing; otherwise, you may encounter errors when publishing. For full instructions, see Common problems and solutions.
When not to use this scenario
- If your data resides in a database. Instead, use the preceding scenario.
- If you want to publish feature or WFS-T services.
C) The publisher's machine and ArcGIS Server site reference different geodatabases and the data is not static
Because of firewalls, differences between computing platforms, or the desire to keep a separate copy of the data for web use, the publisher and ArcGIS Server site may each reference the same data in different geodatabases. To register your data using this scenario, you'll need to import both the connection to the publisher's database and the connection to the ArcGIS Server site's geodatabase.
When to use this scenario
Use this scenario if you want to maintain a separate copy of the data in your on-premises enterprise geodatabase for web use. In this case, you're responsible for making sure a copy of the data in your publisher's geodatabase exists in the ArcGIS Server site's geodatabase. This scenario can only be used with enterprise geodatabases; not databases.
To allow you to replicate data so both the publisher and the ArcGIS Server site have access to changes the data, check Create geodata service for server database when registering your enterprise geodatabases in ArcMap. Selecting this option automatically creates a geodata service that you can use to manually send a replica of the data in the publisher's geodatabase to the ArcGIS Server site's geodatabase.
You can also use the geodata service to synchronize the enterprise geodatabases, thereby ensuring that any subsequent changes made to the publisher's database are reflected in the ArcGIS Server site's geodatabase. This is particularly advantageous in cloud deployments as it does not require someone to log in to the cloud machine and arrange for the data transfer.
This scenario is also well suited for publishing feature services to ArcGIS Server sites on-premises or in the cloud. For example, if you publish a feature service using this scenario, edits made on-premises could be pushed to the ArcGIS Server site's geodatabase, thereby becoming available to end users of your feature service. Conversely, if web editors change any features in the ArcGIS Server site's geodatabase, the edits can be synchronized with the publisher's geodatabase.
When not to use this scenario
- If your data resides in a file geodatabase or file directory. Instead, use scenario D.
- If your data resides in a database (one that does not contain a geodatabase). Instead use scenario A.
- If you do not want to maintain a separate copy of your geodatabase on the server.
- If you are publishing to one of your portal's federated servers from ArcGIS Pro.
- The published data is static. In that case, you don't need to synchronize changes from the publishers geodatabase to the ArcGIS Server site's geodatabase. In that case, you can use a managed database scenario without replication.
D) The publisher's machine and the ArcGIS Server site reference different folders
Because of firewalls, differences between computing platforms, or the desire to keep a separate copy of the data for web use, the publisher and the server may each reference copies of the same data in their own data folder. To register your data using this scenario, you'll need to enter the path to both the publisher's folder and the server's folder.
When to use this scenario
This scenario is useful for Linux deployments, cloud deployments, or any deployment where you want publishers and web users to work with separate copies of the data.
For example, if you want to publish a map service from ArcMap to a Linux-based ArcGIS Serversite, you could create an identical copy of your map document's data and place the data on the Linux-based server. After you register both directories with the server and publish, the map document is automatically modified to reference the folder on the Linux-based server.
This scenario is beneficial if you are publishing to a cloud-based server such as ArcGIS Enterprise on Amazon Web Services. For example, you can copy your on-premises data and place it in any directory you want to in the cloud. When you publish, the data paths are automatically modified to reference the directory on the cloud server. The disadvantage of this approach is that it requires someone to log in to the cloud machine and arrange for the data transfer to the cloud (which could be performed through FTP, remote desktop copy and paste, or other supported data transfer methods).
When not to use this scenario
- If your data resides in an enterprise geodatabase, use scenario C instead.
- If your data resides in a database, use scenario A instead.
- If you do not want to maintain a separate copy of your data on the server.
- If you are publishing to one of your portal's federated servers from ArcGIS Pro.
E) The publisher's machine and ArcGIS Server site reference different geodatabases
This scenario is similar to scenario C but, in this scenario, data is not synchronized between the two geodatabases. This is useful as a method to move feature data from your on-premises enterprise geodatabase to an enterprise geodatabase in the cloud.
When to use this scenario
Use this scenario as a way to move feature data to the cloud. This scenario requires the following:
- Both the on-premises data source and the data store in the cloud must be enterprise geodatabases.
- The enterprise geodatabase in the cloud must be registered as the managed database for a stand-alone or federated ArcGIS Server site.
- The publisher must use ArcMap to publish feature services to the stand-alone or federated ArcGIS Server site in the cloud.
When not to use this scenario
- If your data resides in a file geodatabase or file directory.
- If your data resides in a database (one that does not contain a geodatabase).
- If you want to synchronize data changes between the publisher's and the ArcGIS Server site's geodatabase, use scenario C.
F) The publisher's machine references local map or image data and the ArcGIS Server site references a cloud storage location
If your ArcGIS GIS Server site or ArcGIS Image Server site is running in the cloud and you want to store map or image service caches in the cloud too, provide connection and authentication information for your cloud provider before publishing. When you publish cached map or image services, the caches will reside in your registered cloud store.
When to use this scenario
Use this scenario if your ArcGIS Server site is running on AWS, Microsoft Azure, or Alibaba and you want your map or image services to reference caches stored in an Amazon S3 bucket, Azure Blob storage container, or Alibaba bucket respectively.
When not to use this scenario
- Your ArcGIS Server site is not running in the cloud.
How to register your data with ArcGIS Server
You can register your data folders, databases, and cloud locations with ArcGIS Server using ArcGIS Server Manager, ArcMap, or ArcGIS Pro. For full instructions, see the following:
Considerations when unregistering data stores
You should not unregister a data store if existing services contain data from the data store.
If you do unregister a data store from your ArcGIS Server site, and that data store is used to populate existing services, you may still be able to view the services depending on the type of data store that was used. Keep the following limitations in mind when you unregister a data store:
- For registered and managed databases, you can still view the data in the services they populate. However, if the password stored with the data store changes, you cannot update your services to use the new password. At that point, the services will no longer function, and you will have to register the database that contains the service data and republish the services.
- For registered and managed databases, any new ArcGIS Server machines you add to your cluster will not recognize services if their source data store is no longer registered with the ArcGIS Server site. You will have to register the database that contains the service data and republish the services to allow the new machines to recognize the services.
- You should not unregister ArcGIS Data Store relational, tile cache, and spatiotemporal big data stores from the hosting server site, even though it is possible to do so in ArcGIS Server Manager. If you unregister these data stores from Manager, the services they populate will no longer function.
If you or a publisher in your organization accidentally unregisters an ArcGIS Data Store item from within ArcGIS Server Manager (or unregisters a relational data store from within ArcMap), you must reconfigure the ArcGIS Data Store with the same ArcGIS Server site to get your services to function again.