To help troubleshoot it would be helpful to see the actual error in the logs. Is the file getting distributed to the endpoint or is the setup failing?
I recommend joining our discord channel for a more interactive discussion:
charrise_dlc, check the temp folder and see if the EXE downloaded. If it did, then there is a problem with execution, but I suspect it didn't. Probably blocked by AV or Firewall. You could try renaming it to .txt or something, then changing the name during the download.
Don't forget a "Deletefile" to delete the download package, once it is working so you don't leave it hanging out there!
PS. Make sure that c:\temp exists and that it can be written to. A preferred directory is #vAgentConfiguration.AgentTempDir#\ which will put it in the kworking directory.
You mentioned its failing on STEP 2, which is the "IF True"... meaning that its actually something in the IF thats not qualifying so it fails on entering...
I would guess its what Chris suggested, an issue with the c:\temp folder. It's either not there, read only or not accessible by the ":NTAuthority\System" account the steps are running as. It could also be a space before or after the agentDrv var declaration, maybe it hates /s after the execute file... or the file your writing isnt on the KServer/managedFiles location your writing it from...
I would start by removing the "IF True" line and out-dent the rest of the procedure. IF True is legacy and not required today. This way it will fail on the actual issue.
I would remove the "getVariable" agentDrive step and use Chris's suggestion, write the file to #vAgentConfiguration.agentTempDir#\filename.exe
If your still having an issue replace the "executeFile" with an executeShellCommand and do the entire command on one line, in "quotes"... the down side of this is, executeShell doesn't have an "execute and wait" option, it moves on right after it calls. It wont matter in your case unless you add the "deleteFile" as Chris appropriately suggested.,, whch can still be done, just add a long pauseProcedure after the executeShell.
Thank you Chris. I changed the agntdrv to C:\ and it worked.
I am actually still a newbie on kaseya. Is it normal that silent installation would take 1 hour? The one I tried to deploy took 1 hour before it was successfully installed.
Thank you Kirk for the help. I change the agntdrv to C:\ and it worked. My concern now is that it took 1hour before it it successfully installed. :(
I mean it took the system 1 hour to silently install. Is this normal?
(writeFile) is notoriously slow. This is a known issue and cannot be resolved due to the method it writes. It's not a good solution for distributing files more than a few MB.
A better solution is to write into the procedure to copy from a network share or download from internet.
I usually only use (writeFile) for batch files, etc.
getURL works great for large packages and it will recover even if the machine is rebooted in the middle of the transfer. It operates outside of the "tunnel" between the agent and the VSA (FYI). writeFile uses the "tunnel" between the agent and the VSA and breaks down to package into smaller chunks which causes problems with large packages. We were having problems with our 400+MB packages with writeFile and once we switched over the getURL we could deliver them in less than 10 minutes, typically 7. As a test, once you create a getURL path with your file you can copy it into your browser and the package will be downloaded to your desktop.
It should not take any longer to install then it would run locally. How large is the file? Eric and Stephen are right, the transfer will be a bit slower, getURL is a better option and it will follow the LANCache configuration.
One thing to note is that Agent Procedures are executed linearly... meaning if the system was performing an Audit or Patching... this procedure wont start till those ahead of it complete.
This means if the /q does not make the installer run silent and unattended, and the installer presents a prompt to the user... it will sit there till it times out. The prompt would present to the user "System", not the current user, so the user would likely never see it. I have seen situations where a prompt to System did present to the current user after a long period of time, but I dont know what triggered it to present. You should assume it wont though and ALL procedures will queue up behind this stalled procedure. So always make sure your procedures are in fact unattended be testing them locally first.
Not to take a long side trip but, is there a way to programmatically clear stuck procedures?
Not really... restarting the Agent will do it, which can be done with a procedure... but that procedure wont run till the stuck is un-stuck. Live Connect will still work since that uses a different service.
Thank you so much @eric, Stephen Funari and Kirk Feathers for the help and for the explanation. It is a great help for a newbie like me :)