A free translation of the error message "L'operation d'ajout a échoué. Impossible d'extraire les informations de déploiement à partir du package. Exécutez la validation du package pour vérifier s'il est correct." is 
"The add operation failed. Unable to extract deployment information from the package. Run the package validation to check if it is correct."

Google delivers lots of lots of hits for that message (French and English), for example <http://support.microsoft.com/kb/324886/EN-US>

I only found one OOo Issue "Published Installation with Active Directory Group Policy fails with error message" that might be related, "See Also"!
Also <https://issues.apache.org/ooo/show_bug.cgi?id=97661> might contain information, but I co not know anything about GPO

@choffardet:
What did you try already to solve the problem?
Did that work for you with any other LibO version - for example A master version?

@rainer
i tried to make an installation image (msiexec /a)

the process to create the installation image run fine.

a new msi file is created, with all the files needed to perform the deployment

but when adding the msi file for deployment, the same error occurs

i've run a validation package.

there are thousands of errors and warning.

so i did the same investigation on libo 3.4.5, and there are also thousands of errors and warnings.

most of msi packages show warnings and errors and work fine

i can do any investigation you would like me to do

i've been deploying openoffice, since 1.9beta to openoffice 3.2.1 and libreoffice 3.3 and 3.4

i provide mst file to deploy openoffice and libo for years for other network adminsitrator

http://msicreteil.free.fr/softs/libreoffice.php

>Google delivers lots of lots of hits for that message (French and English), for
>example <http://support.microsoft.com/kb/324886/EN-US>

i saw this page when i tried to solve my problem. this is not the probleme we have. when are not running windows 2000 servers
problem occurs on 2008R2 an 2003 servers

the file showing errors and warning in libo35 is here :
http://dl.dropbox.com/u/23365262/libo35log.txt

the file showing errors and warning en libo345 is here :
http://dl.dropbox.com/u/23365262/libo345log.txt

Du to comment 2

> Du to comment 2 
???

are you talking about this ?

>I only found one OOo Issue "Published Installation with Active Directory Group
>Policy fails with error message" that might be related, "See Also"!
>Also <https://issues.apache.org/ooo/show_bug.cgi?id=97661> might contain
>information, but I co not know anything about GPO


https://issues.apache.org/ooo/show_bug.cgi?id=46041

>However the OOo 2.0 beta installer checks if the user has administrator
>permissions, and if not it will generate an error message:

i've never tried to install libo or openoffice at user level.

if you want i can try to do it to check if the problem is not solved but i guess that the problem occur at the same step

On bug 46041, the problem appears on the machine where oo should be installed 

so it was possible to add oo.msi on the GPO

at the moment, it in impossible to do it

Please provide us with an install log file, see http://www.advancedinstaller.com/user-guide/qa-log.html#automated-logging

Thanks.

bugzilla-daemon@freedesktop.org schrieb:

> are you talking about this ?
>

No, <https://bugs.freedesktop.org/show_activity.cgi?id=45750> "Regression"!

CU

Rainer

(In reply to comment #6)
> Please provide us with an install log file, see
> http://www.advancedinstaller.com/user-guide/qa-log.html#automated-logging
> 
> Thanks.

as a understand the purpose of this, the aim is to trace deployment process on the client machine.

But i can't go so far on the deployment process.
i can't add the soft for deployment, so i can't trace it further

(In reply to comment #7)
> bugzilla-daemon@freedesktop.org schrieb:
> 
> > are you talking about this ?
> >
> 
> No, <https://bugs.freedesktop.org/show_activity.cgi?id=45750> "Regression"!
> 
> CU
> 
> Rainer

sorry but i don't understand your aim here...

my english skill is.... very low

when adding libo 3.4.5 in gpo for deployment
there are over 115 warnings :

http://dl.dropbox.com/u/23365262/libo345warning.jpg

"Software Installation encountered an unexpected error while reading from the MSI file <path to msi file>. The error was not serious enough to justify halting the operation. The following error was encountered: The operation completed successfully."

the deployment process works fine

with libo 3.5 there are only two errors
http://dl.dropbox.com/u/23365262/libo35error.jpg

the process is shown here :
http://www.advancedinstaller.com/user-guide/tutorial-gpo.html

at step 4, i can't go further than :

click on Assigned and then click OK (the package will be added to the right
pane of the "Group Policy" window)

when i click ok, error message occurs nothing is show on the right

Thanks, I got all the info I needed. I also reproduced the error on my English Win2008R2.

Open the MSI in Orca, go to View - Summary information...
From the Languages field delete everything, keep only 1033,1036 (English and French). I assume you need French. :)
Then you can add it to GPO. 

I'll prepare a patch, so we will have only "valid" language codes in Languages field, but I need to find out which languages are invalid.

if you open msi with orca, then click on tools > validate and go

then go to the editor, and you will see all the languages that give you a problem

as i can see 1569, 1610, 32771, 1574,1605, 1606,1579,1603,1580,1154,1553,...

here are some of the languages code :

http://www.eclipse-web.com/us/download/manual/avn726e_fr/avn/contents/_408_60_56.13713.html

No, the problem was not with the language codes. There can be any code in the Languages field, providing that the full length of the string is below 254. I think this limitation is Microsoft's bug, because I can add a longer string there and installer can work with it during normal install.

So this bug cannot be fixed without limiting functionality in other area. For mass deployment via GPO, systems administrators may want to modify the installer anyway, because I doubt that they want to install all languages, all dictionaries etc. As an extra step, they should edit Summary Information - Languages, too.

*** Bug 46171 has been marked as a duplicate of this bug. ***

So this bug is closed ?

I don't install all languages. for this, I build an mst whith the languages I want, the extensions i want and so on.

But, as I can't add the msi file in the gpo, I can't add the mst file too

I think it's very surprising to said : "it's a Microsoft bug, so go away"

it was working well until 3.4.x and it should work again in 3.5.x

(In reply to comment #18)
> So this bug is closed ?

Yes, it is.

> 
> I don't install all languages. for this, I build an mst whith the languages I want, the extensions i want and so on.
> 
> But, as I can't add the msi file in the gpo, I can't add the mst file too
> 
> I think it's very surprising to said : "it's a Microsoft bug, so go away"
> 
> it was working well until 3.4.x and it should work again in 3.5.x

I did not say "go away". I wrote the solution, the workaround, whatever we call it. I write it once again, maybe it was not clear. You mentioned you use Orca.
1. Open the MSI in Orca.
2. Select View - Summary Information from the menu.
3. In Edit Summary Information dialog, go to Languages field.
4. Delete everything, keep only 1033.
5. Press OK.
6. Save MSI.
Now you can add it to GPO. 

3.4 was different. Multi language single MSI is a new feature of 3.5. I did not expect that it will cause problems in corporate environment and I'm sorry that it does. I will continue to improve the quality and usability of the installer, but I don't want to go back to 2 layer installer (NSIS + MSI).

Xavier, these ICE errors and warnings are unrelated to the issue. See the solution in comment #19.

*** Bug 47665 has been marked as a duplicate of this bug. ***

(In reply to comment #19)
> (In reply to comment #18)
> > So this bug is closed ?
> 
> Yes, it is.
> 
> > 
> > I don't install all languages. for this, I build an mst whith the languages I want, the extensions i want and so on.
> > 
> > But, as I can't add the msi file in the gpo, I can't add the mst file too
> > 
> > I think it's very surprising to said : "it's a Microsoft bug, so go away"
> > 
> > it was working well until 3.4.x and it should work again in 3.5.x
> 
> I did not say "go away". I wrote the solution, the workaround, whatever we call
> it. I write it once again, maybe it was not clear. You mentioned you use Orca.
> 1. Open the MSI in Orca.
> 2. Select View - Summary Information from the menu.
> 3. In Edit Summary Information dialog, go to Languages field.
> 4. Delete everything, keep only 1033.
> 5. Press OK.
> 6. Save MSI.
> Now you can add it to GPO. 
> 
> 3.4 was different. Multi language single MSI is a new feature of 3.5. I did not
> expect that it will cause problems in corporate environment and I'm sorry that
> it does. I will continue to improve the quality and usability of the installer,
> but I don't want to go back to 2 layer installer (NSIS + MSI).

I have done this and can now add the msi to the GPO, but the GPO states that the msi language is Arabic and the install fails silently (nothing in the event log). I have pushed other msi's to the same computers without issues in the past. Can you please provide some indication as to what is happening or an English only msi?

(In reply to comment #19)
> I did not say "go away". I wrote the solution, the workaround, whatever we call
> [...]
> 3.4 was different. Multi language single MSI is a new feature of 3.5. I did not
> expect that it will cause problems in corporate environment and I'm sorry that
> it does. I will continue to improve the quality and usability of the installer,
> but I don't want to go back to 2 layer installer (NSIS + MSI).

Just stumbled upon this issue on my 2k3 server, trying to update my install-libo gpo with 3.5.2. The proposed workaround worked fine in my case. 

Now I might sound naive, please excuse my lack of knowledge on the why's and how's here, but seeing that this was closed with a NOTOURBUG state and speaking with utmost respect for the developers here, I would like to ask whether WONTFIX would be better for the purpose: this does seem like a libreoffice issue and definitely is a critical issue for mass/corporate deployments.

Bottomline: perhaps a fix should be prioritized for a future release?

*** Bug 56576 has been marked as a duplicate of this bug. ***

*** Bug 62758 has been marked as a duplicate of this bug. ***

How can this bug resolved? The bug is still not fixed. in 4.x

It is still not fixed, because it was RESOLVED as NOTOURBUG.
Workaround is described in comment 19.

Microsoft officially does not support MUI MSI's. I guess this is part of the reasons. As you are aware of this limitation, why is there no EN only installer or multiple installers every one with it's own setup language or 3 installers e.g. Asia, Europe, US that contains only parts of the translations, but always less than the 256 chars. I guess a custom action may workaround, too. There are really enough known workarounds available nevertheless I fully understand that this limitation suxxx a lot.

As I guess you are finger pointing to Microsoft - have you filed a bug report to them and have they confirmed to fix it in a future version or not?

Since nothing is resolved here, this case need to be kept open until the bugs are really solved or a workaround for the known limitation has been implemented. 

Telling every admin to edit the MSI with Orca is not an acceptable workaround.

@Marc Bauer: You reopened the bug second time. Good luck to find somebody to fix it. I'm out.

Hi there,

> Microsoft officially does not support MUI MSI's. I guess this is part of the 
> reasons.

   That is pretty pathetic on their part; then again I guess they don't have much software with so many languages.

> As you are aware of this limitation, why is there no EN only installer
> or multiple installers every one with it's own setup language or 3 installers 

   Building, signing, and distributing large numbers of binaries instead of a single one, to work around a Microsoft bug that is primarily of interest to system administrators with large installations, who can tweak their MSI files using ORCA anyway - seems a bit sad.

   Nevertheless, the first step here would be to hack on the perl files that generate the MSI installers - sounds like a sysadmin'y sort of thing to do; and git it to spit out three MSIs instead of one. I guess that's possible.

> As I guess you are finger pointing to Microsoft - have you filed a bug
> report to them and have they confirmed to fix it in a future version
> or not?

   Not that I'm aware of - but I'm no expert. Please feel free to file that bug, and link to this issue - that would be a helpful contribution.

> Telling every admin to edit the MSI with Orca is not an acceptable workaround.

   Sure - but telling volunteer developers how they should spend their time is not acceptable either :-) if you want to be part of the solution please do jump in and help. Please bear in mind that we will also need to significantly complicate the download page: trying to detect / pre-select people's regions between three options (for windows only), and so on - but I guess if you want to do that work, we'd be happy to have the bug fixed.

   Failing that - if you want an en-US build, you could deploy:

http://dev-builds.libreoffice.org/daily/libreoffice-4-0/Win-x86@6/current/

    Which is built ~hourly from the stable branch etc. Personally, I'd recommend multiple filings of the MSI issue for each user. Hard-coded 256 character limitations have no place in a modern world of gigabyte memories :-)

Closing it again--RESOLVED NOTOURBUG

The issue in the summary description is simply not true. Work around of comment 16 and comment 19 perfectly acceptable for managed GPO or MSSA based deployment of an edited MSI--or equally the use of MST custom action, or via Administrative install deployment all available for managed deployment.

Andras' work on L10N support of a multi-language installer was needed when it was conceived, and it remains viable for the vast majority of users.

There are other more substantive UI issues with Windows builds in general and other issues with the Windows installer specifically -- ref bug 41884

It would not be rational to revert from multi-language MSI adopted during 3.5 development. Nor is the suggestion of multiple Windows installer builds for regional L10N support a rational suggestion. Either tact definitely at odds with existing cross platform build and distribution mechanisms.

Considering that if, and when, Microsoft fixes the MSI framework this issue goes away. Not worth developer cycles of an enhancement request when reliable and functional work arounds already exist for "enterprise" deployments. 

Suggest ESC formalize a NOTOURBUG - WONTFIX decision.

It looks like nobody answered my main questions.

1. Has the "bug" verified by MS or not? It's a feature from my point of view and if a feature is not available and here - broken - and a developer nevertheless make use of it - it's plain wrong.

2. I know that MUI MSIs are officially NOT supported by MS. We can complain about this, but it don't make the issue better as you are using a functionality that is NOT supported at all. Something that is not supported will never fixed (by itself)! Nor does complaining here tell any MS guy about the missing feature. Therefore your complains end in a black hole here. Nobody from MS will fix it by setting a case to "NOT OUR BUG" as it's not a bug per MS definition, too.

3. If a Foo software is incompatible with Windows and I'm aware of it as the developer of my software, or a binary I compiled for Linux does not run native on windows this will also end with "not our bug" per your definition. This is a joke, isn't it?

To summarize what you guys are saying here is - if a developer of LibreOffice implements code that does not use an official API and is therefore broken makes the software it runs on buggy. Interesting point of view - but all times incorrect.

PS: I'm not for rolling back this MUI installer, but I think this issue MUST be driven to MS and there need an definitive answer from them IF and WHEN they will implement this feature. But not telling them about this issue is not the way how feature requests will be implemented somedays. Don't ask please, I have no contact to them. :-)

TODO: Please provide an English only installer on download page and explain why users should use one or the other. This known issues, including this case here are not discoverable on the libre download page nor via Google. It took me a wasted day to investigate and and just to get to the same result that this case describe. You download website has major usability and SERP issues.

(In reply to comment #33)
> It looks like nobody answered my main questions.
> 
> 1. Has the "bug" verified by MS or not? It's a feature from my point of view
> and if a feature is not available and here - broken - and a developer
> nevertheless make use of it - it's plain wrong.
> 

Who knows? But YOU are welcome try to determine that, and to file an issue if it has not.

> TODO: Please provide an English only installer on download page and explain
> why users should use one or the other. This known issues, including this
> case here are not discoverable on the libre download page nor via Google. It
> took me a wasted day to investigate and and just to get to the same result
> that this case describe. You download website has major usability and SERP
> issues.

Not sure about that, the installation guide is here http://www.libreoffice.org/get-help/installation/windows/ ,otherwise found on the LibrerOffice Website -> Get Help -> Installation tab.

An English only installer--doubtful to happen. But, you are more than welcome to grab the git repo and build one exactly to your requirements.

Or, more simply edit the MSI package in MS Orca to remove all but your target language -- as in Comment 19, it is a very simple work around to a legacy Microsoft imposed limitation.

As this is clearly the bug I just experienced, it should be noted that now a year out, the attempts to bill 4.2 as more "enterprise friendly" seem pretty ridiculous when this is still an issue.  I'm not sure how there can be a debate about using a field in a way Microsoft specifically doesn't support, to create an MSI that doesn't validate (which would seem to conclusively answer the "whose bug is it" part of this), that breaks one of the most primary reasons an enterprise would use an MSI, with an error message that is unrelated to the breakage, and with a workaround that is completely undocumented in LibreOffice's resources outside of a convoluted bug ticket full of arguments.  Doesn't help me much that I can lock down settings across the enterprise if I can't install it across the enterprise without hand-editing a broken MSI each time (since the MSI is so broken it won't even load in GP so that I could apply an MST over it, and don't even get me started on attempting an admin install).

@Helge,

Sorry nothing new in your blog. But you probably should note in it that retaining only the 1033 (en-US) language code, as you suggest, should be modified to match the user's OS local language. Folks with different local language installs will have issues if one of the language codes remaining does not match their system local.

Also, the MS SDK provided ORCA is perfectly functional for making the language code changes to the Summary of the LibreOffice .msi installer so that it can be used with a GPO deployment.

See comment 13 or comment 19 for Andras's take (he is the project lead dev on Windows packaging).

Stuart

If you are using SuperORCA instead of ORCA, the dialogs to be changed are under the Tools dropdown instead.  They are there and the workaround does function with LibreOffice 4.3.2.

*** Bug 106673 has been marked as a duplicate of this bug. ***