Kaseya Community

How do I stop users with admin rights from uninstalling the client?

  • I have a few users with admin rights. I don't want to take away their admin rights, but how can I stop them from uninstalling the client, like prompt for a password or something? Thanks.

    Legacy Forum Name: How do I stop users with admin rights from uninstalling the client?,
    Legacy Posted By Username: ck75
  • Hi

    There are two scripts, one that removes the systray icon, and a different script that removes program group.

    Howard Cunningham




    Legacy Forum Name: Server,
    Legacy Posted By Username: howardc
  • Thanks Howard, I am going to try the script for the program group.

    Legacy Forum Name: Server,
    Legacy Posted By Username: ck75
  • Hi Howard, we just got Kaseya up and running, could you please direct me to those scripts?



    thanks! Joe


    Legacy Forum Name: Server,
    Legacy Posted By Username: jfountaine
  • We just purchased Kaseya and my scripting skills need help. Can anyone provide a step by step process for this? I've spent half a day getting nowhere.



    thanks! Joe


    Legacy Forum Name: Server,
    Legacy Posted By Username: jfountaine
  • We just purchased Kaseya and my scripting skills need help. Can anyone provide a step by step process for this? I've spent half a day getting nowhere.



    thanks! Joe


    Legacy Forum Name: Server,
    Legacy Posted By Username: jfountaine
  • Here is the exportd script from the sample scripts section. I think this is the one they are talking about:


    Script Name: Remove K Menu
    Script Description: Remove the Agent folder from the Start Menu. Hide the System Tray Icon (blue K) by disabling the Client Menu (Client Tab - Client Menu). Run this script on machines you do not want to give anyone the ability to uninstall, exit, or stop the Client.

    IF True
    THEN
    Execute Shell Command
    Parameter 1 : rmdir "%ALLUSERSPROFILE%\Start Menu\Programs\Kaseya" /S /Q
    Parameter 2 : 1
    OS Type : 9
    Execute Shell Command
    Parameter 1 : rmdir "%ALLUSERSPROFILE%\Start Menu\Programs\Kaseya" /S /Q
    Parameter 2 : 1
    OS Type : 8
    Execute Shell Command
    Parameter 1 : rmdir "%ALLUSERSPROFILE%\Start Menu\Programs\Kaseya" /S /Q
    Parameter 2 : 1
    OS Type : 3
    Execute Shell Command
    Parameter 1 : rmdir "%WINDIR%\Profiles\All Users\Start Menu\Programs\Kaseya" /S /Q
    Parameter 2 : 1
    OS Type : 4
    Execute Shell Command
    Parameter 1 : rmdir "%WINDIR%\Start Menu\Programs\Kaseya" /S /Q
    Parameter 2 : 1
    OS Type : 5
    Execute Shell Command
    Parameter 1 : rmdir "%WINDIR%\Start Menu\Programs\Kaseya" /S /Q
    Parameter 2 : 1
    OS Type : 6
    Execute Shell Command
    Parameter 1 : del "%WINDIR%\Start Menu\Programs\Kaseya\?*.*"
    Parameter 2 : 1
    OS Type : 7
    Execute Shell Command
    Parameter 1 : rmdir "%WINDIR%\Start Menu\Programs\Kaseya"
    Parameter 2 : 1
    OS Type : 7
    Delete Registry Value - (Continue on Fail)
    Parameter 1 : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{48C76121-4F90-11D5-9884-0050BA85A903}\DisplayName
    OS Type : 0
    ELSE




    Legacy Forum Name: Server,
    Legacy Posted By Username: rodbibeau
  • We use a version of this script to remove the folder from Start menu and rename the services. And we don't enable the client menu to Exit.

    However, from time to time a user either finds a way to uninstall or alter the Kaseya setup. Or the Kaseya agent simply dies and stops connecting to the server. We can still see those machines through LANWatch at every scan (we scan every 2 hours) but some of them have not checked in for a week or even a month in some cases.

    Does Kaseya have any way to find these discrepencies? i.e. what systems are seen as currently online via LANWatch but do not have a recent "check-in"?

    When we manually find these ourselves right now, what can we do to fix the problem? If we re-deploy via LANWatch is says "Installed" but it doesn't cause the agent to re-install or re-connect.

    Any ideas?

    Kaseya,

    Any plans to make it easier for us to indentify systems where the agent has stopped or been uninstalled but is still seen by LANWatch?


    Legacy Forum Name: Server,
    Legacy Posted By Username: kentschu
  • Personalizing (limiting the client menu) and running the script to hide the install can help. The main issue here is that regular users should NEVER be given administrative rights. If they didn't have rights, they could never uninstall, stop or do anything to the agent from the beginning. Giving them admin rights is like saying - do whatever you want to do without restrictions. Now you want to take some of those rights away. My point is why give it to them in the first place?

    Users should not be given the right to install, uninstall, change or modify anything on their machines. IF they need to change something, they should ask their administrator to do it for them so that it is done right the first time. They should be using the programs you provide them to do work, not to spend time playing with settings because they think they can fix it themselves. Allowing users to have free reign is asking for problems. Most help desk tickets are created because users are given more rights than they should have. Limit your exposure and try to start with nothing and only give them the rights you want them to have. You will find that there will be less problems, viruses, phone calls and ticketsin the long run.


    Legacy Forum Name: Server,
    Legacy Posted By Username: elehman
  • Obviously, best practices dictate that users shouldn't have admin rights locally. But in reality at smaller clients, that isn't feasible.

    Nonetheless, in our situation, we are finding the agents stopped running (not necessarily uninstalled) but we don't have a way to easily identify those systems. And since a simple way to identify this and re-push the client would solve both types of problems, I think it's worth brainstorming ideas rather than just trying to lock down admin rights on the desktop in all situations (because that won't solve our issue anyway).


    Legacy Forum Name: Server,
    Legacy Posted By Username: kentschu
  • I can understand that. I would do two things in this scenario - one is to use the personalization script, take off the ability to exit from the taskbar and remove it from the Start menu. The less they can see, the less chance they have to shut down the client. That should leave either the service or the tasks. Now the service's configurationshould be able to be protected by securing the registry keys and foldersto domain admins only. The tasks and the service itselfremain the problem. If they have local admin rights, it is very hard to prevent them from killing the agent tasks unless you can somehow deem them as a vital system process. With admin rights, they should be able to just go into services and stop it if they are savvy enough.

    So i understand the need for admin rights when you have no IT staff in a smaller client because you don't want phone calls every 5 minutes because they can't install Flash on their favorite webpage or something. However the dilemma is that they already have ultimate control, so taking away that control is very difficult. If the user has enough knowledge to be dangerous, they will know how to stop the agent and will continue to do so and there is not too much you can do about it unless you have something running in the background that they can't see and can't stop that will relaunch the service every so often. If they have a server, you might look into running something on there that will poll the agent service on each machine every 30 minutes and start it if it is not running. That might be an idea rather than trying to restrict permissions.


    Legacy Forum Name: Server,
    Legacy Posted By Username: elehman
  • I agree. And we've taken many of the steps discussed, so this problem is not wide-spread, but still exists for us.

    I'm hoping in the not-too-distant future, Kaseya could integrate the LANWatch functionality/install capability with a more automated mechanism that basically lets you easily identify and perhaps automatically re-push the client to a system where the service has been stopped.

    Here's a question:

    Let's say that the agent/service has been stopped (either by a user or a system error/crash) but not uninstalled. Is there a way for us to easily identify that system via Kaseya and to re-deploy or re-start that agent remotely?

    We aren't currently deploying Kaseya via login scripts but perhaps that would solve some of this problem. Though there are many users that leave their systems on for weeks at a time without rebooting or logging in again...

    I've found that when we try to re-install the agent via LANWatch, if the agent was merely stopped but not uninstalled, it says that it installs but doesn't actually make the agent run again. And as I mentioned, finding those systems is not easy to begin with, it requires checking various screens (LANWatch, Client Status, Delete Clients) to compare last checkin and last seen dates.

    Any additional thoughts or ideas?


    Legacy Forum Name: Server,
    Legacy Posted By Username: kentschu
  • Good point. An automated push mechanism would be a very nice feature - either to re-push when its been offline for X amount of time, when the agent version has been updated or what would be really nice would be a domain-based push. In other words you should be able to specify that if any machine is a member of the domain that they automatically get re-pushed from their domain controller - including new members that get added, with an alert that the client has added a new machine (so that you can adjust your accounting on your end).Some caveats though - at least one machine would have to be online at all times(ie. the domain controller)and they would have to be in a domain. If the agent is not running, how can you tell it to run if you don't have any local access to that network other than the agent itself?

    Now these push features and the ones you are looking for can be accomplished either via login script or group policy software policies. However as you said, even after a push, if they leave their machine on for weeks and the service has been stopped - it doesn't matter - the agent never comes back online until you go in and restart it or reboot the machine.

    A possible workaround to this would be - assuming they have a server and it is always online, is to make a script run on it once a day (or whenever you want) that will restart the services for you. This would be kind of manual, but you could have a simple batch file perform a remote service start from the server. you would just have to manually specify each machine's name in the command syntax.

    http://technet2.microsoft.com/WindowsServer/en/Library/03928250-2796-4253-8fb1-b25329ddf35f1033.mspx?mfr=true

    Other than that, I will see if there is a Group Policy way to force this to happen on a regular basis.


    Legacy Forum Name: Server,
    Legacy Posted By Username: elehman
  • Yes, we always have one or more agents still running within that site. So, we always have multiple systems that can scan and find these missing systems. Obviously, the server as you mentioned, would be completely under our control so we can always have the agent running there.

    This isn't a widespread problem but we regularly find a few systems here and there that have this problem, but over time if we're not finding them and re-starting/re-deploying them, that number will continue to grow.

    I'd rather not run a custom script from the server to check each machine because maintaining that script with computer names would be a big pain. As I mentioned, I'm hopeful that Kaseya will be able to tweak a few things in the future to allow us to at least quickly identify these systems.

    Is there any easier way to find these systems that the one we use right now?

    Here's what we do: Each week, we create a filtered view for machines that have been offline for at least 5 days. Then we copy that list of computers in Notepad. Then we go over to LAN Discovery (either Install Clients or View LAN) and look for each of the systems from our list to see if they've been seen on the network in the past 5 days. Inthe cases where the agent stopped (for whatever reason), they often show up in the most recent (every 2 hours) LANWatch scan, so we know that something is wrong since they haven't checked in for more than 5 days. Then we work to get the agent running again.

    Is there an easier way?




    Legacy Forum Name: Server,
    Legacy Posted By Username: kentschu
  • If you want automation (assuming it will not be a feature in 4.6), then you're talking Visual Basic. I have some programmers on staff that i can ask, but maybe someone on here has already done it.

    Here's what you would need - a VB program/script that is able to query Active Directory, find the list of registered machines inits domain, then check each one to see if the agent service exists and is started. If it not started, then start it. If it does not exist or will not start, then execute the agent install (stored on the server) on that machine, then try to start the service again. The script could loop several times in case it doesn't install or doesn't start the service on the first shot. It could even send a command touninstall and reinstall the agent as a last resort. At the end of the script, you could always generate an email to you, saying that these listed machines refused to launch the service - making your search for offline machines and/or problematic agent installsmuch easier.

    This is easy for someone who knows VB sincemost ofthe commands you would need to do this are already built into all versions of Windows. So you could almost do it in a batch file, but querying AD and automating this is better left up to VB. Kaseya can be used to launch the VB script on a regular basis.

    If i find anything like this i will post it for you.


    Legacy Forum Name: Server,
    Legacy Posted By Username: elehman