As a site admin here @ Stanford, I have two questions with the Adobe Reader/Acrobat update fixlets (e.g - “Adobe Reader 9.3.4 Available - Adobe Reader 9.3.3” ):
The AR update fixlets disable the AR updater and forces the AR client to depend on BigFix for any future updates. Why is this and how do we disable this feature within the fixlet?
Is there any way to keep the same settings for an AR client if the AR update fixlet runs against that AR client? (read: I do not want any AR settings changed - esp. if Adobe Acrobat is used as the default PDF viewer and not AR.)
After doing some further reading, it seems the AdobeUpdaterPrefs.dat needs to be modified to enable the AR client to continue to check for updates (instead of depending on BigFix).
This setting with the .dat file needs to be modified to:
appendfile 1
(instead of 0, which is listed in the action script).
So on that note, why is there a need to disable the updater?
Disabling the automatic updater is a pretty common request, because it saves bandwidth; left to defaults, all instances of Adobe products will be regularly checking the Internet for updates and then downloading them directly from the Internet. By disabling it and relying on BigFix, we can use the fixlet to check for updates and use the relays to download files, which should save at least a little bit of resources. As you note, in some cases it’s possible to disable the updater with a configuration file (which is how we do it in this fixlet, and I believe where ever possible).
I don’t think it’s possible to have the new updater be disabled for Reader and enabled for full Acrobat. If you’d like it to be enabled, I would suggest copying our fixlet and modifying the action line as you suggest in your second post.
heymon - just offering my view here, but generally most companies are trying to standardize on a version of an app and as such, we want to prevent the app from updating itself and introducing a different version into the mix. As Jack pointed out, there is also a bandwidth issue - even if you have plenty of it, you may want to control the usage.
Thanks for the suggestions and the rationales to both of you.
On a more light-hearted note, what’s “standardization” thingy you talk about? That’s hard to come by here at Stanford. (But on a more serious note, I do recognize and understand your standardization concerns. Unfortunately, anything can happen here without us knowing about it.)
As for bandwidth - oh… Stanford’s just a glorified ISP. Fortunately, bandwidth is much less of a concern. Unfortunately, customization takes precedence over standardization when it comes to the various departments here, which is why I had to ask the above questions.
Once again - thanks for the input from both of you.
(But on a more serious note, I do recognize and understand your standardization concerns. Unfortunately, anything can happen here without us knowing about it.)
Fortunately, bandwidth is much less of a concern. Unfortunately, customization takes precedence over standardization when it comes to the various departments here, which is why I had to ask the above questions.