Select to view content in your preferred language

Cannot view local ArcGIS Server Feature services in Portal Maps

10-07-2015 09:56 AM
New Contributor III


I'm having trouble with our portal instance accessing services from an ArcGIS Server on the same host.

When adding a feature or map service from our local (non-federated) ArcGIS Server onto the map all is fine initially. I can see the features, the layers populate and I can configure everything as I like it and save the map.

However when I then re-open the map it never loads the layers from the feature service into the table of contents, and so the edit toolbar is never activated.  I can see the features on the map, but they don't appear in the layers listing and so we can't interact with them.  The following error is shown in the browser console:

TypeError: Cannot read property 'trim' of undefined(…) "TypeError: Cannot read property 'trim' of undefined

    at Object.trim (

    at h._checkProtocol (

    at h._doSignIn.g (

    at h._doSignIn.s.addCallbacks.c.sinfo_._restInfoDfd (

    at c (

    at d (

    at b.Deferred.a.resolve.callback (

    at c (

    at d (

    at b.Deferred.a.resolve.callback ("

This happens regardless of whether the feature services are secured or publicly available.

If I add the service using an alternative hostname or the IP address of the ArcGIS Server things work OK, like it's 'tricking' portal into thinking the service are hosted on a different server.

Is there a limitation on Portal consuming (and especially editing) ArcGIS Rest services hosted on the same server?  All are setup using the Web Adapter.  We also use Integrated Windows Authentication but I don't think this is the issue as the problem is the same for anonymous services.


0 Kudos
6 Replies
Esri Esteemed Contributor

Hi Andrew,

> Is there a limitation on Portal consuming (and especially editing) ArcGIS Rest services hosted on the same server?

No, there is no such limitation. This workflow is fully supported.

The error messages you posted suggest that some Portal for ArcGIS install files are missing or inaccessible to the web browser. It sounds like something is amiss with your Portal for ArcGIS installation/configuration.

Please contact Esri Tech Support so they can help investigate and resolve your issue.

Hope this helps,

0 Kudos
New Contributor III

Thanks Derek - that could explain a few other issues we are having around Portal.

I'll submit a case to ESRI UK Technical Support


0 Kudos
Occasional Contributor

Where you able to resolve this issue? I'm having the same thing come up for us.

0 Kudos
New Contributor III

Hi Carlos

I'm afraid not - we've quite a few outstanding issues with Portal and integrated windows authentication so I'm trying to fix them before pursuing this one with tech support.

Please let us know if you can resolve the problem though.


0 Kudos
New Contributor III

I get the same issue but I can add the service then the pop-up doesn't work. I reported the bug last year BUG-000085674 - Feature pop-ups lack attribute information in Port.. I just ended up "tricking portal" that my services were on a different machine with the IP address instead of the dns website name. I finally ended up just publishing my services to another machine because of certificate error issues and ssl.

0 Kudos
Regular Contributor

We setup our Portal/Hosting Server/DataStore to all be HTTPS only with a domain CA.

I have found that I can initially access data from our older 10.1 Servers that are strictly HTTP.

I can add the REST Endpoint to a map service as an item in My Content and then drop it on a map.

And it seems ok.

But then the next day, the map will no longer draw the data and if I try to look at the underlying service, it is not accessible.

I assume this is all related my HTTPS only setup (on both Portal and AGS.)

This is fine with me.  What was confusing was being able to see http at all initially.

And it's a head scratcher as to why it takes some period of time for things to stop connecting.

EDIT:  Spoke with an Esri Portal guru the other day about this issue.  He felt that reason you can initially see http when set to https only is related to the browser.

IE is apparently especially known for doing this sort of thing.