Kaseya Community

Patch Status Test

  • Hi,

    We have a number of LanCache's setup for a customer and all but a few work as required. the one's causing issues are when files required for Patch Management and patch testing are not in the LanCache:




    The Patch Status Test sits at Pending and when we look at the log for the server with the LanCache we get this error.

    FAILED in processing THEN step 1, Write File, with error File or Directory Not Found, Source = D:\Kaseya\WebPages\ManagedFiles\..\install\curl.exe, Destination = D:\HWSLancache\VSAFileShare\PATCH\curl.exe

    The destination directory is correct but the Source directory does not exist on the KServer, believe the curl.exe file is in the folder D:\Kaseya\WebPages\install\curl.exe

    If one of the files above is missing it reports that file, as per above.

    FYI, we have a LanCache server that uses E: drive for the LanCache and that works fine. These all used to work fine, but we only found out about the issue when a clear cache was done on a LanCache and everything stopped working. Once the files are in the LanCache patching works correctly with the patch files being loaded into the LanCache and then distributed to the clients. I can manually load the 4 files into the LanCache as a workaround but I would like to resolve it.

    If I change the File Source setting on this server to be pull from internet or System Server the files are downloaded.

    I opened a ticket with Support (#761888) and got emailed a knowledgebase article about Lan Watch!!  So feel that the forum might be my quickest source of an answer.

    The file kpmchk.exe is downloaded to the LanCache if I run a patch scan after placing the 3 files above in the LanCache.

    If support comes back with anything I will let you know.



  • I had a similar issue a while back with patch tests failing and an equivalent error message. I opened a ticket and was told by support to disable the "Use Fast Transfer option" found in System > Default Settings. It immediately fixed the problem.

    Hope this helps!

  • My advise is don't use lan cache. We used to, had problems, changed to internet only and never looked back.

    With internet speeds improved, you shouldn't need it. The 2016 CUs are it of a struggle because of their size,  they fail with Windows updates too.

  • Hi Roger,

    That fixed my problem, said the Forum would fix it before Support!!!

    They are still asking lots of level 1 questions.

    So what does anyone know what “Use Fast Transfer option” actually does.


  • Bob,

    Here in Australia we don't have large bandwidth everywhere, so need to use LanCache


  • Hi Andy,

    This is what I was told:

    "The Fast Transfer features its supposed to speed up file transfer between VSA and endpoints. It is known to have issues with certain setups that will prevent curl and other tools from being transferred to the endpoints. It will not affect any functionality on the server other than file transfers."

    We stopped using LAN Cache as well. It has some very strange behavior. Basically we found that the LAN Cache user created by VSA was accessing and locking files in shares that were completely separate from the LAN Cache. These locked files were causing problems in some of our clients' LOB apps.

    I implemented a LAN Cache substitute using regular file shares and managed variables. It's not as full-featured as LAN Cache in that it doesn't integrate with Patch Management and doesn't have the automatic fetching, but it's more understandable and secure. We use it mostly for holding large files (such as Win10 ISOs) that are accessed via a regular UNC patch in agent procedures.

  • I believe the "Fast Transfer Option" allows the Agent to fetch the file directly on port 443 using Curl.  When you disable it it will use the slower but more reliable in some use cases, writeFile delivery.

    LAN Watch Caution:

    In is important to never use a Domain Controller as part of LanCache.  When an Agent is added to a cache, it will create the account Roger mentioned.  Typically, this is a local admin user account and password... but a DC doesn't have local users, so it will create a Domain Admin account instead.  Now you have a Domain Admin UN and PW exactly the same as a local Admin PW, exposing you to a pass-the-hash attact.

    If you setup LC, also setup "Set Credentials" and delete or disable the account it created... especially on a DC.

    The big advantage of LanCache feature is, once setup, any getUrl or writeFile in Procedures will follow the LC settings.

    LanCache will be evolving as we continue to add controls into the Software Management P2P methods until   eventually, current method is replaced by the new.

  • Kirk,

    Little-used feature - a DC does have a local Administrators group, so creating a local Domain User and adding it to the Administrators group on a DC will grant that user local admin rights without being a Domain Admin. We leverage this when our RMM Suite creates local admin accounts using our tools.

    We create an account "RMM_Admin" as a domain user, then on the DC (every computer, actually), we run the NET LOCALGROUP ADMINISTRATORS <DOMAIN>\RMM_ADMIN /ADD. The user has full local admin access to the domain controller server, but not the domain. In many environments where I worked, this was leveraged to allow the IT team to manage ALL servers, even if they didn't manage the domain.

    I understand that this probably isn't how the logic to create the Lan Cache user account works, but it could be if someone reviewed this with engineering. :)

    BTW - This concept is covered in the Securing Your RMM presentation that I deliver at the Connect Local events.