haven't tried that exact scenario, but i don't understand why it would treat the uninstall MSI command any differently for that one than the Java ones. interesting.
If you want to modify the .MSI that a particular package uses and DON'T want it to check to see if the checksum matches what it thinks it should be, you might try this:
- Instead of using the Download Content/Import Source option consider duplicating the package (so that your changes to the package you're about to make don't get overridden with the next catalog sync)
- Edit the duplicate package.
- Go to the middle page in the wizard (the one where the top option is to choose whether it is an .EXE, .MSI, or .MSP).
- Choose the option for "i already have the content for the package locally on my network" and then point it to the install file.
- Don't change any of the rules or anything (unless you want to enable some of the PackageBoot options or something)...just Next Next, etc.... and Finish to save it.
That way the rules that check applicabilty, etc... are the same but the file to be installed is different.
Same problem here.
If i duplicate the package i have to create a duplicated package every time, because i have to add the former package as superseeded package.
Do we have to approve the old package for uninstall and the new one for install?
in theory you wouldn't have to duplicate it; you could just modify it and publish it... but you'd just need to know that the modified package will get overwritten next time the catalog sync happens. If you've already published it, it wouldn't affect the already published update; that would still be on the WSUS server as you had published it....but it could be confusing to someone else if they were not aware of the changes you had made before publishing.