Here's his reply:
As we discussed yesterday, see additional information and suggestions below:
Current build version is SCCM 1706. I have looked over the feature updates in the build, and there does not appear to be any items that would explain the behavior discussed, but just a reference point, the following site will provide links to all of the builds and documentation for them: https://buildnumbers.wordpress.com/sccm/
SCCM build numbers
↓SCCM Current Branch build numbers ↓SCCM Technical Preview build numbers ↓SCCM 2012 R2 build numbers ↓SCCM 2012 SP1 & SP2 build numbers ↓SCCM 2012 build numbers ↓SCCM 2007 build numbers ↓SMS 20…
I would suggest that taking a look at the logs associated with client configuration and the server logs associated with client management might help to shed some light on what is happening as the client is initially configured, and then through the first 24 - 36 hours of life, is changing from 3600 minutes to 86400 minutes. There has to be one or more events being recorded that are indicating what is happening, and what is making the change, and this would be the place to start working backwards from. I would suggest that the following site will provide a good overview of the logs available: https://docs.microsoft.com/en-us/sccm/core/plan-design/hierarchy/log-files
Log files for Configuration Manager | Microsoft Docs
Use log files to troubleshoot issues in a System Center Configuration Manager hierarchy.
There is a set of tools in the SCCM toolkit that may be valuable to use here as well. Specifically, the policy spy tool. The link for it is here: https://www.microsoft.com/en-us/download/details.aspx?id=50012
System Center 2012 R2 Configuration Manager Toolkit
This toolkit contains fifteen downloadable tools to help you manage and troubleshoot Microsoft System Center 2012 R2 Configuration Manager.
The other thing, even though the initial answer to my first comment about this was that there is nothing that is being used to configure the client as an additional policy, or "external" factor, I would also throw out the possibility of a Primary / Secondary site hierarchy. If the architecture here is not flat, as in a single primary site being used to manage the client in question, but rather there is a Primary / Secondary relationship in force, and the client is getting the settings from the Primary site, then the change may be attributable to the policy settings from the Primary site. I would not expect that this is the case, given the behavior and the explanations of observed settings, etc... up to now in the conversation, but I am just throwing it out there as a possibility as well.
If none of the other items above, (relay item #2) yield any further information or insights, then I would suggest that it may be time to go direct to the source and open a support ticket with Microsoft, as they will have access to tools and information for troubleshooting that will most likely provide the answer."