Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Overlapping Install Commands from different software policies - CMS 7.1

Created: 11 Jul 2013 • Updated: 30 Jul 2013 | 9 comments
This issue has been solved. See solution.

Hi all,

We are just starting with CMS 7.1 and Managed Software Delivery policies.

We would have one policy installing one piece of software - as a general rule.

Is it normal the Execute Install commands to run in parallel? See below.

CMS_Overlapping_Policies.png

One would expect an Install Command to wait until the previous one has finished - with either status.

Even I would think that the framework should run the policies one by one, rather than all in the same time.

If this is normal behavior? Does that mean that if a computer gets 20 policies, it will run 20 install commands in the same time?!

And if so what is the way to avoid this?

Operating Systems:

Comments 9 CommentsJump to latest comment

Dmitri Dragunov's picture

Hi Klim,

Actually "Running" in the End time column means that tasks were initiated. Windows do not support paralel installation, so one of them, which has started later will wait untill previouse task will finish installation.

Running the task based on the schedule. You may schedule policies in the different time.

If you have a lot of policies or tasks, we do not recomend you to start them in one time as some software require restart and other software installations may fail and installation will be rescheduled to next day or next week. It depends on schedule settings.

Regards,

Dmitri

SOLUTION
David_SES's picture

Hi Klim,

Dmitri has right. Windows doesn't support more than one installation when you use msi file installation. But, you can start another installation in the same time if and only if it's not a msi file, for example a setup.exe.

If you have some software dependance, you can use software detection rules

Regards,

SOLUTION
andykn101's picture

I've never seen the agent show two installs running at the same time in that way, If you look in the altiris log on the client you can see that software management will check that the windows installer service isn't being used by anything else (for example, windows update) before it runs any an msi based install.

The default is for the whole Policy to stop if any Task within it fails, (Policy > Advanced Options > Results based actions tab > Upon failure).

I think there may be a problem with the Task History reporting GUI you are looking at, does the lower right pne in the Software Delivery tab show both tasks running when you select the Policy in the top right pane?

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

David_SES's picture

I did a test to push 3 installations in the sametime on a test machine and this is the result:

from history altiris

alt.jpg

from process manager

proces.jpg

So, you andykn, it's possible, ;-)

andykn101's picture

The Windows Installer often spawns more than one msiexec.exe process. If you look in either the "Software Delivery" tab, the Altiris log, or the log files of the individual installs I'm sure you'll find the msi install happen sequentially.

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

Klim_Belchev's picture

Thank you alll for your help. Finally I managed to test this properly.

So Dmitri is correct - the install commands from the policies do queue as one would expect.

But this is only if your policies are installing Software resources.

If your policies are just running tasks - the tasks overlap (run together).

David's comments are also correct.

So this is something that people need to know.

We have tasks that install software (which is not in the software library) so this is an issue.

I have marked Dmitri's, David's and this post as solutions as all three provide some info on the topic.

SOLUTION
jlawson's picture

I had a tech support case regarding this a few months ago.  Basically what we were experiencing is that we start a few installs at computer startup and they all kick off at the same time.  The issue is as everyone knows MS can only run one at a time.  So all but one Errors (1603) out.  This is crazy Altiris software management should be SMART enough to know it can't do two install policies at the same time!

Basically I was told after they went to development that this is the way it was.  There is no fix for it and no plans in the future to fix it because of something to do with task that they implemented conflicts with this.  Since they went down one road they are not going to fix the other road I guess.

So resolution is reboot again to install other packages or schedule them at different times and this does not work at all because if I schedule all of them to happen say 7/20 at every other hour when I deploy a new PC on 7/21 and it gets all these polices guess what happens...  They all try to run right away at the same time.  Their other solution was to build policies that held all the software packages for that computer so they could run step by step.  This was laughable since there is no possible way anyone could ever manage this.  I won't go into what happened next.  Frustrating is all I can say.

andykn101's picture

Are you talking about Tasks or Polices? I've never had this problem with Policies, I'm sure I've seen entries in the log where the agent chaeck to see that the Windows installer Service is free before running.

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

jlawson's picture

It is SMD policies and happens all the time.  Symantec even admitted to it and said have no plans in fixing it.

One note: the example I shared with Symantec in my case was related to a three msi uninstall policies running at the same time.