I suspect my environment is like others... where although you are pushing out the latest Daylight Savings Time compliant version of Sun Java Runtime, you'll have some exceptions where computers have multiple versions of Java because some applications require a specific version in order to run.
Here's my solution, using an SMS Report, TZupdater.jar, and a vbscript
1) Determine all of the possible locations of "java.exe" in the Program Files folder (report.mof in attached Zip file)
2) Next, go grab a copy of tzupdater from sun (http://java.sun.com/javase/downloads/index.jsp). Unzip it so you have tzupdater.jar. Put tzupdater.jar and the vbscript (in the attached ZIP) as the Source, after you modify the vbscript, and advertise the VBscript to your target collection. Note you WILL need to update the strDir() lines to match your reported folders from the report you ran from #1 In the attached sample I just put in a few of the folders I had listed from my report--and your folders may be completely different. Also, if you have more (or less) folders, make sure you update the for i = 0 to whatever to match the number of folders you are looking for.
3) If TZUpdater ran fine, a success code of 0 will be returned to SMS. If it could not update a specific version that you listed, a failure return code of 1 will be returned. To know which version failed to update via TZUpdater, remotely look at that computer's Event Log, Application Log, for a note from WSH
Brief explanation of the vbscript:
-Set the possible directories where java.exe might exist.
-For each folder defined, check to see if that folder exists on this computer. If it does, then run tzupdater.jar using the options provided by the documentation from Sun.
-Once it's done running tzupdater, in my tests (granted, I did not test every version of Java I had in my environment), the file ZoneInfoMappings was updated to one with the date stamp of 2007. I used that as a low-tech way to determine success or failure.