Issues with latest WMI installer

[thiagoftsm]

Issue 1

When I tried to install and claim a node today on Windows Server 2022 I received this error:

And I could not finish installation. After this double click installer and everything worked as expected.

Issue 2

During installation time on the same server, it cannot use WSL2 and it uses WSL1:

I am not sure if this is an error with installer and our image, or an issue on server. :thinking:

Issue 3

We are not using latest version of windows exporter. Is there a specific reason for this? I am using the latest to develop and I do not identify an error that can postpone our use.

Issue 4

@cakrit we are always installing Windows Exporter with default options instead to detect possible servers installed and enable options. Should we improve this a little bit?

[dfpr]

Issue 1

When I tried to install and claim a node today on Windows Server 2022 I received this error:

And I could not finish installation. After this double click installer and everything worked as expected.

MSIEXEC won't open .\netdata.msi, the correct command is msiexec.exe /i netdata.msi without the .\ prefix. Double click will only work for the built-in administrator account that has UAC disabled.

Issue 2

During installation time on the same server, it cannot use WSL2 and it uses WSL1:

I am not sure if this is an error with installer and our image, or an issue on server. 🤔

Server doesn't have Virtualization or Nested virtualization available so it has to use WSL1. Task manager | Performance | CPU will say "Virtualization: Enabled" only when available.

Issue 3

We are not using latest version of windows exporter. Is there a specific reason for this? I am using the latest to develop and I do not identify an error that can postpone our use.

I guess that version was released after I started working on the installer, anyway, I have updated it to v0.20.

[thiagoftsm]

Thank you for your explanation, I will keep it open until we update Windows Exporter.

[dfpr]

Latest release includes windows exporter v0.20

[thiagoftsm]

Hello @dfpr ,

Thank you to update the Windows Exporter. Now about to claim a node, we still have an issue on Windows Server, please, take a look in what happens when I use Power Shell to install:

On the other hand, when I do not use additional information necessary to claim a node, the installation happens as expected:

Best regards!

[dfpr]

Latest release should handle rooms with spaces in their names correctly.

[thiagoftsm]

Latest release should handle rooms with spaces in their names correctly.

Yes, but I used quotes around them.

[dfpr]

msiexec received the variable correctly but invocation of netdata-claim.sh didn't, that is fixed

[thiagoftsm]

Hello @dfpr ,

Unfortunately the latest release still has the issue:

I kept the Room name this time to help you, and I also showed part of the key too.

Best regards!

[dfpr]

Sorry, I thought the issue was in the installation script but it is just a powershell issue: double quotes inside the command need a backtick place before: msiexec /i netdata.msi ROOMS=`"My room`" or even better don't run the command using powershell but use cmd.

[thiagoftsm]

Sorry, I thought the issue was in the installation script but it is just a powershell issue: double quotes inside the command need a backtick place before: msiexec /i netdata.msi ROOMS=`"My room`" or even better don't run the command using powershell but use cmd.

Nice, now I could run the command and install netdata from Power Shell, but the VM restarted without to ask me nothing. When I ran msiexec.exe /i netdata.msi I had the expected behavior asking me to reboot.

[dfpr]

Non-interactive restart only happened to me with the AUTORESTART=1 argument, I'll test deeper this weekend.

[thiagoftsm]

Non-interactive restart only happened to me with the AUTORESTART=1 argument, I'll test deeper this weekend.

All right, thank you!
I never set AUTORESTART=1 while I was installing, probably we have something inside our codes. :thinking: Please, let me know if you need any additional information.

[dfpr]

I could take a look at the installation log at C:\netdata.log

[thiagoftsm]

Of course, this is the file we have right now at our C:.

Please, refresh my mind, on normal situation we do not store nothing in / on Unix systems, should we also have the same principle on Microsoft? Why we are not moving C:\netdata.log to C:\Netdata after installation is done?

[dfpr]

I couldn't reproduce the issue, I'd say don't use powershell but use cmd... but let me see the Windows Installer log generated like this: msiexec /i "installer.msi" /L*v "log.log" Also, since the installer creates C:\NETDATA and removes it at uninstallation then the log can't be saved there.

[thiagoftsm]

Hello @dfpr ,

Sorry for the delay, this is the output of the command you gave me.

For the second time I had server restarting while I was installing.

About I'd say don't use powershell but use cmd, well I think we need to detect the prompt and raise a message box for users stopping the installation and redirecting them for the normal cmd.

Please, let me know if you need any other thing.

Best regards!

[dfpr]

I'll check deeper how to avoid the issue with powershell and try to show message boxes when the command line is malformed

[dfpr]

Problem was handing of spaces in ROOMS, it is fixed now. BUT I can't claim as the installer sends app.netdata.cloud to netdata-claim.sh but that script uses api.netdata.cloud disregarding the argument and failing to reach such address.