Zulu: Installation for All Users


I am looking to implement FreePBX at 2 clients who have Complex IT environments, but Zulu will be a problem.

Because these environments- for 2 separate reasons - rely on Roaming Profiles, Zulu won’t work. It installs only to the %appdatalocal% folder for a specific user, not Program Files as would be traditional.

This means that when the users log on to a different PC they would need to reinstall Zulu, and we don’t want that.

The existing solution, 3CX, installs to Program Files and stores it’s config data in %appdata%, so we can install it to all the PCs and when they log in it just works.

I know a few apps these days have a tendency to do this, including Dropbox and even Microsoft’s own OneDrive client, but it always causes headaches for us in these environments.

Is there a way to install Zulu for all users in this way?


I just did some testing with the Client.

I moved %localappdata%\Programs\Zulu to %ProgramFiles%, replaced the desktop shortcuts and it seems to work.

The config does seem to be store in the roaming AppData folder so in theory this should work.

I would just need to re-pack the app in to my own installer so that the uninstall routine works as desired.

Can I do this with Zulu as it is a commercial module? Happy to make the package available to the community.

Depending on what they need, could UCP+webrtc phone be an option? All in the browser then.

Trying to avoid that. User acceptance would be poor. They’re used to an app on their desktop and I don’t think they’d get on with a web alternative.

Didn’t see your reply until now. Did you open a support ticket with Sangoma? If there really is not a way you could submit a feature request to get it added.

Yes I may do that.

As an update, my attempt to make this work myself fell flat somewhat. Yes I was able to re-package the app in my own installer and it worked beautifully - until 2 users on the same terminal server tried to run the app at the same time - it was trying to write in to the Program Files folder. That said it has just occurred to me that I didn’t try changing the working directory on the app.

No good - just tried it and even if I install it separately from the official installer, so it is running from AppData, the app gives errors about “Address In Use”. I hadn’t read it properly in the past but thinking about it now the app must listen use a static local port (either as its source port or as a listener for notifications).

I need some clarification here…

Are you running roaming profiles on PCs, or are you running terminal services and thin clients?

If you’re running terminal services (or xenapps, or other RD clients) with thin clients, then %ProgramFiles% is going to give you an issue. It needs to be something unique for the user. You could try %UserProfile% instead of %ProgramFiles%, which should roam properly AND be unique to the user.

It is indeed terminal services with roaming profiles. The program files thing is inconsequential. The problem is that Zulu listens statically on port 5006, so it can’t run more than once on any given TS. No good when we have 10 users per TS. I’ve tried RDS IP Virtualisation but the app listens on rather than a specific local IP, so it doesn’t work.

In thinking about this further, you will probably have issues with running soft phones on terminal server anyway; audio (and especially microphone) has always been a little sketchy at best with terminal services (I have gotten stuff like youtube to work, but it can still get pretty choppy)

You’d probably be better off getting actual phones (Yealink, etc), and putting them on the desks. Worst case if you don’t have the physical connections for the network, put the phone on the network, plug the thin client into the phone… that does a couple of things; it saves you having to run more cable, and it will also give the voice priority on the network (since the thin client is plugged into the phone)

Terminal Services really just isn’t meant for multimedia stuff.

TS is quite capable of doing the audio, but that’s irrelevant we won’t be using the soft phone in Zulu anyway, everyone will have desk phones, the client wants the CTI functionality.

You can open a feature request to add a setting in Zulu to let you set the listening port.

A more useful solution would be to have the listening port opened dynamically based on the available ports. What is this port for, is it for notifications?

It can not be dynamic. Its how the plugins for things like the browser and office365 and outlook talk to the client. It has to be static as the plugins have to know how to reach the client.

Could you not write the port number in an ini file that the plug ins can read? Each time it runs and starts listening on the port referenced in the ini file and if it is in use choose another one and update the ini? Or use 5006 plus the session ID? On a normal workstation the session ID would be 0.

Should Zulu not be listening on the loop back address for this instead of Sounds like a security vulnerability to me.

All I am saying is millions of businesses use terminal services (or Citrix, as is the case here ) and roaming profiles and their apps work, so surely there must be a way of making Zulu work.

I think we are going to have to find a different CTI solution for this client.

Please open a feature request. You are more than welcome to find a different CTI solution for your needs. I think you will find very little exist that works well.

Anyways please open a feature request and I am sure the team will take a look.

Yes that is unfortunately what I have found, but unfortunately Zulu physically won’t work in this customers systems.

Have you put in a feature request.

Not yet been responding to this on my phone from the sofa. Will do though.

I’ve gone off on a tangent really because I only found out about the port 5006 issue yesterday.

We have another client who use roaming profiles with standard desktops (no Citrix/VDI/TS etc).

The challenge in that environment is every time they move desks they’d need to reinstall Zulu, which will irritate them. I’d much rather put Zulu in to Program Files on each of the workstations so it is already there.

So my original question is - would I be permitted under the commercial license to pop the Zulu Files in to my own MSI installer so I could do this?

If you’re not using it as a softphone, what features are you wanting? Personally, I use “OutCall” for caller ID and dialer integration… it’s pretty slick.