https://bugs.documentfoundation.org/show_bug.cgi?id=94193
V Stuart Foote <vstuart.fo...@utsa.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |d.ostrov...@gmx.de, | |je...@softcatala.org Summary|Installer ignores at least |Installer forces AD domain |some options in Custom |users in Administrators |mode, such as changes to |group to run as |the target directory |Administrator, otherwise | |custom actions are | |disallowed during execution | |stage and not completed Severity|normal |enhancement --- Comment #13 from V Stuart Foote <vstuart.fo...@utsa.edu> --- @sebalis, OK, thanks for another round. So comparing the two installs--the first, AD Domain account in Administrators group run from a command window, and the second, run from a command windows "Run as Administrator", have different outcomes regards the MSI transition from UI stage to Execute stage. Public values are being disallowed for the first--even though the logs recognize you as an admin in the UI stage. It shows a EnableUserControl disabled but gets clobbered by a RestrictedUSerControl enabled. At line 5343 we get "MSI (s) (B0:3C) [02:01:39:675]: Running product '{A18CF6D8-7CE1-46F2-85B9-D87B7197B2F6}' with elevated privileges: All apps run elevated." In the latter, "Run as Administrator" at line 5044 we get: MSI (s) (2C:0C) [16:58:54:988]: Product installation will be elevated because user is admin and product is being installed per-machine. MSI (s) (2C:0C) [16:58:54:988]: Running product '{A18CF6D8-7CE1-46F2-85B9-D87B7197B2F6}' with elevated privileges: Product is assigned. And the Execute stage and actions passed to the service assert as expected. So, problem solved... sort of ;-) It is a work around--i.e. "Install from an elevated command prompt". Or one can create and merge the following registry hack which will offer a "Run as Administrator" from the Windows context menu--and accomplishes the same work around. <clip> Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Msi.Package\shell\runas] @="" [HKEY_CLASSES_ROOT\Msi.Package\shell\runas\command] @="msiexec.exe /i \"%1\"" [HKEY_CLASSES_ROOT\Msi.Patch\shell\runas] @="" [HKEY_CLASSES_ROOT\Msi.Patch\shell\runas\command] @="msiexec.exe /p \"%1\"" </clip> Despite work around(s) I continue to see this is a UAC issue with AD managed user account, AD deployed GPO and interaction with the Windows Installer package. Suspect it is a manifestation of our legacy build scripts for Windows installer packages. Yes, we've added support for 64-bit flavors--but we are getting further away from current Windows Installer Single Package Authoring. We have been unable to do peruser installations beyond XP. We've now dropped Windows XP, perhaps we should drop Windows Vista as well and refactor the MSI packaging fully to Installer 5.0 including current ICE validation, and again support peruser as well as permachine installs and I'd hope better handling of UAC for AD "managed" machines and accounts. @Andras, @DavidO, @Jesus how do you see this? I beleive the work around should hold for folks, but going forward, e.g. VS2015 etc. the Windows install packaging may really need some attention. Restoring ability to install peruser alone might justify refactoring. But as the work falls to you--I'm just opining... Stuart =-ref-= http://blogs.msdn.com/b/windows_installer_team/archive/2009/09/02/authoring-a-single-package-for-per-user-or-per-machine-installation-context-in-windows-7.aspx https://msdn.microsoft.com/en-us/library/dd408068%28VS.85%29.aspx -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs