It's interesting you deploy the EXE... and then use a test of tasks to kill the scheduler. How does this compare to deploying the data1.msi and the jre7u7.msi (that you can get from the exe if you run it. you can find it in C:\users\username\appdata\sun\jre7u7 (or whatever the dir name is).... 
 
At any rate... deploying the MSI with these flags seems to have done the trick: 
 
/qn REBOOT=ReallySuppress MOZILLA=1 IEXPLORER=1 JAVAUPDATE=0 AUTOUPDATECHECK=0 SYSTRAY=0 SKIPLICENSE=1 REMOVEEXISTING=1 /l*v C:\temp\java_7u7.log 
 
Is your way more preferred? does it permanently disable updates? 

Hi Ryan, 
 
That is a great question. Trust me, we would rather deploy using the MSI in this case. We chose the EXE method only because the current version of the Installer Library only downloads the installer files (jre1.7.0_07.msi) and couldn't utilize Data1.cab. We recommend users who are able do what you have done and deploy Java with the MSI.  
 
Incidentally The MOZILLA and IEXPLORER properties have been deprecated and are no longer honored after Java 6 Update 20. We (and others) have also noticed the JavaUpdate and AutoUpdateCheck work in some updates but not in others. (it's really annoying). It looks like Java 7 Update 7 installation DOES honor the AutoUpdateCheck property but not the JavaUpdate (I just verified by checking the registry). Look at the Java applet in the Control Panel on one of your targets. If you see the Update tab, then your settings weren't honored. 
 
When another update no longer The registry values to change are HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy\EnableJavaUpdate and EnableJavaUpdateCheck. Value 0 will turn off the update check and 1 will turn it on. In the next version we will be able to verify the 32 and 64 bit OS during the installation and make the appropriate change in the registry (SOFTWARE\JavaSoft... or SOFTWARE\Wow6432Node\JavaSoft...)

Thanks! I know the IEXPLORE and MOZILLA flags are depreciated, but I can't help but leave them in because flags seem to come and go. 
 
I can confirm that the "Update Tab" in the Java Control panel is disabled on all the machines I checked. 
 
 
Great to hear that the next version might handle 32-bit vs 64 bit deployments better. I'd like to have one deployment for other apps I update frequently and have the installer be smart enough to chose the 32 bit or 64 bit version of the app in question. Right now I have a separate Inventory Group that checks if the machine is 32 bit and I run PDQ Deploy on those with my 32 bit package, and then again another Inventory Group for 64 bit machines and another deploy package for 64-bit app. 
 
 

Cool. It's a smart move to keep them in there since you have also observed that "flags seem to come and go". Too true, unfortunately.  
 
I think you will really like the new conditions based on Arch. It makes deployments so much easier. There are more conditionals coming down the pipeline a little later. (OS, Registry, Files, etc.)

I really love the new Arch flags for exactly that reason! Thanks for digging into the registry on checking out the flags-and to Ryan for the REMOVEEXISTING=1 flag.  
 
 
 
Normally I don't bother digging too deep besides disabling updates, because most of my installs are done on new machines, and we had some software that required a specific version of Java (which is equally annoying) but now that isn't the case, and telling the installer to remove the old one at the same time is great!