Will leave this here. Here is a script I use with a powershell to always show the tray. It puts it the first icon next to the clock. I also use a modified version of Darren's getfile script here to transfer the PS1 in the script. Hope this helps. I will say this restarts explorer for the user and I have it scheduled to run every 4 hours on a group. So it is kind of "bringing a shotgun to a knife fight" kind of thing but it uses script state so it only does it once per user per machine. Show Automate Tray Always.xml show_notification_icon.ps1

@Frznto hit me up on slack MSPGeek as bigdessert so I can help you out.

I belelieve it works in cloud. Try to right click the DLL and unblock first.

are you on MSPgeek slack? If so come find me with the same usersname.

Yes this sounds just like the issue we had with @apbirch67. Check that field in the config table and update it to your correct URL if not correct.

BIG SECURITY IMPROVEMENTS!!!! Released Control version 1.0.27 and Automate plugin version 1.0.0.20 today. This release uses MFA codes if configured for each user that are the same codes used to access automate. If a user is configured to require MFA then so is this plugin.

Uploaded new version 1.0.0.18 of the Automate DLL plugin. This allows to IP filter for extra security.

Can you confirm if one of the users logs into the control center they can in fact see and/or edit passwords? @automationGuy This is under tools->RMM Password Link

So does the manage plugin or any other plugin that offers 2-way communication. I could implement a OTP type 2FA but I don't believe I can easily tie into the automate 2FA because that is a plugin itself. The helper is completely unaware of the server installation on control so I can't use that for 2FA so I am stuck with either creating my own or finding another way to secure or minimize risk. If you have other ideas I am all ears!

The hard part about 2FA is that really the only attack surface is during the login to get the token. If you enable 2FA on control and automate that helps but the API is still there so there is an attack surface present. Not sure how I would even do it if I wanted to but it would have to be separate from the Automate or Control 2FA implementations. Maybe as an alternative would be to limit exposure in different ways like IP filtering or other methods.

I don't have any plans for SSO. There is just no way that Control is aware of the user that is logged into Automate and definitely no way to validate it. If they ever add that then sure we can look at SSO but for now it has to stay separate. If you don't care about security just create a Super Admin user with basic user/password and set your tokens to never expire. You would very rarely get prompted to login then. - I DO NOT SUGGEST DOING THIS.

New version 1.0.0.17 posted of the dll plugin for automate that corrects an issue with permissions that was only looking at client level permissions and not computer level permissions. This allows the group permissions to work under user roles where "All Clients" isn't selected.

Not sure what you want me to say. Free product and you can decompile the exe to see what it does..... Audit the code or pay someone to audit the code if you are concerned. The only thing sent off-site are stats which are just integers.

not at this time. I wish they would add this to mobile....but out of my control.

Want to hit me up on MSPGeek slack? bigdessert is my name there.