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?