|
POST
|
Hm, 7443 is definitely a valid port to use. Changing the log level shouldn't fix that problem. Are your machines on different domains? Can you reach the Data Store Configuration Wizard from your Portal machine? Ex. https://ds.domain.com:2443/arcgis/datastore Could be a firewall issue.
... View more
10-29-2018
09:59 AM
|
1
|
2
|
5463
|
|
POST
|
Are there any queued/unsubmitted jobs within the .submitted folder for any GP services you have published?
... View more
10-29-2018
09:40 AM
|
0
|
1
|
1411
|
|
POST
|
If the PORTAL_ADMIN_URL you're using is set to the 7443 portal, put in your browser, and append /sharing/rest, does the URL redirect anywhere? Ex. https://portal.domain.com:7443/arcgis/sharing/rest If it redirects, use the URL it redirects to. If you're not using the 7443 URL, is the URL configured with Windows Authentication? You can enable more verbose logging within the logback.xml file.
... View more
10-29-2018
09:38 AM
|
4
|
7
|
5463
|
|
POST
|
Well, in one approach, it's making an extra hop, (RP -> WA -> Portal), rather than going straight to the Portal, (RP -> Portal or WA -> Portal). Some organizations only want standard ports through the firewall, though, (80/443). If the WA is in the DMZ, then ports 7443/7080 need to be open through the firewall. In that case, they'd configure the WA within the internal network and have the RP send traffic in through 80/443.
... View more
10-29-2018
09:35 AM
|
2
|
0
|
1243
|
|
POST
|
And I imagine you can reach all services from the desktop you're running the tool from? If so, there's something the ExportWebMapTask or ConvertWebMapToMapDocument tools can't handle within the JSON that's getting sent in. I'd slowly start pulling out complexity within the webmap_as_json, (graphic layers, symbolization, etc), until you can determine the cause of the problem. I don't think there's any other way to go about it. Are you services public?
... View more
10-25-2018
01:57 PM
|
2
|
1
|
1306
|
|
POST
|
A good troubleshooting step is watching the network traffic. Before you add an item, have the dev tools or Fiddler running and check what the response is. If it's a 200, then check your content under the Sharing API: https://<portal>.<domain>.com/<context>/sharing/rest/content/users/<user> If you see if there, then the item is getting added, but there's something wrong with the index. Check the index status through the Portaladmin API: https://<portal>.<domain>.com/<context>/portaladmin/system/indexer/status If all values match up between the Database count and Index count, then something else is going on. If they don't, reindex through the Reindex operation at the /indexer page. For the Categories, I noticed that if they fail to create, the error isn't returned. I'd check the network traffic again when creating the category. What do you mean by the services are invalid? What makes them invalid? Are you unable to access them in the map viewer or when logging in directly through the REST API?
... View more
10-25-2018
10:43 AM
|
1
|
3
|
1895
|
|
POST
|
If you run the ExportWebMapTask GP tool on your Desktop providing the same webmap_as_json from your application, does it work there?
... View more
10-25-2018
10:32 AM
|
0
|
3
|
4571
|
|
POST
|
Glad it's sorted out, but strange fix. As far as I know, (haven't set it up to check network traffic), clients such as Esri Maps for Office make initial connections to Portal to determine if it supports hosted services. I wouldn't expect them to connect directly to the Server and check either Publishing Tools, but it would have been interesting to see what the traffic looked like to return the error you saw. In terms of the upgrade issues, I know there's ongoing investigation into the Continue Upgrade problem. It seems it's random and difficult to reproduce consistently in-house. I'd suggest the next time you need to upgrade, contact Support and have them give you steps on capturing as much information as possible for the upgrade. It's difficult to investigate retrospectively, so if they can make sure the environment is set up to get as much info out of it as possible, that may help diagnose the problem.
... View more
10-25-2018
10:30 AM
|
0
|
0
|
1449
|
|
POST
|
I'm glad that it's working, but I'm surprised it was a problem with the URL and not with the referer. For example: import urllib, urllib2, json, traceback, ssltoken
URL = 'https://sampleserver6.arcgisonline.com/arcgis/tokens/generateToken'
tokenParams = dict(username='user1',password='user1',client='referer',expiration='1440',referer="https://server.domain.com",f="json")
tokenRequest = urllib.urlopen(tokenURL,urllib.urlencode(tokenParams))
jsonResponse = json.loads(tokenRequest.read())
token = jsonResponse['token'] I create a referer based token. If I make a request without providing any headers, I get invalid token: restParams = dict(f="json",token=token)
restRequest = urllib.urlopen("https://sampleserver6.arcgisonline.com/arcgis/rest/services",urllib.urlencode(restParams))
print(restRequest.read())
{"error":{"code":498,"message":"Invalid Token","details":[]}} If I use a different referer, I get the same response: request = urllib2.Request("https://sampleserver6.arcgisonline.com/arcgis/rest/services")
request.add_header('referer',"https://server")
restRequest = urllib2.urlopen(request,urllib.urlencode(restParams))
print(restRequest.read())
{"error":{"code":498,"message":"Invalid Token","details":[]}} However, if I use the correct referer, then it works: request = urllib2.Request("https://sampleserver6.arcgisonline.com/arcgis/rest/services")
request.add_header('referer',"https://server.domain.com")
restRequest = urllib2.urlopen(request,urllib.urlencode(restParams))
print(restRequest.read())
{"currentVersion":10.6,"folders":["AGP","Elevation","Energy","LocalGovernment","Locators","NetworkAnalysis","Oblique","OsoLandslide","ScientificData","StoryMaps","Sync","Utilities"],"services":[{"name":"911CallsHotspot","type":"GPServer"},{"name":"911CallsHotspot","type":"MapServer"},{"name":"Census","type":"MapServer"},{"name":"CharlotteLAS","type":"ImageServer"},{"name":"CommercialDamageAssessment"....} If the valid referer was sent along with the request to an invalid page, you shouldn't get an invalid token response.
... View more
10-24-2018
05:12 PM
|
0
|
0
|
3860
|
|
POST
|
There will be no impact to ArcGIS Enterprise. Even if you found applications hosted on Git that you use in your deployment, I'm pretty sure you download and host them locally anyway. Are you seeing issues or are you just wondering?
... View more
10-24-2018
09:51 AM
|
1
|
1
|
1139
|
|
POST
|
Under the https://machine.domain.com/<context>/sharing/rest/portals/self page, scroll down until you see the supportsHostedServices property. Is that True or False? Pretty sure that's what every client will look at to determine if the Portal has a hosting server.
... View more
10-24-2018
09:49 AM
|
0
|
3
|
4048
|
|
POST
|
1) Since the external URL is different from the internal URL, then that's why the tokenServicesURL is blank. That's won't affect your ability to publish, though. 2) Ok, there's a DEBUG message that is logged that may seem like it indicates a problem, but it can be ignored. It doesn't seem like you're seeing that error, though. 3) That would tell you whether you can get to the Sharing API, (what Server is trying to do). Have you configured a forward proxy for Server, either through the System Properties of Server or through the IE settings? 4) Yes. To go a bit deeper, if Server is using a self-signed certificate, Portal doesn't care about it, (as long as it's not a certificate mismatch). However, if Server is using a different certificate, then it must validate it. Let's say you use a wildcard certificate signed by your domain signing authority; Portal will look at the certificate, see it's associated with server.domain.com, but the CN is *.esri.com. It determines those don't match exactly, so it checks the root certificate. Since it doesn't trust your root signing authority, the request is blocked. You can simply tell Portal to trust the root certificate: Configuring the portal to trust certificates from your certifying authority—Portal for ArcGIS (10.6) | ArcGIS Enterpri… Server, on the other hand, does everything through the Trusted Root Domain Certificate store through the service account. The BUILTIN setting within the tokens page is fine, that's what I see in my environment as well.
... View more
10-23-2018
09:38 AM
|
0
|
5
|
4048
|
|
POST
|
Is your web adaptor or reverse proxy on a different domain than your Portal and Server? If so, that's likely the reason why the tokenServicesURL is blank. That shouldn't be an issue, though. Does the error you posted continue to say "trying a portal token next" or something similar? If so, you can disregard that error. Can you remote into the Server machine as the user running the Server service and reach the Portal Sharing API in a browser through https://portal.domain.com:7443/arcgis/sharing/rest? Invalid token errors and failed to connect errors are definitely different. Server would only be able to log an invalid token error if it was able to connect to the Portal to actually validate the token. Any trust issues can be resolved by adding the certificate to the Trusted Root Domain Certificate store. And yes, never unfederate.
... View more
10-19-2018
04:16 PM
|
0
|
7
|
4048
|
|
POST
|
The first thing that comes to mind, (and only because you didn't explicitly mention it), is that you're not sending the same value of the referer header as the one you use to generate the token. They have to match exactly.
... View more
10-19-2018
04:05 PM
|
0
|
1
|
3860
|
|
POST
|
In general, self signed certificates are fine within an Enterprise deployment. Can you describe the issue you're running into? Are you not seeing layers when you print? Do you see any errors in the Server logs?
... View more
10-19-2018
04:02 PM
|
1
|
1
|
4571
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 05-28-2026 06:05 AM | |
| 1 | 08-26-2016 10:10 AM | |
| 2 | 02-22-2024 07:22 AM | |
| 1 | 06-07-2024 07:11 AM | |
| 4 | 12-12-2024 08:52 AM |
| Online Status |
Offline
|
| Date Last Visited |
06-08-2026
07:43 AM
|