Kaseya Community

Best Practice to deploy new agents?

  • I am curious what some of the more experienced Kaseya users are doing. We are new to Kaseya and still trying to get the best practices we can in place.


    I would like to know what people are doing to get the agents installed on new users to a network. I have heard of a script that will push out agents to anyone that logs on to the domain, I cannot seem to find this script can someone possibly point me in the right direction?


    I am guessing this is going to be our best option as we have some clients who have wifi for clients/students to connect to, we do not want to monitor these units so I think LAN watch would not be the best option, we just want to monitor the units that are on the domain. Suggestions?

    Legacy Forum Name: Best Practice to deploy new agents?,
    Legacy Posted By Username: jrodirguez
  • If on an AD we make sure we flush the stale DNS records first, then we'll push out from there, after that we tag each machine. Other than that we tend to manually install custom (per client) packages. We do this because we have to tag each covered machine with a service sticker with SLA and inventory number on the machine

    Legacy Forum Name: How-To,
    Legacy Posted By Username: thirteentwenty
  • How do you handle new machines coming into the network?

    Legacy Forum Name: How-To,
    Legacy Posted By Username: jrodirguez
  • Once all machines are covered. I remove the install policy (if applicable). From there if the client wants a new machine on the network we would push it after it was joined to the domain. Luckily we purchase and do all the build outs for our clients so the agent is installed at that time.

    If the client isn't on a domain (AD) we would first have to approve the machine (we generally wont cover any "home" machines). If it passes we have our /dl.asp populated with client install packages, Our POC would then download and install the package from there.

    Legacy Forum Name: How-To,
    Legacy Posted By Username: thirteentwenty
  • jrodirguez
    How do you handle new machines coming into the network?


    We handle new machines by adding a new Group Policy with a Logon Script to run the KcsSetup.exe out of the domain Scripts folder. Link this GP to the top of your domain structure and it will catch all new computers/servers that are added. Just make sure you update the KcsSetup.exe if you update Kaseya or your settings.

    Legacy Forum Name: How-To,
    Legacy Posted By Username: CCDave
  • CCDave
    We handle new machines by adding a new Group Policy with a Logon Script to run the KcsSetup.exe out of the domain Scripts folder. Link this GP to the top of your domain structure and it will catch all new computers/servers that are added. Just make sure you update the KcsSetup.exe if you update Kaseya or your settings.


    Are you doing this just with new machines or are you also doing this to roll out to an exsisting network?

    We were using another platform befor coming on board with Kaseya and we are looking for the best way to roll out agents to networks that are already established and much to large to download one by one on each machine.

    This policy sounds like it would work but I am worried about it running each time the user logs on, there would be no need to install a new agent each time correct? Or if multiple users use 1 machine would it install multiple clients?



    Thanks for the help in advance!

    Legacy Forum Name: How-To,
    Legacy Posted By Username: jrodirguez
  • We use it in both situations: Original rollout (though I prefer LAN Watch) and adding new machines.

    When you create the agent package there are command line switches you specify in the package. One of these (I can't remember which) tells the KcsSetup.exe to terminate if Kaseya is detected. This prevents any type of second install, which wouldn't work anyways. You can also bind administrator credentials into the package so the users don't need to have admin privlidges to run.

    I like having this package running all the time like this so we catch when an existing machine is rebuilt.

    Legacy Forum Name: How-To,
    Legacy Posted By Username: CCDave
  • CCDave
    We use it in both situations: Original rollout (though I prefer LAN Watch) and adding new machines.

    When you create the agent package there are command line switches you specify in the package. One of these (I can't remember which) tells the KcsSetup.exe to terminate if Kaseya is detected. This prevents any type of second install, which wouldn't work anyways. You can also bind administrator credentials into the package so the users don't need to have admin privlidges to run.

    I like having this package running all the time like this so we catch when an existing machine is rebuilt.



    Thanks for the response again Dave.

    Can you please let me know if you are getting the same results I am worried maybe I am missing something.

    I have a few agents installed on servers and when I attempt to scan the ip ranges it never updates, or at least it is taking at least 10-15 to show up on the install agent list. Is this normal? Sometimes it looks like it is not even scanning the ip range.

    Legacy Forum Name: How-To,
    Legacy Posted By Username: jrodirguez
  • jrodirguez
    I have a few agents installed on servers and when I attempt to scan the ip ranges it never updates, or at least it is taking at least 10-15 to show up on the install agent list. Is this normal? Sometimes it looks like it is not even scanning the ip range.


    Depending on the IP range you are scanning, and what else your K server is doing at the time, it can take several minutes for the LAN Watch to show up. LAN Watch runs as a several step process. Basically it runs a scan of the IP range and dumps the results to a text/xml file. From there it uploads the file to the K server where it processes it into the database. Depending on the refresh intervals of your agents, script cycles on the K server, workload, bandwidth, etc, it can take several minutes for the wanted data to show up.

    Legacy Forum Name: How-To,
    Legacy Posted By Username: CCDave
  • We've only just started rolling out Kaseya since Dec 09. The procedure we've put together so far for the roll out to a new client is this (feel free to critisize if there's a better way)

    Kaseya agent installation
    1. Choose a primary workstation in the network environment you are setting up
    2. Download the default agent from http://xxxxx/dl.asp
    3. Install the agent on your primary workstation
    4. Once installed, go into Kaseya, go to System->Machine Groups->Create / Delete
    5. Name the machine group – City Medical Centre = city-medical-centre; Figtree Sales = figtree-sales; etc all in lowercase, no spaces, using dashes for space
    6. Go to the Agent menu and select “_default” from the “Select Machine Group” drop down menu (we renamed our default group so it always sat at the top)
    7. The machine you setup should be in this menu
    8. Click Install Agents->Change Group, then tick the machine you have just installed from the list and change the “Select new group ID” to the group you created then click “Move”
    9. From the “Select Machine Group” drop down select your new group, your machine should appear.
    10. You will need to create a Kaseya service account on the server. Create a user called monitor with a suitable password (document this in Autotask). Give the account admin rights so that it can install patches and software on each computer without elevation.
    11. On the Agent page, go to Configure Agents->Set Credential and tick the machine you created. Enter the username (monitor) and password and select “Use machine’s current domain”. Then click Apply and then Test. If the test passes you can continue, if not you may need to check the credentials.
    12. Go to Agents->Configure Agents->Agent Menu. Ensure the following options are ticked only.
    a. Enable Agent Icon
    b. About “Insane Technologies Management Tool”
    c. “About InsaneTechnologies” -> http://www.insane.net.au
    d. Disable Remote Control
    e. Refresh
    13. Tick your machine and click Update.
    14. Go to Patch Mgmt->Manage Machines->Scan Machines. Set the schedule to be 10.00am, scan every 1 day, stagger by 1 min and skip machine if offline. Tick your machine and click the Schedule button
    15. Go to Patch Mgmt->Patch Policy->Membership. Select your machine and select the “default-workstation” group and click Add.
    16. Go to Patch Mgmt->Configure->Windows Auto Update. Select your machine, select Disable and click Apply.
    17. Go to Patch Mgmt->Configure->Reboot Action. Select your machine and select “If user logged in ask to reboot every [30] minutes until reboot occurs. Reboot if user not logged in” and click Apply.
    18. Now download the default agent to the server and repeat the above, except
    a. When selecting Membership select “default-server”
    b. When selecting Reboot Action select “Do not reboot after update [tick] When Reboot required, send email to xxxxx (at) insane.net.au”
    19. If it does not already exist, create a Source folder on the server with the most amount of free space and share it as “source$”
    20. Now go to Patch Mgmt->Configure->File Source and
    a. [tick] Copy packes to temp directory on local drive with most free space.
    b. [tick] Delete package after install (from temp directory)
    c. [tick] Pulled from file server using UNC path \\\source$\updates\
    d. File share located on [select the server from the group you are working on]
    e. In local directory [drive]:\source\updates
    f. File server automatically gets patch files from [tick] the internet
    g. [tick] Download from internet if machine is unable to connect to the file server
    h. Tick all your machines and click apply.
    21. Go to Agent->LAN Discovery->LAN Watch, schedule 9am, run every 3 hours scanning the subnet you are working on, [tick] Enable SNMP Read Community Name: public Confirm: public. Tick the server in this group and select Schedule.
    22. Go to Agent->Install Agents->Deploy Agents. Click Create Package and select the following options
    a. 1 = Computer Name
    b. 2 = Existing Group [the group you created]
    c. 3 = [tick] Silent Install
    d. 4 = Display Accounts from [this group]
    [tick] your primary machine
    e. 6 = [tick] Securely bind administrator credentials to the install package and enter the admin details for the service account you created
    f. 7 = name the package after the site you are working on.
    23. Now on the server go to http://xxxxxx/dl.asp and download the new version of the Agent you just created. Put it in the source$ drive.
    24. Modify the startup script (or create one if it does not exist) and add
    %LOGONSERVER%\source$\KcsSetup.exe
    25. Now reboot every machine on the network and you should find they come on line, using the settings you entered in the primary machine and be ready to start scanning for patch status.
    26. You will not have selected an automatic update schedule yet. Talk to the client about the best time for this to happen, it is almost transparent to the user but may annoy them if the reboot request comes in during a busy time. The first few times the updates run will be the longest, after that it should be very quick.
    27. Once you know a good time to update, go to Patch Pgmt->Manage Machines->Automatic Update. Select all your workstations (DO NOT SELECT SERVERS, they are done manually) and set the schedule to be Daily at around the time (-15 min stagger 1 min) that the client has suggested. This can always be changed later.

    (feedback definitely welcome Smile)

    Legacy Forum Name: How-To,
    Legacy Posted By Username: justX
  • Wow, that's a great documented list for new installs! One big suggestion I have right off the bat is why you aren't using template agents to preform most of your configuration automatically.

    Template agents are agents that you create, but never actually install on a machine. They never check-in and are not counted against your license count. (You can see this by going into System->License and there is a special count for template agents.) You create an agent under some group (I would suggest a Template group) using the Agent->Create function. Once the agent is created you can assign any setting you want globally (i.e. Check-in, Agent Menu, Monitor/Event Sets, etc). You can also pre-schedule scripts to run on a new agent install (i.e. VNC install) so it will always be run automatically. Finally, you create your agent install package under Deploy Agents and have it copy the settings off the template you just created.

    Personally I have 3 templates for Remote, Server, and Workstation. Each of these have the default settings I want and only the scripts I want to run (i.e. I removed the audits from the Remote template). From this, I create new agent packages pointing to each customer's group and set to copy the settings from the template I want (like Workstation). The only setting I have to do manually is the Set Credential one.

    You can also create templates for each customer if you want to completely customize each template and have everything happen automatically. Just make sure you update the templates with any changes you want made to new installs. Sometimes I forget and wonder why old settings are being applied to new agents.

    Legacy Forum Name: How-To,
    Legacy Posted By Username: CCDave
  • CCDave
    Wow, that's a great documented list for new installs! One big suggestion I have right off the bat is why you aren't using template agents to preform most of your configuration automatically.


    ahhh! i did not know of this feature. thank you.

    I'll go back and do that then re-work our install procedure to take that into account.

    ta!

    Legacy Forum Name: How-To,
    Legacy Posted By Username: justX
  • The method we use for configuring is similar to templating. We'll configure the first WS the way we want it for that client, copy the settings to all of the other machines, then add the server stuff to the servers.

    Every now and then we do it backwards and get "OMG Exchange isn't running and I can't start it" messages on the workstations... Then we laugh at the tech that did it (usually me).

    Legacy Forum Name: How-To,
    Legacy Posted By Username: dwujcik
  • dwujcik
    The method we use for configuring is similar to templating. We'll configure the first WS the way we want it for that client, copy the settings to all of the other machines, then add the server stuff to the servers.

    Every now and then we do it backwards and get "OMG Exchange isn't running and I can't start it" messages on the workstations... Then we laugh at the tech that did it (usually me).


    We do that all the time... In the begining it was maddening but now we just laugh... (sometimes someone even applies wrong templates just to see whos watching)...

    Anyways, our basic roll out goes like this:
    we deploy our "Audit" templates, which includes lan watch for AD servers. the we'll audit the workstations, again with a template... Usually we do this through the "Install Agents" link (my prefered way) but will do it through the "View AD Computers" link if need be (I don't like the way Kaseya creates the GP for the install).Note: we do DNS cleanup prior to delploying on workstations...

    PS Lan Watch on a network with mutiple subnets sucks harshly...

    Once the audits are done and a game plan is in place and documented we strip the Audit template and apply what ever template needs to be applied. Then comes things like patch management and specialized monitoring (Hummingbird DM and crap like that)

    Legacy Forum Name: How-To,
    Legacy Posted By Username: thirteentwenty
  • wow that is great help.

    I will read over this and I am sure it will help us out!

    Legacy Forum Name: How-To,
    Legacy Posted By Username: jrodirguez