Patch Management Group

 View Only
Expand all | Collapse all

ABSB15-24 - anyone else having trouble with DC installers?

  • 1.  ABSB15-24 - anyone else having trouble with DC installers?

    Trusted Advisor
    Posted Oct 16, 2015 02:49 PM
      |   view attached

    Failing for me on all clients.

    If I try to run the .msp file that Symantec puts in Software Delivery folder, I get attached error.  Anyone else seeing this, or is it working for others?

    This is on Win7.  Previous DC upgrades worked for me.



  • 2.  RE: ABSB15-24 - anyone else having trouble with DC installers?

    Posted Oct 19, 2015 06:53 AM
    Modern Windows Installer (msi) packages usually cache the components needed for upgrades or uninstalls in the c:\windows\installer folder. It looks like, for whatever reason, your original Adobe DC install didn't do this; maybe previous patches worked because the original package hadn't been removed from the Altiris Agent cache but it now has. You can maybe use the Application Management features in ITMS to update the source path locations to a network share or local path where you recache the DC msi (C:\support\DCmsi for example). Or add a dummy command to your original DC install package and use a Policy to run that on all PCs this will recache the msi in the original location; make sure the Policy (Advanced > Download tab) is set to never delete the package.


  • 3.  RE: ABSB15-24 - anyone else having trouble with DC installers?

    Posted Oct 19, 2015 09:21 AM

    Files are never cached in C:\Windows\Installer (Well ... they might since installer 5.0 ... to keep the manifest/signature valid ... but these are never used ... long story)

    Just never delete any MSI from the Altiris Agent cache to be safe.



  • 4.  RE: ABSB15-24 - anyone else having trouble with DC installers?

    Trusted Advisor
    Posted Oct 19, 2015 11:20 AM

    Thanks @andykn101 for giving me something to go on.

    I guess this is what I get for using Adobe's tools to package their installers :(

    I see now in my registry where it's looking for source path in the local software delivery folder (I searched for acroread.msi or acropro.msi and see sourcelist folder listing softwaredelivery folder path).

    Anyone have any feedback on downsides to running 'updating source path of windows install applications' using the built in source path update for all windows install apps?  

    I did this on a test machine and see it updated the sourcelist folder in registry to my CMS server & the adobe patches installed properly.

    Could this mess up locally install programs somehow?  I checked office (installed on the image) and it seems like in registry the source list looks ok still on the test machine.

    I would prefer to just update the 2 Adobe app source locations, but when I right click on the package in software catalog and do update source, it runs on another test machine without error, but source locations in registry didn't change on the client.  It also seems like doing it this way you can't schedule it to run and would only hit computers that are powered on?

     



  • 5.  RE: ABSB15-24 - anyone else having trouble with DC installers?

    Trusted Advisor
    Posted Oct 19, 2015 11:33 AM

    I've been using CMS for over 4 years now and have always deleted packages installed after a week and never ran into this before ... not sure why.  Probably more an adobe issue than anything?



  • 6.  RE: ABSB15-24 - anyone else having trouble with DC installers?

    Posted Oct 19, 2015 12:02 PM
    I was thinking out loud as I was typing my previous answer and I'd definitely follow my last suggestion; "...add a dummy command to your original DC install package and use a Policy to run that on all PCs, this will recache the msi in the original location; make sure the Policy (Advanced > Download tab) is set to never delete the package." If you use source locations on your network you then have to start either running jobs as an account with access to the share or completely opening up your shares.


  • 7.  RE: ABSB15-24 - anyone else having trouble with DC installers?

    Trusted Advisor
    Posted Oct 19, 2015 12:14 PM

    I was going to create a policy to copy AcroRead.msi and AcroPro.msi back to their original locations, but on 3 different test computers I have 3 different source locations for AcroRead.msi somehow.  

    I had trouble packaging it initially so not sure if it was just me testing the installers or why the source locations would be different.

    Can you give me a hint of whaty ou mean about a dummy command, maybe that will click something in my brain on what you mean?

    I've since changed the reader/pro installers to never delete the package for future use.



  • 8.  RE: ABSB15-24 - anyone else having trouble with DC installers?
    Best Answer

    Posted Oct 19, 2015 12:37 PM
    In your Software Release for Adobe Acrobat DC you add a Command with a type of Install that requires the package you used originally: CMD /c "dir" Then create a Managed Software Delivery Policy to run that command on all PCs that had the original Adobe Acrobat DC installed on them. In the Policy check in the Advanced > Download tab that the Package is set to never delete. Provided you use the same Software Release and Package that you used before the source files will get copied back to the same location on your PCs.


  • 9.  RE: ABSB15-24 - anyone else having trouble with DC installers?

    Trusted Advisor
    Posted Oct 19, 2015 04:00 PM

    Thanks, Andy, this seems to work so far in my testing.  I'm glad I only have one package I built for Acrobat.

    I'll have to re-evaluate how to fix Reader.  I think I had a package I pushed originally that no longer exists in CMS.  Worst case maybe I could just build a new installer (assuming it will remove old versions) and make sure to keep that .msi in place.  Stupid Adobe.

     

     



  • 10.  RE: ABSB15-24 - anyone else having trouble with DC installers?

    Posted Oct 21, 2015 06:46 AM
    Provided you don't have any "per user" installs, where the source path will be encoded in the User's registry hive, you could just create a package to copy the msi to a location of your choosing (C:\support\ReaderX) and do a reg add to correct the source file location in the registry.