Software Deployment

On the machine(s) which already have Acrobat Reader 7 and on which you wish to make the modification, you could use the following command :

msiexec /i "Adobe Reader 7.0.msi" TRANSFORMS=<Name of your Original Transform> ADDLOCAL=ReaderBrowserIntegration

to revoke the browser integration , use the converse of which is

msiexec /i "Adobe Reader 7.0.msi" TRANSFORMS=<Name of your Original Transform> REMOVE=ReaderBrowserIntegration

[NB: I haven't tested either of these commands myself, but believe they should work]

Regards,

Spartacus

no go sparticus... but thanks.

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.

If you speak german you can follow this link:

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.

Component Directory_
ActiveX_AcroPDFdll.DEU BROWSER_PATCH
ActiveX_AcroIEHelper.dll BROWSER_PATCH
ActiveX_AcroPDF.dll BROWSER_PATCH
Browser_UI_German BROWSER_PATCH
Browser BROWSER_PATCH
Next, we declare this temporary folder by means of the directory table

Directory_ Directory-Parent DefaultDir
BROWSER_PATCH INSTALLDIR BrowserDuplicateFiles

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.


FileKey Component_ File_ DestFolder
BrowserPatch1 ActiveX_AcroPDF.dll AcroPDF.dll ACTIVE_X
BrowserPatch2 ActiveX_AcroIEHelper.dll AcroIEHelper.dll ACTIVE_X
BrowserPatch3 Browser nppdf32.dll BROWSER
BrowserPatch4 ActiveX_AcroPDF.dll_DEU AcroPDF.DEU ACTIVE_X
BrowserPatch5 Browser_UI_German nppdf32.DEU BROWSER

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.


FileKey Component_ FileName DirProperty InstallMode
BrowserPatchRemove1 Reader_Bin_AcroRd32.exe *.* BROPWSER_PATCH 2
BrowserPatchRemove2 Reader_Bin_AcroRd32.exe BROPWSER_PATCH 2
BrowserPatchRemove3 BrowserDummy AcroIEHelper.dll ACTIVE_X 2
BrowserPatchRemove4 BrowserDummy AcroPDF.dll ACTIVE_X 2
BrowserPatchRemove5 BrowserDummy nppdf32.dll BROWSER 2
BrowserPatchRemove6 BrowserDummy nppdf32.DEU BROWSER 2
BrowserPatchRemove7 BrowserDummy AcroPDF.DEU ACTIVE_X 2


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.

Dominik Oberlin

You are all misssing the big picture.

Adobe has a special (and free) edition of InstallShield Tuner for Acrobat 7 on its site which has ALL of the options you are talking about.

Here is the link:

InstallShield Tuner for Acrobat 7

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.

KJ

Wise Packager