I am looking into a problem on a server. I don't know that it has anything to do with it, but I noticed at the same time the Kaseya script "File Source Config" ran. I am not familiar with this script. Can anyone tell me what it is/does?
Thanks in advance.
Here is the code for that system script;
<scriptDef id="319" name="File Source Config">
<scriptIf ifFunc="1" fp1="" fp2="" fp3="" ifTest="1" testVal="" scriptType="-2" description="Prepare File Source Configuration" />
<scriptThenElse teType="0" stepNum="1" teFunc="26" fp1="2" fp2="+++SQLCMD:SELECT CASE WHEN (RIGHT(sourceLocal,1) = '\') THEN LEFT(sourceLocal,(LEN(sourceLocal)-1)) ELSE sourceLocal END AS fileSharePath FROM patchParams WHERE sourceType IN (2,3,6,7) AND sourceLocal LIKE '[a-z]:\%' AND sourceMachineAgentGuid=+++GETVARGUID:" fp3="fileSharePath" osType="13" contOnFail="0" />
<scriptThenElse teType="0" stepNum="2" teFunc="20" fp1="mkdir "#fileSharePath#"" fp2="1" fp3="" osType="13" contOnFail="1" />
<scriptThenElse teType="0" stepNum="3" teFunc="5" fp1="#fileSharePath#\FileSource_DO_NOT_DELETE.txt" fp2="VSAHiddenFiles\FileSource.txt" fp3="2" osType="13" contOnFail="0" />
Is this server that this script is running on used as the patch repository?
All that script is doing is making sure the agent is designated as a file source server. It tests if the local directory is present and creats a "FileSource_DO_NOT_DELETE.txt" file in it.
It is very common for engineers/technicians to eyeball anything and everything that was running around the time of a problem. This script is definitely not a cause, but what is more likely, is that the script was pending while the server was offline and simply ran the moment the agent checked back in (hence the timing).
SMason is correct. To add a bit of background, that script will run on the patch File Source machine on a scheduled basis (every 12-24 hours, depending on the config of your KServer) and will ALSO run on the patch file source machine any time you configure an agent to point to that machine as its file source. It's a critical step in the patch process - if the FileSource_DO_NOT_DELETE.txt file does not exist in the folder, patching will fail. That's why the script runs daily - to replace the file if it's been deleted. It's a built-in automatic remediation to prevent problems before admins know they exist.
Let's say you have a patch file share called \\server1\patches on machine Server1 in local folder c:\patches
In Kaseya, you assign the the file source configuration of \\server1\patches to the agent workstation1
At the time you click "Apply" to assign the file source to workstation1, the FileSourceConfig script will run on Server1.
If you enter invalid data for the file source (say you typo \\server1\patches as \\sever1\pacths) or you enter an invalid local path, when the FileSourceConfig script runs, it will error because it won't be able to access the defined location (since it's invalid/typoed/inaccurate).
You can figure out if this is the cause of the failing script by creating a view to show all machines that connect to a specific patch file source (select the machine that's throwing the error - for this example, Server1). When you use this view, you will see a list of agents assigned to the Server1 machine. Look through the list and identify if any of the agents are configured incorrectly (check for typos, incorrect share, incorrect local drive or local path, etc.).
I know you're not specifically reporting an error with this script, but in the event you happen to see any, this is the best way to diagnose w/o having to get into SQL queries.