It looks like the JSBytecodewin.bin file didn't get updated when you created the 9.3.4 AIP and that's why after installing from this AIP the same unupdated file was copied on your machine.
When you replaced the file then you have the updated file and that's why the issues got resolved.
Whatever I have said can be confirmed by doing a simple experiment.
1. Download a freeware called MD5 calculator (http://www.bullzip.com/download.php)
2. Install it on the client machine on which you are deploying the Reader .
3. After you have deployed the Reader via GPO, browse to the JSBytecodewin.bin file location--> right click and select MD5 calculator.
(This would give you a MD5 digest value for this file.)
4. Download the same file from http://kb2.adobe.com/cps/853/cpsid_85367.html and find the MD5 value by right clicking
5. Compare the two MD5 values (step 3 Vs step 4)
In your case (where you were getting problems) these values should be coming different.
Can you please confirm this?
When you are deploying the 9.3.4 AIP on your client machine, is there any Acrobat or Reader version already installed on it ?
Hi deepak_sisodia, thanks for your reply.
It is obvious to me that the JSByteCodeWin.bin file didn't get updated when I created the 9.3.4 AIP. I don't need to take an MD5 to demonstrate that -- the files were different sizes. The question is, why didn't it get updated?
The client I deployed to did have a previous version of Adobe Reader: 9.3.3. I had the same issue with JSByteCodeWin.bin when I created the 9.3.3 AIP as I did when I created the 9.3.4 AIP and had to patch it the same way. (I would have just applied the security patch to the 9.3.3 AIP and redeployed, but after the JSByteCodeWin.bin issue I wondered if there was a problem with it, so I thought I might as well start from scratch.) Sorry, I probably should have pointed that out in my first message.
The reason JSByteCodewin.bin is not updated is because you are not installing on a clean machine.
If you deploy the same 9.3.4 or 9.3.3 AIP on a clean machine then you won't see this problem.
Whenever Acrobat or Reader AIP is used for installation then one thing to be ensured is that - No previous version of the same product is installed on the machine.
If you will try to manually install from an AIP on a machine with some existing version installed then installation wouldn't even start and fail straight way.
If you use GPO to deploy the AIP on a machine with some existing version installed then installation would go through successfully but it is very likely that some of the files will not be patched. (This seems to be the case with you!)
Reason: When deploying via GPO the comand which basically runs on the client is-
msiexec /i <msi inside AIP> REINSTALL=ALL REINSTALLMODE=vomus
This command won't give correct results all the time. so avoid using it.
Here is what you should do- (Here I am taking Reader as an example )
NOTE: This method is mainly for enterprise admins. Individual users should avoid using AIP altogether for Acrobat/Reader installations.
1. First of all make sure client machine has no version of Reader installed.
2. Now let's say Reader 9.3 is avaliable.
3. Create Reader 9.3 AIP and deploy via GPO.
4. On client you now have 9.3 Reader installed.
5. Now let's say Reader 9.3.2 patch is avaliable.
6. Create Reader 9.3.2 AIP
7. On your server, go to Group Policy management console and delink the earlier AIP from the OU. Example: Delink the Reader 9.3 AIP
8. Link the newly created Reader 9.3.2 AIP
9. Restart the client
(Step 7 is important!)
Since you have delinked the last deployed AIP, so on client restart first Reader 9.3 would be uninstalled followed by the installation of Reader 9.3.2. So effectively you are installing Reader 9.3.2 from an AIP on a clean machine.
NOTE: To make sure on delinking the uninstallation happens, check the option "Uninstall this application when it falls out of the scope of management. Refer page 6 of http://www.adobe.com/devnet/acrobat/pdfs/gpo_ad_9.pdf
If you are doing any of the below cases then new version would get installed but there is a possibility that some files are not updated. So it's better to avoid these scenarios :
(1) If you don't delink the earlier AIP(Reader 9.3) and link the newly created AIP(Reader 9.3.2) and enforce it, then on client restart Reader 9.3.2 would be installed but there is a possibility that some files are not updated.
(2) If you have installed previous version (Reader 9.3) on your client without using GPO ( like manually installed from an AIP or directly installed from a msi installer) and new version (Reader 9.3.2) you are trying to deploy via GPO.
Hope this helps you.
This doesn't make any sense. The version of JSByteCodeWin.bin in the AIP is the wrong version. How could a client which has been deployed from this AIP end up with the correct version of the file?
Oops! I misunderstood your problem.
I was under the impression that your AIP is correct but when you are installing on your client then you are not getting the updated file and so you are manually replacing it.
Sorry for that..I should have read it more carefully.
Anyway, for hassle free deployment of any future patch you can follow the deployment process described above.
I am also using Reader 9.3.4 AIP but in my case it has the correct version of JSByteCodewin.bin. I am also following the same steps as mentioned in your initial post.It seems you are doing something different which I am not doing.
Can you try recreating 9.3.4 AIP and check if this is consistently happening. In case you are able to replicate this problem again please post the exact steps followed by you.