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).
[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
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
not tested. Reopening
Lionel - is this still the case? We can just mark as NEW if it is
(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 ;)
@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 ..."?
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.
(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.
(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.)
Ah, thx, I'll try to reproduce ASAP
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.
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
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.
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.
(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.
adding to Windows install tracking bug
Marking as NEW since it is now confirmed
my mistake, misread comment 17, marking as UNCONFIRMED and not blocking 41884 based on it being unconfirmed
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?
(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.
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.
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.
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]