Error 001359: Failed to connect to the server

5547
8
Jump to solution
04-13-2017 07:47 AM
ApurvDanke
Occasional Contributor

Hi,

I am using ArcGIS Desktop and ArcGIS Server 10.4.1. I have spent many hours trying to find a solution for this. The background to this issue is that I want to publish an MXD which refers to raster data in mosaic datasets. This data is going to be stored in a network drive on another server to which we have read-write access but no access to that server itself (such as RDP access or Administrator access). Previously we were using a local account "arcgis" to run the ArcGIS Server service. This account was created during installation. So when we had this local account, we were able to work with mosaic datasets because the raster data was stored in another server where we had remote and administrator access. So we had created a local "arcgis" user with the same password on that server, so that the raster data is accessible to ArcGIS Server on the other server through UNC path.

The problem is that now we have got a much bigger network share to store the raster data, but as per the policies we cannot have a local "arcgis" user created on that server. So to work around this problem I found that we can use domain account to run ArcGIS Server instead of local account, and ensure that the domain account has access to the network share which has all the raster data. So using the "Configure ArcGIS Server Account" utility I have changed that account to a domain account, and it has permissions to read the data from the new network share. I have also registered the geodatabase connection and the network share folder in ArcGIS Server. So when I try to "Analyze" the MXD it does not show any errors or warnings. But I'm getting the error message below while publishing.

I also have web adaptor installed on the same machine as ArcGIS Server so that services are accessible through IIS. I have tried a lot of things such as ->

1. Restarting the ArcGIS Server service after configuring with the new domain account.

2. Restarting the server.

3. Removing the local "arcgis" user from the server and again configuring the domain account using the utility and restarting the ArcGIS Server service.

4. Created a role "GIS Administrator" in ArcGIS Server Manager and created a user and assigned the user to that role.

5. Created a new connection in ArcCatalog with this new user and tried to publish the service.

6. Changed the service security for PublishingTools service to "Public, available to everyone".

7. Created a new connection in ArcCatalog using web adaptor URL in this format : http://<hostname>/arcgis

8. Saved a service definition file and then tried to publish the map service using ArcGIS Server Manager. I get the following screen for an eternity.

Nothing has worked for me. Even if I try to publish vector data in the MXD I'm unable to. Can someone please suggest solution for this?

Regards,

Apurv

1 Solution

Accepted Solutions
JonathanQuinn
Esri Notable Contributor

The 8004 you see in Fiddler isn't the ArcSOC.exe process trying to communicate to somewhere over port 8004, it's just showing the process name and the process ID, (8004 being the process ID). I believe that ClientHello is just an SSL handshake, so that's not really relevant.  The thing that isn't clear about your post is you see a 404 in Fiddler but you see "Your requested host <hostname> could not be resolved by DNS." as well.  The 404 is simply telling you a requested resource can't be found, (but note the host was found), while the second would be a 502 error.  In a browser, can you navigate to http://<server>.<domain>.com:6080/arcgis/rest/services?

View solution in original post

8 Replies
RebeccaStrauch__GISP
MVP Emeritus

There may be other issues (with the permissions, as you mention), but make sure you have the publishing patch installed

ArcGIS for Server Publishing Patch for 10.4.x

and for 10.5.x ArcGIS Server 10.5 Service Publishing Patch 

Re: mosaic datasets and publishing......can we assume you have the Image Server extension installed?

Could your password for your domain account expired?  I know when we started using our domain accounts for access to, for example, the user store, once our password changed, everything would break.  This would also happen if we used it to run the ArcGIS Server service.  We we able to finally get a domain "service account"....with a very complicated, random password so IT was ok with it.  This was recommended by tech support and has prevented us from many of the "but it worked last week, and nothing has changed" type of issues.  fwiw.

Also, just in case this is using an EDN/developer authorization, make sure that it hasn't expired.  That can also break things mysteriously. 

ApurvDanke
Occasional Contributor

Hi Rebecca,

Thanks for your reply.

Yes of course we have the Image server extension authorized. We were able to publish MXD's having mosaic datasets before. I will try the patch you mentioned. The domain account which we're using has "password never expires" option enabled. Also I use the same account to initially login to the server where ArcGIS Server is installed. We are not using any EDN license, it is a permanent one.

EDIT: The patch did not help. I noticed that in the Data Store settings in ArcGIS Server Manager, the option to "Allow data to be copied to the site when publishing services." was enabled. This is not required as all the databases and folders are already registered with ArcGIS Server. After I unchecked this option, I now get the following message.

EDIT: Now back to getting the old "001359: Failed to connect to the server error". Haven't done any changes, except that I deleted those registered database connections which failed validation. So now only those connections exist which are properly validated.

Regards,

Apurv

0 Kudos
RebeccaStrauch__GISP
MVP Emeritus

(After the patch install, make sure you rebooted the machines involved....I don't know if it is mandatory, but never hurts and it seems with machines more reliable, it's some thing we overlook these days.   )

again, no absolute answer, but my guess (and probably what you already know) is it is a permission issue.  I would look at some of the threads and help docs on connection to UNC, shares and "letter" data connections.  A couple I would start with

Sharing and connecting to UNC pathnames 

ArcGIS Help (10.2, 10.2.1, and 10.2.2) 

These are AGS or 10.4 links (mare be newer versions, but in an iPad right now), but they may give you some ideas on ways to connect using the data store settings.

We try to make sure all data is accessible on our AGS d drive and have a folder d:\data folder registered.  This does mean that we have some data duplicated on our dev and prod machines.

for mosaics datasets, we have the raw data store on a network server, but the mosaic datasets, including overlays etc., are created and stored in the d:\data\imagery folder.  I create those on dev and copy to same structure on prod.  This has worked in both 10.2.x and 10.5.x (testing).

as mentioned in another thread, I decided to cache the imagery using my image server to increase drawing speak for web and most desktop viewing.  That has worked well, and of course is still much smaller than the actual raw data.  I have a second image server service pointing to the same mosaic database that isn't cached that I figure will be used for more analysis (drawing is of course slower).

btw, both of these services are created by right-clicking on the local D drive mosaic database and desired image dataset, then selecting Publish As Image Service   (Or similar, again, not at computer to get actual verbiage)

one last comment, I have been successful for imagery, but still working on our other mosaic datasets like CIR and DEM.

ApurvDanke
Occasional Contributor

Hi Rebecca,

Thanks for your suggestion. I restarted the server but that did not resolve the issue. Currently I'm not even trying to publish any map service with mosaic datasets, just trying to publish an MXD with a single layer having vector data, which resides in Oracle geodatabase. I tried checking in Fiddler and I got the logs below.

Looks like arcsoc process is trying to access something over port 8004. I tried to telnet port 8004 and it failed. However, with local ArcGIS Server account I didn't have to worry about such ports. The web view in Fiddler mentions -

"Your requested host <hostname> could not be resolved by DNS."

For this I added the IP address and hostname in the hosts file, but no luck.

Important excerpts from Fiddler log is given below.

10:49:33:3159 Fiddler Running...
10:49:33:3279 Windows 8+ AppContainer isolation feature detected.
10:50:12:8167 HTTPSLint> Warning: ClientHello record was 390 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance

11:04:54:9856 fiddler.network.readresponse.failure> Session #140 raised exception System.Net.Sockets.SocketException An established connection was aborted by the software in your host machine

Regards,

Apurv

RebeccaStrauch__GISP
MVP Emeritus

Sorry, I think I'm out of suggestions.  I know that internally, ArcGIS Server usually is set to 6080, but beyond that, the "ClientHello" and some of the other error messages are not anything I am familiar with.  You may have better luck with a tech support call so they can look at your situation's specifics. 

0 Kudos
JonathanQuinn
Esri Notable Contributor

The 8004 you see in Fiddler isn't the ArcSOC.exe process trying to communicate to somewhere over port 8004, it's just showing the process name and the process ID, (8004 being the process ID). I believe that ClientHello is just an SSL handshake, so that's not really relevant.  The thing that isn't clear about your post is you see a 404 in Fiddler but you see "Your requested host <hostname> could not be resolved by DNS." as well.  The 404 is simply telling you a requested resource can't be found, (but note the host was found), while the second would be a 502 error.  In a browser, can you navigate to http://<server>.<domain>.com:6080/arcgis/rest/services?

ApurvDanke
Occasional Contributor

Thats it! Thanks a lot Jonathan, you nailed it! I was not able to browse the REST URL in the same server but was able to access from different machine. As it was accessible from different machine I didn't think of checking from same server at all. The issue was that in my IE LAN settings I had the checkbox checked - "Use Proxy Server for your LAN". After unchecking it I was able to access the URL and was able to publish the map service .

Now I will try to undo all the unnecessary changes and try to publish map service having raster data.

EDIT: Undone the role and account creation in ArcGIS Server Manager and undid the public security option which I did for PublishingTools service. Still able to publish vector and raster data. The only issue is I cannot publish raster data which is sourced from a mapped network drive such as Z drive which internally points to a network share where all the raster data resides. This was confirmed by ESRI as well that only UNC path is supported for publishing data.

Regards,

Apurv

CalebAnderson
New Contributor II

Added a proxy while signed in to the web server as the ArcGIS Server user so that we could access living atlas content on the portal. This worked but also broke ArcGIS Server and we could no longer start or publish services or validate data stores via server manager. Checking the option in the proxy settings to ignore local traffic did not resolve the issue but adding the internal network url to the list of urls that the proxy ignores did fix things. Didn't know what was going on at first, this post saved the day, thanks. 

0 Kudos