Kaseya Community

C:\KaseyaEndpointDownloads Folder Growing

  • I have a folder called C:\Kaseya\EndpointDownloads on my Kaseya server that seems to be growing with patch Microsoft patch files

    Does anyone know what this folder is? I do not recall seeing it before. It is now up to 24Gb. It was 15Gb week or so ago.

    I noticed it after a did an upgrade to 9.5

  • It's the patch repository for Software Management - in order for it to populate you will have it configured on some agents which are being scanned, and the appropriate files downloaded in preparation for installation.

    I put in a request months ago for Kaseya to add the functionality to be able to move this folder to another drive.

  • I had a feeling that is what it was. I will ask them about that request.

    Patch Management did not do that before as far as I know. It would be a good thing to put in the documentation somewhere as that will just grow over time

  • Elarsen, there is an option inside of Kaseyas patch management to delete these after install. we also set up a folder name to be able to identify were the patches/agent procedures where going. if we ever had to look for them.

  • We discussed this with Kaseya Engineering a few months ago after we started testing Software Management. They recommended that we allocated 200GB of space for this. After 3 months, it's been hovering between 130 and 150G.

    During VSA maintenance, we created a new volume, assigned it to "X:" (an unused letter) and then MOVED all of the files to that drive. We then removed the assignment from X: and mounted it on the original and now empty folder. After restarting the Kaseya services, we have not had any further issues. Should that volume fill it will only impact Software Management and not the VSA itself.

    We actually recommend mounted volumes for several of the folders within the Kaseya VSA folder structure when we build platforms for MSPs, particularly for those that hold agent data or shared files. Our typical VSA build targets a 25G D: drive for the Kaseya folder structure and 4 additional mount points with volumes from 10 to 50G (plus a 200G volume  if you use Software Management).

    Glenn

  • We've done the same with our R9.4, as even the Ninite folder can get big, it's folder cache started to get to around 100gb in size.  Moved the data off to a new volume, and mounted the volume as a folder.   So the VSA doesn't know the difference, but now all that third-party patch data is on that new volume.

  • I've configured Software Management on all of two machines (for testing) and that folder has 48000 files in it.

    This seems... less than optimal.

  • If you ever managed a WSUS server, this shouldn't be surprising. The last WSUS server I managed needed a 200G volume and that was just MS updates. This is application updates as well.

    Creating it as a mounted volume lets you increase it dynamically if it's a virtual platform.

    Glenn

  • Hi Guys,

    Thanks for the feed back. I will take Glenn's advice and move it to another drive this weekend. That seems to be the best solution

    We only started using Software management after the upgrade to 9.5. It was there but was not scanning anything.

    On my test server I have the same folder but did not realize it was taking up so much space

    I agree this seems a bit not optimal as we previously had Patch Management to pull from the internet instead of the Kserver. It would be nice to specify that instead of having to dedicate all this space.

    Glenn,

    What are the other folders you move to dedicated drives? I have not seen from best practice from kaseya on that but I would think these would be canidates for dedicated drives:

    DB Backup

    DB Archive

    Endpoint Downloads

  • This is our standard disk layout when we build a VSA for someone. Sizes may vary depending on number of agents, type and amount of data collected and such. The EndpointDownloads was a Kaseya Engineering recommendation after we filled the disk and then the dedicated volume 3 more times while evaluating it last quarter.

    D:\                                                      25G - Kaseya installed here

    D:\Kaseya\KNM                                 10G - if you use KNM heavily, 5G for moderate use.

    D:\Kaseya\EndpointDownloads       200G - if you use Software Management

    D:\Kaseya\WebPags\ManagedFiles  30G -

    D:\Kaseya\UserProfiles                      30G - for more than 2500 endpoints or large data collections

    We just built two new servers for our production and the last two volumes are 50G each. We've rarely needed to adjust the first two. EndpointDownloads is currently the wildcard. :) Time will tell. For a new server, I create the folders on D:, then mount the volumes, then install Kaseya.

    These are the folders that we tend to see grow the largest depending on number of agents and how many custom deployments you support. Basically, look at your existing folder sizes and add 50% or so for growth. Once the volumes are there, it's easy to expand them as needed.

    The DB folders we place on a separate drive (E:) mostly to keep them logically separate from that Kaseya installation. Less chance of someone doing maintenance on D: messing with backups if they are on E: is the theory.

    Of course, if you have SQL installed, there's volumes for Data, Logs, and TempDB at least. For that, I create C:\SQL and place the mount folders there - SQL installs so much on C: in the Shared folder I've given up trying to install it to another drive, but use mounted volumes for all the transient stuff.

    This isn't official Kaseya best practice, but ours based on experience building and supporting VSA platforms. I've paid attention to which folders held the most data and had the most activity, especially when VSA ground to a halt with a full disk. The advantages here are distributed I/O and the ability to dynamically increase specific volumes, rather than channeling all I/O through a single interface.

    Glenn