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

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).

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

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 yes 64 bit, and no antivirus running.

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 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.

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.

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'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.

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

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

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

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.

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 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"

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

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 - 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 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 .

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 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. 

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.

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, 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?

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.

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.

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.

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