How do Application revisions propagate from an SCCM site server to a client

OK, this will be a long post, but there's good stuff here.

First off, the GUIDs for installed software are located in the following locations...

For 32-bit Windows, and 64-bit software on 64-bit Windows:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

For 32-bit software on 64-bit Windows:
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

The problem you are running into is that the GUID string is incorrect. The MSI you downloaded from Adobe is the US English version, hence the 1033 in the 3rd part of the GUID string (1033 is the ANSI code page for US keyboards).

The EXE installer, however, is the MUI version, which has a GUID of {AC76BA86-7AD7-FFFF-7B44-AB0000000001} -- note the FFFF in place of the 1033, which means it's multilanguage.

In your detection method, you need to add an OR clause so it will recognize either GUID as a valid install.

Two gotchas you should also be aware of:

1) You should specify the version number in your detection method. All versions of Reader 11 have the same GUID (i.e. 11.0.1 is the same as 11.0.7) so it will cause your detection method to return a false positive if users are on an older version.

2) If you care about security patches for Reader, then you should know that Adobe releases their patches only for the MUI version. You cannot "upgrade" from, say 11.0.1 to 11.0.7 with their MSIs without doing an uninstall/reinstall of the whole product. If you try, it will just tell you the product is already installed (because the GUID is the same).

Here is the correct way to manage Adobe Reader with SCCM: You need two deployment types in your application.

1) Configure the 11.0.0 MSI just as you already have (make sure the detection method has the version number of 11.0.00 specified -- do not just use the GUID) and save and close it.

2) Go back in and add another deployment type. This time, select Script Installer as the type (SCCM does not handle MSP files natively). Point it to your MSP file and use msiexec /update (instead of the usual msiexec /i) as your command line. For the detection method, use the same GUID, but 11.0.07 (or whatever) as the version. Specify the first deployment type as its dependency. Then make sure the patch has a higher priority in the list. Now save and close it again.

Now, when a client that does not have reader installed requests the application, both will be installed. If the person already has the EXE version installed, it will be patched. If it's already patched, then it will just show as already installed.

I doubt you'll be able to resolve this if this is true "I don't have backend server access to the management points, or the DPs".

Can you access the distmgr.log on the site server? If not, then you will need to escalate the issue to someone who can.

This issue is nothing to do with the client so I would ignore other answers advising to look at the clients. This issue is caused because the Site Server cannot copy the files from your source folder to the distribution point.

If you can't access the Site Server logs, one thing you could try to eliminate it being down to your folder structure being too long is to zip up your package, deploy it, and unzip before installing at the client end.