Hi

Does anyone know how to prevent the return code 3010?

REBOOT=REALLYSUPPRESS is not preventing 3010. fyi.

Any suggestions would be greatly appreciated!!!
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
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.
Answered 05/05/2011 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 05/05/2011 by: WSPPackager
Senior Purple Belt

Please log in to comment
0
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.
Answered 05/05/2011 by: WSPPackager
Senior Purple Belt

Please log in to comment
0
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.
Answered 05/05/2011 by: dj_xest
Fifth Degree Black Belt

Please log in to comment
0
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).
Answered 05/05/2011 by: bearden3
Purple Belt

Please log in to comment
0
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.
Answered 05/05/2011 by: WSPPackager
Senior Purple Belt

Please log in to comment
0
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.
Answered 05/05/2011 by: bearden3
Purple Belt

Please log in to comment
0
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.
Answered 05/06/2011 by: dj_xest
Fifth Degree Black Belt

Please log in to comment
0
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.
Answered 05/06/2011 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 05/06/2011 by: WSPPackager
Senior Purple Belt

Please log in to comment
0
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.
Answered 05/06/2011 by: WSPPackager
Senior Purple Belt

Please log in to comment
0
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?
Answered 05/06/2011 by: bearden3
Purple Belt

Please log in to comment
0
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.
Answered 05/06/2011 by: jmaclaurin
Third Degree Blue Belt

Please log in to comment
0
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"
Answered 05/07/2011 by: itolutions
Orange Senior Belt

Please log in to comment
0
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.
Answered 05/07/2011 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 05/11/2011 by: WSPPackager
Senior Purple Belt

Please log in to comment
Answer this question or Comment on this question for clarity