Software Deployment

It won't suppress the generation of the return code, since a reboot is still required, it's simply that the reboot prompt has been suppressed.

We want to supress this since it will help to install other application in the sequence and do a final reboot.

We do not want to reboot the machine before installing the other applications. Hope you understand our situation.

Adding to that, we are using TS in SCCM to install multiple applications in single task.

TS will not stop rebooting the machine if it sees 3010.

Only workaround we have is...wrap the MSI and ignore return code.

To apply this workaround, we would need to do for 1000+ applications. fyi.

Your workaround is the perfect fix then as REBOOT property is internal to MSI and has actually made its job not to reboot it. That is what I think.

ORIGINAL: We want to supress this since it will help to install other application in the sequence and do a final reboot.
We do not want to reboot the machine before installing the other applications. Hope you understand our situation.
How about changing the sequence of the applications so that the one that requires the reboot is the last one that installs? That would solve the issue.

Something else to try - find out what is causing the 3010 in that install. If it is a file in use, then force the closing of the file/application/process prior to the install. That might result in a full install not requiring a restart (3010).

We can not do this for 2 reasons.
1. Reboot action will be decided only by the return code.
2. We can not change the order of installation since this may disturb the prerequisites.

Only way is use the wrapper as work around. I was curious to know if we have any option to prevent 3010 from MSI.

1. Reboot action will be decided only by the return code.
2. We can not change the order of installation since this may disturb the prerequisites.

Only way is use the wrapper as work around. I was curious to know if we have any option to prevent 3010 from MSI.
#1 seems irrelevant to me but then I don't fully know what you are doing.
#2 is a logical response but for every application, the packager should already know what the prereqs are for the app. So if you don't already know what your prereqs are for each app in the wrapper, you should find out first. Once you know, you can determine if you can rearrange the installs so that the app throwing the 3010 is the last app installed.

About the prevention of the 3010, maybe you didn't read what I said about that? If you look at the MSI verbose log, you can figure out what is causing the reboot call. Knowing what is causing the 3010 can be a starting point for you to take care of the issue prior to the install of the app that is causing throwing the 3010 once completed.

Something else you could try - After your app that throws the 3010 is installed look at the registry key:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
Chances are the PendingFileRenameOperations key contains Data. Look at the files listed (it could be tmp files, DLLs, txt files, etc.). Find out WHY those files are in use BEFORE the install and close the files (close all applications, stop whatever service, etc.) so that the files are NOT in use prior to the install of the app. Then when you install the app, your log file should end with a return code 0 instead of 3010.

What bearden3 said could be a good point to start with. But for me in reality, it is not practical to go deeper on each MSI just find out where 3010 come from if you have tens or hundreds more MSI´s to check if your SLA is suffering. Even if you can manage to find out what has caused i and looks good in your test machines, once you have set free the packages into the wild they could behave differently.

For me, I will just stick with the workaround of wrapping them just like you are currently doing.

Why use TS at all? My SCCM is a little rusty so can't recall the exact sequence but at my last client, we set SCCM package programs to run other packages first, ending up with a potentially unlimited chain of events. If the rebooting package is set to ignore "errors", the chain will execute start to finish (notwithstanding other, actual errors, of course.

Your approach will work if we have only 2 applications installed one after the other. If you have more than 2 applications to be installed in a sequential order then your approach will be little difficult to setup.

It will be easy in TS to setup as many as applications you want.

We have some requirements that we need to make sure all the prerequisites should be installed before installing the main application.

Thank you very much for all your valuable suggestions.

ORIGINAL: bearden3
#1 seems irrelevant to me but then I don't fully know what you are doing.
#2 is a logical response but for every application, the packager should already know what the prereqs are for the app.  So if you don't already know what your prereqs are for each app in the wrapper, you should find out first.  Once you know, you can determine if you can rearrange the installs so that the app throwing the 3010 is the last app installed.

About the prevention of the 3010, maybe you didn't read what I said about that?  If you look at the MSI verbose log, you can figure out what is causing the reboot call.  Knowing what is causing the 3010 can be a starting point for you to take care of the issue prior to the install of the app that is causing throwing the 3010 once completed. 

Something else you could try - After your app that throws the 3010 is installed look at the registry key: 
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
Chances are the PendingFileRenameOperations key contains Data.  Look at the files listed (it could be tmp files, DLLs, txt files, etc.).  Find out WHY those files are in use BEFORE the install and close the files (close all applications, stop whatever service, etc.) so that the files are NOT in use prior to the install of the app.  Then when you install the app, your log file should end with a return code 0 instead of 3010.



#1 I was referring the return code 3010. This will be returned by the Windows Installer during the installation time.

Your approach looks feasible but time consuming. We need to update each MSI to close the respective applications before installation start.

Thanks so much for the suggestion... I might start applying this approach moving forward.

Back to your original post, you asked if anyone knows how to *prevent* the return code 3010. That is what I was responding to. You have to determine what file(s) is/are open that the install needs to update/modify but can't because they are open. If don't do that you'll probably always get the 3010 for that application, requiring a reboot.

I thought of this one too - what do you think?

How about putting a run-once key into the registry so that once the computer reboots, the rest of your wrapper script will continue? You'll most likely need to split your wrapper in two - one that does everything prior to and including the app that requires the reboot, then the other half of the wrapper script that installs the apps beyond the one that required the reboot. Would that work for you?

Not to say that any of the responses here aren't helpful, but if you want answers specifically for SCCM, http://www.myitforum.com/ is the place to go.

It is possible to avoid 3010 somethimes:
1) Set ScheduleReboot custom action condition to "0"
2) Disable iteration with restart manager by setting MSIRESTARTMANAGERCONTROL property value to "Disable"

if you want answers specifically for SCCM, http://www.myitforum.com/ is the place to go.Jeff, the problem is nothing to do with SCCM, which is merely the deployment mechanism.Disable iteration with restart manager by setting MSIRESTARTMANAGERCONTROL property value to "Disable" This is only relevant for WI v4.0 and above.

ORIGINAL: itolutions

It is possible to avoid 3010 somethimes:
1) Set ScheduleReboot custom action condition to "0"
2) Disable iteration with restart manager by setting MSIRESTARTMANAGERCONTROL property value to "Disable"


Yes, We found this answer last week and implemented. Giving good results.

Thanks.