POST
|
I have a older 10.3.1 ArcGIS Server installation that I am maintaining. Recently, the primary publisher of the server told me that the server is reverting to HTTP Only for its protocol after the service is restarted in the Windows Services control panel. I've verified that this is, in fact happening. After the service is restarted, a new config.json.rlock file is taken and than, after a few minutes (presumably after the server have completed startup), the rlock file is updates (new timestamp) and the config.json file is changed to set sslSecurity to false. The config.json file have the same last modified timestamp as its corresponding rlock file. Obviously updating from 10.3.1 is the final plan, but I am wondering if anyone else has seen this behavior and is aware of a way to fix it in the short-term. The ArcGIS Server is a base installation and does not have any patches applied, as far as I know.
... View more
12-11-2017
07:30 AM
|
0
|
3
|
899
|
POST
|
Yes, we worked around the issue by moving all of the Service Items into the root of the Named User that owned the service, instead of placing them in Portal folders. We could still publish the services into ArcGIS Server Folders, but the corresponding Portal Item needed to be in the root of the Named User's My Content page.
... View more
10-18-2017
06:55 AM
|
0
|
0
|
898
|
POST
|
I assume you can only reach Manager using the URL used as the Admin URL during federation? Yes, this is correct. Thanks for the explanation; not a serious issue, obviously, so I'll keep an eye on future releases.
... View more
09-26-2017
11:23 AM
|
0
|
0
|
703
|
POST
|
I have a multi-machine ArcGIS Server 10.5 site with two machines that is Federated with a Portal for ArcGIS deployment.. I have no problem logging into the ArcGIS Server Manager on the machine that I selected as the server when Federating the site, but I cannot log into Manager from the other machine. I have isolated the cause to the generateToken portal endpoint and have a short Python script that replicates the issue. If I call the generateToken endpoint and attempt to exchange a Portal token for a Server token using the server name that appears in the Servers tab in Portal, then request succeeds. However, if I set the referer to the other machine that is part of the ArcGIS Server site, it fails with {"error":{"code":400,"message":"Unable to generate token","details":["Unable to generate token for this server"]}} Reading between the lines of the documentation, I can see how this may be the intended and correct behavior, but since the ArcGIS Server rest endpoints can be accessed from any machine in the site and since we can publish services to any of the machines, it seemed odd that Manager would somehow be an exception. Is there any documentation that I may have missed that addresses this point specifically?
... View more
09-26-2017
10:44 AM
|
0
|
2
|
862
|
POST
|
I have a reproducible scenario that is causing duplicate Portal items to be created for services published to a Federated ArcGIS server. All software is running version 10.5 and the ArcGIS Server site is a multi-machine site with two machines. The ArcGIS Server config-store and directories are on a network drive references by a UNC path. The ArcGIS Server processes both run under the same domain account and I have verified that the file system permissions on the network storage are appropriate. Here are the steps taken along with a description of the intermediate errors and effects: Publish a new service with Map and Feature services enabled. The data is backed by an Enterprise Geodatabase properly registered as a Database Data Store in ArcGIS Server. The publishing process has been giving intermittent failures stating that an intermediate folder cannot be deleted from the config-store. After starting the service manually, it appears to the running normally. The Map Service and Feature Service appear as Portal Items under the named user credentials that were used to publish the services, as expected. The Item IDs are Map Service: 0c77d43a865246e0b4d049284a373e87 Feature Service: e20bb117f0a54d64b924b878a0f5c7a2 These items have been placed in a folder named 'Services' Next, I share the two items with my Organization via the Portal Share dialog Now is where we begin to see errors. If I go back to the ArcGIS Server Manager appliction and open up the Sharing dialog in the Manage Services page, the sharing that I set in Portal does not show up. Further, if I capture the REST response from Manager to Portal for the URL https://portal.mydomain.org:7443/arcgis/sharing/rest/content/users/username@DOMAIN/items/0c77d43a865246e0b4d049284a373e87 I see a JSON response of {"error":{"code":400,"messageCode":"CONT_0005","message":"Item does not exist in this folder.","details":[]}} Clearly there is a problem at this point. But, if I continue and try to set the sharing in Manager to share the services with my Organizations, I end up with three new items in Portal and the original service Items remain in Portal as well. The report endpoint in Manager not identified these two new items as the Portal items associated with the service. Also, changing the sharing in Portal is properly reflected in Manager. The biggest issue I have at the moment is that there is a lot of content that needs to be repairs because the original service items no longer map to the portal Items that ArcGIS Server believes represent the services, so users get errors trying to add these old items to their Web Maps. This issue just started happening in the past week, so I am assuming some sort of corruption or misconfiguration was introduced. Restarting the ArcGIS Server services and the Portal service has had no effect. Absent any advice from this forum, my next attempt to resolve the issue is to remove each ArcGIS Server from the Site and then re-add it, hoping that will reinitialize whatever if causing the issue. I have seen other reports of CONT_0005 error, but they all seemed to be related to republishing service via ArcPy without setting the sddraft to Replacement mode. Any and all advice is appreciated. UPDATE It appears that this issue I've run into is documented as a series of BUGs in 10.5 that were fixed in 10.5.1. Other than keeping Portal Service Items out of Portal folders in the short-term, upgrading appears to be the correct fix.
... View more
09-26-2017
08:30 AM
|
2
|
3
|
1431
|
POST
|
I just ran into this strange situation on Portal 10.5. I was unable to find a BUG in the support site that described the issue and the list of resolved issues in 10.5.1 did not appear to contain it, either. I wanted to create an Application Item in Portal that points to an application in my ArcGIS Online Organizational account using a URL like http://myorg.maps.arcgis.com/apps/webappviewer/index.html?id=1fe52f64640247c99c772de938809f7a Once I click the Add Item, the item is created, but the URL is not pointing at the Portal URL with the ArcGIS Online Item ID appended If I look at the item's JSON data in AGO Assistant, the correct URL is present. So it appears to be a bug in the Home application where the URL is being interpreted and transformed into an local Portal URL. I was able to work around the issue by using a URL shortening service on my original URL and saving the shortened URL in the Portal Application Item, but I would like to either find a way to prevent the Home application from transforming my URL, or know if this is a BUG that is fixed in Portal 10.5.1.
... View more
09-06-2017
07:37 AM
|
0
|
2
|
802
|
POST
|
A workaround! The actual issue appears to be a lack of support for SNI in the ArcGIS Server proxy. Our web server was set up with multiple sites, each bound to a FQDN. On a hunch, I added a default HTTPS binding to the site that contains the Portal Web Adaptor and things began working. At one point I did have a default binding on the site in order to configure the Web Adaptor (so I could use https://localhost/ to get at the configuration page), which is why it worked for a while and then "stopped". At the time, I didn't associate removing the default binding with the loading failures. There is an Esri BUG-000093827 that discusses an issue with the Portal proxy and SNI support that was fixed in 10.4.1, but nothing I could find that discussed the state of SNI support in the ArcGIS Server proxy. I'm hoping to get a resolution from Esri support that either Confirms this as a bug in the AGS proxy, or Provides some details on how to enable SNI support For now, moving on from this issue.... TLS Extension List sent from ArcGIS Server extensions [extension_type: elliptic_curves,extension_type: ec_point_formats,extension_type: signature_algorithms] TLS Extension List sent from Chrome Browser extensions [extension_type: 31354,extension_type: renegotiation_info,extension_type: server_name,extension_type: extended_master_secret,extension_type: SessionTicket_TLS,extension_type: signature_algorithms,extension_type: status_request,extension_type: 18,extension_type: application_layer_protocol_negotiation,extension_type: 30032,extension_type: ec_point_formats,extension_type: elliptic_curves,extension_type: 10794]
... View more
06-13-2017
10:02 AM
|
1
|
5
|
6470
|
POST
|
The original certificates that were installed on IIS were ECDHE_ECDSE which were not on the list. After discovering that discrepancy, IT installed new certificates that are ECDHE_RSA with P384. My understanding is that the block cipher and message authentication are negotiated and, according to the Chrome Security toolbar, it can connect with AES_256_CBC_SHA1 (AES_256_CBC with HMAC_SHA1, specifically). That would appear to match the TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA entry in the list of supported ArcGIS Server ciphers, so our expectation was that ArcGIS Server would (at least) be able to use that cipher as well. Unfortunately, the new certificate did not resolved the issue. So we are looking more closely at the details of the certificates and network traces to try and figure out where the TLS handshake breaks down. I am certainly not a certificate/TLS/Networking expert by any means, so I may be misunderstanding the specifics of how this is supposed to work and any quirks of the Java networking stack when talking to Windows/IIS web servers.
... View more
06-12-2017
10:42 AM
|
0
|
0
|
3885
|
POST
|
I have had an open support case concurrent with this thread and have cross-referenced customer support to this topic as well. Hopefully the specific failure mechanism will be found soon...
... View more
06-12-2017
08:36 AM
|
0
|
2
|
3885
|
POST
|
Getting closer to a resolution. It appears that this is likely an IIS/SSL issue related to certificate negotiation. The IIS Web Server we are using has an ECC certificate installed (versus the more common RSA signed certificate) and that appears to be problematic. We had an issue when installing ECC certificates on ArcGIS Server, as well. Chrome and other broswers reported that they could not negotiate a common cipher and the connection failed. We ended up using RSA certificates instead. The same type of issue appears to be in play here. Some relevant stackexchange posts on this issue https://security.stackexchange.com/questions/96804/server-sends-rst-after-receiving-client-hello-when-binding-certain-certificate https://serverfault.com/questions/774826/tls-1-2-client-hello-triggers-tcp-reset-from-2012-r2
... View more
06-09-2017
07:34 AM
|
0
|
10
|
3882
|
POST
|
More information. I’ve attached a network trace of the traffic captured between our ArcGIS Server and the Web Server that hosts the Web Adaptor for Portal. It appears that the Web Server (192.168.103.50) is sending a TCP Reset packet in response to the CLIENT HELLO send by the ArcGIS Server. This process repeats a few times and then, apparently, the ArcGIS Server side gives up. We actually have three ArcGIS Servers set up right now (1 dev, 2 production) and the same error is happening in all cases, so it appears to be something systemic and specific to how the proxy page and/or tomcat/geronimo/Java is handling it's networking. Might be time to write a test client in Java and see if that behaves the same as ArcGIS Sever....
... View more
06-09-2017
06:23 AM
|
0
|
11
|
3882
|
POST
|
New information: Logging in as the ArcGIS Server service account made no difference. I created two python scripts on the ArcGIS Server, one that POSTs to the /proxy page and one that POST directly to the generateToken URL that is trying to be proxied. Each has appropriate headers and body content. The first script returns the same ArcGIS Server error page as shown in the network panel screenshot and the second succeed and returns a token from Portal. For a few hours today things started working and I was able to log into ArcGIS Server Manager. The IT staff I'm in contact with stated that they had not made any changes. A few hours later and the error returned. Very strange. Turning on DEBUG level logging in the ArcGIS Server doesn't show anything specific, but there are these entries that appear to be somewhat related to the issue at hand, Token is not a valid Admin token. Trying portal token next. Token = 8_AptoTJ86nrEVK5hBnnfD-9C7LzVwrcQNoFgnLNkMh1PkFTV8ssh4EyaDOknlAYQmygXFCykSiYl2_xnp178FKqk2tNBc0tvQ8JpV05r5dFXvElHufzydxeMsIfImSk3QNklmn1obIstorWPo2s_U8GFhk4gq3LLUpu8KcClOo8f7vAhgta4C3d2Fl09OA0, referrer = https://ags-dev.mydomain.org:6443/arcgis/manager/Could not decrypt token. Token may not be valid. ARCGIS_PORTAL_TOKEN Authentication, Token is not available in the request, request is treated as anonymous
... View more
06-06-2017
09:06 PM
|
0
|
0
|
3882
|
POST
|
I have seen the behavior you describe caused by self-signed or incorrect SSL certificate, however in this case we do have proper certificates installed on both the ArcGIS Server, Portal and Web Adaptors in IIS. I have added a screenshot of the browser when connected to the Manager page with the SSL credentials shown. Please let me know if you see anything amiss in this settings. The issue seems to be pretty clearly caused by a network connection being terminated when the ArcGIS Server proxy page attempts to connect to the Portal generateToken page via the Portal Web Adaptor. This behavior is confirmed by the ArcGIS Server error page that was captured from the Web Server network inspector, and by monitoring the traffic between the ArcGIS Server and Web Adaptors via Fiddler. I am waiting on IT to grant remote login privileges to the ArcGIS Server domain account in order to test Johnathan Quinn's suggestion of verifying that the ArcGIS Server process identity is not being blocked due to external policy considerations.
... View more
06-05-2017
09:17 AM
|
0
|
0
|
2585
|
POST
|
I'll try logging in as the ArcGIS Service account and see if that makes a difference. Regarding logging into Portal first, that is actually how I discovered the issue. I had just Federated the server and clicked on the server link in the Portal Server setting page, which pointed to the server manager page. I may not have verified that I was logged into Portal on subsequent tests, so I'll double-check that being logged into Portal does not change the behavior. Thanks for the suggestions.
... View more
06-04-2017
06:36 AM
|
0
|
0
|
3882
|
Title | Kudos | Posted |
---|---|---|
1 | 06-13-2017 10:02 AM | |
1 | 01-04-2017 07:28 AM | |
1 | 11-29-2016 02:29 PM | |
2 | 04-13-2018 12:23 PM | |
5 | 10-17-2016 12:45 PM |
Online Status |
Offline
|
Date Last Visited |
04-04-2022
10:14 PM
|