POST
|
Hi Derek, Is september still realistic? Is there anything we could do to get Insights 2.3 to work against 10.6.1 ? Like a manual edit of something or a dependency update... ? Regards
... View more
08-13-2018
10:28 AM
|
1
|
3
|
1156
|
POST
|
Try using the command line tool http://enterprise.arcgis.com/en/data-store/latest/install/windows/data-store-utility-reference.htm and in particular configuredatastore
... View more
07-10-2018
04:31 AM
|
0
|
1
|
1569
|
POST
|
Thanks, this has been raised with the support. They are aware of this thread too.
... View more
07-10-2018
12:34 AM
|
0
|
0
|
2346
|
POST
|
Hi Jonathan, I took the DR Backup of my Test environment, and i wanted to play it back onto the same Test environment. Thats when i hit the problem. Because this was taken and played back on the same environment and the same machines i cant tell where the mismatch would come. I was not testing a playback to my DR environmnet, it all took place on the same environment with exactly same machines. There are in total 4 DS machines: 2xRelational(Primary+Standby) +2xTileCache(Primary+Standby). Each machine has only _one_ type of datastore. So on a machine with Relational store there is no TileCache and the other way around too. This ouput stated above: | |-- TileCache Data Store: https://ec2amaz-<tilecache-id>.mydomain.local:2443/arcgis | | | |-- Relational Data Store: https://ec2amaz-<relational-id>.mydomain.local:2443/arcgis Illustrates distribution of the DS machines. These are the machine names of the primary nodes. These are all separate machines. Regards
... View more
07-09-2018
02:06 AM
|
0
|
6
|
2346
|
POST
|
Hello, I have a fairly complex 10.6 setup on multiple windows 2016 with all elements being HA/duplicated: -Portal -Hosting AGS Site --Separate Relational DS cluster --Separate TileCache DS cluster -Federated AGS Site Everything works fine on it, stuff gets published, users can deal with it, hosted layers get created, map services work, all good. Yesterday i have successfully created a full webgisdr backup (including tilecaches). No errors upon creation of the backup all looks good. Today i was going to test if webgisdr tool works/verify my DR procedure. Sadly upon calling the webgisdr tool with --import option the recovery fails with message: Failed to validate the ArcGIS Data Store for the web GIS. The ArcGIS Data Store in the web GIS backup does not match the ArcGIS Data Store in the current web GIS. Nothing has changed in terms of machines in any of the sites/nodes. All machine names are the same, Load Balancer URLs are the same. Yet it feels like the message indicates a mismatch? Here is the console output when i run the tool: ================================================== Starting the WebGIS DR utility. ================================================== The configuration and base backup time in the current Web GIS ------------------------------------------------------------- Portal: https://portal.<site>/portal | |-- Federated Server: https://mapping.<site>/server | |-- Hosting Server: https://hosted.<site>/server | | | |-- Relational Data Store: https://ec2amaz-<relational-id>.mydomain.local:2443/arcgis | | | |-- TileCache Data Store: https://ec2amaz-<tilecache-id>.mydomain.local:2443/arcgis Unzipping the backup file: \\<backups>\July-4-2018-11-29-39-AM-EDT-FULL.webgissite The backup file has been unzipped in 00hr:12min:15sec. The backup file was created at July 4, 2018 11:29:39 AM EDT. The configuration and base backup time in the incoming Web GIS -------------------------------------------------------------- Portal: https://portal.<site>/portal at 7/4/18 11:24 AM | |-- Federated Server: https://mapping.<site>/server at 7/4/18 11:24 AM | |-- Hosting Server: https://hosted.<site>/server at 7/4/18 11:24 AM | | | |-- TileCache Data Store: https://ec2amaz-<tilecache-id>.mydomain.local:2443/arcgis | | | |-- Relational Data Store: https://ec2amaz-<relational-id>.mydomain.local:2443/arcgis Starting the restore process with the WebGIS DR utility. Failed to validate the ArcGIS Data Store for the web GIS. The ArcGIS Data Store in the web GIS backup does not match the ArcGIS Data Store in the current web GIS. Exiting the WebGIS DR utility. Here is the 'crucial' section of the additional log file in DEBUG mode: 2018-07-05 08:36:55 DEBUG [main] org.apache.http.impl.execchain.MainClientExec - Connection can be kept alive indefinitely 2018-07-05 08:36:55 DEBUG [main] org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection [id: 144][route: {s}->https://hosted.<site>:443] can be kept alive indefinitely 2018-07-05 08:36:55 DEBUG [main] org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection released: [id: 144][route: {s}->https://hosted.<site>:443][total kept alive: 1; route allocated: 1 of 2; total allocated: 1 of 20] 2018-07-05 08:36:55 DEBUG [main] org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection manager is shutting down 2018-07-05 08:36:55 DEBUG [main] org.apache.http.impl.conn.DefaultManagedHttpClientConnection - http-outgoing-144: Close connection 2018-07-05 08:36:55 DEBUG [main] org.apache.http.impl.conn.DefaultManagedHttpClientConnection - http-outgoing-144: Close connection 2018-07-05 08:36:55 DEBUG [main] org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection manager shut down 2018-07-05 08:36:55 DEBUG [main] com.esri.arcgis.webgis.util.WebGISUtil - {"incrementalBackupTimeStamp":1530770427265,"backupMode":"FULL","incrementalRestoreTimeStamp":0,"fullBackupTimeStamp":1530789177251,"fullRestoreTimeStamp":0} 2018-07-05 08:36:55 INFO [main] com.esri.arcgis.webgis.storageservice.file.FileStorageService - Unzipping the backup file: \\<backups>\July-4-2018-11-29-39-AM-EDT-FULL.webgissite 2018-07-05 08:49:10 INFO [main] com.esri.arcgis.webgis.util.WebGISUtil - The backup file has been unzipped in 00hr:12min:15sec. 2018-07-05 08:49:10 INFO [main] com.esri.arcgis.webgis.service.impl.WebGISDRFrontController - The backup file was created at July 4, 2018 11:29:39 AM EDT. 2018-07-05 08:49:10 DEBUG [main] com.esri.arcgis.webgis.service.impl.WebGISDRFrontController - Failed to validate the current Web GIS. com.esri.arcgis.webgis.WebGISException: Failed to validate the ArcGIS Data Store for the web GIS. The ArcGIS Data Store in the web GIS backup does not match the ArcGIS Data Store in the current web GIS. at com.esri.arcgis.webgis.service.impl.WebGISDRFrontController.a(WebGISDRFrontController.java:818) at com.esri.arcgis.webgis.service.impl.WebGISDRFrontController.a(WebGISDRFrontController.java:221) at com.esri.arcgis.webgis.service.impl.WebGISDRFrontController.service(WebGISDRFrontController.java:103) at com.esri.arcgis.webgis.service.impl.WebGISDRManager.c(WebGISDRManager.java:142) at com.esri.arcgis.webgis.service.impl.WebGISDRManager.importWebGIS(WebGISDRManager.java:125) at com.esri.arcgis.webgis.client.WebGISDR.main(WebGISDR.java:103) 2018-07-05 08:49:10 DEBUG [main] com.esri.arcgis.webgis.service.impl.WebGISDRFrontController - Deleting the temp directory \\<share>\tempbackups\WebGISSite1530794203646. 2018-07-05 08:49:12 DEBUG [main] com.esri.arcgis.webgis.client.WebGISDR - Exiting the WebGIS DR utility. com.esri.arcgis.webgis.WebGISException: Failed to validate the ArcGIS Data Store for the web GIS. The ArcGIS Data Store in the web GIS backup does not match the ArcGIS Data Store in the current web GIS. at com.esri.arcgis.webgis.service.impl.WebGISDRFrontController.a(WebGISDRFrontController.java:224) at com.esri.arcgis.webgis.service.impl.WebGISDRFrontController.service(WebGISDRFrontController.java:103) at com.esri.arcgis.webgis.service.impl.WebGISDRManager.c(WebGISDRManager.java:142) at com.esri.arcgis.webgis.service.impl.WebGISDRManager.importWebGIS(WebGISDRManager.java:125) at com.esri.arcgis.webgis.client.WebGISDR.main(WebGISDR.java:103) Caused by: com.esri.arcgis.webgis.WebGISException: Failed to validate the ArcGIS Data Store for the web GIS. The ArcGIS Data Store in the web GIS backup does not match the ArcGIS Data Store in the current web GIS. at com.esri.arcgis.webgis.service.impl.WebGISDRFrontController.a(WebGISDRFrontController.java:818) at com.esri.arcgis.webgis.service.impl.WebGISDRFrontController.a(WebGISDRFrontController.java:221) ... 4 common frames omitted 2018-07-05 08:49:12 ERROR [main] com.esri.arcgis.webgis.client.WebGISDR - Failed to validate the ArcGIS Data Store for the web GIS. The ArcGIS Data Store in the web GIS backup does not match the ArcGIS Data Store in the current web GIS. Regards, Szymon
... View more
07-05-2018
09:51 AM
|
1
|
24
|
6242
|
POST
|
Hello Esri Team, ArcGIS Online does not support Dynamic Map Service. This has been suggested as one of Ideas for the product. My question is why has Esri Inc decided NOT to enable such capability for ArcGIS Online? I do understand it supports hosted feature services and tiled services and I am not looking for alternatives. I am trying to understand what was the thinking behind deciding on not giving the option to AGOL's users. Did it prove to be too CPU intense? Not scaling too well? Regards, Szymon
... View more
06-11-2018
12:17 AM
|
1
|
2
|
497
|
POST
|
After some investigation I am thinking now that it is crucial that the shared keys are different. IF the shared keys are the same i think that server performs different validation:it acts as if token was generated by server itself, hence expects different token structure (can be seen after token decryption) IF keys are different then debug logs of the Federated Server DO report an error, but then pass on to the section that causes this error: java.io.IOException: com.esri.arcgis.discovery.admin.security.InvalidTokenException: com.esri.arcgis.discovery.admin.security.AGSSecurityException: com.esri.arcgis.discovery.admin.security.AGSSecurityException: Server machine 'https://portal.<HOST>.com/portal/sharing/rest/community/self' returned an error. 'User does not exist or is inaccessible.' This could mean that the token is passed back by server internally to portal (where original encryption has happened, with the different key). Only then Portal decides if the token is valid or not. For reason i cannot determine my tokens generated with AppID get rejected with 'User does not exist or is inaccessible.' After token (not acces_token, but the one that my proxy uses to talk to server!) decryption I can see that it contains: {"s":"9f22","t":"a","c":1528196962495,"d":"<Federated-Site-Id>","e":true,"g":"<App-ID>","h":"0123456789ABCDEF","l":0,"m":0} Federated-Site-Id IS the ArcGIS Server site that is federated with my portal and that i try to reach, so it matches overall logic. This has no user info though, i suppose <AppID> plays its role? After seeing the above error in Server Logs, I cannot see any meaningful error in Portal logs that would indicate a crash or so. Am I missing some settings on the Application? I have shared it with everyone but did not help. Regards, Szymon
... View more
06-05-2018
02:32 AM
|
0
|
0
|
1260
|
POST
|
Thanks Jonathan. What I have observed is that if our Shared Key is different between Portal, Hosting and the Federated sites then in Server Logs i see: DEBUG Exception caught while validating token. Could not decrypt token. Token may not be valid. After this there occurs multiple errors of this form DEBUG java.io.IOException: com.esri.arcgis.discovery.admin.security.InvalidTokenException: com.esri.arcgis.discovery.admin.security.AGSSecurityException: com.esri.arcgis.discovery.admin.security.AGSSecurityException: Server machine 'https://portal.<HOST>.com/portal/sharing/rest/community/self' returned an error. 'User does not exist or is inaccessible.' If I set the keys to be the same the above go away. I observe this when I acquire a (portal exchanged) token via the DotNet proxy & AppID and AppSecret and make calls with the token to access resources on ArcGIS Server Federated site, where our maps are. I have set up an Application as a Portal Item under the (SAML) account that owns some map services in the Mapping Federated site. When i try to reach to that mapping service via the proxy (and the AppID) I do get the token itself generated OK, but it is detected as invalid: DEBUG Exception caught while validating token. Invalid token. What I think that also might be important is that our system uses SAML. Even if i use an Application that was created as Portal primary Site Admin this still does not work. If the shared keys dont need to be the same how can the Federated Site decrypt the token?
... View more
06-05-2018
12:29 AM
|
0
|
1
|
1260
|
POST
|
I think I have found the answer to my own question: this is not possible in SAML scenario Make a user connection to ArcGIS Server in ArcGIS Desktop—ArcGIS Server Administration (Linux) | ArcGIS Enterprise If the ArcGIS Server site you're connecting to is federated with a portal, provide portal credentials. If your portal uses SAML authentication, you cannot connect directly to the federated server from ArcMap.
... View more
06-04-2018
10:22 AM
|
0
|
0
|
2297
|
POST
|
Chris, What role level were you at when connecting? I can connect fine if I try as publisher or administrator & my portal role allowes me to perform given level's operations. But I was not able to do so when I degraded myself to User role in Portal and then tried to set up a connection in ArcMap with 'Use GIS services'. What happens then to me the connection is set up, but it has no content, even the items/map services I own. Interestingly during the connection process the dialog to sign in (as on your screenshots) does not show - it creates the connection immediately. The dialog does show if i connect as publisher or administrator though. Regards, Szymon
... View more
06-04-2018
08:20 AM
|
0
|
1
|
2297
|
POST
|
I have been hitting the same problem (invalid token message) when working with DotNet Proxy & OAuth. In my scenario i created an App in Portal 10.6 and I wanted to user app ID + secret to get tokens which does not work so far. What I also observed that in my (federated) server 10.6 logs there is a message: DEBUG Exception caught while validating token. Invalid token. Nothing furder, no stack trace, no details. No messages in logs around the error giving more idea about the incident. I went further and decided to try and decode the tokens. For this i followed: Decrypting ArcGIS Server Tokens | The above with some small tweaks worked really well and I could now see what is in the tokens. So my portal-exchange-to-server token (NOT access token!), after decoding, has the following content: {"s":"aa50","t":"a","c":1528067244042,"d":"<federated-site-id>","e":true,"g":"<app-id>","h":"0123456789ABCDEF","l":0,"m":0} So pretty much looks like a JSON. I cannot see any user login info in there though, perhaps its because this was generated from app id/secret? BUT if i decode a token generated via: https://<federatedserver>/server/tokens/?request=gettoken&username=LOGIN&password=PASS It then decodes to: serveradmin:1528100607636: So different syntax/shape. No more JSON, just values separated with ':' What im wondering is if the exchange token can be used in exact same way as the old-fashion produced tokens, or if the exchange tokens need to be submitted differently/other parameter? The DotNet proxy from Esri uses the exchange-token in the same manner as the 'default' token so i would assume they are compatible? On the Server side (in backend code) do they need different handling mechanism? Regards, Szymon
... View more
06-04-2018
01:48 AM
|
0
|
0
|
614
|
POST
|
Hello I have a setup of 10.6 with Portal + 2 Sites: Federated Site and Hosting Site. Each component has its own, different shared key. Should I make sure all actually have the same shared key?
... View more
06-03-2018
10:47 AM
|
0
|
3
|
1926
|
POST
|
Has anyone been able to programatically generate tokens for SAML users? I am facing similar issues.
... View more
06-01-2018
03:01 AM
|
0
|
0
|
1631
|
POST
|
Hi Rohit, Thanks for this. Got more question on the API. I want to try the non-interactive scripting of connectivity to portal, so im following this sample, but populated with parameters relevant to my environment: gis = GIS("https://python.playground.esri.com/portal", username="arcgis_python", password="amazing_arcgis_123", client_id='f8cRxbP3NO8bf9ag') print("Successfully logged in as: " + gis.properties.user.username) This does not work right away as i suspect there might be issues with my IDP - i still am prompted to log in to my portal/IDP button needs to be clicked and i get the SAML code OK. What makes me wonder is the syntax of URL produced that i am supposed to follow: https://<portalhost>.com/portal/sharing/rest/oauth2/authorize?user_orgkey=&username=MYUSER&password=MYPASSINPLAINTEXT&oauth_state=<SOMELONGCODE> Is there documentation on syntax of this rest/oauth2/authorize endpoint that would list all params it takes? I found this Authentication—ArcGIS REST API: Users, groups, and content | ArcGIS for Developers but does not mention username or password etc Would you know in particular how to allow username/pass enabling for OKTA (or is it comatible)? If not, what options to look for other IDPs so perhaps we could try to figure out OKTA please? Regards, Szymon
... View more
05-30-2018
05:47 AM
|
0
|
0
|
5239
|
POST
|
Hi Jonathan, thanks for your answer. My point is not about if or how to use Load Balancer. Its about what _endpoint_ is better to user for the Administrator URL: <lb-host>:6443/arcgis OR <lb-host>/<webadaptor_with_admin_access> . Is there significant performance gain when using access via 6443 rather than via webadaptor? Considering I have admin access enabled on the webadaptor and i have choice what to specify as Administrator URL which is better (and how much) ? What i am concerned about is the extra work and potential issues for the bit around X-Forwarded* settings.
... View more
05-22-2018
02:50 PM
|
0
|
1
|
623
|
Title | Kudos | Posted |
---|---|---|
1 | 05-18-2018 07:35 AM | |
1 | 03-13-2018 02:19 AM | |
1 | 05-17-2018 11:11 AM | |
1 | 05-17-2018 11:11 AM | |
1 | 06-11-2018 12:17 AM |
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:24 AM
|