/build/static/layout/Breadcrumb_cap_w.png

Detection of msiexec to avoid 1618 code

We use a not often mentioned solution to deploy software to our machines, and have a very small percentage (~3%), that fail with the exit code of 1618 because another installation is already in progress.  This typically occurs for machines that have been off the network for a period of time, that requires the antivirus update process to install a new version.  So, the process more or less goes like this...

Machine boots and logs in to network

AV update check occurs, starts to download/install

Software Delivery program performs job check, starts to download/install updates

AV software continues to progress and succeeds, software delivery program fails occassionaly because another installation is in progress.

I'm thinking what I could do is write a pre-flight step in our scripts, to check for msiexec.exe as a running process - if found, pause for a period of time and then re-attempt (and loop this for some reasonable amount of time).

With the failure rate so low, I'm not overly concerned - our support staff receives e-mails with verbose logs attached to these e-mails so failures can be remediated, but I try to be proactive to reduce unnecessary intervention.

I'm guessing others have come across this before - just wondering if there may be a better way to do this, or if others have taken this similar approach and what your results have been.

 

Asked 11 years ago 4368 views
2 Comments   [ + ] Show comments
  • Your plan is somewhat flawed since the process could be running when no installation is actually taking place. Often, WI leaves itself behind, running what I call the server process.

    I guess you *could* take th eplan a little further by detecting if the process was using CPU cycles or was writing/deleting files and/or registryt data but, to be honest, - and I am very much like you in wanting to be able to head off failures - with the failure rate you have, I wouldn't bother unless you find yourself with a monumental void of time with nothing better to do! :-) - anonymous_9363 11 years ago
  • Thanks VBSCab - that's a good point about the process being running without installation. I'd probably also have to do a loop to extend the timer each time, such as IF RUNNING - Pause 5 minutes (or some other time), re-run the check, and extend the time each time. In the event that was flawed or not scanning correctly, the impact could be negative to a wider audience compared to the small percentage of the impact now. Definitely have better things to do, just looking to see if these problems could be solved.

    Appreciate the input regardless. - drose23 11 years ago

Answers (0)

Be the first to answer this question

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ