Adobe Reader 7

I have packaged Reader 7 and have it rolled out to 10000+ workstations in the enterprise. I created a transform.
Under Preferences - Internet/Web Browser Options
I have disabled the option for users to display pdf in browser. (grayed out)
I did this because of past issues with them not displaying when in the browser.
Now some bone head develpers are demanding i provide a "quick fix". They say their web app displays pdfs in frames or windows in the browser. Their users machines can have a fix pushed to the via sms.

Any one know the registry key (or other) to:
1) Enable users to change this setting
2) Flip the setting to display in browser.

I have found the registry key which flips the setting for "graying out" view pdf in browser.
(Disables users from being able to change setting)
HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Acrobat Reader\7.0\FeatureLockdown
RED DWORD = bBrowserIntegration The value is 0 when it is disabled using the tuner.
Here are the other keys in this location the tuner uses to disable features.
"bUpdater"=dword:00000000
"bShowEbookMenu"=dword:00000000
"bShowAdsAllow"=dword:00000000
"bEFIPrintMe"=dword:00000000
"bPurchaseAcro"=dword:00000000
"bCreatePDFOnline"=dword:00000000
"bBrowserIntegration"=dword:00000000

I am still looking for a way to flip the setting "check box" enable or disable check for the "Display PDF in Browser".
Why would Adobe not include this as one of the exposed items in the tuner? grrr
Looking for a way to do this....
I have exported my registry with the setting checked and with out.
I have a program "Beyond Compare".
It finds 92 differences. If any one has done this, please post..
I am also going to try to get this info out of Adobe.

see 'Customizing Adobe Reader: Display PDF in Browser' under
http://www.doctordeploy.com/tipps--und--tricks-zu-msi-f6.html

...or read this (but sorry, my english was not perfect)

Customizing Adobe Reader: "Display PDF in Browser"
Troubleshoot problems with "Missing Source" message after selecting "Display PDF in Browser" and malfunctioning of this checkbox in a multi-language environment.
(Instructions for Deployment)

Background
When the "Display PDF in Browser" checkbox is selected, Acrobat Reader performs a remove/reinstall feature operation. If the original source is no longer in the original folder after the checkbox has been ticked, a dialogue box is displayed which enables you to search for the source.

Often, however, the complete source was only to be found at the given path at the time of installation. When software is distributed within a company, this path may indicate a temporary network folder or a temporary local folder. Home users may also see this message if they delete the downloaded source after installing Adobe Acrobat Reader.

A further problem occurs if multiple languages of Adobe Acrobat Reader are installed on the same client. Adobe supports parallel installations of different language versions of the Reader and even provides an option (International) enabling the user to switch between different languages after installing multiple language versions of the Reader. Unfortunately, however, integration here is not through-going. The "Display PDF in Browser" option no longer works if more than one Reader is installed.

Problem workaround:
Problem 1 Ã¢Â€Â“ missing source:
The program tries to access the missing source when the checkbox is deactivated and then reactivated again. This means that a resource which was previously deinstalled is now required again. Windows Installer tries to reinstall the "ReaderBrowserIntegration" feature. This feature contains some files that were deleted when the checkbox was deactivated on the local client.
(In the German version, for example, these are AcroIEHelper.dll, AcroPDF.dll, AcroPDF.DEU, nppdf32.dll and nppdf32.DEU)

One option would be to provide these files at all times in a cached folder so that access to the original MSI file or the cabinet file it refers to would be unnecessary. To do this, change the destination path in the MSI file's component table. In our example, we changed it from ACTIVE_X or BROWSER to BROWSER_PATCH.

and specify in the component table that, in the event of a feature deinstallation, these files should not be deinstalled from this cached directory, by setting the attribute flag to 16 (msidbComponentAttributesPermanent).

The files will now always be available, but they are in the wrong place in a "wrong" directory. To ensure that the features in these files do reach the correct destination folder in the event of an installation, I've configured the respective instructions in the "DuplicateFiles" table. To do this, a new component has to be filled with blank (for example BrowserDummy) content and assigned to the "ReaderBrowserIntegration" feature.

Now, you can use the "DuplicateFiles" table to specify where the file should be copied to. (BrowserPatch1-5) It is the "Component_" column that is of interest. Here it is necessary to declare in which event this copy operation should take place, i.e. when the relevant component is installed.

Now we have a state in which a non-flagged "Display PDF in Browser" can be flagged. However, these files are not deleted when the flag is removed. We therefore have to fill in the "RemoveFile" table. We enter the filename in the "FileName" column (BrowserPatchRemove3-7) and the target directory in "DirProperty". The "Component_" column specifies when the remove operation is to be executed, i.e. always when our new component (BrowserDummy) to which the "ReaderBrowserIntegration" feature belongs, is removed. By placing a "2" in the InstallMode column, we define that the remove operation should take place when the component is removed.

This also shows why it was necessary to create a pseudo-component (BrowserDummy). If we would have referred to the original components (ActiveX-AcroPDF.dll, Browser, etc), then the remove would never work, because these components are flagged as "permanent" in the Component table.

We can also use the "Remove File" table to specify that the temporary directory we created (BROWSER_PATCH - [INSTALLDIR]\BrowserDuplicateFiles) is to be removed when the product is deleted (BrowserPatchRemove1-2). Because the files in this directory are marked as "permanent", a regular remove would not remove them.

The modified setup allows the "Display PDF in Browser" option to be enabled and disabled without the need for access to the original source. It also ensures that the product is removed completely from the system if it is deinstalled, with one small exception. The registry keys associated with the components "ActiveX_AcroIEHelper.dll" and "ActiveX_AcroPDF.dll" are not removed in the event of a complete deinstallation of the product or a "ReaderBrowserIntegration" feature deinstallation. The reason for this lies in the fact that we set the attribute flag for the components "ActiveX_AcroIEHelper.dll" and "ActiveX_AcroPDF.dll" to 16 (msidbComponentÃ‚Â¬AttributesÃ‚Â¬Permanent)

I deliberately didnÃ¢Â€Â™t implement these keys, because out of unexplainable reasons, when these keys are linked with the feature Ã¢Â€ÂœBrowserDummyÃ¢Â€Â (which is created in this routine), the browser integration is no longer fully supported. This would be the last operation that has to be done. Apart from that, I didnÃ¢Â€Â™t use the corrected typelib registration in the ACTIVE_X-Path, because everything seems to work fine even with the registration show to the BrowserDuplicateFiles Directory.

Problem 2 Ã¢Â€Â“ Malfunction in multi-language environments:
To solve the second problem, all you have to do is to carry out the steps already described for each language setup. The important thing is to create a new component GUID for the BrowserDummy components of each language. Only this way can the Windows Installer be made to believe that it is a single component when removing the feature for a language. If the component GUIDs were the same, the Windows Installer would not execute the operations in the "RemoveFile" table because the component would, in fact, also not be removed as it would be in a shared state.

Of course, it is possible to create, with the appropriate tools, a transform file from the changes that would subsequently apply the changes. InstallShield, Wise PackageStudio and also Microsoft Platform SDK contain tools that can produce a MST file by comparing two MSIs.

Now, if you ever have an issue with Acrobat, Java Runtime or Quickime already in Production and you want to disable the auto updates, the desktop or tool bar icons then use Active Setup which is included in Windows XP. I have a link to the text document I created on using this tool on my website below.