ArcGIS Server Data Stores and Fully Qualified Domain Name

1052
2
Jump to solution
10-28-2021 07:50 AM
LanceCole
MVP Regular Contributor

We are using a couple of Stand-alone ArcGIS Servers to host numerous Map/Feature services.  With more users working from home we recently ran into an unusual situation when authoring new data to the ArcGIS Servers while connected via a virtual private network (VPN).  Our VPN users are required to use the Fully Qualified Domain Name (FQDN) of the GIS SQL and ArcGIS servers when connecting.  This has not been an issue connecting to the Enterprise Geodatabase or ArcGIS Servers until today.  Everything is working in ArcGIS Pro they are able to add/edit features from the EGDB, create a new map, etc.  Today we had a user, for the first time, attempt to publish a new feature service while connected via a VPN.  However, when they attempted to publish the new feature they received a audit message that all the features are not registered with the server and data and data will be copied to the server, which we do not allow.

After a little research it was found the enterprise database was registered with the ArcGIS Servers using only the server name and not the FQDN, therefore, VPN users attempting to publish data using the FQDN are receiving the error message and unable to publish.  We added a second registered data store using a SDE connection string with the FQDN and the user is now able to publish.  These point to the same enterprise geo-database.  Edited screen shots below.

Server Name OnlyServer Name Only

Server with FQDNServer with FQDN

Added Both to Data Store RegistrationAdded Both to Data Store Registration

This leads to several questions:

1) Is this expected behavior or a bug?

2) With the FQDN connection added to the Data Store Registration, will it work for both server name only and FQDN users?  I currently cannot remove the server name only registration for further testing as all currently published features are using this path.  

EDIT:  I was able to test this on a development system and the server name used in the connection file must match.  If the FQDN of the server was used for the database connection is ArcGIS Pro the same needs to be used in Registering the Data Store.  Likewise,  if only the server name is used in ArcGIS Pro connection only the server name should be utilized for the Registering the Data Store.  They cannot be mixed.  I did put a ticket in with ESRI for clarification on this issue and if adding two reference to the same geodatabase would result in any other problems.

3) Should all users be using FQDN connections to help alleviate this issue?

We are running ArcGIS Server 10.9.0 build 26417 and ArcGIS Pro 2.8.3

0 Kudos
1 Solution

Accepted Solutions
ChristopherPawlyszyn
Esri Contributor

This is expected behavior because ArcGIS Server compares the entire connection string (of which the database hostname is part) when determining whether the data source is already registered with the site. In general, FQDNs provide the most reliable routing from both on-prem and VPN-based users. Some administrators decide to take the concept a step further and use CNAME aliases for their DBMS instances to allow for easier migration in the future, then use those connection strings when accessing from client applications and registering with ArcGIS Server.


-- Chris Pawlyszyn

View solution in original post

2 Replies
ChristopherPawlyszyn
Esri Contributor

This is expected behavior because ArcGIS Server compares the entire connection string (of which the database hostname is part) when determining whether the data source is already registered with the site. In general, FQDNs provide the most reliable routing from both on-prem and VPN-based users. Some administrators decide to take the concept a step further and use CNAME aliases for their DBMS instances to allow for easier migration in the future, then use those connection strings when accessing from client applications and registering with ArcGIS Server.


-- Chris Pawlyszyn
LanceCole
MVP Regular Contributor

Thanks for the reply.  ESRI support indicated the same although recommended not using the FQDN for security reasons.  To work around publishing services via VPN connections we are creating a VM the user can access remotely using a RDC connection.