Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zulip on Active Directory working in 5.8.1 and not Working in 5.9.2 #1210

Closed
Atygor opened this issue Apr 25, 2022 · 15 comments
Closed

Zulip on Active Directory working in 5.8.1 and not Working in 5.9.2 #1210

Atygor opened this issue Apr 25, 2022 · 15 comments

Comments

@Atygor
Copy link

Atygor commented Apr 25, 2022

Instead of running as intended for low priviledged users, on the same server, it requires to run as an administrator since the update, but we really don't want to grant them admin rights.

Why is that?

Is there a way to disable Update Notifications? Since in both of current ways Zulip results in being not usable for our specific needs.

@dalstede
Copy link

dalstede commented Apr 26, 2022

We're having the same problem. Windows Server 2019 x64 Terminal Services environment and users have no administrative permissions. Working fine with 5.8.1 until yesterday, now after the Update to 5.9.2 the desktop application does not open on login and users don't seem to be able to open the application manually.

Executing as Administrator seems to work but won't help the users. Users also are identified via Active Directory.

@Atygor
Copy link
Author

Atygor commented Apr 26, 2022

What i did, maybe it helps: rollback to 5.8.1 and then edit the Zulip settings.json (in user Appdata) in order to disable Auto-Update. That way it is running and not spaming that insisting Push Notification.
Greetings.

@dalstede
Copy link

Thank you for the follow up. I'll probably have no choice. I checked with the few users that were only and they were either using the web version or a user profile local version in AppData\Local\Programs\Zulip.

@andersk
Copy link
Member

andersk commented Apr 27, 2022

I can’t reproduce this. When testing with a low-privileged user on Windows 10 (member of the Guests group), I have no problems installing 5.9.2 for myself, upgrading 5.8.1 to 5.9.2 for myself, using 5.9.2 if it was installed system-wide by an administrator, or upgrading to 5.9.2 for myself if 5.8.1 was installed system-wide by an administrator. No administrative rights are required.

Can you clarify exactly what you saw that suggested administrative rights are required, and what you did to trigger that?

@Atygor
Copy link
Author

Atygor commented Apr 27, 2022 via email

@andersk
Copy link
Member

andersk commented Apr 28, 2022

Running the system-wide installation of 5.9.2 from two different users in the Guests group works fine for me.

@dalstede
Copy link

dalstede commented May 2, 2022

Can you clarify exactly what you saw that suggested administrative rights are required, and what you did to trigger that?

I don't know if OP also uses a Windows Remote Desktop Services environment but that's where I encountered the Problem. On the RDP Client (Windows 10) I could install 5.9.2 as the Administrator and run it as unprivileged user. In the remote sessions however the unprivileged users could not open Zulip. Per the zulip client settings it was configured to open on startup but it didn't. When users clicked the desktop icon, it wouldn't start either.

I logged in via web access and noticed 3 of our users were online. I checked with them and one had opened Zulip in the browser, while the other 2 must've had an old config where I hadn't yet deactivated the auto-update, so when confronted with the "update for me / update for all" dialog they will have installed a local version in their AppData directory because that's what they were using.

As Administrator I uninstalled 5.9.2 and reinstalled 5.8.1 and users could log in again. We run 2 Windows Terminal Servers and the behaviour was the same on both.

@Atygor
Copy link
Author

Atygor commented May 4, 2022

Yes, indeed we are using Windows Remote desktop, with one centralised install and for each user own appdata config, I think that the users had no access to one of the new files in install folder, if it was already opened in an other instance.

@dedisoft
Copy link

Hi,
Same here. Each user has Zulip installed on their own profile (app-data).
So they are all rights on folders used by Zulip.
But since 5.9 version, Zulip refuse to start. The program starts and then close without any errors or error on any log file.
How can we enable a debug log at startup ?
Thanks

@dedisoft
Copy link

Hi,

As I see, Zulip Desktop use Electron 18.0.1.

Electron 18.2.2 includes a fix for "crash on Windows when opening apps in multiple, separate user sessions.".

https://www.electronjs.org/releases/stable?version=18&page=2
electron/electron#34161

Perhaps this is the cause of the bug.

Can you try using Electron 18.2.2 ??

Thanks !

Regards,

@dedisoft
Copy link

Hi,

For our internal needs, I've compiled Zulip desktop using these versions of eletron (by modifying package-lock.json file) :

    "electron": "^18.3.14",
    "electron-builder": "^23.5.1",
    "electron-notarize": "^1.2.1",

Zulip desktop now runs fine on our Windows Server 2022 environment.

Regards,

@xchemax
Copy link

xchemax commented Oct 4, 2022

Same problem here, 2 users without administrative permissions can't run on the same server with Remote Desktop Services. Tested on Windows 2012 and 2022.

@xchemax
Copy link

xchemax commented Oct 10, 2022

I have compiled 5.9.3 with the electron versions indicated by dedisoft and works perfectly. Thanks dedisoft!

@andersk
Copy link
Member

andersk commented Jan 5, 2023

We released Zulip Desktop 5.9.4 today with Electron upgraded to 22.0.0. Can someone affected by this issue check if it’s now resolved?

@xchemax
Copy link

xchemax commented Jan 5, 2023

Thanks for the upgrade, I can confirm that the problem is solved with this version.

@andersk andersk closed this as completed Jan 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants