I have enabled verbose MSI logging on the target PC and nothing is being written to %temp% when the package is ran on the target PC. I have tested that the MSI logging is working and it correctly logged when an application was uninstalled and installed.
If anyone has any ideas I would love to hear them, I am hitting a wall and cant see anyway of overcoming this.
The Part of the error code that stands out from the error code --
-2147467259 (0x80004005 - code 16389)
is not the 16389 but the Hex error 0x80004005. I have yet to find a distribution failure with the error code 80004005 where the problem was not permissions related. (Not to say that this couldn't happen) This could be problems such as
- Share permissions - The share (UNC or HTTP) could not be accessed by logged on user OR Local System
- Rights Permissions - The Application was downloaded to the sdmcache folder in C:\Program Files\LANDesk\LDClient\sdmcache but was unable to be executed properly. either in part or in whole by by the logged on user OR Local System account.
Check out the following document for some tips for testing the software distribution as Local System.http://community.landesk.com/support/docs/DOC-1645
The other thing you could try would be to look at the Software Distribution Package, check the Accounts portion and check to see if the package will be run by the Local System Account, or as the Currently logged in user. If one, then choose the other, rehash the package and redeploy. Did this change the behaviour?
Hope this helps
Thanks Kothoga, it is strange after your post I went back and couldn't see anything obvious with permissions. What I did find was that if I was to remove the DNS alias that we have for the server and used the server name for all folder paths (so instead of \\appdeploy\... I used the server name \\srvName\...) and this worked, nothing else was modified.
Is there a known issue with using DNS alias' for this sort of stuff?
Thanks for your assistance.
1 of 1 people found this helpful
As i experienced also this, yes it is you need to put right path which is the tru conanical name of the server or machine youre getting the file.
as i tested it before I run it via http://localhost/installer/ ... the file name
but is has the same error code 16389
then i tried to change the locahost to the name of the server then it work fine now..its DNS dependent too.
Wow, that is rather annoying. We prefer to use aliases for all this sort of stuff so that when it comes time to upgrade we dont have to go and change the server names in any custom scripts that we use. It would be great if this was able to be resolved, but at least I know about it and will just need to keep that in mind whenever we need to upgrade/migrate the server.
Thanks to all for your time and assistance with this, it has helped me greatly.