locked
Error code 2869 with Vista RRS feed

  • Question

  • We have our application Setup program created using Visual Studio 2005 (Setup & Deployment project). Our application setup program runs fine on Windows XP / 2003, however we get the following error message when we try to run the setup program under Vista:

    The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2869.

    According to the Windows Installer documentation, error 2869 means "The dialog [2] has the error style bit set, but is not an error dialog."

    I don't understand what the issue could be here? Do we need to create/build a separate installer for Windows Vista?

     

     

     

    Monday, January 22, 2007 6:42 PM

Answers

  • These are the steps to solve the above mentioned problems:

    1) Copy the .MSI file to the root directory of your main hard drive (i.e. C:\).

    2) Open Windows Notepad.

    3) Copy this text into windows notepad:

    msiexec /i C:\program_name.msi

    (You can write the total path of your .msi file in the system, after msiexec /i.)

    4) Replace the text "program_name" in the code that you copied with the actual name of the    .MSI file .

    5) Click File -> Save As...

    Instead of saving it as a .txt file, change the file name to installer.bat.

    Save the file to your desktop.

    6) On your desktop, right click on the file and select Run as Administrator.

    This will run the .msi file properly to install the application in the system.

    Thanks


    Cheers, Eliza
    • Proposed as answer by mvidev Saturday, February 20, 2010 12:15 AM
    • Marked as answer by Mary Lee - MSFT Monday, June 21, 2010 9:07 PM
    Thursday, February 4, 2010 8:19 AM

All replies

  • This indicates that a dialog in your setup is improperly authored. But it may not the root cause for the failure. I guess your setup is encountering whatever error, and when it tries to display the error message it detects a problem with the error dialog. So I'd suggest you generate a verbose log of the install to find the root cause:

    msiexec.exe /i your.msi /L*v c:\logfile.txt

    And of course: fix the dialog.

    Monday, January 22, 2007 10:38 PM
  • I receive the same message trying to install Guidance Automation Toolkit on Windows Vista. A workaround is to create a shortcut:

    msiexec.exe /i <name of the msi>.msi

    And run this shortcut as an Administrator.

    Thursday, February 1, 2007 6:03 AM
  • The source of problems occur when the installer tries to execute another application under Vista. The new process will not have the required credentials to run and so it might fail if any of its actions requires elevated credentials. For more on this see: Teach Your Apps To Play Nicely With Windows Vista User Account Control (http://msdn.microsoft.com/msdnmag/issues/07/01/UAC/).

    Tuesday, April 10, 2007 10:11 PM
  • Snippet from the article above:

    To specify that a package can only be installed by an administrator into the Public profile, set ALLUSERS="1" or ALLUSERS="2" and set bit 3 of the Word Count Summary property to 0. To specify that a package is a per-user installation that can be installed by a standard user, set ALLUSERS="" or don't define the property, and set bit 3 of the Word Count Summary property to 1.


    We use VisualStudio 2005 to create our installer, and I'm guessing that ALLUSERS = "" can be set by specifying InstallAllUsers=False in the Deployment Project Properties window. However, I don't know how to set bit 3 of the Word Count Summary property to 1. Could someone point me to the correct place where I could set this?


    Another snippet:

    .. these MSI files fail because the CustomActions attempt to do something that requires administrator privileges. Usually this can be fixed by merely adding the msidbCustomActionTypeNoImpersonate attribute to the CustomActions.


    I'm guessing this is an attribute I attach to my CustomActions class, does anyone have a C# sample of what the attribute looks like?

    Thx!


    Wednesday, May 16, 2007 8:58 PM
  • I encountered the same problem a while back and for the most part the only information I could find was to run the installer from a command prompt with administrative priveleges or other work arounds.  In my case, the MSI package needs to be distributed through SMS.  I want a clean and simple solution.  The MSI I have been building is built with Visual Studio 2005.  It doesn't exactly give the option of setting the impersonate settings for CustomActions included in the MSI.  My installer has a managed custom action that was not getting the Administrative priveleges that the rest of the installer is running under.  To fix this I installed a program named ORCA.  Once installed i opened ORCA and used it to open the MSI package.  On the left-hand side a list of editable regions of the MSI are listed.  I navigated to the CustomAction package and located an action with a value of 1025.  There are probably a few different values that this can contain.  using the wonderful MSDN documentation i located a value that turns ont he impersonation feature, 3137.  After changing the 1025 -> 3137 i saved the file, closed ORCA, loaded the MSI on to a vista machine and it installed without any problems.
    Friday, March 28, 2008 4:31 PM
  • I've solved this long time ago in a way that enables it to be added to automated build using some help from the internet (links are shown below). Run this script after creating the MSI file. Save this script to a file called "NoImpersonate.vbs" and invoke it from a command line as this:

    cscript NoImpersonate.vbs MSI-FILE

    Here is the script code:

     

    '' --------------------------------------------------------------------------------------------------------------------------------------------------------------------

    '' From:

    '' http://blogs.msdn.com/mshneer/archive/2007/03/02/windows-installer-fails-on-vista-with-2869-error-code.aspx

    '' http://www.shahine.com/omar/VSTOAddinsAndVista.aspx

    '' http://msdn2.microsoft.com/en-us/library/aa368069.aspx

    '' Since I had the same problems, I combined the 2 scripts, Aaron and Misha proposed to 1.

    '' For those, who are not developers and try to install an existing Msi, just run the script on the msi:

    '' cscript <path to the script> <path to the msi>

    '' Here is the script, most of it is taken from Aarons post of setting the NoImpersonate-Flag:

    '' prepare MSI-Files for use on Vista-Systems

    '' Visual Studio forgot to include 2 things:

    '' 1. Mark Custom Actions as NoImpersonate, otherwise an Security-Error results in Error 2869

    '' 2. User-Exceptions in CustomActions are not shown. Instead a plain Error 2869 without description occurs.

    '' Therefore Error-Message for this case has to be defined.

    '' cscript NoImpersonate.vbs <msi-file>

    '' Performs a post-build fixup of an msi to change all deferred custom actions (CA) to NoImpersonate

     

    Option Explicit

    '' Constant values from Windows Installer

    Const msiOpenDatabaseModeTransact = 1

    Const msiViewModifyInsert = 1

    Const msiViewModifyUpdate = 2

    Const msiViewModifyAssign = 3

    Const msiViewModifyReplace = 4

    Const msiViewModifyDelete = 6

    Const msidbCustomActionTypeInScript = &H00000400

    Const msidbCustomActionTypeNoImpersonate = &H00000800

    Dim databaseFile

    Dim installer : Set installer = Nothing

    Dim database : Set database = Nothing

    Dim sql

    Dim View, Record

    Dim openMode : openMode = msiOpenDatabaseModeTransact

    On Error Resume Next

    Call Main()

    Sub Main()

    If WScript.Arguments.Length <> 1 Then

    Fail("Usage is: cscript " & WScript.ScriptName & " [msi file]")

    End If

    databaseFile = WScript.Arguments(0)

    'WScript.Echo(WScript.ScriptName & ": operating on file '" & databaseFile & "'")

    '' Instantiate Windows Installer object

    Set installer = WScript.CreateObject("WindowsInstaller.Installer") : CheckError

    '' Open the MSI database

    Set database = installer.OpenDatabase(databaseFile, openMode) : CheckError

    Proc1 : CheckError

    'Proc2 : CheckError

    If openMode = msiOpenDatabaseModeTransact Then

    database.Commit

    End If

    WScript.Quit 0

    End Sub

    Sub Proc1()

    '' 1. problem: CustomActions in Vista have to run with NoImpersonate

    sql = "SELECT `Action`, `Type`, `Source`, `Target` FROM `CustomAction`"

    Set View = database.OpenView(sql) : CheckError

    View.Execute : CheckError

    Do

    Set Record = View.Fetch

    If Record Is Nothing Then Exit Do

    'typeVal = Record.IntegerData(2)

    If (Record.IntegerData(2) And msidbCustomActionTypeInScript) <> 0 Then

    'WScript.Echo "Here 1, Type=" & Record.IntegerData(2)

    Record.IntegerData(2) = Record.IntegerData(2) Or msidbCustomActionTypeNoImpersonate

    'WScript.Echo "Here 2, Type=" & Record.IntegerData(2)

    View.Modify msiViewModifyReplace, Record : CheckError

    End If

    Loop

    View.Close

    End Sub

    Sub Proc2()

    '' 2. problem: explicit format User-Errors, otherwise they are not visible in Vista, the User just sees Error 2869

    sql = "INSERT INTO `Error` (`Error`, `Message`) VALUES (1001, 'Error [1]: [2]')"

    Set View = database.OpenView(sql) : CheckError

    WScript.Echo "Here 2"

    View.Execute : CheckError

    WScript.Echo "Here 3"

    View.Close

    End Sub

    Sub CheckError

    Dim message, errRec

    If Err = 0 Then Exit Sub

    message = Err.Source & " " & Hex(Err) & ": " & Err.Description

    If Not installer Is Nothing Then

    Set errRec = installer.LastErrorRecord

    If Not errRec Is Nothing Then message = message & vbLf & errRec.FormatText

    End If

    Fail message

    End Sub

    Sub Fail(message)

    Wscript.Echo message

    Wscript.Quit 2

    End Sub

    '' --------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Friday, March 28, 2008 7:43 PM
  • Visual Studio 2008 Setup Projects generate MSI files that have that "no impersonate" bit already set, so the Orca fix isn't necessary.

     

    Friday, March 28, 2008 7:46 PM
  • I got this error when I try to run the MSI file.  If I start the EXE file (thet in the next fase use the MSI file) i works without any problem.

    I use VS2008
    Thursday, April 17, 2008 10:10 AM
  • Some our customers receiving this error during the installation on Windows XP Professional SP2. MSI runs Custom Actions that uses .Net dll that invokes web service.
     Users are administrators and PC connected to the internet. Any ideas?

    Best regards,
    Michael
    • Proposed as answer by NatureBoiy Monday, January 26, 2009 4:05 PM
    Thursday, January 15, 2009 4:08 PM
  • Try starting a new thread rather than resurrecting this old one.  Describe what kind of setup it is (a web setup or ordinary setup&deployment) and which version of Visual Studio.  Error 2869 is a generic one that unfortunately obscurs the actual error just prior to it. Doing the install with an MSI log may tell you what's going wrong:

    msiexec /i <path to msi> /l*vx <path to some text log file>
    Phil Wilson
    Thursday, January 15, 2009 9:01 PM
  • You are having the same problem as described above. XP Professional has the same user access security turned on by default like Vista, this causes programmes run by users (even if that user is an administrator) to run with less privileges unless the programme has a manifest to elevate its privileges. Unfortunately as far as I know you can not attach manifests to customer actions of MSI files. The MSI , running under administrator, is starting new processes for the custom actions and they start with the lower privileges. Setting the NoImpersonate flag stops the administrator from pretending to be a user with less privileges when starting these new processes.
    Monday, January 26, 2009 4:14 PM
  • Hi, I appologise for starting up this old thread again. Not sure where to post this otherwise. If anyone could point that out the that would be helpfull.

    I'm experiencing the MS Installer 2869 error as explained above in thread on Vista with VS 2005. I've run scrip to set the NoImpersonate bit on the custom action. I am running my setup.msi from the command prompt with admin rights (selected the cmd.exe as run as administrator).

    I have used the .Net Framework 2.0 Configuration tool to set my Runtime Security Policy Machine Code Groups My_Computer_Zone permission set to Everything. In this state the install fails. When the permission is set to Full Trust the install succeeds no problem. I've done this at the recommendation of the MS Self Paced Exam Prep for 70-536.

    Am I right in thinking that when set to Full Trust any CAS statements in my code are completely ignored? The setup project attempts to install an untouched windows forms application. It doesn't do anything but do the default stuff provided by the template.

    I seems as though an end user of an application might install it with at least an Everything permission set, otherwise CAS is ignored.

    Any feedback would be most appreciated.

    Thanks.
    Friday, November 20, 2009 12:04 AM
  • These are the steps to solve the above mentioned problems:

    1) Copy the .MSI file to the root directory of your main hard drive (i.e. C:\).

    2) Open Windows Notepad.

    3) Copy this text into windows notepad:

    msiexec /i C:\program_name.msi

    (You can write the total path of your .msi file in the system, after msiexec /i.)

    4) Replace the text "program_name" in the code that you copied with the actual name of the    .MSI file .

    5) Click File -> Save As...

    Instead of saving it as a .txt file, change the file name to installer.bat.

    Save the file to your desktop.

    6) On your desktop, right click on the file and select Run as Administrator.

    This will run the .msi file properly to install the application in the system.

    Thanks


    Cheers, Eliza
    • Proposed as answer by mvidev Saturday, February 20, 2010 12:15 AM
    • Marked as answer by Mary Lee - MSFT Monday, June 21, 2010 9:07 PM
    Thursday, February 4, 2010 8:19 AM
  •  I found it helpful to adjust our MST Orca-transform file to modify the bit directly. Here is how to do so:

    1.       Open the MSI in Orca.

    2.       Go to the CustomAction table.

    3.       Find all rows that need modification.

    a.       All rows whose Type value has the inscript bit set need modification. To verify:

                                                                   i.      Convert the row’s Type (decimal) value to Hex

                                                                 ii.      And the Hex value with 0x400 (the inscript bit)

                                                               iii.      If result is not 0, then the row needs modification.

    4.       For each of these custom action rows, perform the following steps:

    a.       Convert the row’s Type (decimal) value to Hex

    b.      Or the Hex value with 0x800 (which is the noimpersonate bit)

    c.       Convert the value back to decimal.

    d.      Replace the row’s Type value with the newly calculated decimal value.

    5.       Save the transformed MSI, if desired, or incorporate the above steps into an existing transform file for future re-use.

     

    Saturday, February 20, 2010 12:19 AM
  • These are the steps to solve the above mentioned problems:

    1) Copy the .MSI file to the root directory of your main hard drive (i.e. C:\).

    2) Open Windows Notepad.

    3) Copy this text into windows notepad:

    msiexec /i C:\program_name.msi

    (You can write the total path of your .msi file in the system, after msiexec /i.)

    4) Replace the text "program_name" in the code that you copied with the actual name of the    .MSI file .

    5) Click File -> Save As...

    Instead of saving it as a .txt file, change the file name to installer.bat.

    Save the file to your desktop.

    6) On your desktop, right click on the file and select Run as Administrator.

    This will run the .msi file properly to install the application in the system.

    Thanks


    Cheers, Eliza
    This works. Can be marked as answer.
    -- Thanks Ajith R
    Monday, June 21, 2010 8:57 AM
  • Eliza's comment should NOT be marked as an answer at is doesn't actually resolve the issue with the MSI.
    Wednesday, June 23, 2010 8:22 PM
  • Hi Elizas,

    I tried your solution and it works very well. Thanks for the help here.

    But I had a doubt in my mind, how does running a Bat file as Administrator is different than running the msi file from the command windows which is opened up using "runas /user:Administrator cmd". This command will also open up the command window in admin mode and any application you run from there will be running under administrator.

    Also any Setup program get the privileges because of which it runs under the (logged in ) admin user account. Then how is this behaviour different here?


    Cheers,
    Saurabh | GS Lab
    Thursday, June 24, 2010 1:20 PM
  • In the context of UAC systems and setups generated with Visual Studio 2008:

    In "Everyone" installs the custom actions run as the system account because that's the way they run elevated.

    If you turn on impersonation they run as the installing user, but they do not run elevated, that's just how UAC systems behave.  If you want the impersonated custom actions to run elevated then you must arrange to have the entire MSI install run from an elevated context, either a setup.exe type of program that elevates then runs the MSI, or some other type of elevated context.

    Visual Studio 2005 setups have custom actions that are already impersonated, which is typically why they fail onm UAC systems unless you elevate the entire install.


    Phil Wilson
    Thursday, June 24, 2010 5:45 PM
  • If I use VS 2008 or above will this problem get resolved?

    My Problem is either I use the .Bat file as suggested by Elizas in this thread earlier or use the setup.exe which is available in the output folder of the setup project, it will be slilghtly difficult to redestribute these both file as a single downloadable for my customers.


    Cheers,
    Saurabh | GS Lab
    Friday, June 25, 2010 4:51 AM
  • Thank you very much. It worked for me.
    Saturday, August 28, 2010 10:12 PM
  • I tried your workaround on Windows 7 but I still get the same error.  Is there something I can do to get the install working?
    Thursday, January 6, 2011 3:50 PM
  • Amyea Barvy, thanks your workaround fixed my problem, I set the AllUsers="'To specify that a package can only be installed by an administrator into the Public profile, set ALLUSERS="1" or ALLUSERS="2" and set bit 3 of the Word Count Summary property to 0. To specify that a package is a per-user installation that can be installed by a standard user, set ALLUSERS="" or don't define the property, and set bit 3 of the Word Count Summary property to 1.
    Tuesday, January 11, 2011 2:38 PM
  • Thanks for the help.
    I worked to perfection
    Friday, March 2, 2012 6:34 PM
  • This worked for me, thanks.
    Thursday, February 7, 2019 2:20 AM