none
What could cause some deployments to have corrupt software installations? RRS feed

  • Question

  • Using MDT 2013 to deploy Windows 7 x64 Enterprise. In our reference image we have our common software apps installed. These are:

    • Encase
    • Adobe Reader
    • Firefox
    • Flash for Firefox
    • Flash for IE
    • Jabber
    • Java
    • Office 2010
    • Quicktime

    We also use Windows Update to patch the machine with the built-in MDT 'Windows Update' actions. On SOME of our deployments, applications are corrupt, and won't launch. When you attempt to remove the application via Add/Remove programs, you get an error: "This action is only valid for products currently installed." This has happened for Office, Adobe Reader and Quicktime so far. 

    Is there something we could be doing wrong in our reference image capture process? Or perhaps in our deployments?

    Wednesday, September 30, 2015 5:37 PM

All replies

  • Add logging to the application install command lines.  Also make sure that your command lines are such that they won't return before they are done.

    Most important details are logs. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/

    Wednesday, September 30, 2015 5:50 PM
    Moderator
  • Do you mean during the build and capture task sequence?
    Wednesday, September 30, 2015 5:51 PM
  • There are 3 likely failure points. 

    During the install of the applications (so yes during your build and capture).  For the applications I would add logging to the installs. 

    Sysprep could be failing in some way.  I would check the sysprep logs (MDT logs as well as PantherGC.

    Or the captured WIM could have issues due to Sysprep failure or corruption.


    Most important details are logs. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/

    Wednesday, September 30, 2015 8:29 PM
    Moderator
  • The only thing that doesn't jive with those 3 suggestions is that only SOME of the deployments have corrupt installs. If there was a problem with the reference image, wouldn't all of the deployments have this issue?

    The odd thing is that WHEN the deployment "goes bad", it goes bad the same way. Corrupt Adobe Reader and Office.

    Thursday, October 1, 2015 3:48 AM
  • Most common problem is when Application A returns to ZTIApplications *Before* it's finished will the full installation. Application B then starts up, and is blocked by Application A which is still running in the background.

    That is why in my deployments I try to call MSI packages with the /l*v switch so I can go back and *verify* the command finished before exiting to ztiapplications.wsf through the bdd.log file and with corresponding timestamps.

    See: https://keithga.wordpress.com/2013/09/04/application-installation-and-packaging-via-mdt-and-sccm/

    If you are still having problems, please upload your logs, including bdd.log to a public site like onedrive and share the link.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Thursday, October 1, 2015 7:52 PM
    Moderator
  • Thanks for taking the time to reply, I follow your blog and enjoy being on your email list! I should point out that the OP and I are colleagues. I read the post from the link you provided and though it’s useful, I don’t think it deals with this particular issue unless I’m misunderstanding something.

    In our reference image is where all of the 3rd party apps are installed, they’re the ones listed above in the original post. We’ll call this our Windows7 x64 “thick image.” We then take the resulting “thickimage.wim” and import it as an OS for MDT. This is what’s used for the “Install Operating System” MDT task sequence step in the Litetouch deployment. My understanding is that when MDT is laying down an OS during this step, they’re the exact same bits we sealed up with Sysprep before importing the WIM. Since there are no install binaries in the reference image, or the deployment task sequence, the apps are being laid down because they’re embedded in the reference image. (Sorry for being painfully obvious, I just want to be clear)

    In the State Restore portion of the task sequence we can use a pause so that we can spot check the online OS to determine if things look right. This is where we discover if things are wonky. Most of our builds go on to succeed with no problems and become functioning members of the enterprise. But a few, which don’t have to be the same make/model will “break.” They each are consistent in breaking the same way, however.

    So, how is it possible that most PCs image perfectly, but few fail in the exact same way without any seeming commonality?

    EXAMPLES: 

    In the start menu the links to Adobe Reader & QuickTime don’t have any properties, and there’s no representation for them in Add/Remove. I'll use QuickTime below as an example.

    Most all of Office 2010's components work with the exception of Outlook. When trying launch and then to perform a repair, the errors below results.


    Where ever you go, there you are.

    Friday, October 2, 2015 9:21 PM
  • Gov,

    I don't have any answer for this.  As I posted earlier I would fall back to making sure my base image was put together properly.  I don't suppose you have any custom steps added anywhere?


    Most important details are logs. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/

    Friday, October 2, 2015 9:38 PM
    Moderator