March 21, 2017 at 15:11 #14096
This issue seems to affect our workstations running Win10 build 1607. We were running 5.1.42 successfully on the LTSB version of Windows. Doesn’t work on 1607 though. Even tried installing 5.2.11. We’re attempting to connect to a physical display. Local Windows version is also 1607 and works fine when connecting to a host running LTSB.
For us, ProcExplorer shows lsass.exe is not protected. Application Logs are saturated with faults from nxserver.bin. I tried disabling Window Firewall and Windows Defender – no dice.March 23, 2017 at 10:10 #14108
Please make sure that you started ProcessExplorer as Administrator, when it’s launched without rights elevation it doesn’t correctly report protection mode.
In case you rule out protection level as potential source of problems, send us server-side logs gathered according to these instructions:
Send them to forum[at]nomachine[dot]comMarch 23, 2017 at 10:10 #14110WoofboyXParticipant
I have the same issue here. 5 windows 10 machines all with NoMachine 5.2.11 or 5.1.42 we working well before the windows 1607 update. Now the nxservice won’t run at startup and the nxserver stops running as started. 1607 Windows home update appears to be generally toxic to NoMachine and all connections fail. The only device still working is an android tablet but it is only a client so it has nothing it can connect to 🙁 help?March 29, 2017 at 08:40 #14167
I emailed the logs per the instructions. Please let me know if you need anything else. Thanks for your help.April 7, 2017 at 13:40 #14291
We provided you with patched version fixing issue with unavailable descriptor, described in this thread: https://www.nomachine.com/forums/topic/error-descriptor-fd_____-not-available
In logs you recently sent we found another issue. It’s not possible to obtain home directory for ‘nx’ user. In past such problem occurred when Windows hosts were part of Active Directory and NoMachine was installed on Domain Controlled (Windows Server). Is this a case in your setup? Can you uninstall NoMachine on Domain Controller and reinstall NoMachine on hosts on which you experience problems?April 7, 2017 at 13:57 #14297
Thanks for getting back to me. We don’t have NoMachine installed on a domain controller, but the workstation is joined to the domain. I’m able to confirm that the local NX user does exist on the machine, although admittedly, the home folder does not have a path specified. That said, when I compare it to the one machine that does have NM working, the nx user doesn’t have a home folder specified there either.April 10, 2017 at 07:30 #14298
For what it’s worth – I specified the path to the profile/home directory for the local user and restarted the NoMachine service, to no avail.April 11, 2017 at 08:50 #14351BritgirlParticipant
Uninstall NoMachine and check if nx user is present. If it is, remove it and then reinstall NoMachine.April 12, 2017 at 08:37 #14355
I uninstalled NoMachine and rebooted. The nx user account was properly removed by the installer. I reinstalled the software and rebooted. Tried connecting – no dice.
The NoMachine installer creates the nx user account, but it still throws an error trying to create the home directory. Either way, I’m in the same boat.April 12, 2017 at 12:24 #14376
I suspect that default user profile on your host might be corrupted. You can try to create few user accounts and check if it’s possible to login on their desktops. If you experience any problems, please refer to this Stack Overflow thread:April 12, 2017 at 17:31 #14379
I was able to figure out the issue. The installer doesn’t like UAC. To get it working, I had to remove my machine from the domain, remove the UAC policy, disable UAC, then install the software and rejoin the domain. No issues with UAC once the software is already installed.
Needless to say, this is kind of painful. It’d be great if you guys could update your installer accordingly to prevent requiring UAC to be disabled.
Anyhow, thanks a bunch for your help!April 14, 2017 at 13:20 #14419
This topic was marked as solved, you can't post.