Solution: Print GP service not printing cached basemap (AGS 10.5.1)

RebeccaStrauch__GISP

• New setup:  ArcGIS Server 10.5.1  (non-federated)
• Basemaps are non-secure cached services (JPEG) using the v2 of the compact cache format
• "operational" layers are dynamic,  (tried adding a cached layer just to test but it didn't like that)
• I have a proxy in place, and it is working for the web site and for accessing my secure services
• All layers are in Alaska Albers, so reproject is not involved.

All layers show on my JS web page as expected.  I set up the 10.5.1 print GP service following instructions found 

https://enterprise.arcgis.com/en/server/10.5/get-started/windows/tutorial-publishing-additional-services-for-printing.htm 

and the print service itself seems to be working. (currently set to sync, received AGS log error if async, even though I am not using Portal or Pro)

I think I have everything setup the same way as I do on my 10.2.2 AGS server. 

-The 10.2.2 server prints the base map with no issues.

-The 10.5.1 server prints all except the based map.

I have seen several threads about basemap not printing in Flex app, but this is JS.  The other thread I have reviewed is Cached basemap not fully loading in layout view but there was no answer int hat thread yet.

BTW - I am currently working with JS v3.10, which I know is old, but does work with every thing else so far, except maybe printing basemaps in 10.5.1.  I haven't taken the time to update my JS to a newer version....that may take some work since the html format messes up...and I'm short on time.  I have not yet played with things in the JS sandbox online since our 10.5.1 servers are still inside the firewall.  

I think we have all the patches that may effect this install (the GP one).  I see there is a Basemap patch for Portal, but again, this is ArcGIS Server, non-federated, so I do not think that applies.  For the record,below is the result of "check for updates"

Any help is appreciated.  Thanks

--------------------------------

EDIT:  some additional testing, which leads me to think this is a bug.

Above is based on:

1. AGS 10.5.1 custom GP Print service
2. AGS 10.5.1 tiled map service  in 10.5.1 compact format (v2)
3. a working proxy

• If I switch out #1 above with the the working GP Print service from 10.2.2 ... does not work
• If I switch out #1 and the #2 for the same on 10.2.2 ...does not work
• if I leave #1 as 10.5.1 and switch out #2 with the map service from 10.2.2...IT WORKs

So, I think is it an issue with the cached map serivces in 10.5.1 (I tried more than one cached map service).  I am not sure if it is the cached map service in general of or  the v2 compact format.

I will put in a tech support ticket and report back....but if anyone else has run into this issue and/or found a solution, I would appreciate the info.  Thanks

RebeccaStrauch__GISP

After working with very patient and thorough tech support staff (Jordan), she was finally able to figure out the difference between the DEFAULT 10.2.x and DEFAULT 10.5.1 services. We did not test the versions in between, so I do not know when this default behavior came into play.

For our situation, this difference only caused an issue on cached services where 1) the original source layers were not readily available any more, and/or  2) layers that where included in the cache were removed and/or even just unchecked in the TOC.

The actual property is not one I would have thought controlled whether PRINTING came from the cache vs. the mxd source layers. However, I can see the controlling the drawing/display (I believe this is what allows a user to change the rendering on-the-fly)

The checkbox that was causing all this confusion is in the services:
Service Properties (Service Editor) -> Capabilities -> Mapping ->

   "Allow per request modification of layer order and symbology"

• in 10.2.x this was UNCHECKED by default.
• in 10.5.1 (unfederated) this is CHECKED by default. 
  
  
• Note: Federated AGS may have it unchecked by default. This was not verified (since it was not my setup), but was the initial setup the tech was using. She was not able to reproduce the issue on that setup, but this was not retested to know for sure.

--> SOLUTION <--  To force the print geoprocessing service to read from the cache and not the source, make sure to uncheck the box.

There are times you do want it checked as mentioned, such as if you need to give the users' a bit more rendering control. So, I can understand while this may have been changed to being checked by default (i.e. an as designed feature).

In our case, there are two main reasons we would want it unchecked:

• Cached services where the source data is not longer available, or access to the data is not practical (i.e. network too slow.
• Cached service where we purposely removed or unchecked layers to prevent Identify from returning info. For example, we may have topo or imagery cache data, but when queried, we want to only return information from a polygon layer with the quadrangle info (or maybe parcel info) so we removed the imagery. 

And in my opinion, most cached raster basemaps used for public web maps we would want to use the cache only. 

BTW - the only variable that was making this show up (because of the default) was the AGS version (10.2.x vs 10.5.1).  It did not matter whether we used the AGS default print service, a custom print service, the AGOL print service, the print service rest endpoint to export a map (with the json input), or a different version's print service.  All those acted the same given the cached 10.5.1 service.  Also, the results were the same using the REST endpoint tools vs. using a JavaScript api app (WAB or api only).  So, that little box being checked, and the fact the published mxd did not match the cache exactly anymore...that was the cause.

I hope this prevents frustration and wasted time for others running into this in the future.