Bug 33966 - Windows installer behaves differently when run from user session and from startup script
Summary: Windows installer behaves differently when run from user session and from sta...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: (target:3.6) (target:4.0.0)
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-06 06:33 UTC by Lionel Elie Mamane
Modified: 2015-12-22 01:32 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2011-02-06 06:33:36 UTC
When Microsoft Office (2003) is already installed, by default the installer does not make the Windows system open Microsft Office files (.doc, .xls, ...) with LibreOffice. So far so good.

But that only happens when the installer is run from a user session, even if it is run non-interactively (with msiexec).

But if the installer is run from a computer startup script (typically when being deployed automatically on several desktops in an entreprise), using msiexec, so _not_ from a user session, then by default it makes LibreOffice the default application for Microsoft Office files. That's rather invasive.

It should behave the same in both cases (user session or not).
Comment 1 Björn Michaelsen 2011-12-23 11:42:59 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 2 Florian Reisinger 2012-08-14 13:57:16 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 3 Florian Reisinger 2012-08-14 13:58:38 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 4 Florian Reisinger 2012-08-14 14:03:11 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 5 Florian Reisinger 2012-08-14 14:05:26 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 6 sasha.libreoffice 2012-08-24 06:04:42 UTC
not tested. Reopening
Comment 7 Joel Madero 2013-02-07 17:38:29 UTC
Lionel - is this still the case? We can just mark as NEW if it is
Comment 8 Lionel Elie Mamane 2013-02-07 17:43:59 UTC
(In reply to comment #7)
> Lionel - is this still the case?

I haven't had the occasion to test it on anything more recent than 3.5. I installed LibreOffice on about 15 machines, got the problem, and then never reinstalled it again... Would need a "fresh" install of Windows + Microsoft Office 2003 to test because now on our machines, All users have overriden the system default of "LibreOffice is the default" (which is what this bug complains that LibreOffice unduly preempts from Microsoft Office) with a per-user preference of "Microsoft Office is the default", so the problem is invisible... until we get a new employee ;)
Comment 9 Rainer Bielefeld Retired 2013-03-05 11:44:43 UTC
@Lionel:
Isn't this simply the problem that a server Installation (msiexec /a) always shows all MS documents except .xls with Checkmarks for "Open this document type ..."?
Comment 10 Rainer Bielefeld Retired 2013-03-05 12:04:15 UTC
User session means "from Dos Prompt"? 

My install.log for a very simple server installation done from a batch shows:

Property(S): ApplicationUsers = AllUsers
Property(S): SELECT_WORD = 0
Property(S): SELECT_EXCEL = 0
Property(S): SELECT_POWERPOINT = 0
Property(S): SELECT_VISIO = 0

My batches fro normal installation (mxiexec /i) are "without frills", but of course I can run wiht more parameters.
Comment 11 Lionel Elie Mamane 2013-03-05 12:07:24 UTC
(In reply to comment #9)
> @Lionel:
> Isn't this simply the problem that a server Installation (msiexec /a) always
> shows all MS documents except .xls with Checkmarks for "Open this document
> type ..."?

It could be linked, but note that I don't do a server installation; I do:

 msiexec /norestart /qn /i LibreOffice.msi SELECT_WORD=0 SELECT_EXCEL=0 SELECT_POWERPOINT=0 REGISTER_NO_MSO_TYPES=1 RebootYesNo=No CREATEDESKTOPLINK=0


That is run as the SYSTEM identity, *not* any actual logged in user.
Comment 12 Lionel Elie Mamane 2013-03-05 12:20:54 UTC
(In reply to comment #10)
> User session means "from Dos Prompt"? 

No, user session means "after pressing CTRL-ALT-DELETE and giving a username/password", ultimately launched through the Windows GUI (even if opening a command prompt from the GUI and launching from there). Command prompt = what you call DOS prompt. Everything launched directly/indirectly from the GUI inherits the user session's environment (security and otherwise).

Windows has a mechanism to run scripts automatically at OS Start/Stop (and user session Logon/Logoff), through something called "Group Policy". I use the domain group policy (centrally administered from the domain controller for a group of machines), but using the local policy should (?) give the same results.

Scripts run through this mechanism have no user session active, because... there is no user session (guaranteed to be) open! Security-wise, they run as a special user SYSTEM (that is even more privileged than Administrators by the way), like some core services do. The rest of the environment, I dunno, but I can imagine that e.g. there is no HKCU (HKEY_CURRENT_USER) registry tree there.

So, for example, on way I could imagine this bug happening is if LibreOffice tries to interrogate some registry key in HKCU to detect whether Microsoft Office is installed, then it will not find it. (But that would be buggy in other ways anyway, since if Microsoft Office is *installed* but never *run* by the current user, there will be no trace in HKCU.)
Comment 13 Rainer Bielefeld Retired 2013-03-05 12:39:59 UTC
Ah, thx, I'll try to reproduce ASAP
Comment 14 Lionel Elie Mamane 2013-03-05 12:47:08 UTC
See http://technet.microsoft.com/en-us/library/cc770556.aspx for how to do it through Local Group Policy.

On a domain (network), to do it through Domain Group policy: http://technet.microsoft.com/en-us/library/cc779329(v=ws.10).aspx

Pay attention to test with a fresh user; if the user has one time in the past made a selection for "which program to use by default for what file", it forever and ever overrides the system setting (which is what LibreOffice clobbers) for that user.
Comment 15 Lionel Elie Mamane 2013-03-05 12:49:26 UTC
Also, since my msiexec command-line (and anything that runs through Startup scripts) is completely headless (no UI), it can be useful to enable msiexec logging; add e.g. to the command line:

 /l* c:\libreoffice.msiexec.log
Comment 16 Rainer Bielefeld Retired 2013-03-05 15:01:53 UTC
I'm afraid even a former LibO- "Install for all users" might have influence to the test results. Although that sometimes differs a little from real life, I wonder whether a fresh new (WIN XP) Virtual machine might be the best way to do a first test. Installation of the VM from an ISO is very quick, and so it's easy to do the test again and again without costs.
Comment 17 Timur 2013-03-06 11:53:03 UTC
I'd kindly ask Reporter to confirm if this still happens with 3.6 or 4.0. 
Please confirm whether this is duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=39791.
Comment 18 Lionel Elie Mamane 2013-03-06 13:10:06 UTC
(In reply to comment #17)
> Please confirm whether this is duplicate of
> https://bugs.freedesktop.org/show_bug.cgi?id=39791.

Not a duplicate of bug 39791. The latter is about .doc only (not other filetypes: .docx, .xls, ...), with a normal (default) installation run from a user session.

This bug is about *all* Microsoft Office filetypes, and is specific to the installer being run from a startup script.
Comment 19 V Stuart Foote 2013-03-06 20:20:33 UTC
adding to Windows install tracking bug
Comment 20 Joel Madero 2013-03-06 20:22:33 UTC
Marking as NEW since it is now confirmed
Comment 21 Joel Madero 2013-03-06 20:46:03 UTC
my mistake, misread comment 17, marking as UNCONFIRMED and not blocking 41884 based on it being unconfirmed
Comment 22 V Stuart Foote 2013-03-06 21:07:23 UTC
Lionel,

(In reply to comment #11)
> It could be linked, but note that I don't do a server installation; I do:
> 
>  msiexec /norestart /qn /i LibreOffice.msi SELECT_WORD=0 SELECT_EXCEL=0
> SELECT_POWERPOINT=0 REGISTER_NO_MSO_TYPES=1 RebootYesNo=No
> CREATEDESKTOPLINK=0
> 
> 
> That is run as the SYSTEM identity, *not* any actual logged in user.

Confused about which way to test/confirm this "managed" deployment.

Is the source of your LibreOffice.msi the LibreOffice packaged installer or have you done an /A install to a network share where the resulting LibreOffice.msi becomes source for the scripted run?  Or are you mounting the LibreOffice packaged installer and running it directly from script as above?
Comment 23 Lionel Elie Mamane 2013-03-06 21:25:19 UTC
(In reply to comment #22)
> (In reply to comment #11)
>> It could be linked, but note that I don't do a server installation; I do:
>> 
>>  msiexec /norestart /qn /i LibreOffice.msi SELECT_WORD=0 SELECT_EXCEL=0
>> SELECT_POWERPOINT=0 REGISTER_NO_MSO_TYPES=1 RebootYesNo=No
>> CREATEDESKTOPLINK=0

> Confused about which way to test/confirm this "managed" deployment.

> Is the source of your LibreOffice.msi the LibreOffice packaged installer

The .msi downloaded straight from www.libreoffice.org

> have you done an /A install to a network share where the resulting
> LibreOffice.msi becomes source for the scripted run?

No.

> Or are you mounting the LibreOffice packaged installer
> and running it directly from script as above?

In my scenario, the installer downloaded from the website is placed on a file share (pay attention that the computer identity must have access to that share; giving read-only rights to "All authenticated users" (or "everyone") both at filesystem and share level achieves that). For testing, placing it on local disk should work just as well (make sure SYSTEM identity can access it; usually not a problem, SYSTEM has access to ~everything locally).

the script does:

 msiexec /norestart /qn /i \\serverName\shareName\path\LibreOffice_version.msi  RebootYesNo=No CREATEDESKTOPLINK=0


It is a .vbs script, but I doubt that this makes a difference.
Comment 24 Timur 2013-03-08 08:51:28 UTC
It seems to me that Reporter reported this 2 years ago and hasn't repeated tests now?
According to my current tests with LO 3.6. and 4.0, LO does exactly what told: to take over or not MS extensions by using  REGISTER_NO_MSO_TYPES=1 or REGISTER_ALL_MSO_TYPES=1. 
We are also using scripts. 
So, I recommend this be closed as INVALID for current LO or FIXED for old.
Comment 25 Rainer Bielefeld Retired 2013-03-08 09:17:28 UTC
WFM due to Comment 24 concerning a test with current versions and has not been reproduced for years. And until today we even do not have one single info concerning a Version with what that happened. Although this proves nothing, I believe we would have had some duplicates and CC if that would be a bigger problem

Please feel free to reopen this one if you observe the problem with a current Version (3.6 or later) and can contribute a step by step instruction how the problem can be reproduced reliably.
Comment 26 Robinson Tryon (qubit) 2015-12-22 01:32:44 UTC
Removing comma from Whiteboard (please use a space to delimit values in this field)
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started
[NinjaEdit]