Portal Print Service Doesn't Work Unless Feature Service is Shared Publicly (Export Web Map Task error)

[RyanUthoff]

I'm having an issue with my Portal's print service (using the built in Print button in the web map). If a map contains a referenced feature service, the only way the print service will work is if the feature service is shared publicly. If the feature service has organization or owner level permissions, the print service will fail. I receive the following message when using the print service: "An error occurred while creating the printed map."

If I check the server logs, I receive the following error for the Utilities/PrintingTools.GPServer service:

Error executing tool. Export Web Map Task : Failed to create layer from service at <feature service URL>. 

Note that the feature service URL it provides in the URL is valid. I can copy and paste it in a browser and it takes me straight to the rest endpoint. The only way it works is if the feature service is shared publicly. Otherwise, it fails.

Here is what I have tried with no success:

• Share the PrintingTools service with the public.
• Make the referenced feature service (when not shared publicly) and PrintingTools service the same owner in Portal.
• Share the feature service and PrintingTools service with the same group in Portal.

None of that works and the only way it works is if the feature service is shared publicly.

We're using ArcGIS Enterprise 11.2.

I'm assuming this is not expected behavior, right? If not, does anyone have any issues on what the issue could be? Thank you!

UPDATE: I've made progress in determining the root cause of this issue. The PrintingTools service doesn't seem to like AD accounts. If I am logged in under a built-in Portal account and use the print service with a feature service not shared publicly, it works fine. However, if I am logged in under an AD account and attempt to use the print service with the same feature service (not shared publicly), it fails.

Second UPDATE: I initially thought it was an AD vs. built-in account issue. But I've ruled that out and realized that it's just a browser issue. Opening the map in an incognito tab or using another browser works..... I don't think it's ideal for users to have to completely clear their cookies and cache every time they want to use the print service (because this is happening to multiple people), but at least it's not completely broken.

[BillFox]

do you have the option to stand up a separate (stand-alone) (not federated) ArcGIS Server machine to handle just printing chores?

[RyanUthoff]

Technically, we could do that. But I feel like that's a pretty excessive workaround (paying for additional ArcGIS server licensing as well as the costs of running the server itself) just to run a printing service that should be working on the federated server in the first place.

I don't know what the root cause of the actual issue is. I'm not sure if it's on the browser side or the server side, but clearing out the cookies and cache seems to temporarily fix it. But regardless, I feel like the root cause of the issue should be fixed as opposed to deploying additional servers just to get around this printing service issue.

[BillFox]

note 1: https://community.esri.com/t5/arcgis-web-appbuilder-questions/export-web-map-task-failed-to-create-l...

[BillFox]

note 2: https://community.esri.com/t5/arcgis-online-questions/printing-limited-usage-layers-with-our-own-pri...

[BillFox]

note 3: https://community.esri.com/t5/arcgis-enterprise-portal-questions/have-you-printed-arcgis-com-marketp...

[BillFox]

I'm not sure if those are exactly like what you are troubleshooting but hope they help or spark some others memory to help you

[rcGIS]

Hi @RyanUthoff, seeing now your 2nd update, do they have to continuously clear the browser cache to use the print service without issues (every user's session?) or just once, and then it remains to work well?

I have had in the past that when changing the print service type within the Web AppBuilder print widget end-users were then getting the "Error executing tool. Export Web Map Task..." and clearing the cache solved the issue (as a complete final solution, I mean). I also see that clearing the browser cache is listed as a workaround in this Support article.

[RyanUthoff]

They have to clear it periodically. It's not literally every time, but also frequently enough to where it's pretty annoying. Also, it appears that the user has to clear both the cookies and cache. We tried only clearing the cache, and that doesn't fix it. It needs to be both cache and cookies.

I went on a wild ride trying to figure out this issue. When I was troubleshooting, I did try clearing the cache and it didn't work, so I initially ruled that out. And then opening an incognito tab and it working with a built-in account made me think that was the issue. But in reality, the incognito tab worked because it reset both the cookies and cache. I was caught off guard because there were ArcGIS Server logs saying it couldn't create the layer, so I thought those were permissions related issues. I never would have expected it to be cache related.

[TimoT]

Hi @RyanUthoff 

This issue is likely related to a known limitation: BUG-000135413.

Using DevTools, you'll see that the token isn't passed in the request payload when the issue occurs. Off the top of my head, potential workarounds include:

1. Continue to clear cache and cookies or use incognito mode
2. Switching the default print service to another federated server's print service where users are less likely to trigger the known limitation
3. Embed credentials into a custom print service. This could potentially pose a security risk.