I've created a deployment of an application then deployed it to a test machine. The test deployment ran flawlessly so then we deployed it to a production computer. This second deployment resulted in a message saying the application could not be detected following installation. The application did seem to be installed and working fine. So then I tried deploying to a second test machine. This second test also worked flawlessly.

My detection rule in the software application was for the Last Modified date and time of the Application executable.  On the failed machine I found that the last modified time had been 'modified'.   

Any ideas why SCCM would change the timestamp and or how to prevent it?

All and any comments or suggestions greatly appreciated.

WD

The problem computer was freshly rebuilt, having been completely wiped.   The particular application had never been installed on this computer.   On all other installations the timestamp is 11:28 while on the problem computer the timestamp is 8:28. 

Now since the application has never been on the computer before,  SCCM installed the application and immediately reports a failed application I can only surmise that SCCM changed the timestamp.

WD

Think of CM12 as UPS, it only delivers what you tell it too. It would be your install that would be causing the problems. Having said that and based solely on the fact that it is exactly 3 hours off, I would suggest it is a time zone issue.

I am having the same issue using CM 2012 SP1.  I have a file that was distributed to 18 distribution points.  It is copied to a directory on the users machine.  Then the detection method is supposed to look for the modified time of the file to verify it was successful.  Most machines receive the timestamp of the file the same as it is in the content location but some machines receive a completely different timestamp which then causes the detection to mark the installation as a failure.  We have used this method in the past without issue.  I am not sure what is causing it to behave this way now.

I am having the same issue using CM 2012 SP1.  I have a file that was distributed to 18 distribution points.  It is copied to a directory on the users machine.  Then the detection method is supposed to look for the modified time of the file to verify it was successful.  Most machines receive the timestamp of the file the same as it is in the content location but some machines receive a completely different timestamp which then causes the detection to mark the installation as a failure.  We have used this method in the past without issue.  I am not sure what is causing it to behave this way now.

IMO this is not a CM12 problem but a setup/WS problem. Heck it might even be a AV problem.

What make you think this is a CM12 problem? What is common between the PC seeing the issue? What happens when you manually install the app as you and Local System?

This is not an actual install just a file placement or copy.  The file in the content location where SCCM created the deployment from has a date modified time stamp of 3/28/2014 5:37:40.  When the application deployment runs most machines get the same timestamp for the date modified as the original file.  Some machines for example get a date modified of 3/28/2014 5:53:37.  All SCCM is doing is placing a file.  This is about as simple as a deployment as you can make.  I have tried updating the content of the deployment type.  This is where it gets interesting.  Most machines then still get the original time stamp correctly but the ones that were getting the incorrect timestamp now get a newer timestamp corresponding to the updated content time.

I'm not following you.

Where is the file get changed, on DP side or Client?

What is common between PCs where you are seeing the issue?

The file timestamp appears to be changed as SCCM is putting it on the client machine.  If I remove the file and run the install again it puts it back with the same incorrect date.  The good timestamp and the bad timestamp are all coming from the same DP which leads me to believe it is correct still at that point.  I agree this could be something on the client side but the million dollar questions is what on the client side is causing this interaction with the deployment.

The file timestamp appears to be changed as SCCM is putting it on the client machine.  If I remove the file and run the install again it puts it back with the same incorrect date.  The good timestamp and the bad timestamp are all coming from the same DP which leads me to believe it is correct still at that point.  I agree this could be something on the client side but the million dollar questions is what on the client side is causing this interaction with the deployment.

So what is common with those WS? Have you turn off AV? Have you checked the cache folder to see if the file has the right date/time? IS it your setup that is changing the file date/time. Are you sure that they are all getting it from the same DP? Are you using WAN accelerators?

Why can't you use file version instead of date/time?

I'm just asking the question... is the target workstation perhaps configured for a different time zone?

I never looked deeply at file dates and times, but I know when I run sql reports for file info with date and time info returned; sometimes, yes, the results for the date/time stamp are off by hours one way or the other.  I just assumed but NEVER verified (so take this observation as just that... a guess) that it was somehow or other related to timezone stuff.

With that in mind, for an application deployment, I wouldn't use in my Detection method (if I'm using date) checking for File, Modified Date, Equals an exact date.  I'd use   Modified Date Between... and put in a range of a day either way. 

sure, sure... it's 'possible' that widgets.exe with a date of April 2 is the old version, and April 3 is the new one... but how likely is that really?  A fudge factor of a 72 hour window should alleviate this issue (presuming my guess is right... like I said.. just a g

I had similar problem with ConfigMgr 2012 R2, my detection method included a timestamp of single .ini file, four machines had different date in the ccmcache and the rest were fine. I ended up changing the detection method to something else. All the machines were on the same timezone and configured the same way.

Thanks to everyone who is commenting on this thread.  I'm enjoying the discussion even if we are no closer to determining a cause.   In my case the time zones are identical. I checked the target computer and it has the correct time zone and time. 

I ended up copying the file with the correct time stamp to the computer and that made SCCM happy.  But I'd still like to know how the time stamp gets changed.

Thanks again to all

WD

GarthWe use a base image that is deployed by SCCM and all the aspects of the machines are the same.  They are in the same time zone, using the same DP and have the same AV policy.  The DP is at the site so it is upstream from any WAN accelerators.  Where is the cache folder?  Is it on the DP or the local machine?  File version is a good thought.  I created my file just in notepad and renamed it.  Under properties it does not have all the extra attributes. 

SherryThese are in the same time zone.  I thought about using a range as you suggested as you are correct I would put in a wide timeframe.

NarcoticooIt sounds like our situations are identical in what we were trying to accomplish.  Mine is a simple .cfg file.

WD I did the same thing.  I ended up manually copying the file to make SCCM happy for the problem machines.

Thanks all for input and suggestions.

This behavior has bothered me for some time. I finally found someone that outlined why this happens! This should clear up the confusion. 

"SCCM has a habit of changing the Date Modified timestamp of all files it delivers when it detects an upgrade of the source files for that application. It typically does not touch the timestamp of the source files if it delivers a brand new install to a client that has never received the software, however if a single file in the source folder is changed for that application, then SCCM tries to use a previous version of the application in the cache (C:\windows\ccmcache) and only downloads the new file that has change. This results in all files having their Data Modified timestamp changing (except for the brand new file). Therefore determining if that application has delivered successfully using Date Modified timestamps is not recommended. The key to seeing this process in action is looking at the file properties in the C:\windows\ccmcache\<sccm code> folder for that application, particularly before and after a file is updated in the original source SCCM application folder."

http://blog.kloud.com.au/tag/sccm/