Windows Desktop App Auto Start

[JBSE]

I have run into an issue whilst deploying the v18 desktop client (we are a new customer of 3CX, going live soon)

We are installing the app using msiexec to add it for all users of the machine (msiexec.exe /i "installer.msi" ALLUSERS=1 /norestart)

However, it then auto starts for every user who logs on to the machine (this has been particularly apparent on our RDS test environment). The option on the 3CX right click menu to launch on startup has no effect that I can see. A registry entry is created for 3CX autostart (in HKLM) - deleting this, as expected, stops the auto start, but does so in all circumstances.

Is there any fix for this/has anyone else experienced similar?

 

[JBSE]

As an addendum, I have installed the app via the method advised here:
https://www.3cx.com/docs/desktop-app-windows-terminal-server/

The autolaunch "issue" is still present

 

[SteveITS]

The "normal" install is by account/user so you could install it that way, only for the desired accounts.
Or have them run it on their PC and not on the RDS server?

 

[JBSE]

Many of the users have thin clients, so in that case, local install isn't viable. Install per user is potentially do-able, but adds additional and unecessary load to the User Profile Disks and is something of an administrative pain and I don't feel is a solution for the issue

 

[SteveITS]

Delete the entry from HKLM and add to HKCU? The creation ought to be automate-able by creating a GPO to create the registry entry.

 

[JustinB-PedEnt]

I am using V16 in my live environment but just did a test with V18 in my test system. Like you, I deploy desktops (Citrix) to my users via Thin clients. After installing the client using control panel > Install App on Remote Desktop and deleting the HKLM\..\Run key I verified it doesn't autostart for users.

However, for me the right-click > Launch at Login preference DOES correctly add the autostart key to HKCU\..\Run. I can see the key appear and disappear in real time (after refreshing) as I flip the option on and off. Can you confirm this isn't the
case for you? Perhaps there's some sort of permissions restriction?

Failing that, the best solution is probably what SteveITS suggested: add a GPO to create(or not) the HKCU key for anyone belonging to a specific AD group. Alternatively (a bit messier but what I ended up doing for V16) you could copy the desktop shortcut into all user's Startup folders as well as the Default user, and then remove it for anyone you don't want the client to autostart for. GPO/Reg is definitely cleaner.

 

[JBSE]

I am using V16 in my live environment but just did a test with V18 in my test system. Like you, I deploy desktops (Citrix) to my users via Thin clients. After installing the client using control panel > Install App on Remote Desktop and deleting the HKLM\..\Run key I verified it doesn't autostart for users.

However, for me the right-click > Launch at Login preference DOES correctly add the autostart key to HKCU\..\Run. I can see the key appear and disappear in real time (after refreshing) as I flip the option on and off. Can you confirm this isn't the
case for you? Perhaps there's some sort of permissions restriction?

Failing that, the best solution is probably what SteveITS suggested: add a GPO to create(or not) the HKCU key for anyone belonging to a specific AD group. Alternatively (a bit messier but what I ended up doing for V16) you could copy the desktop shortcut into all user's Startup folders as well as the Default user, and then remove it for anyone you don't want the client to autostart for. GPO/Reg is definitely cleaner.

Thanks @JustinB-PedEnt. I was trying it with our test account and for some reason it isn't writing that registry value to HKCU. It does it for me on the same server (as an administrator)

Out of interest, did you test it with a "normal" user or one with more privileges?

I'll do some more testing next week - I am unsure why it isn't writing the relevant key for the test user in question

 

[JustinB-PedEnt]

That's good news. Sounds like we at least found where the disconnect is. I first tested with an admin account, but had no problems with a non-administrator account either.

 

[SteveITS]

isn't writing that registry value to HKCU

Have you looked at RSOP/Group Policy Results Wizard?

Any user has permissions to write to their own registry. It could be done with reg.exe in a login script for instance.

 

[JBSE]

Have you looked at RSOP/Group Policy Results Wizard?

Any user has permissions to write to their own registry. It could be done with reg.exe in a login script for instance.

Thus far, I haven't done anything with GPO, just toggled the switch in the app (right clicking on the taskbar icon). On my admin user, as @JustinB-PedEnt mentioned, the reg key is getting updated in real time. The test user should have the ability to write to their HKCU (Windows wil undoubtedly be writing other stuff). However, we do restrict access to regedit for users, so I am wondering if there is some oddity going on with that (it may be a far out idea, but worth a look!)

On the face of it, my only testing with our "limited access" user was deceiving me into thinking the software wasn't playing ball - it looks like the problem is somewhat more nuanced

 

[JBSE]

On further investigation with Process Monitor, it would appear that the software is adding the startup value by doing the folliwing:


This seems to be clashing with a policy we have to prevent users running regedit (though it isn't disabled from running silently) and consequently the setting change fails to persist to next launch

I'm not a software expert, but I would have thought using a RegSetValue would have been a better option that doesn't potentially hit issues running regedit in such a manner.

Removing the policy to prevent users running regedit resolves the issue (though is undesirable). The other "fix" for it would potentially be using the presence of a file in the user folder to write the relevant registry key through Group Policy Preferences to give users some flexibility over the auto launch themselves