I also have Reader 8.2.2 installed in a similar way from AIP as you did but I can open PDF populated with FDF.
This is what I am doing-
I have a FDF file. When I open this FDF file(by double clicking) then it downloads a PDF form from a server and populates this PDF with the data present in the FDF.
Finally I see a PDF opened in browser with all required data populated.
What exactly you are doing?
Are you doing something else??
I'm not sure about the inner working of the process because I'm a sysadmin and i'm not the programmer who created the page, but AFAIK it's a ASP.NET that dinamically create this FDF/PDF file, so you open it via Internet Explorer (but it doesnt work with Firefox too). As stated above, if we reinstall 8.2.0 with GPO it works, if we launch manually 8.2.0 MSI and then 8.2.2 MSP it works. The problem seems to be when we create the 8.2.2 MSI starting from 8.2.0 MSI + 8.2.2 MSP. Have you created the MSI in the same way I wrote above?
PS You say "double clicking". Dont u use a web page for FDF generation?
1 person found this helpful
How exactly you are creating the 8.2.2 msi on which you are seeing this problem?
Applying 8.2.2 msp over 8.2.0 is fine but I want to know the exact commands or steps you are using?
Here is how I did it-
Perform administrative installation
1. Copy the Reader 8.2 msi installer to your machine.
2. Create a distribution point (a folder where the installer can install the uncompressed program files).
3. Click Start, click Run, and then enter the following command:
msiexec /a <path of Reader8.2.msi>
4. When you receive a prompt asking where to install the files, browse to the distribution point you created in step 2.
5. Click OK. When the installer finishes, all files will be at the distribution point.
Also Reader820 msi is also present at the distribution point.(This msi is used in step 7 below)
To add patches to the administrative installation:
6. Copy the Reader 8.2.2 msp patch on your machine.
7. Click Start, then click Run, and then type CMD.
At the command prompt, type the following:
msiexec /a <path of msi at distribution point> /p <path of Reader 8.2.2.msp>
After installation is successfull you can copy this folder (distribution point) to any server and create GPO package and
manually also you can install Reader 8.2.2 by running the msi at the distribution point.
We've used the same command:
msiexec.exe /p <adobeMSPfile.msp> /a <AdobeMSIfile.msi> /qb /qb options is used for changing the setup interface the strange thing is that doing with 8.2.1 msp works, while applying 8.2.2 is not ok. I'm wondering if it's something related to computer language (we have italian XP). Both msi and msp are multilanguage but maybe there's something wrong in some italian language library..
I applied the 8.2.2 reader patch to an 8.2.0 ITA Reader AIP created via command mentioned by you (i.e. with the /qb switch) and installed it on my machine.
Could not reproduce the issue you have mentioned and I am able to view FDF files without any problem (they are not blank).
There's something else that's causing this problem. It would be helpful if you could provide the MSI log of the installation.
To enable MSI logging on your system set the registry key:
@vbhv_malik: do you know any public FDF service that can be used to test the feature? I just wanna be sure that it's not related to our web implementation.
PS btw I noticed that the acrord32.exe process is spawned when I try to visit the FDF page, even though the acrobat interface is not showed to the user
Go to this link-
and download the test.fdf.
Open this fdf file.
This will open a PDF hosted on a server and populate the PDF with the data present in this FDF file.
'First Name' field will come populated as 'XYZ' in the PDF.
NOTE: Click 'Allow' button if any security warning dialog pops up.
@deepak: unfortunately rapidshare is filtered on our internet access so I cant test it.
In these days I have discovered that the problem seems to be related to the way the msi is generated: i've compared a separated msi+msp installation and a patched-not-working one and in the latter the file version/dates are incorrect, it seems they're related to 8.2.0 instead of 8.2.2
So, I've followed another MSI preparation guide and this guide separates the "decompression" step and the "patching" step: firstly it explodes the MSI using msiexec.exe /a file.msi targetdir=c:\test and then it patches with another msiexec /p patch.msp execution. Doing this procedure, if I launch the produced MSI it installs and works correctly, the only problem is that the created msi is not a standalone 30-40MB file but it's 4MB and it depends on files that are exploded in that folder.
We've lost enough time on this problem so we are approach the problem from two sides:
1) our develop team has bypassed the problem by changing the way this PDF files are created. They have removed the FDF approach (that is always one of the our main source of problems) and used itextsharp library in order to fill our PDF modules. This works better with other OS and browsers too (i.e. we had problems with FDF on Safari on Mac, now we're ok).
2) for software deployment we use both GPO and wkpg.org, so we're going to prepare a wpkg package that will install adobe after removing it and without using a patched MSI.
btw we have also noticed that both 8.2.2 and 9.3.2 adobe reader seem to be more instable than previous versions: they tend to rest in memory after you close the documents (i think it's by design, maybe it checks for updates?) and sometimes they crashes. So we're stick to 8.2.1
thanks all for your support
You were creating the AIP package in a wrong way.
It's a 2 step process. First you have to create a distribution point and then aply patch to the distribution point.
In my earlier post I have written the exact steps which are required.
Now one question arises, if you are doing something in a wrong way then how come it worked in case of Reader 8.2.1??
Here is the catch-
8.2.1 was a zero day patch which means it would target only specific files.
Only 1 files - Acroform.api is patched by the 8.2.1 patch.
After you created the 8.2.1 package (via the wrong way) then actually this file is not patched and is still the same as it was for 8.2.
So effectively you have all the files of 8.2 version so it works fine as if you have installed Reader 8.2.
But 8.2.2 is a Quaterly update and it patches a lot of files (about 60-70 files).
When you create a 8.2.2 package then some files are now updated to new version 8.2.2 and some are at the old version 8.2.
Because of this mismatch of the files you are facing the problems.
Intrestingly in earlier case (with 8.2.1) also there was the same problem but all the files were at the level of 8.2 so there was no mismatch and hence it worked!
@deepak: that really makes sense.. thank you very much!
this just leaves one opened question: is there a way to repackage the patched distribution point into a standalone 8.2.2 msi file? Or you have to stick to use the full distribution point with small-size patched msi and all the subfolders inside?
You have to use the full distribution point with small-size patched msi and all the subfolders inside. ( Repackaging the patched distribution point into a standalone 8.2.2 msi file is not possible as far as my knowledge is)
You can deploy this Reader 8.2.2 package using GPO.
Detailed steps are mentioned in this doc- http://www.adobe.com/devnet/acrobat/pdfs/gpo_ad_8.pdf
OK. Thank you very much for your help!