Why are published items in My Content not visible in Map Add Layers?

[MarcWeinshenker1]

We have assembled for testing a single ArcGIS Enterprise 10.5 server with all three components (Server, Portal, Data Store), and with the Server federated to the Portal.  We already have a Portal in production, so we are familiar with it, but we have no experience with federation until this test configuration.

Here's a problem I have encountered during testing:  feature layers published from ArcMap to the Enterprise Server and automatically registered as items in Portal do not appear in the list of available layers under Search for Layers when attempting to add content to a web map in Portal. If instead of using Search for Layers under the Map Add, I choose Add Layer from Web and provide the REST endpoint URL, it will find the layer and add it to the map.  Meanwhile, other items I manually registered from an independent non-federated and unrelated production Server do appear in the list when using Search for Layers under Map Add.  

Is this a bug, an annoying feature, or did we do something wrong?

Thanks much.

[JakeSkinner]

Hi Marc,

A couple things to try/check:

1.  Make sure the service has the correct tags you are searching for

2.  Try unchecking 'Within map area' when searching for the layers

3.  Does the service appear under 'My Content'

[MarcWeinshenker1]

Hi Jake,

1. I was not doing any tag searches.
2. This fixed it but I don't see why as I was zoomed well outside the bounds of the data extent.  Further, when I zoomed out to the entire world I would expect to see the layers listed even with the box checked since the map area is the entire world, but they still don't appear until I uncheck the box.  
3. I've already been working under My Content for these tests.  In fact, I am pretty much forced to go to My Content to see my services because selecting Portal for ArcGIS pulls in all the Living Atlas data.  Yes, I have disabled bringing in Living Atlas data in the Portal settings but apparently there's a bug where Administrators still see it all anyway.

So, even though unchecking the box for 'Within map area' fixed my problem, I still feel something is wrong for the reasons I stated in #2.

Thanks,

Marc

EDIT:  I looked further at the behavior of the map area checkbox and the listed data.  If I zoom out to the entire world with the box checked, the layers don't show up.  But, then if I uncheck the box, the layers show up and I discovered that they stay visible when I check the box again and start zooming back in to the point where I get close enough and they disappear when I toggle the box.  So, I see now that the layer list does not actively change with map area so it must be toggled.  Comparing the behavior in our production Portal, it has no problem listing the same data published from the same MXD when the box is checked and the map area is the same.  I'm back to thinking there is something going on when publishing to this Server federated to Portal.

EDIT 2:  I registered one of the offending layers from this Enterprise test Portal (10.5) to our production Portal (10.5) using the REST endpoint URL from the Enterprise test Server to test visibility behavior when searching Layers to add to web map.  It turns out there are no issues when the 'Within map area' box is checked.  It behaves quite properly and Layer shows up in the list right off.  I'm definitely thinking there is something going on in the Enterprise system.

ONE MORE THING:  I discovered on the Enterprise test Portal that I only had to zoom the map out one step for the published layers to appear in the list with the 'Within map area' box checked.  All this makes it look like publishing to the Enterprise system changes the extent of the service when it automatically registers it with Portal.  Sounds totally crazy, but not out the realm based on other behaviors I've run into over the years.

[JTessier]

Came across this searching for something else, but I believe we saw this if you did not publish in a projection that Portal's "extent" filter can work with.  I'm guessing you resolved this problem, but that may be something to check if you did not.