Software Deployment

Why not simply let Windows Update take care of instaling the hotfix? If you *must* package it, as Murali says, a CA in the deferred sequence is all you need.

Can you not use the custom action to run this file. Run exe from destination or VBScript CA should be useful.

Thanks a lot !
@ VBScab - the reason for packaging this updates is ,our client need some extra registry to be added to the package with the update.

i have also tried the above solution of adding a CA, vbscript is as follows

Dim sDestinationFolder1 , sFile , WshShell
sFile = "Windows6.1-KB917607-x64.msu"
Set WshShell = WScript.CreateObject("WScript.Shell")
set objWshShell = CreateObject("WScript.Shell")
sDestinationFolder1 = objWshShell.ExpandEnvironmentStrings("%Temp%")
WshShell.Run sDestinationFolder1 &"/"& sFile &" /quiet /norestart" , 1, True

but my script doesnot runs inside the msi,it only run frm outside the msi, even in deferred mode.
So i tried a different solution of converting the above vbscript to exe by a tool and den adding it to a CA "execute prog frm dest" and also change the "In Script Option"to "Commit only".(which also run in deferred).
This way i installed the updates successfully through msi.Please let me knw if the my solution is feasible or not as per your experience in packaging.

Thanks,

Fearful of encouraging you to proceed, the issue with your script is that the WI engine doesn't use WSH to process script, but its own internal interpreter (let's call it). Therefore, you cannot use the 'WScript' directive. Note that that does NOT apply to WScript object App IDs. So, changeSet WshShell = WScript.CreateObject("WScript.Shell")toSet WshShell = CreateObject("WScript.Shell")Hopefully that's clear. Also, you are creating two objects for the same AppID, WSHShell and objWSHShell. You only need one.

Why script, anyway? A simplr deferred CA is, as mentioned, the simplest way, if you *must* have an MSI.

Now, moving on to the correct way to proceed, build a package which contains just the additional registry data. Have it search for the presence of the hotfix using file existence and/or its installation data. If it's present, install the package. If it's not, show a message (if not silent) and/or write to the Application event log.

Your deployment system ought to be able to sequence the two appropriately. Alternatively, schedule the package to run until it's successfully installed and have WSUS/Windows Update install the hotfix as intended.

Lastly, please remember that English isn't always the first language of this forum's users. You should thus avoid "text-speak".

Thanks !!! VbScab , I'll definitely try your solution.