Reader XI slipstreaming

Question

As a rule, we roll out updates for 3rd party apps through Group Policy. I recently rolled out the latest Reader XI by slipstreaming the 11.0.01 and 11.0.02 .msp's to the original .msi. When the package is installed, Reader comes up showing that it is at the 11.0.02 level. However, when you look at the properties of AcroRd32.exe on the client machine, the file version is 11.0.0.379 and is dated 9/23/2012 instead of 11.0.2.0 dated 2/15/2013. What's more confusing is that the slipstreaming process creates a number of other folders in the installation that I'm working with, one of which is a "Program Files" folder, which contains the correct version of the AcroRd32.exe file.
Because the version shows up as 11.0.02 when viewing from within Reader, I assumed everything was OK. But we use something called "Nessus Vulnerability Scanner" to scan our network for various OS and software vulnerabilities, and that 's what caught this. So my question is, is the installed package actually at the 11.0.02 level, or is it really at the 11.0.00 level? Because I've always found the numbering convention somewhat confusing, I've always referred to the Acceptable AIP patch patterns for Windows deployments guidelines to create my install packages. But I've looked pretty extensively and I can't find the same reference for Reader XI yet. So I'm not really sure if maybe I created an "Unacceptable" package. Do these guidelines exist yet for Reader XI? One last note: I also use the Adobe Customization Wizard after slipstreaming to create a customized installation package. I've followed this process successfully going back to Reader 8, so it's not new to me. And I can't recall coming across a similar situation with the previous versions of Reader. Is there some nuance with Reader XI that I need to be aware of? Or is this just normal behaviour that we just haven't noticed before?

Answer 1

The scrollbar appears and works but unfortunately the dialog size is still too big therefore the print button ends up being hidden by the windows taskbar. Could you please make sure that the print dialog size is calculated against the work area (desktop size minus the taskbar, there's a win32 API to get that) rather than the whole desktop to fix the issue?
That would also fix another issue: when the taskbar is sized higher than usual whatever the resolution you have it could still end up covering the print buttons but if you calculate against the work area rather than the desktop area that issue would be fixed as well.
Please don't leave it unfixed because even if the requirements say 1024x768 if you have higher DPI settings or have a taskbar with a non-default size the print button could easily become unreacheable.