I've got a procedure that is designed to write a file, then execute it to install an applicaion.
The problem is the file is writing about 1.5MB then failing. The file is about 28MB in total.
I can write smaller files fine.
I've tried putting the file in c:\kworking or in c:\temp. Same results with different dirs.
Is there a limit to file size that can be written?
Any idea why it's failing?
when you write file in the procedures you're using curl
check in your agent temp, there should be a curl.exe in there. find a download file about that size or bigger
run from command line within your agent temp folder
curl -o "name of download" http://url-to-download
this will test your download abilities and flag any errors on the download to help you determine what went wrong.
:D or check the procedure log in kaseya, it also may have some info as to what happened during the file write.
my guess though off the top of my head, Anti-Virus is flagging it as a virus and deleting it, may want to exclude scanning your agent temp folder.
Thanks for the response.
I tried the same thing but to a system on the same LAN as the Kserver. It downloaded 7MB of the 28MB. It seems like there is a timeout process associated the "write file" procedure. Maybe write file is only designed to write simple files, like logs or scripts?
I can use the "distribute file" process with no problems, unfortunately I can't use that in an agent procedure.
Anti-virus is not the problem, as one of the systems is currently not running any AV programs.
I still need to try the curl test.
I don't beleive curl has a limit, I use the write file in a Trend install script that pushes a 100Mb installer msi file with no issues.
Just an fyi, the transfer from the Kserver to your local LAN machine is still going out then back in, it's not a direct connection b/c curl uses the links under your kaseya vsa web page. Check your upload on your kaseya server internet connection. You may have an issue with upload. as an example, comcast blocks specific upload connections with packet shaping, this while most likely is not the case is a good example of what could be occurring. Packets dropping or too many errors in the transfer.
I've done some more testing. The write file command does not use curl.exe. When the procedure runs and downloads the file, curl.exe never shows in task manager.
I changed the procedure to use "get URL" and pointed it to the file on the Kserver. When this procedure runs curl.exe DOES get used, and the file does download correctly.
Another interesting note is the "write file" procedure works fine on an XP machine, but both systems that fail are on Windows 7. The XP machine is sitting here at my desk along with the first Windows 7 machine that failed. They are both using the same switch, firewall, and ISP connections.
This is also not an ISP or firewall issue. The connections are fast and reliable with no loss. The system on the same LAN only has to pass though a firewall and never goes through an ISP.
Pretty sure there is a timeout on Windows 7 machines or a bug with how the write file command works on Windows 7. Maybe a recent MS patch has changed something, since this type of procedure has worked in the past.
Figured it out.
This is quite possibly the craziest sh!t I've seen on a computer.
The transfer was going to c:\temp.
If I had an explorer window open and viewing the contents of that directory (C:\temp) the download would fail.
The moment I closed the window and ran the procedure again the files would download with no errors!
I found this to be impossible, crazy and far-fetched; so I tested it a dozen times between Windows 7 and server 2008 R2.
Sure enough, on those operating systems something is happening when you view the folder that is causing the transfer to fail.
This is easily repeatable.
I even started a download, waited a minute then opened the folder. The download had gotten to 14.4MB, and the moment I opened the folder the download stopped and the procedure failed.
wow, who knew! that is weird that if the folder's open it would stop the download. Sorry about the wrong info with curl, I had spoken with a dev out in Vegas when the new k2 came out and in the discussion file writes was said to use curl. I assumed that their dev's would know and never checked, (or I mis-understood him).
I wonder what Kaseya is using for the transfer then, I bet that would explain why that fails if open. Thanks for posting your fix though. I'm surely going to update my notes to include this tid bit of info.