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-serv... 

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 · Accepted solution]

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.

[MichaelVolz]

In your initial post towards the bottom you say "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 the v2 compact format."

What do you mean by v2 compact format?  I only see COMPACT and EXPLODED as options for how the cache is created.  I do not see different options for the COMPACT type of cache.

[RebeccaStrauch__GISP]

Hi Michael Volz,

Sorry I'm late responding..

The Compact version is in the cache's

      \\<server>\<drive>\arcgisserver\directories\arcgiscache\<service>\Layers\conf.xml 

near the end of the file. 

For 10.2.x it is:

<StorageFormat>esriMapCacheStorageModeCompact</StorageFormat>

For 10.5.1 (and maybe prior) it is:

<StorageFormat>esriMapCacheStorageModeCompactV2</StorageFormat>

color and bold added for emphasis.

To get it to recognize my 10.2.x version, if the conf.xml file was already created, I needed to edit and delete the "V2".  If you look at you tiles, you can tell whether the tiles themselves are the original compact or V2 by whether there are .bundle AND .bundlex files (version 1) or just .bundle files (V2).

That helped me get the cache to work with 10.5.1, but the printing issue was with the default behavior as I mentioned above.

(btw - I think the line you quoted had a typo on my part.  The "of" should have been an "or"  ...I really should proof read my posts better.     I will fix that.)

 And since I'm here, I'll add the more succinct answer to the printing issue, provided by tech support

After further review we were able to determine when publishing a map service to ArcGIS Server 10.5.1 
"Allow per request modification of layer order and symobology" is checked on by default. However, this is not the case when publishing to ArcGIS Server 10.2.2. After unchecking the "Allow per request modification of layer order and symobology" the cache was recognized as expected for the 10.5.1 cache map service. 

[ZachBodenner]

Hi! I know this is an old threat but I just wanted to comment to say thanks for the sleuthing you did to solve this issue. We had a cached aerial image that was being consumed in a bunch of web applications, but the data was taking quite a bit of space on our server. We copied it to an external and then cleared out the database that previously held the aerial imagery, and lo and behold we could no longer get the aerial to print, even though the image itself was still visible in all the maps. Took some banging our head against the wall but eventually we just said forget it, and restored the data, not knowing what else to do. Today I returned to the problem thinking I'd not be able to solve this one without a trip to ESRI tech support, but your solution worked like a charm!

[JamieHammermann]

This has helped me immensely!  Thank you so much for posting the solution.  Worked like a charm!

~Jamie

[WalterSimonazzi_VicPol]

I had the same issue in 10.8 Server federated with  Portal 10.8. Just unchecking the option   "Allow per request modification of layer order and symbology" fixed the issue. Now users can print maps in WAB with basemaps. 

Service Properties (Service Editor) -> Capabilities -> Mapping ->

   "Allow per request modification of layer order and symbology"