Unsupported Automatic deployment and provisioning for the Desktop App

[john_doe]

TLDR
At the moment, the Desktop App is rather useless for automatic deployment and provisioning.
The installer is missing (at least) a few options:

• install parameter to prevent auto-launch after install
• install parameter to disable "launch on login for all users on this machine"
• a way to provision the Desktop App without user interaction

All of these should be trivial to implement. Also useful would be complete and up-to-date documentation ...
/TLDR


3CX is planning to phase out the legacy Windows client and replace it with the new „Desktop App“. Therefore I’ve started looking into how to automatically deploy and provision the new app.

Unfortunately, in that regard (and right now), the Desktop App looks like a step-back to me, compared to the legacy client.

There are a whole bunch of forum posts about install options for the Desktop App. But even though many of these threads are only 2-3 months old, a lot of the information appears already obsolete and doesn’t work any more with the current version of the Desktop App installer (3CXDesktopApp-18.7.10.msi).
Apart from various forum posts, I can't find any (complete and current) documentation on how to deploy the Desktop App.

Some things that work for me (with 3CXDesktopApp-18.7.10.msi):

Silent machine-wide install with custom directory
The default for the machine-wide install is C:\Program Files\3CXDesktopApp.

Using the MSI parameter APPLICATIONROOTDIRECTORY, I'm able to set a different directory for the Desktop App:
msiexec /i 3CXDesktopApp-18.7.10.msi /qn /norestart ALLUSERS=1 APPLICATIONROOTDIRECTORY="%ProgramFiles%\MyCustom3CXFolder"


Preventing app auto-launch after machine-wide install
After installing the MSI it will launch the Desktop App right away. When you deploy under the SYSTEM account for example, that’s not something you want.
The MSI should really have a property to prevent that, but at the moment there doesn’t seem to be one.

To avoid the auto-launch, I’ve found this – rather complicated – workaround:
Using Microsoft Orca, you can generate a transform (.mst) for the 3CXDesktopApp-18.x.xx.msi installer. In the transform, you delete the last action (LaunchApplication, sequence number 6601) from the InstallExecuteSequence table.
After saving the transform, you can install the Desktop App like this:
msiexec /i 3CXDesktopApp-18.7.10.msi /qn /norestart ALLUSERS=1 TRANSFORMS=“3CXDesktopApp.mst“

The annoying thing with transforms is that they only work with the exact MSI they were created with. When you want to deploy a new version of the 3CXDesktopApp-18.x.xx.msi, you have to create a new transform as well.


Automatic provisioning for the Desktop App
The legacy Windows client can be provisioned by opening the .3cxconfig file attached to the welcome email.
However, the „new and improved“ Desktop App can’t seem to open those files.

Instead, it's suggested that every user should log in to their webclient and manually provision the Desktop App from there.
To be honest, I find that idea absurd and completely detached from reality.

So far, I have not figured out how to automate the provisioning process, and I couldn't find a solution on the forum either.

The „missing link“ is the user-specific provisioning URL that has to be supplied in order to initialize the Desktop App:
tcx+app:https://<3CX hostname>:5001/p/<provisioning directory>/<user-specific ID>

I’ve found only 2 places where you can get that URL:

• by clicking the „Provision“ button in the webclient
• in the the welcome email, encoded in the QR code attachment (qr.png)
  Unfortunately, the URL is not contained anywhere in the email text.

Does anyone know of a way to get the provisioning URL for a specific user/extension using a script for example?
All the URL components, apart from the user-specific „provisioning ID“, are static and known beforehand. So there's probably only one small thing missing to automate provisioning.

Grabbing the provisioning URL with wget or curl, you end up with exactly the same file that is attached to the welcome email (with the .3cxconfig file extension).
Why the Desktop App can’t load its provisioning options from the 3cxconfig files - just like the legacy Windows client - but has to retrieve the identical data via https, is a mystery best left for the 3CX developers to solve.


As I have - sadly enough - come to expect from 3CX, the whole deployment and provisioning process is - at least at this time - poorly designed and not thought-out at all.
Documentation is non-existent, obsolete or incomplete and if you want reliable, automated deployment you’re basically forced to cobble together a solution out of various parts.

At the moment, I’m planning to stick with the legacy Windows client as long as possible, until these issues with the Desktop App are ironed out.

 

[Pldbvs60]

Hello,

Thanks for posting this topic. We're facing the same issue here. Did you found more informations about these concerns ?

KR,

 

[john_doe]

Unfortunately, I have not made any progress with this.
Since no one else seems to have any ideas either, I'm going to put this issue on the back burner and stick with the legacy client for the time being.

Maybe 3CX will actually come up with a coherent deployment concept in a few months - we can always hope

 

[kathrin]

Hey!

I was in contact with 3CX too, regarding the automatic User-login and got a suggestion per private Message. I am going to quote it below:

"What the browser does is invoke the EXE and pass as argument the HTTP/S link that the QR code resolves to. To be more precise, you could load a config like this:

3CXDesktopApp.exe tcx+app:<HTTP/S link of QR code>

After my question on how I should get those hundrets of QR Code Links I got the following answer:

"I suppose you could get the QR codes of the users from the Management Console and via GPO, also have a CMD script run on startup doing this. For now the only way I can think to get the codes is to download the images one by one from the users section, then upload them to a decoding site like: https://zxing.org/w/decode.jspx which will give you the links."

We decided to use the Webclient PWA and "fake" it being an installed application to our Users. Until this is going to be possible with the RestAPI, SSO or any other way, we are staying in this config. I would also really like to start using the desktop app but that simply isn't possible to roll out in our company with this provisioning from Webclient thing.

Hope this helps!

Regards,
Kathrin

 

[john_doe]

Hi,

thanks for your input!

"I suppose you could get the QR codes of the users from the Management Console and via GPO, also have a CMD script run on startup doing this. For now the only way I can think to get the codes is to download the images one by one from the users section, then upload them to a decoding site like: https://zxing.org/w/decode.jspx which will give you the links."

That is a ... let's say interesting idea, and leave it at that

I have looked at a couple of those "Welcome to 3CX!" emails and checked the URLs from the attached qr.png.

It seems to me that the user-specific "provisioning ID" (the URL component at the end) is the same as the name of the .3cxconfig attachment, minus the file extension and the 3cxProv_ prefix.

For example, if the attachment is called

3cxProv_ABCD12DEFG100.3cxconfig

On our case (3CX configured with 3 digit extensions) the recipient's extension is "100" (last 3 characters of the filename).
The provisioning ID would be "ABCD12DEFG100".

So the URL in the QR code (of that same email) should be

tcx+app:https://<3CX hostname>:5001/p/<provisioning directory>/ABCD12DEFG100

If that pattern works for all provisioning emails, one could probably use it for automating deployment.

But that sounds like a lot of work for an issue that the 3CX developers could fix with a few trivial changes to the provisioning email template or the Desktop App itself - it they actually cared.

 

[bitn2]

At the moment the deployment with the version 18.8.580 doesnt work at all... Can you test this on your side?

 

[Twigglett]

I found some things helpful in this thread, so I'll give back what I can.
The provisioning link can also be found in the existing v16 softphone XML configuration file if you have that.
I have used the existing v16 config to rewrite for v18 for deployment.

I have attached the powershell script in .txt format for anyone interested.
Please read and understand the script before you run it. Don't run random scripts you find online.

 

[bitn2]

Looks nice... but msiexec doesnt work anymore with the actual version. Are there any ideas why?

 

[dranjbar]

Also couldnt find an easy way to deploy/provision the desktop app to our users.
We ended up using GPOs to install the PWA on login, and launch the PWA app after 30 seconds of the PC starting up.
Since we are M365 integrated now, our users can just click on the "Microsoft" button on the PWA to login to the client.

 

[jameshs]

Update: Sorry having lots of problems pasting code below, does not like closing brackets, I've had to replace with closing braces. Trying to fix encoding.

I've figured out a way to find out all the user provisioning URLs by directly querying the PostGres backend on 3CX, obviously this is not supported, but can help with bulk deployment.

You can find DB password in /var/lib/3cxpbx/Bin/config.json

Open PostGres

psql -d database_single -U phonesystem -p 5432 -h 127.0.0.1

The following is for extensions with a length of 3, you may need to modify numbers for 4 digit extensions.

SELECT Substring(value FROM 19 FOR 3} AS Ext,
       Substring(value FROM 9 FOR 13} AS ProvURL,
       value                          AS File
FROM   dnprop
WHERE  name = 'PROVFILE';

To Export to CSV

\copy (SELECT Substring(value FROM 19 FOR 3} AS Ext, Substring(value FROM 9 FOR 13} AS ProvURL, value AS File FROM dnprop WHERE name = 'PROVFILE'} to prov.csv csv header

Can also include AzureUPN if set

SELECT Substring(pv.value FROM 19 FOR 3} AS Ext,
       Substring(pv.value FROM 9 FOR 13} AS ProvURL,
       pv.value                          AS File,
       upn.value                         AS UPNAddress
FROM   dnprop pv
       LEFT JOIN dnprop upn
              ON pv.fkiddn = upn.fkiddn
WHERE  pv.name = 'PROVFILE'
AND upn.name = 'AZURE_UPN'
ORDER  BY ext;

 

[jameshs]

To avoid the auto-launch, I’ve found this – rather complicated – workaround:
Using Microsoft Orca, you can generate a transform (.mst) for the 3CXDesktopApp-18.x.xx.msi installer. In the transform, you delete the last action (LaunchApplication, sequence number 6601) from the InstallExecuteSequence table.

You can also change the Condition to “NOT REMOVE AND UILevel >3”, which is what 3CX should do so it does not run during silent installs.

 

[ChrisC_3CX]

@jameshs

There indeed is no supported method to access a list of the provisioning links for the 3CX Desktop app, but for anyone one else reading this, as already mentioned by @jameshs himself, I do have to stress that accessing the 3CX Database in any way, even if it's just for reading data, is unsupported by 3CX so do keep that in mind before proceeding with this.

 

[jameshs]

@jameshs

There indeed is no supported method to access a list of the provisioning links for the 3CX Desktop app, but for anyone one else reading this, as already mentioned by @jameshs himself, I do have to stress that accessing the 3CX Database in any way, even if it's just for reading data, is unsupported by 3CX so do keep that in mind before proceeding with this.

This is just one aspect of @john_doe original post that I have a work around for. The other issues of not auto-launching 3CX after a silent install and a better way to deploy across large network still need to be addressed by 3CX. We should not need to manually edit MSI files after each release or force users to manually login to a website to provision 3CX.

 

[Terry_S]

Justed wanted to weigh in on this thread and say we're find the lack of auto-deployment disturbing.
Yes, a smooth working application should be the primary objective, but rolling out is the first step and depending on users to do it shouldn't be the default advice.

Step 1: installation for a machine, not user
This reminds me a lot of the starting days of MS teams, where the software would also be installed in the user directory instead of having a machine-wide installer. Deployment through GPO or other (even basic through cmd) would be a step forward.

Step 2: auto start app
Do not auto start the app after it's installed. This prevents the user having to close an unprovisioned app if he doesn't need it.

Step 3: auto provision
The user shouldn't have to login in a provision himself. This is very confusing and let's the user believe he should work through the web client. Instead, Provide a way to provision the app through a command. As tested today, calling the application .exe followed by the name of mailattachment seems to work. The only problem is you have to manually send a provisioning link to have each unique file for deployment.

It's hard to believe that the people who maintain this product, can't give us (admins) a way to provide a working 3CX environment for all users, without them having to think about that.

 

[Evolute IT]

Justed wanted to weigh in on this thread and say we're find the lack of auto-deployment disturbing.
Yes, a smooth working application should be the primary objective, but rolling out is the first step and depending on users to do it shouldn't be the default advice.

Step 1: installation for a machine, not user
This reminds me a lot of the starting days of MS teams, where the software would also be installed in the user directory instead of having a machine-wide installer. Deployment through GPO or other (even basic through cmd) would be a step forward.

Step 2: auto start app
Do not auto start the app after it's installed. This prevents the user having to close an unprovisioned app if he doesn't need it.

Step 3: auto provision
The user shouldn't have to login in a provision himself. This is very confusing and let's the user believe he should work through the web client. Instead, Provide a way to provision the app through a command. As tested today, calling the application .exe followed by the name of mailattachment seems to work. The only problem is you have to manually send a provisioning link to have each unique file for deployment.

It's hard to believe that the people who maintain this product, can't give us (admins) a way to provide a working 3CX environment for all users, without them having to think about that.

I am hoping the upcoming REST API will allow us to grab provisioning information easily in order to script it.

100% agree we need a true deployment solution, not just GPOs too. Intune and RMM.