I've been working through an issue for some time now and I think it's a bug with SCCM 2012 SP1. I've built literally 50 deployments in "Application Management" in SCCM 2012, but I've been chasing my tail on a few of them throwing the "succeeded but couldn't detect" error. The few that have given me problems are all copying text files and then detect the modified date to verify that the file is there. All worked when I initially built them in Windows 8 but are now failing randomly...even on a machine where they previously worked and I deleted the files to test the deployment again. 

What I'm doing:
My java deployment requires policies which we control with the Deployment.config, deployment.properties and java.policy files. A simple script creates the directories and copies the files. I then create a deployment type for this "ConfigFileCopy.cmd" and create a detection rule for each file that I am moving over. The detection rule looks for a "date modified" date between the beginning and end of the date for the day I modified the file. This allows me to modify the files to change our java policies and then redeploy them with the "new" modified date as the detection rule, which forces the update.

The problem:
When I first created my deployment, everything worked pretty well. The files copy out and the script runs successfully. There were some minor tweaks I need to make to my scripts, so I did and then updated the content for the deployment type. I believe this is where things go a little wonky. At this point, my deployment starts failing with the "0x87D00324" error.

Looking through the logs, everything looks good. The reason configuration manager is failing on detecting the modified date for those files, as it turns out, is because the modified dates don't meet the criteria. So that part is properly failing the detection. The problem is that the modified dates are correct on the server but not the client. Looking in c:\windows\ccmcache, I can see multiple folders....presumably one for each version of the application that I updated. Looking at any of the newer content folders for this app, the modified dates are the date and time the file was copied out to the workstation, which is incorrect as the file hasn't been modified during that process.

The odd part, is that this doesn't happen EVERY time on EVERY machine. My primary desktop is windows 8.1 and received the files correctly and installed without issue. My test win 8.1 laptop initially received them correctly, but then as I refined the scripts it began picking up the wrong modified dates and started failing.

I found a similar issue to this existed in SCCM 2007 (http://support.microsoft.com/kb/2276865) so I suspect that this is truly just a bug that hasn't been addressed (or maybe is fixed in R2). Unfortunately we have business reasons we can't upgrade to R2 at this time so I'm hoping someone has experienced this and has some sort of work around that might get me by for now. If someone can confirm it is fixed in R2, that would help my case to upgrade as well.  

I can work around the issue by changing my logic to detect any date greater than a specific date. But I shouldn't have to do that and I'm concerned there are scenarios I haven't thought of that will cause unexpected behavior or failures with that.

 

 

While it's possible this is a bug, remember that other things can potentially change the modified date of a file including AV products and backup software so it may not be the best criteria to use in the first place.

A simple solution is to create a custom registry value when the script to copy the files runs. This is then easily checked by the deployment type and not subject to any mischief by anyone.

I've had pretty consistent luck with the modified date to this point, but you're technically right. In our environment we have things extremely locked down so it shouldn't be a factor unless something else is going awry at which point we would want to have failures that help call our attention to the errors anyways.  

I originally tried a similar solution to your registry idea where I copied a "complete.flag" text file to the computer and verified it's existence. The problem is this only proves that my script completed. It doesn't actually prove that the correct files were successfully copied and replaced the existing files (if they already exist). This is where my need to validate against the modified date originated. I'm basically using the modified date as a version number.

I appreciate the ideas though. 

For what it's worth; I just tried renaming the 3 folders from ccmcache where the files had the incorrect dates to force it to re-copy the folder down from the server and it worked properly this time. Still no rhyme or reason why it worked this time but not the others. I also looked through the roughly hundred or so other folders in CCMCache to see if any other apps had a similar issue and not one did. So I'm still completely puzzled as to why this is happening. 

Ultimately though, the modified date isn't necessarily indicative of what version the file is either though because this can be modified by other things.

For a registry value, set it to your "version" number if and only if the script copies the new file down.

Too bad there's no hash value as that would elegantly solve the issue.

Technically, it is exactly indicative of that. If the file has been modified in any way, it is incremented. At the point that it's been modified, it is a new version no matter what modifies it and we would want to know that this change took place.

Not if it's been modified by something else, like AV, backup, etc. Those processes touch the file and sometimes flip permissions or other attributes that don't materially affect the content of the file so the file itself remains the same and at the same version. You're trying to fight an uphill battle against something beyond your control.

It's not an uphill battle. Attribute and permission changes do not affect the modified date of a file. If it does, you have a problem somewhere else that needs attention. We don't use software that improperly or inaccurately changes the modified date of a file.

Well, until this little bug in SCCM. 

Maybe you don't think it's smart to trust this value. That's fine, you don't have to agree with me. But the fact is that our systems have relied on the modified date of files to be accurate for over 10 years with an exact success rate. In a domain environment with enterprise backup, antivirus software and massive file shares I have terabytes of files that are correctly and accurately reflecting the proper modified dates.

I've got files with modified dates as far back as 1999 in public shares that are backed up nightly and are under heavy antivirus scrutiny. That just shouldn't be possible if what you say is true. 

• Edited by RSchauer77 Thursday, April 24, 2014 9:26 PM

Not trying to argue with you here, but you're obviously not getting the results you expect for whatever reason -- who cares what it is. If you believe its a bug in ConfigMgr, open a case with CSS. In the meantime, your issue still exists. What I proposed above does and is trivial to implement.

As for your file shares of data, apples and oranges. These are user's desktops with desktop AV running and subject to all kinds of other things. Once again who cares at this point, but it still doesn't solve your issue.

On a side note, why are you paying to store 15 year old data online and backup it up every night if no one is modifying it?

I will open a case with CSS. I posted this here as due diligence to make sure there wasn't a switch or behavior that was being triggered by something I was doing. 

Like I stated in my original post, I have a work around and can make it work. 

LOL...you're preaching to the choir. I'm merely a cog in the machine and have little say in where the machine goes. I will say that our agency has it's reasons. 

This outlines the behavior. It's apparently by design. 

"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/

• Marked as answer by RSchauer77 15 hours 16 minutes ago
• Edited by RSchauer77 15 hours 16 minutes ago