Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-47806

7.0 Windows installer always rollbacks during install

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 7.0.0
    • Neo, 7.0.2
    • installer
    • Untriaged
    • Windows 64-bit
    • 1
    • Unknown
    • Build Team 2021 Sprint 16, Build Team 2021 Sprint 17

    Description

      Summary

      At least, on my machine.

      I've downloaded 7.0 enterprise from the website (https://packages.couchbase.com/releases/7.0.0/couchbase-server-enterprise_7.0.0-windows_amd64.msi).  Installing it starts copying the files, but then hits an error and rollsback.  I tried a machine restart.  I made sure to uninstall the old Couchbase Server first, and then removed the c:\Program Files\Couchbase directory as well.  Neither helped.

      Workaround

      (Via Ming)

      • Right-click cmd.exe and choose "run as administrator"
      • Launch couchbase installer via "call couchbase-server-enterprise_7.0.0-windows_amd64.msi"

      Details

      I followed these directions to enable installer logging.  While I'm not keen on uploading as it's a huge file with seems to contain lots of details of my personal (non-work) machine, I can C&P what seems to be the relevant snippet, which looks to be that something goes wrong with the Python install:

       

      MSI (s) (08:28) [12:19:11:871]: Executing op: CustomActionSchedule(Action=RollbackInstallCbpy,ActionType=1345,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c "rmdir /s /q "C:\Program Files\Couchbase\Server\lib\python\runtime"")
      MSI (s) (08:28) [12:19:11:872]: Executing op: ActionStart(Name=InstallCbpy,Description=Installing Python 3,)
      Action 12:19:11: InstallCbpy. Installing Python 3
      MSI (s) (08:28) [12:19:11:873]: Executing op: CustomActionSchedule(Action=InstallCbpy,ActionType=1025,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\Server\lib\python\runtime")
      MSI (s) (08:28) [12:19:11:894]: Creating MSIHANDLE (85) of type 790536 for thread 21800
      MSI (s) (08:4C) [12:19:11:894]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI313C.tmp, Entrypoint: WixQuietExec64
      MSI (s) (08!A0) [12:19:11:982]: Creating MSIHANDLE (86) of type 790531 for thread 3232
      WixQuietExec64:  Entering WixQuietExec64 in C:\WINDOWS\Installer\MSI313C.tmp, version 3.11.4516.0
      MSI (s) (08!A0) [12:19:11:982]: Closing MSIHANDLE (86) of type 790531 for thread 3232
      MSI (s) (08!A0) [12:19:11:983]: Creating MSIHANDLE (87) of type 790531 for thread 3232
      WixQuietExec64:  "C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\Server\lib\python\runtime"
      MSI (s) (08!A0) [12:19:11:983]: Closing MSIHANDLE (87) of type 790531 for thread 3232
      MSI (s) (08:4C) [12:19:12:205]: Closing MSIHANDLE (85) of type 790536 for thread 21800
      MSI (s) (08:28) [12:19:12:206]: Executing op: ActionStart(Name=FixConfig,,)
      Action 12:19:12: FixConfig. 
      MSI (s) (08:28) [12:19:12:207]: Executing op: CustomActionSchedule(Action=FixConfig,ActionType=3073,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\bin\installer-util.exe" "C:\Program Files\Couchbase\Server\FOO" fixpaths")
      MSI (s) (08:28) [12:19:12:208]: Creating MSIHANDLE (88) of type 790536 for thread 21800
      MSI (s) (08:F0) [12:19:12:208]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI3295.tmp, Entrypoint: WixQuietExec64
      MSI (s) (08:E0) [12:19:12:208]: Generating random cookie.
      MSI (s) (08:E0) [12:19:12:209]: Created Custom Action Server with PID 4380 (0x111C).
      MSI (s) (08:C8) [12:19:12:226]: Running as a service.
      MSI (s) (08:C8) [12:19:12:228]: Hello, I'm your 32bit Elevated Non-remapped custom action server.
      MSI (s) (08!B4) [12:19:12:241]: Creating MSIHANDLE (89) of type 790531 for thread 9140
      WixQuietExec64:  Entering WixQuietExec64 in C:\WINDOWS\Installer\MSI3295.tmp, version 3.11.4516.0
      MSI (s) (08!B4) [12:19:12:242]: Closing MSIHANDLE (89) of type 790531 for thread 9140
      MSI (s) (08!B4) [12:19:12:242]: Creating MSIHANDLE (90) of type 790531 for thread 9140
      WixQuietExec64:  "C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\bin\installer-util.exe" "C:\Program Files\Couchbase\Server\FOO" fixpaths"
      MSI (s) (08!B4) [12:19:12:242]: Closing MSIHANDLE (90) of type 790531 for thread 9140
      MSI (s) (08!B4) [12:19:12:275]: Creating MSIHANDLE (91) of type 790531 for thread 9140
      WixQuietExec64:  C:\Program Files\Couchbase\Server\bin\..\lib\python\runtime\python.exe does not exist!
      MSI (s) (08!B4) [12:19:12:276]: Closing MSIHANDLE (91) of type 790531 for thread 9140
      MSI (s) (08!B4) [12:19:12:277]: Creating MSIHANDLE (92) of type 790531 for thread 9140
      WixQuietExec64:  Error 0x80070001: Command line returned an error.
      MSI (s) (08!B4) [12:19:12:277]: Closing MSIHANDLE (92) of type 790531 for thread 9140
      MSI (s) (08!B4) [12:19:12:277]: Creating MSIHANDLE (93) of type 790531 for thread 9140
      WixQuietExec64:  Error 0x80070001: QuietExec64 Failed
      MSI (s) (08!B4) [12:19:12:278]: Closing MSIHANDLE (93) of type 790531 for thread 9140
      MSI (s) (08!B4) [12:19:12:278]: Creating MSIHANDLE (94) of type 790531 for thread 9140
      WixQuietExec64:  Error 0x80070001: Failed in ExecCommon method
      MSI (s) (08!B4) [12:19:12:278]: Closing MSIHANDLE (94) of type 790531 for thread 9140
      CustomAction FixConfig returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
      MSI (s) (08:F0) [12:19:12:279]: Closing MSIHANDLE (88) of type 790536 for thread 21800
      Action ended 12:19:12: InstallFinalize. Return value 3.
      MSI (s) (08:28) [12:19:12:295]: Note: 1: 2265 2:  3: -2147287035 
      MSI (s) (08:28) [12:19:12:296]: User policy value 'DisableRollback' is 0
      MSI (s) (08:28) [12:19:12:296]: Machine policy value 'DisableRollback' is 0
      MSI (s) (08:28) [12:19:12:297]: Note: 1: 2318 2:  
      MSI (s) (08:28) [12:19:12:301]: Executing op: Header(Signature=1397708873,Version=500,Timestamp=1393123936,LangId=1033,Platform=589824,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
      MSI (s) (08:28) [12:19:12:301]: Executing op: DialogInfo(Type=0,Argument=1033)
      MSI (s) (08:28) [12:19:12:301]: Executing op: DialogInfo(Type=1,Argument=Couchbase Server 7.0.0-5302 Enterprise Edition)
      MSI (s) (08:28) [12:19:12:302]: Executing op: RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back action:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescription=Removing backup files,CleanupTemplate=File: [1])
      Action 12:19:12: Rollback. Rolling back action:
      Rollback: FixConfig
       

      I have some older builds, I've just tried to install

      couchbase-server-enterprise_7.0.0-4907-windows_amd64-unsigned.msi - failed, briefly flashed something about Python before rolling back so likely same issue

      couchbase-server-enterprise_7.0.0-3638-windows_amd64.msi - succeeds

      couchbase-server-enterprise_6.6.0-7862-windows_amd64.msi - succeeds

      I have about 20 7.0 builds downloaded.  It willl take a while but I could binary search through them to narrow down where the possible regression happened.  Let me know.

      I'm on Windows 10.  Please let me know if there's other diagnostic info I can provide.

      Attachments

        Issue Links

          For Gerrit Dashboard: MB-47806
          # Subject Branch Project Status CR V

          Activity

            graham.pople Graham Pople created issue -

            Anecdotal "I've had the same issue". Was not able to install Couchbase Server 7 on my Windows 10 machine.

            matt.carabine Matt Carabine added a comment - Anecdotal "I've had the same issue". Was not able to install Couchbase Server 7 on my Windows 10 machine.
            graham.pople Graham Pople added a comment -

            I found how to disable automatic installer rollback so I have my system in the failed state now.  Trying to emulate what the installer is doing:

            PS C:\Program Files\Couchbase\Server> lib\python\cbpy-installer.exe /NoRegistry=1 /S /D="C:\Program Files\Couchbase\Server\lib\python\runtime"
            PS C:\Program Files\Couchbase\Server> echo $?
            True
            PS C:\Program Files\Couchbase\Server> bin\installer-util.exe "C:\Program Files\Couchbase\Server\FOO" fixpaths
            C:\Program Files\Couchbase\Server\bin\..\lib\python\runtime\python.exe does not exist! 

            The cbpy-installer command returns instantly, suspiciously.

            I tried running it with `lib\python\cbpy-installer.exe /NoRegistry=1 /D="C:\Program Files\Couchbase\Server\lib\python\runtime"` (e.g. without /S flag), and followed all defaults. It wanted to install to C:\Users\graha\cbpy and not expected C:\Program Files\Couchbase\Server\lib\python\runtime, so I let it.  It installed fine.  I tried again, but installing to C:\Program Files\Couchbase\Server\lib\python\runtime.  I needed to run it in a console with elevated privileges, but it did then succeed and I now have that runtime directory.  Rerunning the bin\installer-util.exe line now gets past the "python does not exist!" error (though goes on to fail with an odd "trying to run 16 bit application" dialog error).

            graham.pople Graham Pople added a comment - I found  how to disable automatic installer rollback so I have my system in the failed state now.  Trying to emulate what the installer is doing: PS C:\Program Files\Couchbase\Server> lib\python\cbpy-installer.exe /NoRegistry=1 /S /D="C:\Program Files\Couchbase\Server\lib\python\runtime" PS C:\Program Files\Couchbase\Server> echo $? True PS C:\Program Files\Couchbase\Server> bin\installer-util.exe "C:\Program Files\Couchbase\Server\FOO" fixpaths C:\Program Files\Couchbase\Server\bin\..\lib\python\runtime\python.exe does not exist! The cbpy-installer command returns instantly, suspiciously. I tried running it with `lib\python\cbpy-installer.exe /NoRegistry=1 /D="C:\Program Files\Couchbase\Server\lib\python\runtime"` (e.g. without /S flag), and followed all defaults. It wanted to install to C:\Users\graha\cbpy and not expected C:\Program Files\Couchbase\Server\lib\python\runtime, so I let it.  It installed fine.  I tried again, but installing to C:\Program Files\Couchbase\Server\lib\python\runtime.  I needed to run it in a console with elevated privileges, but it did then succeed and I now have that runtime directory.  Rerunning the bin\installer-util.exe line now gets past the "python does not exist!" error (though goes on to fail with an odd "trying to run 16 bit application" dialog error).
            graham.pople Graham Pople added a comment -

            Reran installer for 7.0.0-3638, which works, to see if it was doing anything differently around the Python install area.  AFAICT, no - at least the cbpy-installer.exe line is identical (except I'm installing to a different location):

            MSI (s) (E8:BC) [13:29:44:605]: Executing op: ActionStart(Name=InstallCbpy,Description=Installing Python 3,)
            Action 13:29:44: InstallCbpy. Installing Python 3
            MSI (s) (E8:BC) [13:29:44:606]: Executing op: CustomActionSchedule(Action=InstallCbpy,ActionType=3073,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\7.0.0-3638\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\7.0.0-3638\Server\lib\python\runtime")
            MSI (s) (E8:BC) [13:29:44:607]: Creating MSIHANDLE (11) of type 790536 for thread 16060
            MSI (s) (E8:B0) [13:29:44:607]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSIC74C.tmp, Entrypoint: WixQuietExec64
            MSI (s) (E8:44) [13:29:44:607]: Generating random cookie.
            MSI (s) (E8:44) [13:29:44:608]: Created Custom Action Server with PID 7668 (0x1DF4).
            MSI (s) (E8:1C) [13:29:44:625]: Running as a service.
            MSI (s) (E8:1C) [13:29:44:626]: Hello, I'm your 32bit Elevated Non-remapped custom action server.
            MSI (s) (E8!38) [13:29:44:640]: Creating MSIHANDLE (12) of type 790531 for thread 9528
            WixQuietExec64:  Entering WixQuietExec64 in C:\WINDOWS\Installer\MSIC74C.tmp, version 3.11.4516.0
            MSI (s) (E8!38) [13:29:44:641]: Closing MSIHANDLE (12) of type 790531 for thread 9528
            MSI (s) (E8!38) [13:29:44:641]: Creating MSIHANDLE (13) of type 790531 for thread 9528
            WixQuietExec64:  "C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\7.0.0-3638\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\7.0.0-3638\Server\lib\python\runtime"
            MSI (s) (E8!38) [13:29:44:641]: Closing MSIHANDLE (13) of type 790531 for thread 9528
            MSI (s) (E8:B0) [13:29:59:544]: Closing MSIHANDLE (11) of type 790536 for thread 16060
            MSI (s) (E8:BC) [13:29:59:544]: Executing op: ActionStart(Name=FixConfig,,)
            Action 13:29:59: FixConfig. 
            MSI (s) (E8:BC) [13:29:59:545]: Executing op: CustomActionSchedule(Action=FixConfig,ActionType=3073,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\7.0.0-3638\Server\bin\installer-util.exe" "C:\Program Files\Couchbase\7.0.0-3638\Server\FOO" fixpaths")
            MSI (s) (E8:BC) [13:29:59:546]: Creating MSIHANDLE (14) of type 790536 for thread 16060

            graham.pople Graham Pople added a comment - Reran installer for 7.0.0-3638, which works, to see if it was doing anything differently around the Python install area.  AFAICT, no - at least the cbpy-installer.exe line is identical (except I'm installing to a different location): MSI (s) (E8:BC) [13:29:44:605]: Executing op: ActionStart(Name=InstallCbpy,Description=Installing Python 3,) Action 13:29:44: InstallCbpy. Installing Python 3 MSI (s) (E8:BC) [13:29:44:606]: Executing op: CustomActionSchedule(Action=InstallCbpy,ActionType=3073,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\7.0.0-3638\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\7.0.0-3638\Server\lib\python\runtime") MSI (s) (E8:BC) [13:29:44:607]: Creating MSIHANDLE (11) of type 790536 for thread 16060 MSI (s) (E8:B0) [13:29:44:607]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSIC74C.tmp, Entrypoint: WixQuietExec64 MSI (s) (E8:44) [13:29:44:607]: Generating random cookie. MSI (s) (E8:44) [13:29:44:608]: Created Custom Action Server with PID 7668 (0x1DF4). MSI (s) (E8:1C) [13:29:44:625]: Running as a service. MSI (s) (E8:1C) [13:29:44:626]: Hello, I'm your 32bit Elevated Non-remapped custom action server. MSI (s) (E8!38) [13:29:44:640]: Creating MSIHANDLE (12) of type 790531 for thread 9528 WixQuietExec64: Entering WixQuietExec64 in C:\WINDOWS\Installer\MSIC74C.tmp, version 3.11.4516.0 MSI (s) (E8!38) [13:29:44:641]: Closing MSIHANDLE (12) of type 790531 for thread 9528 MSI (s) (E8!38) [13:29:44:641]: Creating MSIHANDLE (13) of type 790531 for thread 9528 WixQuietExec64: "C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\7.0.0-3638\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\7.0.0-3638\Server\lib\python\runtime" MSI (s) (E8!38) [13:29:44:641]: Closing MSIHANDLE (13) of type 790531 for thread 9528 MSI (s) (E8:B0) [13:29:59:544]: Closing MSIHANDLE (11) of type 790536 for thread 16060 MSI (s) (E8:BC) [13:29:59:544]: Executing op: ActionStart(Name=FixConfig,,) Action 13:29:59: FixConfig. MSI (s) (E8:BC) [13:29:59:545]: Executing op: CustomActionSchedule(Action=FixConfig,ActionType=3073,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\7.0.0-3638\Server\bin\installer-util.exe" "C:\Program Files\Couchbase\7.0.0-3638\Server\FOO" fixpaths") MSI (s) (E8:BC) [13:29:59:546]: Creating MSIHANDLE (14) of type 790536 for thread 16060
            ming.ho Ming Ho added a comment -

            is this on a 64bit OS?

            do you have any antivirus program running?  can you try stopping it?  I wonder if antivirus interfere with installer in any way.

            ming.ho Ming Ho added a comment - is this on a 64bit OS? do you have any antivirus program running?  can you try stopping it?  I wonder if antivirus interfere with installer in any way.
            raju Raju Suravarjjala made changes -
            Field Original Value New Value
            Affects Version/s 7.0.0 [ 17233 ]
            raju Raju Suravarjjala made changes -
            Fix Version/s 7.0.2 [ 18012 ]
            graham.pople Graham Pople added a comment -

            Ming Ho yes 64 bit, and no antivirus running.

            graham.pople Graham Pople added a comment - Ming Ho  yes 64 bit, and no antivirus running.
            ming.ho Ming Ho added a comment -

            cbpy-installer.exe is unable to write to "c:\program files" since it is not a "trustedinstaller".  I wonder if it can be signed to avoid this issue. 

            In order to overcome this as a workaround though, owner and permission of "C:\Program Files" need to be changed.  I was able to install by doing these:

            you might need to do this first:

            1. In Control Panel -> User Accounts, click "Change User Account Control Settings"
            2. Change setting to "Never Notify"
            3. Reboot

             

            1. Right click on Program Files -> Properties -> Security Tab
            2. Click Advanced -> Edit "Owner"
            3. Search for "Administrators", add it as the owner for the folder and subcontainers
            4. Click OK on all boxes to close everything
            5. R-Click on Program Files -> Properties -> Security Tab again
            6. Click Advanced -> Change Permission
            7. Select Administrators and give full control access to This Folder, Subfolder & Files
            8. Click OK -> Apply
            ming.ho Ming Ho added a comment - cbpy-installer.exe is unable to write to "c:\program files" since it is not a "trustedinstaller".  I wonder if it can be signed to avoid this issue.  In order to overcome this as a workaround though, owner and permission of "C:\Program Files" need to be changed.  I was able to install by doing these: you might need to do this first: In Control Panel -> User Accounts, click "Change User Account Control Settings" Change setting to "Never Notify" Reboot   Right click on Program Files -> Properties -> Security Tab Click Advanced -> Edit "Owner" Search for "Administrators", add it as the owner for the folder and subcontainers Click OK on all boxes to close everything R-Click on Program Files -> Properties -> Security Tab again Click Advanced -> Change Permission Select Administrators and give full control access to This Folder, Subfolder & Files Click OK -> Apply
            graham.pople Graham Pople added a comment -

            Ming Ho thanks for looking into this, and I'm glad the root cause is known now.  I'm not personally blocked by this - I generally use Docker, I just found this in passing while exploring MB-47771 - and don't want to un-sandbox my Program Files directory for security, so I'll skip the suggested workaround.

            graham.pople Graham Pople added a comment - Ming Ho  thanks for looking into this, and I'm glad the root cause is known now.  I'm not personally blocked by this - I generally use Docker, I just found this in passing while exploring MB-47771 - and don't want to un-sandbox my Program Files directory for security, so I'll skip the suggested workaround.
            ceej Chris Hillery made changes -
            Assignee Couchbase Build Team [ build-team ] Chris Hillery [ ceej ]

            Thanks for all the diagnostics, Ming Ho and Graham Pople. So my best guess is that there's some permission bit somewhere that prevents an installer from launching a different installer, possibly specifically launching an un-codesigned installer. There's a few avenues I could take to verify this which I will see about working on.

            It's certainly peculiar that this DID work in long-ago builds. We have made some changes in how cbpy-installer gets constructed, and possibly there were even some upstream changes in the way the base Anaconda installer works. At the moment I'm not aware of anything we could "undo" to restore working behaviour, though.

            Random aside Graham Pople: It's expected, albeit annoying, that running cbpy-installer.exe /S will return instantly. That's just some weird fact about how silent installers work. You can instead run start /wait cbpy-installer.exe /S ..... to have the comment prompt wait for the installation to actually complete.

            ceej Chris Hillery added a comment - Thanks for all the diagnostics, Ming Ho  and Graham Pople . So my best guess is that there's some permission bit somewhere that prevents an installer from launching a different installer, possibly specifically launching an un-codesigned installer. There's a few avenues I could take to verify this which I will see about working on. It's certainly peculiar that this DID work in long-ago builds. We have made some changes in how cbpy-installer gets constructed, and possibly there were even some upstream changes in the way the base Anaconda installer works. At the moment I'm not aware of anything we could "undo" to restore working behaviour, though. Random aside Graham Pople : It's expected, albeit annoying, that running cbpy-installer.exe /S will return instantly. That's just some weird fact about how silent installers work. You can instead run start /wait cbpy-installer.exe /S ..... to have the comment prompt wait for the installation to actually complete.
            ming.ho Ming Ho added a comment -

            A much less intrusive workaround:

            1. right-click cmd.exe and choose "run as administrator"
            2. launch couchbase installer via "call couchbase-server-enterprise_7.0.0-windows_amd64.msi"

            don't need to mess with permissions at all.  

            ming.ho Ming Ho added a comment - A much less intrusive workaround: right-click cmd.exe and choose "run as administrator" launch couchbase installer via "call couchbase-server-enterprise_7.0.0-windows_amd64.msi" don't need to mess with permissions at all.  
            ceej Chris Hillery made changes -
            Sprint Build Team 2021 Sprint 16 [ 1704 ]
            ceej Chris Hillery made changes -
            Rank Ranked lower
            ceej Chris Hillery made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            ceej Chris Hillery made changes -
            Remote Link This issue links to "Page (Couchbase, Inc. Wiki)" [ 22853 ]
            drigby Dave Rigby made changes -
            Description At least, on my machine.

            I've downloaded 7.0 enterprise from the website (https://packages.couchbase.com/releases/7.0.0/couchbase-server-enterprise_7.0.0-windows_amd64.msi).  Installing it starts copying the files, but then hits an error and rollsback.  I tried a machine restart.  I made sure to uninstall the old Couchbase Server first, and then removed the c:\Program Files\Couchbase directory as well.  Neither helped.

            I followed [these directions|https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/enable-windows-installer-logging] to enable installer logging.  While I'm not keen on uploading as it's a huge file with seems to contain lots of details of my personal (non-work) machine, I can C&P what seems to be the relevant snippet, which looks to be that something goes wrong with the Python install:

             
            {noformat}
            MSI (s) (08:28) [12:19:11:871]: Executing op: CustomActionSchedule(Action=RollbackInstallCbpy,ActionType=1345,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c "rmdir /s /q "C:\Program Files\Couchbase\Server\lib\python\runtime"")
            MSI (s) (08:28) [12:19:11:872]: Executing op: ActionStart(Name=InstallCbpy,Description=Installing Python 3,)
            Action 12:19:11: InstallCbpy. Installing Python 3
            MSI (s) (08:28) [12:19:11:873]: Executing op: CustomActionSchedule(Action=InstallCbpy,ActionType=1025,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\Server\lib\python\runtime")
            MSI (s) (08:28) [12:19:11:894]: Creating MSIHANDLE (85) of type 790536 for thread 21800
            MSI (s) (08:4C) [12:19:11:894]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI313C.tmp, Entrypoint: WixQuietExec64
            MSI (s) (08!A0) [12:19:11:982]: Creating MSIHANDLE (86) of type 790531 for thread 3232
            WixQuietExec64: Entering WixQuietExec64 in C:\WINDOWS\Installer\MSI313C.tmp, version 3.11.4516.0
            MSI (s) (08!A0) [12:19:11:982]: Closing MSIHANDLE (86) of type 790531 for thread 3232
            MSI (s) (08!A0) [12:19:11:983]: Creating MSIHANDLE (87) of type 790531 for thread 3232
            WixQuietExec64: "C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\Server\lib\python\runtime"
            MSI (s) (08!A0) [12:19:11:983]: Closing MSIHANDLE (87) of type 790531 for thread 3232
            MSI (s) (08:4C) [12:19:12:205]: Closing MSIHANDLE (85) of type 790536 for thread 21800
            MSI (s) (08:28) [12:19:12:206]: Executing op: ActionStart(Name=FixConfig,,)
            Action 12:19:12: FixConfig.
            MSI (s) (08:28) [12:19:12:207]: Executing op: CustomActionSchedule(Action=FixConfig,ActionType=3073,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\bin\installer-util.exe" "C:\Program Files\Couchbase\Server\FOO" fixpaths")
            MSI (s) (08:28) [12:19:12:208]: Creating MSIHANDLE (88) of type 790536 for thread 21800
            MSI (s) (08:F0) [12:19:12:208]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI3295.tmp, Entrypoint: WixQuietExec64
            MSI (s) (08:E0) [12:19:12:208]: Generating random cookie.
            MSI (s) (08:E0) [12:19:12:209]: Created Custom Action Server with PID 4380 (0x111C).
            MSI (s) (08:C8) [12:19:12:226]: Running as a service.
            MSI (s) (08:C8) [12:19:12:228]: Hello, I'm your 32bit Elevated Non-remapped custom action server.
            MSI (s) (08!B4) [12:19:12:241]: Creating MSIHANDLE (89) of type 790531 for thread 9140
            WixQuietExec64: Entering WixQuietExec64 in C:\WINDOWS\Installer\MSI3295.tmp, version 3.11.4516.0
            MSI (s) (08!B4) [12:19:12:242]: Closing MSIHANDLE (89) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:242]: Creating MSIHANDLE (90) of type 790531 for thread 9140
            WixQuietExec64: "C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\bin\installer-util.exe" "C:\Program Files\Couchbase\Server\FOO" fixpaths"
            MSI (s) (08!B4) [12:19:12:242]: Closing MSIHANDLE (90) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:275]: Creating MSIHANDLE (91) of type 790531 for thread 9140
            WixQuietExec64: C:\Program Files\Couchbase\Server\bin\..\lib\python\runtime\python.exe does not exist!
            MSI (s) (08!B4) [12:19:12:276]: Closing MSIHANDLE (91) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:277]: Creating MSIHANDLE (92) of type 790531 for thread 9140
            WixQuietExec64: Error 0x80070001: Command line returned an error.
            MSI (s) (08!B4) [12:19:12:277]: Closing MSIHANDLE (92) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:277]: Creating MSIHANDLE (93) of type 790531 for thread 9140
            WixQuietExec64: Error 0x80070001: QuietExec64 Failed
            MSI (s) (08!B4) [12:19:12:278]: Closing MSIHANDLE (93) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:278]: Creating MSIHANDLE (94) of type 790531 for thread 9140
            WixQuietExec64: Error 0x80070001: Failed in ExecCommon method
            MSI (s) (08!B4) [12:19:12:278]: Closing MSIHANDLE (94) of type 790531 for thread 9140
            CustomAction FixConfig returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
            MSI (s) (08:F0) [12:19:12:279]: Closing MSIHANDLE (88) of type 790536 for thread 21800
            Action ended 12:19:12: InstallFinalize. Return value 3.
            MSI (s) (08:28) [12:19:12:295]: Note: 1: 2265 2: 3: -2147287035
            MSI (s) (08:28) [12:19:12:296]: User policy value 'DisableRollback' is 0
            MSI (s) (08:28) [12:19:12:296]: Machine policy value 'DisableRollback' is 0
            MSI (s) (08:28) [12:19:12:297]: Note: 1: 2318 2:
            MSI (s) (08:28) [12:19:12:301]: Executing op: Header(Signature=1397708873,Version=500,Timestamp=1393123936,LangId=1033,Platform=589824,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
            MSI (s) (08:28) [12:19:12:301]: Executing op: DialogInfo(Type=0,Argument=1033)
            MSI (s) (08:28) [12:19:12:301]: Executing op: DialogInfo(Type=1,Argument=Couchbase Server 7.0.0-5302 Enterprise Edition)
            MSI (s) (08:28) [12:19:12:302]: Executing op: RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back action:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescription=Removing backup files,CleanupTemplate=File: [1])
            Action 12:19:12: Rollback. Rolling back action:
            Rollback: FixConfig
             {noformat}
            I have some older builds, I've just tried to install

            couchbase-server-enterprise_7.0.0-4907-windows_amd64-unsigned.msi - failed, briefly flashed something about Python before rolling back so likely same issue

            couchbase-server-enterprise_7.0.0-3638-windows_amd64.msi - succeeds

            couchbase-server-enterprise_6.6.0-7862-windows_amd64.msi - succeeds

            I have about 20 7.0 builds downloaded.  It willl take a while but I could binary search through them to narrow down where the possible regression happened.  Let me know.

            I'm on Windows 10.  Please let me know if there's other diagnostic info I can provide.
            At least, on my machine.

            I've downloaded 7.0 enterprise from the website (https://packages.couchbase.com/releases/7.0.0/couchbase-server-enterprise_7.0.0-windows_amd64.msi).  Installing it starts copying the files, but then hits an error and rollsback.  I tried a machine restart.  I made sure to uninstall the old Couchbase Server first, and then removed the c:\Program Files\Couchbase directory as well.  Neither helped.

            I followed [these directions|https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/enable-windows-installer-logging] to enable installer logging.  While I'm not keen on uploading as it's a huge file with seems to contain lots of details of my personal (non-work) machine, I can C&P what seems to be the relevant snippet, which looks to be that something goes wrong with the Python install:

             
            {noformat}
            MSI (s) (08:28) [12:19:11:871]: Executing op: CustomActionSchedule(Action=RollbackInstallCbpy,ActionType=1345,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c "rmdir /s /q "C:\Program Files\Couchbase\Server\lib\python\runtime"")
            MSI (s) (08:28) [12:19:11:872]: Executing op: ActionStart(Name=InstallCbpy,Description=Installing Python 3,)
            Action 12:19:11: InstallCbpy. Installing Python 3
            MSI (s) (08:28) [12:19:11:873]: Executing op: CustomActionSchedule(Action=InstallCbpy,ActionType=1025,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\Server\lib\python\runtime")
            MSI (s) (08:28) [12:19:11:894]: Creating MSIHANDLE (85) of type 790536 for thread 21800
            MSI (s) (08:4C) [12:19:11:894]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI313C.tmp, Entrypoint: WixQuietExec64
            MSI (s) (08!A0) [12:19:11:982]: Creating MSIHANDLE (86) of type 790531 for thread 3232
            WixQuietExec64: Entering WixQuietExec64 in C:\WINDOWS\Installer\MSI313C.tmp, version 3.11.4516.0
            MSI (s) (08!A0) [12:19:11:982]: Closing MSIHANDLE (86) of type 790531 for thread 3232
            MSI (s) (08!A0) [12:19:11:983]: Creating MSIHANDLE (87) of type 790531 for thread 3232
            WixQuietExec64: "C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\Server\lib\python\runtime"
            MSI (s) (08!A0) [12:19:11:983]: Closing MSIHANDLE (87) of type 790531 for thread 3232
            MSI (s) (08:4C) [12:19:12:205]: Closing MSIHANDLE (85) of type 790536 for thread 21800
            MSI (s) (08:28) [12:19:12:206]: Executing op: ActionStart(Name=FixConfig,,)
            Action 12:19:12: FixConfig.
            MSI (s) (08:28) [12:19:12:207]: Executing op: CustomActionSchedule(Action=FixConfig,ActionType=3073,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\bin\installer-util.exe" "C:\Program Files\Couchbase\Server\FOO" fixpaths")
            MSI (s) (08:28) [12:19:12:208]: Creating MSIHANDLE (88) of type 790536 for thread 21800
            MSI (s) (08:F0) [12:19:12:208]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI3295.tmp, Entrypoint: WixQuietExec64
            MSI (s) (08:E0) [12:19:12:208]: Generating random cookie.
            MSI (s) (08:E0) [12:19:12:209]: Created Custom Action Server with PID 4380 (0x111C).
            MSI (s) (08:C8) [12:19:12:226]: Running as a service.
            MSI (s) (08:C8) [12:19:12:228]: Hello, I'm your 32bit Elevated Non-remapped custom action server.
            MSI (s) (08!B4) [12:19:12:241]: Creating MSIHANDLE (89) of type 790531 for thread 9140
            WixQuietExec64: Entering WixQuietExec64 in C:\WINDOWS\Installer\MSI3295.tmp, version 3.11.4516.0
            MSI (s) (08!B4) [12:19:12:242]: Closing MSIHANDLE (89) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:242]: Creating MSIHANDLE (90) of type 790531 for thread 9140
            WixQuietExec64: "C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\bin\installer-util.exe" "C:\Program Files\Couchbase\Server\FOO" fixpaths"
            MSI (s) (08!B4) [12:19:12:242]: Closing MSIHANDLE (90) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:275]: Creating MSIHANDLE (91) of type 790531 for thread 9140
            WixQuietExec64: C:\Program Files\Couchbase\Server\bin\..\lib\python\runtime\python.exe does not exist!
            MSI (s) (08!B4) [12:19:12:276]: Closing MSIHANDLE (91) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:277]: Creating MSIHANDLE (92) of type 790531 for thread 9140
            WixQuietExec64: Error 0x80070001: Command line returned an error.
            MSI (s) (08!B4) [12:19:12:277]: Closing MSIHANDLE (92) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:277]: Creating MSIHANDLE (93) of type 790531 for thread 9140
            WixQuietExec64: Error 0x80070001: QuietExec64 Failed
            MSI (s) (08!B4) [12:19:12:278]: Closing MSIHANDLE (93) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:278]: Creating MSIHANDLE (94) of type 790531 for thread 9140
            WixQuietExec64: Error 0x80070001: Failed in ExecCommon method
            MSI (s) (08!B4) [12:19:12:278]: Closing MSIHANDLE (94) of type 790531 for thread 9140
            CustomAction FixConfig returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
            MSI (s) (08:F0) [12:19:12:279]: Closing MSIHANDLE (88) of type 790536 for thread 21800
            Action ended 12:19:12: InstallFinalize. Return value 3.
            MSI (s) (08:28) [12:19:12:295]: Note: 1: 2265 2: 3: -2147287035
            MSI (s) (08:28) [12:19:12:296]: User policy value 'DisableRollback' is 0
            MSI (s) (08:28) [12:19:12:296]: Machine policy value 'DisableRollback' is 0
            MSI (s) (08:28) [12:19:12:297]: Note: 1: 2318 2:
            MSI (s) (08:28) [12:19:12:301]: Executing op: Header(Signature=1397708873,Version=500,Timestamp=1393123936,LangId=1033,Platform=589824,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
            MSI (s) (08:28) [12:19:12:301]: Executing op: DialogInfo(Type=0,Argument=1033)
            MSI (s) (08:28) [12:19:12:301]: Executing op: DialogInfo(Type=1,Argument=Couchbase Server 7.0.0-5302 Enterprise Edition)
            MSI (s) (08:28) [12:19:12:302]: Executing op: RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back action:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescription=Removing backup files,CleanupTemplate=File: [1])
            Action 12:19:12: Rollback. Rolling back action:
            Rollback: FixConfig
             {noformat}
            I have some older builds, I've just tried to install

            couchbase-server-enterprise_7.0.0-4907-windows_amd64-unsigned.msi - failed, briefly flashed something about Python before rolling back so likely same issue

            couchbase-server-enterprise_7.0.0-3638-windows_amd64.msi - succeeds

            couchbase-server-enterprise_6.6.0-7862-windows_amd64.msi - succeeds

            I have about 20 7.0 builds downloaded.  It willl take a while but I could binary search through them to narrow down where the possible regression happened.  Let me know.

            I'm on Windows 10.  Please let me know if there's other diagnostic info I can provide.


            h3. Workaround

            * Right-click cmd.exe and choose "run as administrator"
            * Launch couchbase installer via "call couchbase-server-enterprise_7.0.0-windows_amd64.msi"
            drigby Dave Rigby made changes -
            Description At least, on my machine.

            I've downloaded 7.0 enterprise from the website (https://packages.couchbase.com/releases/7.0.0/couchbase-server-enterprise_7.0.0-windows_amd64.msi).  Installing it starts copying the files, but then hits an error and rollsback.  I tried a machine restart.  I made sure to uninstall the old Couchbase Server first, and then removed the c:\Program Files\Couchbase directory as well.  Neither helped.

            I followed [these directions|https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/enable-windows-installer-logging] to enable installer logging.  While I'm not keen on uploading as it's a huge file with seems to contain lots of details of my personal (non-work) machine, I can C&P what seems to be the relevant snippet, which looks to be that something goes wrong with the Python install:

             
            {noformat}
            MSI (s) (08:28) [12:19:11:871]: Executing op: CustomActionSchedule(Action=RollbackInstallCbpy,ActionType=1345,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c "rmdir /s /q "C:\Program Files\Couchbase\Server\lib\python\runtime"")
            MSI (s) (08:28) [12:19:11:872]: Executing op: ActionStart(Name=InstallCbpy,Description=Installing Python 3,)
            Action 12:19:11: InstallCbpy. Installing Python 3
            MSI (s) (08:28) [12:19:11:873]: Executing op: CustomActionSchedule(Action=InstallCbpy,ActionType=1025,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\Server\lib\python\runtime")
            MSI (s) (08:28) [12:19:11:894]: Creating MSIHANDLE (85) of type 790536 for thread 21800
            MSI (s) (08:4C) [12:19:11:894]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI313C.tmp, Entrypoint: WixQuietExec64
            MSI (s) (08!A0) [12:19:11:982]: Creating MSIHANDLE (86) of type 790531 for thread 3232
            WixQuietExec64: Entering WixQuietExec64 in C:\WINDOWS\Installer\MSI313C.tmp, version 3.11.4516.0
            MSI (s) (08!A0) [12:19:11:982]: Closing MSIHANDLE (86) of type 790531 for thread 3232
            MSI (s) (08!A0) [12:19:11:983]: Creating MSIHANDLE (87) of type 790531 for thread 3232
            WixQuietExec64: "C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\Server\lib\python\runtime"
            MSI (s) (08!A0) [12:19:11:983]: Closing MSIHANDLE (87) of type 790531 for thread 3232
            MSI (s) (08:4C) [12:19:12:205]: Closing MSIHANDLE (85) of type 790536 for thread 21800
            MSI (s) (08:28) [12:19:12:206]: Executing op: ActionStart(Name=FixConfig,,)
            Action 12:19:12: FixConfig.
            MSI (s) (08:28) [12:19:12:207]: Executing op: CustomActionSchedule(Action=FixConfig,ActionType=3073,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\bin\installer-util.exe" "C:\Program Files\Couchbase\Server\FOO" fixpaths")
            MSI (s) (08:28) [12:19:12:208]: Creating MSIHANDLE (88) of type 790536 for thread 21800
            MSI (s) (08:F0) [12:19:12:208]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI3295.tmp, Entrypoint: WixQuietExec64
            MSI (s) (08:E0) [12:19:12:208]: Generating random cookie.
            MSI (s) (08:E0) [12:19:12:209]: Created Custom Action Server with PID 4380 (0x111C).
            MSI (s) (08:C8) [12:19:12:226]: Running as a service.
            MSI (s) (08:C8) [12:19:12:228]: Hello, I'm your 32bit Elevated Non-remapped custom action server.
            MSI (s) (08!B4) [12:19:12:241]: Creating MSIHANDLE (89) of type 790531 for thread 9140
            WixQuietExec64: Entering WixQuietExec64 in C:\WINDOWS\Installer\MSI3295.tmp, version 3.11.4516.0
            MSI (s) (08!B4) [12:19:12:242]: Closing MSIHANDLE (89) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:242]: Creating MSIHANDLE (90) of type 790531 for thread 9140
            WixQuietExec64: "C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\bin\installer-util.exe" "C:\Program Files\Couchbase\Server\FOO" fixpaths"
            MSI (s) (08!B4) [12:19:12:242]: Closing MSIHANDLE (90) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:275]: Creating MSIHANDLE (91) of type 790531 for thread 9140
            WixQuietExec64: C:\Program Files\Couchbase\Server\bin\..\lib\python\runtime\python.exe does not exist!
            MSI (s) (08!B4) [12:19:12:276]: Closing MSIHANDLE (91) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:277]: Creating MSIHANDLE (92) of type 790531 for thread 9140
            WixQuietExec64: Error 0x80070001: Command line returned an error.
            MSI (s) (08!B4) [12:19:12:277]: Closing MSIHANDLE (92) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:277]: Creating MSIHANDLE (93) of type 790531 for thread 9140
            WixQuietExec64: Error 0x80070001: QuietExec64 Failed
            MSI (s) (08!B4) [12:19:12:278]: Closing MSIHANDLE (93) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:278]: Creating MSIHANDLE (94) of type 790531 for thread 9140
            WixQuietExec64: Error 0x80070001: Failed in ExecCommon method
            MSI (s) (08!B4) [12:19:12:278]: Closing MSIHANDLE (94) of type 790531 for thread 9140
            CustomAction FixConfig returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
            MSI (s) (08:F0) [12:19:12:279]: Closing MSIHANDLE (88) of type 790536 for thread 21800
            Action ended 12:19:12: InstallFinalize. Return value 3.
            MSI (s) (08:28) [12:19:12:295]: Note: 1: 2265 2: 3: -2147287035
            MSI (s) (08:28) [12:19:12:296]: User policy value 'DisableRollback' is 0
            MSI (s) (08:28) [12:19:12:296]: Machine policy value 'DisableRollback' is 0
            MSI (s) (08:28) [12:19:12:297]: Note: 1: 2318 2:
            MSI (s) (08:28) [12:19:12:301]: Executing op: Header(Signature=1397708873,Version=500,Timestamp=1393123936,LangId=1033,Platform=589824,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
            MSI (s) (08:28) [12:19:12:301]: Executing op: DialogInfo(Type=0,Argument=1033)
            MSI (s) (08:28) [12:19:12:301]: Executing op: DialogInfo(Type=1,Argument=Couchbase Server 7.0.0-5302 Enterprise Edition)
            MSI (s) (08:28) [12:19:12:302]: Executing op: RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back action:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescription=Removing backup files,CleanupTemplate=File: [1])
            Action 12:19:12: Rollback. Rolling back action:
            Rollback: FixConfig
             {noformat}
            I have some older builds, I've just tried to install

            couchbase-server-enterprise_7.0.0-4907-windows_amd64-unsigned.msi - failed, briefly flashed something about Python before rolling back so likely same issue

            couchbase-server-enterprise_7.0.0-3638-windows_amd64.msi - succeeds

            couchbase-server-enterprise_6.6.0-7862-windows_amd64.msi - succeeds

            I have about 20 7.0 builds downloaded.  It willl take a while but I could binary search through them to narrow down where the possible regression happened.  Let me know.

            I'm on Windows 10.  Please let me know if there's other diagnostic info I can provide.


            h3. Workaround

            * Right-click cmd.exe and choose "run as administrator"
            * Launch couchbase installer via "call couchbase-server-enterprise_7.0.0-windows_amd64.msi"
            h3. Summary

            At least, on my machine.

            I've downloaded 7.0 enterprise from the website (https://packages.couchbase.com/releases/7.0.0/couchbase-server-enterprise_7.0.0-windows_amd64.msi).  Installing it starts copying the files, but then hits an error and rollsback.  I tried a machine restart.  I made sure to uninstall the old Couchbase Server first, and then removed the c:\Program Files\Couchbase directory as well.  Neither helped.

            h3. Workaround
            (Via Ming)
            * Right-click cmd.exe and choose "run as administrator"
            * Launch couchbase installer via "call couchbase-server-enterprise_7.0.0-windows_amd64.msi"

            h3. Details

            I followed [these directions|https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/enable-windows-installer-logging] to enable installer logging.  While I'm not keen on uploading as it's a huge file with seems to contain lots of details of my personal (non-work) machine, I can C&P what seems to be the relevant snippet, which looks to be that something goes wrong with the Python install:

             
            {noformat}
            MSI (s) (08:28) [12:19:11:871]: Executing op: CustomActionSchedule(Action=RollbackInstallCbpy,ActionType=1345,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c "rmdir /s /q "C:\Program Files\Couchbase\Server\lib\python\runtime"")
            MSI (s) (08:28) [12:19:11:872]: Executing op: ActionStart(Name=InstallCbpy,Description=Installing Python 3,)
            Action 12:19:11: InstallCbpy. Installing Python 3
            MSI (s) (08:28) [12:19:11:873]: Executing op: CustomActionSchedule(Action=InstallCbpy,ActionType=1025,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\Server\lib\python\runtime")
            MSI (s) (08:28) [12:19:11:894]: Creating MSIHANDLE (85) of type 790536 for thread 21800
            MSI (s) (08:4C) [12:19:11:894]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI313C.tmp, Entrypoint: WixQuietExec64
            MSI (s) (08!A0) [12:19:11:982]: Creating MSIHANDLE (86) of type 790531 for thread 3232
            WixQuietExec64: Entering WixQuietExec64 in C:\WINDOWS\Installer\MSI313C.tmp, version 3.11.4516.0
            MSI (s) (08!A0) [12:19:11:982]: Closing MSIHANDLE (86) of type 790531 for thread 3232
            MSI (s) (08!A0) [12:19:11:983]: Creating MSIHANDLE (87) of type 790531 for thread 3232
            WixQuietExec64: "C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\lib\python\cbpy-installer.exe" /NoRegistry=1 /S /D=C:\Program Files\Couchbase\Server\lib\python\runtime"
            MSI (s) (08!A0) [12:19:11:983]: Closing MSIHANDLE (87) of type 790531 for thread 3232
            MSI (s) (08:4C) [12:19:12:205]: Closing MSIHANDLE (85) of type 790536 for thread 21800
            MSI (s) (08:28) [12:19:12:206]: Executing op: ActionStart(Name=FixConfig,,)
            Action 12:19:12: FixConfig.
            MSI (s) (08:28) [12:19:12:207]: Executing op: CustomActionSchedule(Action=FixConfig,ActionType=3073,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\bin\installer-util.exe" "C:\Program Files\Couchbase\Server\FOO" fixpaths")
            MSI (s) (08:28) [12:19:12:208]: Creating MSIHANDLE (88) of type 790536 for thread 21800
            MSI (s) (08:F0) [12:19:12:208]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI3295.tmp, Entrypoint: WixQuietExec64
            MSI (s) (08:E0) [12:19:12:208]: Generating random cookie.
            MSI (s) (08:E0) [12:19:12:209]: Created Custom Action Server with PID 4380 (0x111C).
            MSI (s) (08:C8) [12:19:12:226]: Running as a service.
            MSI (s) (08:C8) [12:19:12:228]: Hello, I'm your 32bit Elevated Non-remapped custom action server.
            MSI (s) (08!B4) [12:19:12:241]: Creating MSIHANDLE (89) of type 790531 for thread 9140
            WixQuietExec64: Entering WixQuietExec64 in C:\WINDOWS\Installer\MSI3295.tmp, version 3.11.4516.0
            MSI (s) (08!B4) [12:19:12:242]: Closing MSIHANDLE (89) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:242]: Creating MSIHANDLE (90) of type 790531 for thread 9140
            WixQuietExec64: "C:\WINDOWS\sysnative\cmd.exe" /s /c ""C:\Program Files\Couchbase\Server\bin\installer-util.exe" "C:\Program Files\Couchbase\Server\FOO" fixpaths"
            MSI (s) (08!B4) [12:19:12:242]: Closing MSIHANDLE (90) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:275]: Creating MSIHANDLE (91) of type 790531 for thread 9140
            WixQuietExec64: C:\Program Files\Couchbase\Server\bin\..\lib\python\runtime\python.exe does not exist!
            MSI (s) (08!B4) [12:19:12:276]: Closing MSIHANDLE (91) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:277]: Creating MSIHANDLE (92) of type 790531 for thread 9140
            WixQuietExec64: Error 0x80070001: Command line returned an error.
            MSI (s) (08!B4) [12:19:12:277]: Closing MSIHANDLE (92) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:277]: Creating MSIHANDLE (93) of type 790531 for thread 9140
            WixQuietExec64: Error 0x80070001: QuietExec64 Failed
            MSI (s) (08!B4) [12:19:12:278]: Closing MSIHANDLE (93) of type 790531 for thread 9140
            MSI (s) (08!B4) [12:19:12:278]: Creating MSIHANDLE (94) of type 790531 for thread 9140
            WixQuietExec64: Error 0x80070001: Failed in ExecCommon method
            MSI (s) (08!B4) [12:19:12:278]: Closing MSIHANDLE (94) of type 790531 for thread 9140
            CustomAction FixConfig returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
            MSI (s) (08:F0) [12:19:12:279]: Closing MSIHANDLE (88) of type 790536 for thread 21800
            Action ended 12:19:12: InstallFinalize. Return value 3.
            MSI (s) (08:28) [12:19:12:295]: Note: 1: 2265 2: 3: -2147287035
            MSI (s) (08:28) [12:19:12:296]: User policy value 'DisableRollback' is 0
            MSI (s) (08:28) [12:19:12:296]: Machine policy value 'DisableRollback' is 0
            MSI (s) (08:28) [12:19:12:297]: Note: 1: 2318 2:
            MSI (s) (08:28) [12:19:12:301]: Executing op: Header(Signature=1397708873,Version=500,Timestamp=1393123936,LangId=1033,Platform=589824,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
            MSI (s) (08:28) [12:19:12:301]: Executing op: DialogInfo(Type=0,Argument=1033)
            MSI (s) (08:28) [12:19:12:301]: Executing op: DialogInfo(Type=1,Argument=Couchbase Server 7.0.0-5302 Enterprise Edition)
            MSI (s) (08:28) [12:19:12:302]: Executing op: RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back action:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescription=Removing backup files,CleanupTemplate=File: [1])
            Action 12:19:12: Rollback. Rolling back action:
            Rollback: FixConfig
             {noformat}
            I have some older builds, I've just tried to install

            couchbase-server-enterprise_7.0.0-4907-windows_amd64-unsigned.msi - failed, briefly flashed something about Python before rolling back so likely same issue

            couchbase-server-enterprise_7.0.0-3638-windows_amd64.msi - succeeds

            couchbase-server-enterprise_6.6.0-7862-windows_amd64.msi - succeeds

            I have about 20 7.0 builds downloaded.  It willl take a while but I could binary search through them to narrow down where the possible regression happened.  Let me know.

            I'm on Windows 10.  Please let me know if there's other diagnostic info I can provide.
            ceej Chris Hillery made changes -
            Labels releasenote

            Ming's workaround should be releasenoted for 7.0.0. I'm seeing if I can fix this for 7.0.2.

            ceej Chris Hillery added a comment - Ming's workaround should be releasenoted for 7.0.0. I'm seeing if I can fix this for 7.0.2.

            So this is happening due to the fix I made for MB-45157. Because the Server WiX installer's instructions for launching the cbpy installer say Impersonate="yes", it is launched with the same process owner as the person installing Server itself. For whatever reason, Windows 10 doesn't like this; that user doesn't have permissions to install to C:\Program Files, or something. By restoring Impersonate="no", the cbpy installer is launched as the "Local System", which works.

            The problem, as highlighted in MB-45157, is that when invoked this way, the cbpy installer creates a few un-accessible files. Those files aren't important for Server operation at all, but they trip up our virus scanner. I can delete them prior to scanning, but I think I might be playing whack-a-mole finding all the affected files.

            ceej Chris Hillery added a comment - So this is happening due to the fix I made for MB-45157 . Because the Server WiX installer's instructions for launching the cbpy installer say Impersonate="yes", it is launched with the same process owner as the person installing Server itself. For whatever reason, Windows 10 doesn't like this; that user doesn't have permissions to install to C:\Program Files, or something. By restoring Impersonate="no", the cbpy installer is launched as the "Local System", which works. The problem, as highlighted in MB-45157 , is that when invoked this way, the cbpy installer creates a few un-accessible files. Those files aren't important for Server operation at all, but they trip up our virus scanner. I can delete them prior to scanning, but I think I might be playing whack-a-mole finding all the affected files.

            I think a user on the forum has also hit this issue. It would be good if some one could double check my assumption.

            pvarley Patrick Varley added a comment - I think a user on the forum has also hit this issue. It would be good if some one could double check my assumption.
            ceej Chris Hillery made changes -
            Sprint Build Team 2021 Sprint 16 [ 1704 ] Build Team 2021 Sprint 16, Build Team 2021 Sprint 17 [ 1704, 1739 ]

            Patrick Varley Yes, that certainly looks like the same error.

            ceej Chris Hillery added a comment - Patrick Varley  Yes, that certainly looks like the same error.
            ming.ho Ming Ho added a comment -

            I googled up this a little bit.  It seems impersonate='yes' for a deferred action don't have the full admin rights under UAC (user account control) unless you start the install with elevated rights.  Maybe try "InstallScope=perMachine" or "InstallPrivileges=elevated".

            https://wixtoolset.org/documentation/manual/v3/xsd/wix/package.html

            ming.ho Ming Ho added a comment - I googled up this a little bit.  It seems impersonate='yes' for a deferred action don't have the full admin rights under UAC (user account control) unless you start the install with elevated rights.  Maybe try "InstallScope=perMachine" or "InstallPrivileges=elevated". https://wixtoolset.org/documentation/manual/v3/xsd/wix/package.html
            ceej Chris Hillery made changes -
            Remote Link This issue links to "Page (Couchbase, Inc. Wiki)" [ 22880 ]
            ceej Chris Hillery made changes -
            Link This issue blocks MB-46308 [ MB-46308 ]

            I spent entirely too much time on this today, and tracked the problem to deep in the Conda tool itself where it creates those files by hard-linking another file (conda.exe, in fact, which is just a generic python-wrapper binary). Hard links in Windows are murky at best, especially as regards permissions, so I'm sure that's the location of the problem even if I can't 100% explain why our use case creates these unreadable files.

            I could "fix" it in Conda by using a copy rather than a hard link, but I don't want to maintain our own Conda version going forward. Instead I've opted for a hack: I've added a constructor post-install script on Windows which simply deletes those two files. With Blair Watt's help I've confirmed that those ARE the only two problematic files, so this is Good Enough(tm) for now. Confirmed in a toy build on both Windows 10 and Windows 2016 that Server install succeeds, and there are no un-accessible files afterwards.

            I fixed this initially on the cheshire-cat branch to go into 7.0.2, as it is relatively low-risk and we are looking to make the developer experience better overall - not working on Windows 10 is a bad start. Created cbpy 7.0.2-cb1 there.

            I've then merged that up to the master branch and rolled a new cbpy 7.1.0-cb1, which includes this change and one or two dependency updates that were outstanding.

            ceej Chris Hillery added a comment - I spent entirely too much time on this today, and tracked the problem to deep in the Conda tool itself where it creates those files by hard-linking another file (conda.exe, in fact, which is just a generic python-wrapper binary). Hard links in Windows are murky at best, especially as regards permissions, so I'm sure that's the location of the problem even if I can't 100% explain why our use case creates these unreadable files. I could "fix" it in Conda by using a copy rather than a hard link, but I don't want to maintain our own Conda version going forward. Instead I've opted for a hack: I've added a constructor post-install script on Windows which simply deletes those two files. With Blair Watt 's help I've confirmed that those ARE the only two problematic files, so this is Good Enough(tm) for now. Confirmed in a toy build on both Windows 10 and Windows 2016 that Server install succeeds, and there are no un-accessible files afterwards. I fixed this initially on the cheshire-cat branch to go into 7.0.2, as it is relatively low-risk and we are looking to make the developer experience better overall - not working on Windows 10 is a bad start. Created cbpy 7.0.2-cb1 there. I've then merged that up to the master branch and rolled a new cbpy 7.1.0-cb1, which includes this change and one or two dependency updates that were outstanding.
            ceej Chris Hillery made changes -
            Fix Version/s Neo [ 17615 ]

            Build couchbase-server-7.0.2-6531 contains tlm commit 9707c5e with commit message:
            MB-47806: Post-install script in cbpy to fix Windows 10 installation

            build-team Couchbase Build Team added a comment - Build couchbase-server-7.0.2-6531 contains tlm commit 9707c5e with commit message: MB-47806 : Post-install script in cbpy to fix Windows 10 installation

            Build couchbase-server-7.0.2-6531 contains voltron commit f68ea83 with commit message:
            MB-47806: Revert "MB-45157: Impersonate installing user when installing/uninstalling python"

            build-team Couchbase Build Team added a comment - Build couchbase-server-7.0.2-6531 contains voltron commit f68ea83 with commit message: MB-47806 : Revert " MB-45157 : Impersonate installing user when installing/uninstalling python"

            Build couchbase-server-7.1.0-1162 contains tlm commit 9707c5e with commit message:
            MB-47806: Post-install script in cbpy to fix Windows 10 installation

            build-team Couchbase Build Team added a comment - Build couchbase-server-7.1.0-1162 contains tlm commit 9707c5e with commit message: MB-47806 : Post-install script in cbpy to fix Windows 10 installation

            Build couchbase-server-7.1.0-1162 contains voltron commit f68ea83 with commit message:
            MB-47806: Revert "MB-45157: Impersonate installing user when installing/uninstalling python"

            build-team Couchbase Build Team added a comment - Build couchbase-server-7.1.0-1162 contains voltron commit f68ea83 with commit message: MB-47806 : Revert " MB-45157 : Impersonate installing user when installing/uninstalling python"

            This should be fixed in both 7.0.2 and 7.1.0; please verify.

            ceej Chris Hillery added a comment - This should be fixed in both 7.0.2 and 7.1.0; please verify.
            ceej Chris Hillery made changes -
            Assignee Chris Hillery [ ceej ] Graham Pople [ graham.pople ]
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Resolved [ 5 ]
            ceej Chris Hillery logged work - 18/Aug/21 2:36 PM
            • Time Spent:
              8h
               
              Fixed
            ceej Chris Hillery made changes -
            Worklog Id 14944 [ 14944 ]
            Remaining Estimate 0h [ 0 ]
            Time Spent 8h [ 28800 ]

            Amarantha Kulkarni The workaround from Ming is to do both of those steps: open a cmd.exe Window using "Run as Administrator", and then in that window, run the command call couchbase-server-enterprise_7.0.0-windows_amd64.msi .

            ceej Chris Hillery added a comment - Amarantha Kulkarni  The workaround from Ming is to do both of those steps: open a cmd.exe Window using "Run as Administrator", and then in that window, run the command call couchbase-server-enterprise_7.0.0-windows_amd64.msi .
            ritam.sharma Ritam Sharma added a comment -

            [~ceej - https://issues.couchbase.com/browse/MB-47806?focusedCommentId=535865&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-535865

            In the comment above, not very clear if Administrator is required or not. Based on testing with Build - 7.0.2-6620, it still required Administrator password to continue with installation.

            ritam.sharma Ritam Sharma added a comment - [~ceej - https://issues.couchbase.com/browse/MB-47806?focusedCommentId=535865&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-535865 In the comment above, not very clear if Administrator is required or not. Based on testing with Build - 7.0.2-6620, it still required Administrator password to continue with installation.
            ceej Chris Hillery added a comment - - edited

            Ritam Sharma The discussion about the release note moved into the Doc ticket DOC-9066 and I made a few additional discoveries there; let me copy the final recommended release note here for the reference of those who might find this ticket:

            When installing Couchbase Server on Windows, you must be logged into an account with Administrator privileges.

            For Couchbase Server 7.0.1 and earlier: if you are logged in to an account other than the built-in Administrator account, you will receive an error during installation if you attempt to install into a directory under C:\Program Files. Please change the installation directory to something under your user's home directory.

            If you must install into C:\Program Files, and cannot log in to the built-in Administrator account (this account is disabled by default on Windows 10), the work-around is to take the following steps:

            1. Click the Start button and type "cmd".
            2. Right-click on "Command Prompt" and select "Run as administrator".
            3. At the command prompt, cd into the directory with the downloaded .msi and type call couchbase-server-enterprise_7.0.0-windows_amd64.msi .
            ceej Chris Hillery added a comment - - edited Ritam Sharma  The discussion about the release note moved into the Doc ticket DOC-9066 and I made a few additional discoveries there; let me copy the final recommended release note here for the reference of those who might find this ticket: When installing Couchbase Server on Windows, you must be logged into an account with Administrator privileges. For Couchbase Server 7.0.1 and earlier: if you are logged in to an account other than the built-in Administrator account, you will receive an error during installation if you attempt to install into a directory under C:\Program Files. Please change the installation directory to something under your user's home directory. If you must install into C:\Program Files, and cannot log in to the built-in Administrator account (this account is disabled by default on Windows 10), the work-around is to take the following steps: Click the Start button and type "cmd". Right-click on "Command Prompt" and select "Run as administrator". At the command prompt, cd into the directory with the downloaded .msi and type call couchbase-server-enterprise_7.0.0-windows_amd64.msi  .
            amarantha.kulkarni Amarantha Kulkarni (Inactive) made changes -
            Link This issue is triggering DOC-9066 [ DOC-9066 ]
            ritam.sharma Ritam Sharma added a comment -

            Chris Hillery- Do we really need Administrator permission for the installer ?

            Chin Hong - Assign to you for validation of flow and if this is expected.

            ritam.sharma Ritam Sharma added a comment - Chris Hillery - Do we really need Administrator permission for the installer ? Chin Hong - Assign to you for validation of flow and if this is expected.
            ritam.sharma Ritam Sharma made changes -
            Assignee Graham Pople [ graham.pople ] Chin Hong [ chinhong ]

            Ritam Sharma Yes, we need Administrator privileges to install Server, because it creates a Windows Service. That has always been the case on Windows, although I don't know if it's been clearly documented.

            The reason it got worse on Windows 10 with 7.0 is that, due to an internal change, it now needed to be installed by the actual built-in Administrator account if you targeted C:\ Program Files (which is the default location) - and the built-in Administrator account is normally disabled and unavailable on Windows 10. I've worked around that problem in 7.0.2 and the underlying problem will be gone entirely in 7.1.0, so we'll be back to just requiring Administrator privileges to install regardless of target directory. 

            ceej Chris Hillery added a comment - Ritam Sharma  Yes, we need Administrator privileges to install Server, because it creates a Windows Service. That has always been the case on Windows, although I don't know if it's been clearly documented. The reason it got worse on Windows 10 with 7.0 is that, due to an internal change, it now needed to be installed by the actual built-in Administrator account if you targeted C:\ Program Files (which is the default location) - and the built-in Administrator account is normally disabled and unavailable on Windows 10. I've worked around that problem in 7.0.2 and the underlying problem will be gone entirely in 7.1.0, so we'll be back to just requiring Administrator privileges to install regardless of target directory. 
            chinhong Chin Hong added a comment -

            Chris Hillery We need to guide the user on how to use the Admin privilege during the install, and not expect them to read the doc.

            chinhong Chin Hong added a comment - Chris Hillery We need to guide the user on how to use the Admin privilege during the install, and not expect them to read the doc.
            chinhong Chin Hong made changes -
            Assignee Chin Hong [ chinhong ] Chris Hillery [ ceej ]
            ceej Chris Hillery made changes -
            Attachment Screenshot from 2021-09-08 14-56-50.png [ 158634 ]
            ceej Chris Hillery made changes -
            Attachment Screenshot from 2021-09-08 14-56-50.png [ 158634 ]
            ceej Chris Hillery made changes -
            Attachment User-with-admin-privs.png [ 158637 ]
            ceej Chris Hillery made changes -
            Attachment User-with-no-admin-privs.png [ 158638 ]
            ceej Chris Hillery added a comment - - edited

            If you are logged into an account with Administrator privileges, the installer will already prompt you to grant Administrator privileges during the installation process if necessary (this is the normal "Do you want to allow this app to make changes to your device?" message).

                

            If you are logged into an account without Administrator privileges, the installer will show you a similar dialog that prompts you to provide credentials for an account that does have Administrator privileges. (My "Ceej" account on this box has Administrator privileges.)

                

            I can't have the installer provide any guidance about the issue of non-built-in-Administrator accounts installing to C:\Program Files, because the only versions of the product that suffer from that issue are already GA.

            No action to take here.

            ceej Chris Hillery added a comment - - edited If you are logged into an account with Administrator privileges, the installer will already prompt you to grant Administrator privileges during the installation process if necessary (this is the normal "Do you want to allow this app to make changes to your device?" message).       If you are logged into an account without Administrator privileges, the installer will show you a similar dialog that prompts you to provide credentials for an account that does have Administrator privileges. (My "Ceej" account on this box has Administrator privileges.)       I can't have the installer provide any guidance about the issue of non-built-in-Administrator accounts installing to C:\Program Files, because the only versions of the product that suffer from that issue are already GA. No action to take here.
            ceej Chris Hillery made changes -
            Assignee Chris Hillery [ ceej ] Chin Hong [ chinhong ]
            chinhong Chin Hong added a comment -

            ceej, can you provide an internal 7.0.2 build for Rekha Nair to try it out to see if the flow works for new user?

            chinhong Chin Hong added a comment - ceej, can you provide an internal 7.0.2 build for Rekha Nair to try it out to see if the flow works for new user?
            chinhong Chin Hong made changes -
            Assignee Chin Hong [ chinhong ] Rekha Nair [ JIRAUSER25296 ]

            Rekha Nair  Any recent 7.0.2 build from latestbuilds should work; try: http://latestbuilds.service.couchbase.com/builds/latestbuilds/couchbase-server/cheshire-cat/6659/couchbase-server-enterprise_7.0.2-6659-windows_amd64.msi  (VPN required).

            If there are any issues with the workflow, I'd suggest filing a new ticket - this one has moved far afield from the issue that was originally filed.

            ceej Chris Hillery added a comment - Rekha Nair   Any recent 7.0.2 build from latestbuilds should work; try: http://latestbuilds.service.couchbase.com/builds/latestbuilds/couchbase-server/cheshire-cat/6659/couchbase-server-enterprise_7.0.2-6659-windows_amd64.msi   (VPN required). If there are any issues with the workflow, I'd suggest filing a new ticket - this one has moved far afield from the issue that was originally filed.
            ceej Chris Hillery made changes -
            Link This issue is duplicated by MB-48397 [ MB-48397 ]
            rekha.nair Rekha Nair added a comment -

            I have validated the following two scenarios with no issues with the 7.0.2 build 7.0.2-6659:

            As an administrator - installed Couchbase in the default folder C:\Program Files and also a non-default folder 

            As a non-admin user (rekha) - installed Couchbase in the default as well as a non-default folder

            Chris Hillery - Let me know if I need to test any other scenarios. 

            rekha.nair Rekha Nair added a comment - I have validated the following two scenarios with no issues with the 7.0.2 build 7.0.2-6659: As an administrator - installed Couchbase in the default folder C:\Program Files and also a non-default folder  As a non-admin user (rekha) - installed Couchbase in the default as well as a non-default folder Chris Hillery  - Let me know if I need to test any other scenarios. 

            Rekha Nair That's all I can think of. I believe this ticket can be Closed.

            ceej Chris Hillery added a comment - Rekha Nair  That's all I can think of. I believe this ticket can be Closed.
            ritam.sharma Ritam Sharma added a comment -

            Rekha Nair - Thank you, can you please review the release notes as well.
            Arunkumar Senthilnathan - Please take the defect from here for QE validation. We need to cover Server and desktop version. I have worked with Deepika to validate the scenario, please review testing and finally close out the ticket. I am assigning the ticket to you.

            ritam.sharma Ritam Sharma added a comment - Rekha Nair - Thank you, can you please review the release notes as well. Arunkumar Senthilnathan - Please take the defect from here for QE validation. We need to cover Server and desktop version. I have worked with Deepika to validate the scenario, please review testing and finally close out the ticket. I am assigning the ticket to you.
            ritam.sharma Ritam Sharma made changes -
            Assignee Rekha Nair [ JIRAUSER25296 ] Arunkumar Senthilnathan [ arunkumar ]
            arunkumar Arunkumar Senthilnathan added a comment - - edited

            As per discussion with Deepika Verma, following scenarios were tested:
            Non-admin user on windows - try to install and it asks for Admin privileges as expected - once privileges are granted, user can install
            With Admin user on windows, install goes through
            Tested install scenarios above with both default and non default locations
            Tested uninstall with non-admin user - prompted for admin privileges - once granted, user can uninstall
            Looks good to me

            arunkumar Arunkumar Senthilnathan added a comment - - edited As per discussion with Deepika Verma , following scenarios were tested: Non-admin user on windows - try to install and it asks for Admin privileges as expected - once privileges are granted, user can install With Admin user on windows, install goes through Tested install scenarios above with both default and non default locations Tested uninstall with non-admin user - prompted for admin privileges - once granted, user can uninstall Looks good to me
            arunkumar Arunkumar Senthilnathan made changes -
            Status Resolved [ 5 ] Closed [ 6 ]

            People

              arunkumar Arunkumar Senthilnathan
              graham.pople Graham Pople
              Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 8h
                  8h

                  PagerDuty