6 Replies Latest reply on Oct 6, 2010 2:20 PM by RyanGSteele

    JavaScript not functioning in administrative deployment

    RyanGSteele

      I've created an administrative installation of Adobe Reader 9 as per the instructions here:

       

      http://www.adobe.com/devnet/acrobat/pdfs/gpo_ad_9.pdf

       

      I've applied the patches in the order specified here:

       

      http://kb2.adobe.com/cps/498/cpsid_49880.html

       

      And I've deployed the package using a GPO.

       

      We have a particular PDF form which uses JavaScript to total the numbers entered in the form and display the total at the bottom. When I try to open this PDF with the version of Adobe Reader deployed, the total is not updated. When I open the JavaScript debugger, I get the following errors:

       

      InitializeFormsTrackerJS is not defined

      1:App:Init

      AFDate_FormatEX is not defined

      1:Field:Format

      AFDate_FormatEx is not defined

      1:Field:Format

      AFDate_FormatEx is not defined

      ...

       

      One of my colleagues discovered that the version of JSBytecodewin.bin in the "Program Files\Adobe\Reader 9.0\Reader\Javascripts Folder" in the AIP may be suspect. I replaced that file with the version available from here: http://kb2.adobe.com/cps/853/cpsid_85367.html and redeployed the package. Note that the issue documented there does not apply to me; we are not using a Tier 4 language version of Reader and I did not receive any error message while patching the AIP. However, this appears to have resolved the issue.

      Here is the set of commands I used to create the deployment point (server names changed):

       

       

      msiexec /a "\\server\share\Software\Adobe Reader 9\AdbeRdr930_en_US.msi"


      msiexec /a \\server\deploy\AdobeReader934\adberdr930_en_us.msi /p "\\server\share\Software\Adobe Reader 9\AdbeRdrUpd932_all_incr.msp"


      msiexec /a \\server\deploy\AdobeReader934\adberdr930_en_us.msi /p "\\server\share\Software\Adobe Reader 9\AdbeRdrUpd933_all_incr.msp"


      msiexec /a \\server\deploy\AdobeReader934\adberdr930_en_us.msi /p "\\server\share\Software\Adobe Reader 9\AdbeRdrUpd934_all_incr.msp"

       

       

      I have an MST that accepts the EULA and disables automatic updates, but this issue manifests itself whether or not I apply it.

       

      Can anyone shed any light on what may be happening here? The workaround we've discovered is helpful for now, but I'm hesitant to rely on it for the long term. I suspect this is an issue with the Reader installer.

        • 1. Re: JavaScript not functioning in administrative deployment
          deepak_sisodia Level 2

          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 ?

          • 2. Re: JavaScript not functioning in administrative deployment
            RyanGSteele Level 1

            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.

             

            I'm convinced there is an issue with the 9.3.3 patch which is preventing the JSByteCodeWin.bin file from being updated. I'm surprised that I haven't found any other forum posts about this issue, but the fact that the issue affects only users who work with PDFs containing JavaScript AND had Reader deployed from an AIP might explain that.

            • 3. Re: JavaScript not functioning in administrative deployment
              deepak_sisodia Level 2

              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.

              • 4. Re: JavaScript not functioning in administrative deployment
                RyanGSteele Level 1

                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?

                • 5. Re: JavaScript not functioning in administrative deployment
                  deepak_sisodia Level 2

                  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.

                  • 6. Re: JavaScript not functioning in administrative deployment
                    RyanGSteele Level 1

                    For what it's worth, JavaScript seems to be working fine in the version of Adobe Reader deployed from the latest Quarterly security update (9.4.0), so this is no longer an issue... at least, until the next update...