Software Deployment

Hi Ian,
quite a task you are trying to do here.
First of all: Wouldn't do it with Wise, because it writes some fancy extra stuff into the package.
But then: What is the logfile telling you?
Is it crashing or are some components missing?
What is your deployment scenario?
IMHO, the only chance, this could work, is with per user GPO install.
Regards, Nick

This *IS* by GP! :)

I have a transform to apply against Adobe's MSI, which is *almost* working.

I've added a gazillion 'Set Property' CAs to ensure that ALLUSERS is set to null and I now have an almost-working per-user install. That is to say, the shortcuts go correctly to the user's profile and the registry junk goes to HKCU. The reason why it's only an almost-working is that I get a 'Serious error' warning when Acrobat.EXE starts.

ProcMon tells me that the EXE's getting 'Access denied' on 'C:\Program Files\Common Files\Adobe\Adobe PCD\cache' which is *most* odd. Why? Because I removed the LockPermissions table from the transform (what on EARTH is Adobe doing with THAT?!?) and have the app root set to our normal permissions. I have re-applied explicit permssions manually, even to teh extent of giving 'Everyone' and 'Domain Users' Full Control (are you getting a measure of my desperation?) Somehow, though, Acrobat.EXE is resetting the permissions to how they would be set by LockPermissions. It can't be using LockPermissions because it doesn't exist in the transform (I'm just double-confirming that by re-running with a log)

Transform is being applied:

MSI (s) (FC:18) [14:04:19:474]: Original transform ==> \\group.net\msiroot\AdobeAcrobatProfessional08.00\AcroPro.mst
MSI (s) (FC:18) [14:04:19:474]: Transform we're running from ==> C:\WINDOWS\Installer\2746c.mst
MSI (s) (FC:18) [14:04:19:474]: Found missing cached transform \\group.net\msiroot\AdobeAcrobatProfessional08.00\AcroPro.mst. Adding it to re-cache list.
MSI (s) (FC:18) [14:04:19:474]: SOFTWARE RESTRICTION POLICY: Verifying transform --> '\\group.net\msiroot\AdobeAcrobatProfessional08.00\AcroPro.mst' against software restriction policy
MSI (s) (FC:18) [14:04:19:489]: Note: 1: 2262 2: DigitalSignature 3: -2147287038
MSI (s) (FC:18) [14:04:19:489]: SOFTWARE RESTRICTION POLICY: \\group.net\msiroot\AdobeAcrobatProfessional08.00\AcroPro.mst is not digitally signed
MSI (s) (FC:18) [14:04:19:505]: SOFTWARE RESTRICTION POLICY: \\group.net\msiroot\AdobeAcrobatProfessional08.00\AcroPro.mst is permitted to run at the 'unrestricted' authorization level.
MSI (s) (FC:18) [14:04:19:520]: Validating transform 'C:\WINDOWS\Installer\2746c.mst' with validation bits 0
MSI (s) (FC:18) [14:04:19:520]: Transform 'C:\WINDOWS\Installer\2746c.mst' is valid.

So, now I'm worried...

I removed Administrators, Power Users, System and Creator Owner from the permissions list and STILL Acrobat.EXE managed to assign Administrators Full Control and Everyone Read access to the Adobe PCD folder.

As an exercise, in spite of being happy that the transform is being applied, I have now removed the LockPermissions from the master MSI (I have a back-up, obviously...) and observe that it has GROWN in size: AcroPro.msi.old = 10,480,128, AcroPro.msi = 10,727,936. That's some cool database technology ya got there, MS...

I will post results in an hour or so when the thing's finished installing on my VM.

I *just* completed a test install with the LockPermissions table removed from the MSI and *STILL* something in the install has set the folder 'C:\Program Files\Common Files\Adobe\Adobe PCD' has Administrators set to FC and Everyone to RO, and the folder 'C:\Program Files\Common Files\Adobe\Adobe PCD\cache' has Administrators set to FC and Everyone to RW. Grrrr!

No, no, NO! Leave my workstation security ALONE!

So, I set that folder to inherit its permissions from above and to propogate those to child folders. Check that all's well....and it is - all permissions are as they were before Adobe waded in.

Next, run Acrobat from the shortcut. Arrrrrrrrrrrrrrrrgggggggggggggghhhhhhhhhhh! It reset those folders BACK to "The One True Adobe Way"!

No, no, NO! Leave my workstation security ALONE! AGAIN!

Helpfully, there is nothing in the Event Log telling me who did that so one has to assume that acrobat.exe (or one of its support DLLs) is responsible. Great.

Now, none of this is a problem for my packaging account but, when I run the self-same install with my user-level test account, Acrobat craps out because it gets 'Access Denied' on the folder 'C:\Program Files\Common Files\Adobe\Adobe PCD\cache'.

What a piece of crap...

Hi Ian,
maybe, you should trace what is actually going on.
Be aware, that you indeed install per user, but behind the scene, a lot of things are installed under the context of the system account. Otherwise the distiller service and other stuff like COM servers would never have the chance to run. So, this change is most likely done by one of this components which run under system.
And hey: Adobe will have their reasons for not giving us a 'per user' option.
Regards, Nick

OK, between then and now, I managed to persuade Adobe's forum register to send me my confirmation email so that I can particpate. Their response to my query (and seemingly every other query concerning 'Serious error' messages from Acro Pro 8...) is to install the 8.1 update.

Great...only 2 days down the tubes...thanks, Adobe, for supplying us with a known dud.

You really couldn't make this stuff up...

I'll report back once I've slipstreamed 8.1