1 of 1 people found this helpful
If the Java Not Approved group has the update package set to Not Approved (Inherited), and the Java Approved group has the update package set to Approved for Install, and some computers in the Java Not Approved group are getting the update anyway, the logical inference is that those computers have been accidentally assigned to both groups.
Pick one of those computers that received the update that should not have, find the computer in the All Computers group of the upstream server, select the computer, click on "Change Group Membership" in the Actions Pane, and observe the actual group(s) configured for that computer.
Also potentially relevant is whether these groups are peer-groups, or parent-child groups, because inheritance of approvals is the default behavior. (e.g. a "Not for approval" group should never be a subgroup of another group where the update would be approved.)
Group approval looked good for the test pc. However, got to thinking about this overnight before your reply and remembered, I had an issue with auto approvals and this update had been initially auto approved (all of them did to be exact, but only Java is one we segregate into Approved/Not Approved based on groups) due to auto approvals set on my WSUS server. So I manually set Java to Not Approved rather than inherited, so far i'm not seeing new instances.
Thanks sir for giving me somethign else to check as well.