I will reply to both in one message.
>"The Windows Server Group Policy Objects (GPO) and the Active Directory services infrastructure enables IT to automate one-to-many management of computers."
I take this not as limitation on the installation, but rather as an educational effort, short explanation of what GPO is. Interpreting it as not supporting per-user installations at all is quite a stretch.
If it was not supported, it probably would explicitly say "per-user installations are not supported" - which would be another violation of standards and best practices.
> Why are you trying to use the per user workflow?
I certainly could explain, and I certainly do see lots of benefits in doing that (briefly, I think it makes perfect sense that we enable employees to do things, rather that workstations; including roaming scenario), but I think it's wrong question to begin with. Windows Installer does support per-user installations, and every MSI installation is expected to support it, that's why. It's every administrator's business to decide how exactly they plan their infrastructure, while product vendor's business is to adhere to the existing standards. Microsoft has been giving us this option since Windows 2000, if not before, and it's probably not Adobe's call to decide that we in fact shouldn't have it. It's the same as if somebody built the car that only supported right turns, and then questioned the intentions of someone who wants to make left turn. All cars in the world are supposed to be able to turn both sides, and all MSI's in the world are supposed to be able to install per-machine or per-user.
Microsoft has an article "Windows Installer Best Practices (Windows)" , and if you look there, one of them is "Test packages for both per-user and per-machine installation deployment." Once you are at that page, you may notice that this installation violates bigger part of those practices. For example, one of them is "Fix all validation errors before deploying a new or revised installation package." - and if we run ICE validation of Adobe package, the list of violations will be dozens of pages long.
In fact, "support" of per-user installation is even wrong term. Every vanilla installation does "support" per-user installation by virtue of Windows Installer, without any extra efforts, so that resulting deployment of the product on the workstation does follow best practices, i.e.files and registry keys are created in the right places and with right permissions, etc., taking into account the differences between platforms and systems. One must undertake very special and aggressive efforts to make it impossible - and Adobe developers do undertake them by hacking permissions on the registry keys by custom action (and apparently, permissions on the files as well, by yet another custom action "LockFilePermissions"). Is Adobe Reader really so special product that standard permissions on its executables and reg keys, which are good for thousands of products and Windows itself, are not satisfactory?
> "the user has no permission to write to the keys under his own HKCU". Users write to HKCU whenever they set a preference. The installer also writes to this area.
Right, by default. But this installation has special custom action "LockRegPermissions" which does change default permissions, and after this action runs, the user can't write to these keys anymore. With this custom action commented out in the transform, the errors disappear.
These keys are created under HKCU only when this is per-user installation. If this is per-machine installation, they are created under HKLM - Windows Installer makes that decision, again, following the standards. The developers probably assumed that this will be always under HKLM - same as they assumed that brand icons will always be under %windir%\installer so they hardcoded this path (rather than specified the icon by Installer's standard means). But when the installation is per-user, these keys go under HKCU and icons go under user's appdata, and that's where it becomes broken.
Simply run msiexec /i <adobe-reader-installation.msi> ALLUSERS="" and watch the errors that happen. Note that it wasn't the case in previous versions