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.