I've been trying to get the desktop to install on Windows Server 2019 and I'm having some issues.
During the initial install, it seems to hang and then claims that it can't run the Ziti Monitor Service, and asks if I ignore/abort/retry. For the time being I picked ignore.
The Ziti edge service starts up time, and I can run the GUI to look at the identity, services etc. However the Ziti Edge Monitor sever won't run at all, ever, does this matter?
Are there any logs in the "usual" monitor location that might be useful? Find them at: C:\Program Files (x86)\NetFoundry, Inc\Ziti Desktop Edge\logs\ZitiMonitorService or by making a 'feedback' zip file.
Are there any messages in the event viewer that might lead us to understanding what is going on?
I'm not going to lie, this is probably going to be a difficult thing to track down asynchronously. I am sure I've installed the ZDEW on Server 2019 before and I've definitely seen it working in the past. I have not tried that for "a while" though (probably a year). Let's see if there's anything in the logs that can help us, and if not I can make a server in a cloud somewhere to just verify it still works. After that, it's probably something in the windows environment that's blocking something. In the past, I've seen powershell environments that are corrupt/broken. The tunneler itself definitely calls a powershell command or two so I've seen that be a problem, it MAY be something like that.
I've seen the version of dotnet installed be corrupted too leading to problems. If you would want to, we could either build a "debug" version of the program that you could run manually to see if any useful output happens in a console, or you could try to pull the code down and build it yourself and run it with #DEBUG defined so it will bypass the "it must be run as a service" error you'll get if you don't (it's designed to run as a service).
Let's look at the logs and event viewer, see if anything stands out and then see where we're at. If you have a second server 2019 to try installing it / running it on handy that'd be good to test too...
The monitor/update service is what collects that feedback so if it's not running, it isn't surprising... The UI shouldn't HANG though? You couldn't just click the 'close' that error?
You'll need to look for logs at C:\Program Files (x86)\NetFoundry, Inc\Ziti Desktop Edge\logs\ZitiMonitorService
I think we'll find in the logs that it's crashing for some reason, hopefully the logs will have a clue
No logs there either, seems like its never run once, so its never created a log. I only see the logs for the Ziti Service. Which seems to be working in general now? Even if monitor is not starting.
That's a true mystery... The only thing I think we could do would be to get you a debug build to run/try, or get you to build/run/debug it yourself.
If you like, I can make a debug exe and send it to you somehow, or I can teach you how to build it all yourself. I think that'll be our only avenue though.
Were you able to try it on a different machine? I can fire up a server 2019 and try it, if you don't have one available.
I tried a quick Win10 VM in virtualbox on my mac (apple has made this so terrible) and it installed and ran just fine, so yeah def something specific to the config of this server. I bet it something to do with the security policy, but I didn't see anything in the windows event logs that matched the time, but its tough to find what you need in there, super chatty!
I'd love to get a verbose output of the service when its trying to start, is the debug version the best way to get that? I highly doubt I have the tools necessary to actually build a windows binary I don't normally work on windows honestly.
Let me know if you can share the debug build, google drive perhaps?
I wanted to post a follow up about this for anyone else who might come across this.
We think we narrowed down the issue to an issue with windows itself. This machine I was testing on lives in a restricted env, with limited access to the internet. Port 80 is blocked, but this caused a silent failure within windows when it tried to do signature validation on the Monitor (services) binary. Since it couldn't pull the latest CRL list from Digicert over port 80 (OCSP and CRL use HTTP, not HTTPS), it would fail to validate the binary.
This was a totally silent failure, there was never any logs we could find do indicate this was the issue, we just stumbled on it during testing. So this was a windows failure, not openziti.