Ran against a server to install the msi; eventlogs were clean and all success; but the key file in bin direstory is still old. Later tried installing it directly doing a double click by RDP into the server; installation was success and bin files are updated.
->Reboots were not required and were not involved in both cases. ->why is this happening? and where can i find more logs? -> Server is windows 2008 R2
The most likely cause of this is that you ran the MSI silently via WMI and interactively when logged onto the server (short of the install never having run at all). Is this what you actually did? There are also other reasons that can cause the same problem. We would need to see the content of the update.cmd file to be sure.
To deal with the silent versus interactive issue first: there are different installation sequences inside each MSI File, and the two most important are:
What happens during a silent install is that the entire UserInterfaceSequence is skipped. This is normally fine, and should cause no problems in a properly authored MSI package. However, sometimes, or actually quite often these days, the setup developer has not inserted all the custom actions or scripts that need to run during the installation into the silent installation sequence, resulting in an incomplete installation when run silently. Though the symptom you report (a file is not updated) is not the most typical for this silent installation problem, it is still a likely cause. Other causes could include an incorrect command line, or interference from WMI that I am unaware of. I never use WMI to install MSI files, since there are many other ways to run MSI files. Here is another thread dealing with alternatives to msiexec.exe deployments (under the hood I guess all these different ways call the C-style windows 32 API).
Proper support for silent installation is an absolute requirement for an MSI - it must be able to run silently, or it is not properly authored by definition. But there are always ways to do things wrong, and there are still many packages that don't comply. For corporate use, silent installation is generally the only feature of the MSI that is always used. It is one of the key advantages of MSI files.
At a professional application packager level we find ways to deal with this in each case. Often resorting to modifying the MSI file heavily to ensure that everything runs that has to run. For server installations this is often not worth the effort, as it is easier to run the setup interactively. However, corporations now use more and more thin clients and therefore have more dedicated servers to run the network, and in these cases silent installation is just as important. A better solution is to send the whole MSI back to its vendor and get them to fix it. Check my rather ad-hoc list of common design problems with vendor MSI files. You don't need too many of these errors before the MSI should be sent back.
