Software Deployment

Isn't there an Adobe Customization tool that can do this?

I wish it was. that was the first place i checked, and have even triple checked. But this perticular option there isn't a choice for. You can turn off "Display PDF in Browser" but the option "Display in Read Mode by Default" isn't there.

Using Active Setup will mean that everything is included in the MSI/MST, and not relying on proprietary (Wise) script.

Learn to do it this way and if you change job and don't have Wise (it is the poorer cousin to Installshield and on its way out) then you'll know how to do it the right way - I wouldn't pass QA on your app if it came my way to check/test [:D]

Active Setup will only run once for each user that logs in, the HKLM key is checked and if there isn't a corresponding HKCU key then the action is run (and the HKCU key created), meaning your users can go in and change the setting back and the setting will remain.

Hope that helps,

Dunnpy

Thanks for the advise, I'm defiantly going to look more into active setup. Not sure about Wise going away or not, but were not a big package shop. With the company i work for part of my job is security patching and use wise to wrap our complementary notifications, timers, PSkill, end messages and handle reboot messages. We try to stay away from captures if at all possible and just work with vendor supplied switches. So i don't have to worry about QA at this point :) But again, thanks for the advise and were defiantly going to look more into active setup.

One question. With active setup, when changes are made in a MST, are they removed when the application is uninstalled? or would the uninstall string need to call the MST for uninstalling?

The uninstall of the MSI wouldn't touch the registry keys under HKCU that are created with ActiveSetup running, but as the application has been removed they won't be affecting anything, as that area of the registry won't be referred to.

The uninstall would remove the ActiveSetup key in HKLM to prevent it running for new users.

You could author another Active Setup to go in on uninstall that runs a script to remove the HKCU keys, if you really wanted to, but it shouldn't really be necessary.

Does that make sense?

Dunnpy

Yup. Thanks again!

I've linked the KB article for Adobe Reader X to this thread - see top of page.

There is a note that seems to indicate that the public property DISABLE_BROWSER_INTEGRATION=YES may do it.

Is this the same setting that you're looking for, or is BrowserDisplayInReadMode something different? I've not touched X(10) myself yet, so I don't know for sure.

Thanks,

Dunnpy

yea i tried disabling that. That setting can be changed with the customization wizard. But even with that "Display in Read Mode by Default" is still in effect. they're listed together but are separate options. let me double check that though and i will reply back.

Here's what ive done to work around this. I use SCCM for deployments and Wise to wrap everything into an .exe

I had wise import this key, which is current user so who ever installs it will get the change:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\10.0\AVGeneral]
"bBrowserDisplayInReadMode"=dword:00000000


Then i created this batch file that will enter that key into the default user area of the reg. so any new profile created will get the change:

REG LOAD HKU\TEMP "c:\users\default\NTUSER.DAT"

REG ADD "HKU\TEMP\Software\adobe\Acrobat Reader\10.0\AVGeneral" /v "bBrowserDisplayInReadMode" /t "REG_DWORD" /d "0" /f

REG UNLOAD HKU\TEMP

If there is more then 1 profile on this PC it won't get that setting change, but in our area its not too big of a issue. If deployed with SCCM we can set it to only run with users rights so that person will get it. And when we used OSD to image new PCs it will get created with every new profile.

Eric,

This is a very convoluted method, with flaws as you have already pointed out.

The obvious way to achieve this, in a packaging/MSI context, would be to include the HKCU key in the MST and then use Active Setup (discussed to death on the forums here already) to populate the key for any new, or existing user that logs into the machine by setting it to reapply the user registry keys.

If you have time, I would urge you to do this properly - once you have Active Setup straight in your head you'll find that it will be the solution to a number of scenarios you may come across in packaging.

Thanks,

Dunnpy

OK Ive gone back, active setup has been used in the past. very few times.

For using the MST vs Wise to import the key, i don't see a major advantage putting it in the MST over Wise. Maybe if the techs would use the MST for uninstalling. But Wise is very straight forward and we wrap in the installer with it any way.

Now for the active setup piece. We don't want to enforce the setting, but not have it checked by default. So with active setup wouldn't it re-apply that setting? Again we just want it not defaulting, but its up to the user if they want to check it back or not.