A few days ago i was asked to do some troubleshooting for a project that were having issues deploying their app-v 5.0 SP3 packages via SCCM 2012. when investigating the appenforce log i noticed that the package was generating the 0X87D0128F error code. 

After doing some research and if you have come across this error before you would also notice that most of the topics relate to the sftmime.exe. as soon as i read up to the sftmime.exe the back button to safety was bashed to make the page go away as it was not relivant to the issue.

At this point i thought it would be best to ask how this package got through both QA and the pre-production testing to try and understand where the issue is manifesting itself, and as soon as i heard the answer i proceeded to bash my face of the desk.

turns out for both QA and pre-production testing the package was deployed to Machine collections, and in the live environment it was published to the user collection, this itself shouldn't be an issue as im sure whom ever packaged it tested both the deployment and user config files, but being cynical i decided to test both.

so i ran the following tests

  • manually added the app-v package with the deployment config and published - Passed
  • Manually added the app-v package with and published with the user config -    Failed Malformed XML
  • Manually added the app-v package with the deployment config and published with the user config - Failed on publishing
knowing that there were version of the sequencer especially early 5.0 ones that sometimes the XML files are not generated successfully i opened the package up for editing and was horrified when i seen the package was on revision 17, at this point i was certain that it was not the sequencer to blame.

so i ran the package through various XML validation tools and package validation tools and no error was found. until i started to look over the user config file its self and found to my annoyance and horror the following line (ive changed the exe pointer in this example)

      <Application Path="[{ProgramFilesX86}]\Publisher\Application\exe.exe" />

TerminatechildProcesses section had been copied from the deployment configuration file and dropped into the user config file by the packager, and as this section is not supported in the userconfig file it was causing the client to reject it as a malformed xml file.

but the question was raised, why didn't this generate an error in the sequencer?

to answer this i ran the following tests

  • Open for upgrade
  • add an application
  • edit package
under each of these i re-saved the package not only as a new version but as a new package, and on each occasion the userconfig was keeping the terminate child process that the packager had dropped in.

i hope this helps anyone else having the same problem