Since 7.0.23, the launcher will create a temporary powershell file to start server on Windows, see:

Launcher should catch this error and attempt to start the server using the old way.

That will not work, just limited for playing, but not on production.

The command line on windows is limited in length, when you start an instance in cluster, Windows will kill it on logout, etc. I did not do this because I was bored ...

At least print warning then. There is a lot of complaints about the windows behavior.

Also you should not catch the error, you should detect system capabilities first instead, before you do something with the expectation that it works reliably.

The link gives some advices, we should reflect that somehow. Not sure what is possible, I doubt we can set execution policies from GF. Can we sign the script? I have doubts about this too. So perhaps we can extend the "capabilities" class I created and add something like isPowerShellAvailable, call the command to check and then

• just generate and execute it

• or print warning and execute the "old way"

• https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.5

• https://codesigningstore.com/how-to-sign-a-powershell-script

I agree. Check first, and then decide whether to execute using script or the old way. If execution using script still wouldn't work, maybe all give a user an option to force it using an env var.

Yeah, could be also some configuration to enforce chosen way. Especially when we don't have control over all Windows versions, configurations, patches, etc.

It is more complicated - because the GFLauncher is used by remote commands, and after many tests using many configurations and commands I have found that it is quite clear:

• SSH node instance MUST use PowerShell and windows task scheduler, the instance would be killed otherwise once the SSH session ends.
• DAS can be configured using the env option. By default it should be set for production, so it should use PowerShell and task scheduler to prevent killing the instance after user logout. The env option can be explicitly set in asenv.bat to make it clear and easy.
• Local node can respect the asenv configuration just as DAS.

Any alternative to PowerShell still needs special permissions.

However, when testing I have found yet few other issues, which should be fixed in #25454 now. Some caused very confusing errors (and just on Windows) like:

• Permission Denied when I just executed java.exe instead of the bat file. Caused probably by incorrect path quotation.
• asadmin command froze waiting for instance stop - which stopped.
• asadmin command crashed when stopping the local instance - which stopped. ConnectException.
• nonexisting nadmin when using ssh node with GlassFish path with spaces.