This symptom is a bit erratic with variations using manual install or Adobe Customization Wizard. The only way I've gotten Reader X to work realiably in the browser (overwriting Reader 9.4.2) is to uninstall both Acrobat Pro 9 and Reader, reinstall Reader X, Pro. Not good solution for 90 workstations.
This is an area that could stand a little work with in the deployment arena. The problem is compounded by the overall general messiness of the browser plug-in architecture, and how browsers interact with Windows at a system level. In short, it's layer upon layer upon layer upon layer of cruft. And, the easiest way to clean up the cruft is to tear it back to the studs.
Follow the HKEY_CLASSES_ROOT registry keys for .pdf, Adobe.AcroIEToolbar, Adobe.AcroIEToolbarHelper, etc. to see what I mean. Some of them chain, upon chain, upon chain through the registry. At any point if the wires get crossed POOF! it doesn't work.
For example, Adobe.AcroIEToolBar points to AdobeAcroIEToolbar.1, which points to CLSID {47833539-D0C5-4125-9FA8-0819E2EAAC93}, which points to C:\Program Files\Common Files\Adobe\Acrobat\ActiveX\AcroIEFavClient.dll, back to the calling entries as well as off to {04C567CB-A52F-41f4-9628-10CC965E7179} which also points to C:\Program Files\Common Files\Adobe\Acrobat\ActiveX\AcroIEFavClient.dll
It's not necessarily Adobe Engineering's fault. The guy that develops the installer systems is a pretty smart cookie! Much of the decisions made have to do with the environment in which Adobe has to operate within.
Douglas Hanna is a member of the Production Print Technology team at Aon.
www.aonhewitt.com