How To Keep Teamviewer Running In The Background Windows 10

0 views

Skip to first unread message

Message has been deleted

Odina Conkright

unread,

Jul 16, 2024, 3:29:42 AM7/16/24

to georadorhand

I'd need to confirm if there is something that can be ran to keep teamviewer running on the computer even if the end-user decides to exit out of the application if I have setup it for unattended remote access. I can't seem to find a way to fire up Teamviewer remotely if someone has exited out of the program.

how to keep teamviewer running in the background windows 10

Descargar Zip --->>> https://urlcod.com/2yPEVd

I'll reinstall my machine and make some security changes, however I'm wondering: would the same thing have been possible if my session was locked? Does locking one' session protect against any form of remote control?

This is true even for legitimate use of Teamviewer. It is normal to keep the machine running, lock it, go home, then use TeamViewer to access your machine from home. It's how "work from home" was done for a long time for many people. The computer is still running and all the functions still work.

TeamViewer works like physical access to the machine. The remote user would still have to log in to the Windows session, if you locked the machine.I think it can still transfer files, if I'm not mistaken. So you wouldn't be 'safe' at all. But it would be a little less convenient for the bad guy.

Locking a Windows computer with Windows+L simply prevents the physical user from interacting with any of the processes running within your user. Any processes you have open in your user continue running and this is why you can download a file and lock your computer, and it will continue downloading while your computer is locked.

Teamviewer interacts with Windows as if an extra keyboard/mouse/monitor were plugged in. This is why anything seen through Teamviewer is the same as what the physical person in front of the computer would see. Other software, notably Remote Desktop, interacts with your user session directly which is why you can log in with Remote Desktop even when the computer appears locked to a physical person sitting there.

If you lock your PC, most forms of remote control become more inconvenient for the attacker but you're certainly not completely safe. Teamviewer may still transfer files as Martin Frholz mentioned. If you want to be certain nobody can use your machine while you're not sitting in front of it, your best bet is to disconnect the computer from the network, hibernate or shut down. On sleep, you should be safe but it depends on your settings. Some programs can wake up the computer and exit sleep, but your computer should disconnect from the network so you avoid the Teamviewer-style attack. You can configure Windows to stay connected to the network while on sleep, and in this case sleep doesn't protect against remote control attacks.

Since in your case you didn't have TeamViewer installed, you should probably be quite concerned about possible malware because if the attacker had the necessary privileges to install Teamviewer, they may have done more than just Paypal. Resetting the PC (ideally with fresh install media) is the best solution there.

A program not requiring user interface interaction will always work - and allow remote interaction - no matter if the screen is locked or not. Network communication is not interrupted because you lock the screen.

If teamviewer is installed on the host level (only possible with admin permissions), remote control works even after locking the screen. Since the remote user would only see the windows login screen he/she would need to enter your credentials to unlock the session before being able to do anything of value.

Assuming your user session did not have admin rights: locking your screen would definitvely have prevented the teamviewer-browser-paypal scenario. It would not have prevented other kinds of issues like data exfiltration, etc.

What I'm trying to do: I'm trying to keep TeamViewer running at home so I can always get to my home computer. The other day it got completely messed up and would not let me connect but everything else on the PC was just fine.

... and to test the script at the above URL, I stopped a service on my computer and pointed the above vbs script to that service and the vbs script will not restart that service, so that's not working.

From time to time on my home computer, TeamViewer hangs or gets messed up in some way and I cannot connect to my home computer. The last time this happened, the TeamViewer UI was still running but there was a little red dot next to the tray icon and the id numbers and password were blank in the UI so I had to right click and kill it and restart the computer and all was OK.

Is there a way I can run some kind of script or something that will completely kill all TeamViewer processes and services and restart it completely? I'd like to schedule this type of activity once an hour so I can be assured of pretty much always being able to get into my home computer or else just wait an hour and it should be back up and available?

I have 20 years in IT with networking background, databases, GUI development, website development, hardware and software installation but no experience in brain surgery. I've given it a good try but am now asking for some help.

Just to add that you'll have to have the PC in a associated in your teamviewer account in a group (e.g. My Computers) and use the same account to connect - otherwise the password change on restart will prevent you connecting (you won't know the new password).

I went into settings and turned off whatever "open" is but keep getting this notification repeatably. I would like to turn it off in notifications if I could figure out what app it is. Clicking on the "i" shows it located Macintosh HD > usr > bin >

Thank you for this post, I was able to do the same. I've also noticed the same item appearing on one of two accounts on my MacBook Pro running Ventura. From the bin file it looks like it arrived on 12/2 @ 1:30 am. As referenced in similar replies to this thread.

I do not have a NAS or any other storage device attached. And honestly this post continues to draw attention to the silent updates vendors push without describing what they are doing to the user. Not ideal in an age when we're all on high alert for hackers.

I've included a link to this thread on my Apple Feedback Assistant ticket. I would encourage any Beta Program participants experiencing this issue to report it as well. The fact that the "open" item is listed with our a vendor, doesn't appear in the install log and has a really vague name running from a hidden folder is just stupid to do to users.

While these notifications are what people are primarily complaining about, the notifications themselves are not the problem. It is what is generating these notifications. Plus, some people are confused about these items. They think those controls in System Settings > Login Items / All Background tasks are the notifications. They are not. Those controls are for the apps themselves. The act of turning it off may, in fact, be what triggers the notification.

It sure sounds like it is a Synology item. Third party hardware vendors often have no idea that Apple has released a new operation system with signification new functionality that affects their product.

According to that screenshot you posted, some of those items are turned off. I don't know if you did that or they were turned off originally. I realize this is very confusing. The bottom line is that no one should ever use this new Ventura interface for any purpose. If you did make changes, and the software you disabled (or enabled) isn't aware of how this new interface works (and virtually no one is), then you can expect the system to get totally confused.

If you are getting any unexpected and/or unwanted notifications about background items, then uninstall the software that is, or appears to be, related. Restart. Make sure you get to a point where you get no more notifications. Then reinstall the software. Never touch the "Login Items/Allow background apps".

Have the same issue with Synology Surveillance station, reaching out to Synology as per expected they say this is an "Apple" issue and to reach out to Apple.... I am still trying to make them escalate to a Dev i can talk to.

There is nothing wrong with calling the "open" command. In this case, the fault is Apple's for showing these entries as "open" or "osascript" instead of "/Applications/Surveillance Station Client.app", which would have been much more informative.

However, Synology should definitely not be re-creating this file every time it gets launched. As far as the notifications go, Apple's software is working properly. This is most definitely a Synology bug.

Thank you for bringing this to my attention and for all of your time and hard work. I will be escalating this case to our Tier 3 Engineers, and Development, along with the information you have provided.

The Developers are in Taiwan, so due to the time difference between there and the USA there may be some delay in responses. Though I will let you know as soon as I hear back from them, and let you know where we are to go from there. Thank you in advance for your patience.

I, too, am getting this message since upgrading to Mac OS Ventura 13.1 on my Intel-based iMac (iMac20,2) whenever I open or close MacCleanse, version 11 from KoingoSW. It will display the message "Background Items Added" as above in "Notifications" twice whenever I open MacCleanse and then again twice whenever I close the app MacCleanse. The MacCleanse and MacCleanse Helper app have already been given Full Disk Access in the Settings > Privacy and Security > Full Disk Access. Looking at the help (man) file for "open" in the Terminal app, it says:

This should be normal unless the file is infected with a virus or malware, right? So, is there something that MacOS users should be aware of from the anti-virus community that is trying to maliciously run using the "open" command? I am also running BitDefender Antivirus for Mac, version 9.2.0, but it does not alert me to anything odd before, during, or after this occurs.

The initial warning once whilst itself annoying to long time Mac users makes some sense as part of educating/alerting less experienced users. I do notice however that it happens normally not just for the initial install but also updates of the relevant apps due to the relevant installers typically re-installing launch daemons/agents during such updates even if this is not strictly necessary. (The developers have been lazy and not put a check in to see if it is needed.)