IE is always a pain to install - because you not only need admin rights at the time of the install, worse - you need admin-rights AFTER THE REBOOT as well.
That aside - a bit of detail on your executable package would be a good way to start. Microsoft has recommendations for automated installs of IE 7 ... which may or may not be of help here.
LANDesk EMEA Technical Lead.
Thanks for your reply Paul, not sure if i follow entirely though.
The package has already been created using Microsoft's recommended method, using IEAK 7\Internet Explorer Customization Wizard (because we add a number of customisations which are necessary for our non-AD devices).
Previously i had not included the reboot option within that wizard, because i assumed that LANDesk could handle the reboot. Question 1 still stands - why will the PC not reboot after the installation has completed?
I have recompiled the package and set the reboot option in the wizard, the installation has run on the PC, installed fine, rebooted, but of course because it was the package that initiated the reboot and not LANDesk, the task is sitting there still stating that the installation is active when it is not. This I predicted and this is why i wanted to use LANDesk for the reboot.
I would recommend looking at the SDCLIENT log(s) as a first reference.
Log-files for software distribution (client-side) can be found in two places:
In this case, particularly the SDCLIENT_TASK##.log (where ## == the number/TASK_IDN of the task in the database's "LD_TASK" table) will be useful and tell you where the client has downloaded his files from (i.e. what peer / which preferred package server).
This should include everything you want to know regarding the reboot. Now - it's possible that we don't receive the flag for "this package needs a reboot" because of the way that this package tries to do it (which is my guess as to what happens - LANDesk doesn't know the package requires a reboot on account of some miscommunication). What happens when you change the package to "always reboot" ?
LANDesk EMEA Technical Lead
I have checked the log file from the client which concludes with a result code. In the console, LANDesk shows the 'Status' as 'Failed' with the 'Result' as "The requested operation is successful. Changes will not be effective until the system is rebooted."so i assume that is the response that the executable installation package returns to LANDesk. In other words, there is nothing in there to indicate (to me anyway) why it has not automatically rebooted once the installer has completed (however, the failed status is concerning as other packages are not recorded as Failed when thy require a reboot - any idea why this is different in this case?)
I am confused by your question "What happens when you change the package to "always reboot" ?" Do you mean the setting in the 1) Delivery Method, or 2) Package in LANDesk or 3) the actual IE Customised Executable?
1) The Delivery Method is already set to Always Reboot - it is not working, hence this post
2) The Package in LANDesk does not have any options reboot settings
3) The customised IE7 executable, if set to always reboot causes the task to sit there after the PC has rebooted as i said in previous post.
sdclient_task1198.log 1.2 K
If you have both set to reboot but the IE package is failing to do it, then the failure may be enough to tell the scheduled task it didn't work so the task isn't complete, so don't reboot (if that makes any sense). Only set the task to reboot as a test.
LANDesk will try to use poweroff.exe for this, does it exist or has someone disabled it?
If all else fails, using poweroff.exe or a different reboot utility such as psshutdown add it a 'final package' for execution after the main package (since you can now have up to three packages in a sequence) in an 8.8 scheduled task.
Mark Star - MarXtar LANDesk Enhancements
Home of Power State Notifier & Wake-On-WAN for LANDesk
Aye - what Mark said.
I'd suspect the next step would be to try and find out what this error 3010 means from Microsoft. Generally, anything that's not a 0 is regarded as "not good" by us.
One possibility is that it's having hangups because of user-context -- see this article http://community.landesk.com/support/docs/DOC-1645 on how to create a CMD-box in LOCAL SYSTEM context. Try to run the install by hand in LOCAL SYSTEM that way ... maybe it'll give you a few more useful error message (or just flat out doesn't like local system)...?
Hope this helps a bit along the way.
LANDesk EMEA Technical Lead
In reply to both you guys:
1) I tried in the first place with just the Delivery Method set to reboot and not the IE7 installer - it did not reboot
2) I have checked and poweroff.exe is present in system32 on the test machines - i am certain its not disabled - how would you achieve that?
Should i create an additional package using winrestart.exe or poweroff.exe?? - what parameters will alert LANDesk that the reboot has taken place? (because i am fairly certain that any form of restart that LD is not 'aware' of is going to cause the same problem as in previous post - that the task does not complete. Also, Poweroff does not appear to reboot, it only powers-off! Can it be used to reboot a PC?
3) Paul - I feel LANDesk is interpreting the MSI result incorrectly (see links below) - it should show as Successful NOT Failed. This would mean if the task is re-run on genuinely failed machines (switched off etc.), it does not re-run on those that have completed but just need a reboot (I am sure that i have deployed packages before that have required a reboot that have not had a status of failed?).
4) I have tested the package using the local system account - it works perfectly, the msi log shows the exact same result, that the PC needs to be rebooted.
5) Still no explanation of why the Delivery Method is not rebooting the PC, any other ways to investigate this?? How does LANDesk reboot a PC? Does it use winrestart.exe?
I have answered one of my questions above - I have tried adding both poweroff.exe and winrestart as secondary packages and both still result in the package showing as "Failed".
So one thing to look at is the log file created by the installer. This may answer all your questions. Use this link:
/log:<path> = Create log file at <path>.
Some other good hints and notes on the page.
I think we are loosing the point of my thread here - there is NOTHING wrong with the selfextracting installer that i have created, the problem is that LANDESK will not reboot the PC after the installer completes, even if it is set to ALWAYS REBOOT. It is LANDESK not rebooting that i am trying to investigate so MSI logs etc. are not relevant.
Paul - If LANDESK deploys a package and the result is "Failed" does this prevent it from rebooting a PC?
> Paul - If LANDESK deploys a package and the result is "Failed" does this prevent it from rebooting a PC?
Yes, because rebooting the pc for a failed package produces ill will with the end users. The failed status on the IE package prevents chained packages (such as your attempts to call shutdown tools directly) as well. At this point your options are to figure out why the status code from IE looks like a failure, or to wrap the IE installation in a batch or vbs file so you can control your own return code.
IMHO, this is a sucky situation for all parties concerned... suggestions for fixing it greatly appreciated. We've done BKMs for some packages, but those are infrequent and uncommon. What if LANDesk offered a channel of predefined packages, or a way to post successful package definitions and deployment methods on this site?
Workaround would be a package wrapper (vb, autoitscript, etc...) Save the return code of the running application to a variable, check variable if it is 3010 or other msi success return code then exit with a 0, if not exit with variable return code.
I would also suggest that LANDesk rethink this one. If it is a success but needs reboot, and package is set to reboot, then maybe it should be a success.
I have to agree with Dave's second para - the MSI code 3010 is explicitly defined on MSDN as a successful result (http://msdn.microsoft.com/en-us/library/aa368542.aspx). Creating bat/vb/autoit scripts to workaround this could hardly be described as a good use of resources.
Do I need to submit a formal request for LD to look into this?
Pretty much, yes - because it's still a non-0 result for SDCLIENT - it's consistent with the behaviour I've seen so far.
It may not be presently ideal (and thanks for the link - good find). There's an ongoing discussion (for years now, I think) about whether a "reboot required" should be a success or a failure ... with both sides having good arguments for their respective take. At present, the "it's a failure"-camp (so to speak) still has the larger weight - and the best way to change that is through customer requests - i.e. ER's.
'Tis unfortunately anything but a "simple" matter regrettably. It's the problem with these "it works for you some of the time / it works against you the other part" whichever way you turn it :).
(I think I can already draw up a list of customers and folks who would argue - against my preference, which is that "reboot required" == success - that the way it presently is working is great, and that it shouldn't be touched).
Maybe something like a "global" setting for the Core server (so that we can accommodate both camps) would be the best way - so as to have each organisation be able to define for itself which way it wants to go. This would - essentially - only relocate the argument from us to all our customer's IT - granted - but at least it would be easier to MAKE the choice for the head of IT (irrespective of popularity of one approach or the other), as opposed to have it made for him.
If this works for you, and you want to log this as an ER with us trough the usual means, I think this might actually be something that would work for most involved...
LANDesk EMEA Technical Lead