I am new to using Kaseya and we are trying to update an application on workstations in our domain. What would be the best procedure for performing this task through Kaseya?
Welcome! I have two suggestions. First is that Kaseya has a software deployment module that uses the ninite system for some general updates. If that does not fit your situation, try building an agent procedure.
First I would use credentials
Next, copy the file to a destination of your choice (local drive or temp folder)
Next, execute file with correct switches for silent installation
If this update requires a system reboot, I would put that step there.
Hope this helps.
I don't have the software deployment module.
I was actually playing around with procedures to copy a file to a workstation from a server and that wasn't working.
step 1 was use user logon credentials
step 2 execute command copy \\fileserver\share\*.* c:\windows\system32\
it would say successful, but the files weren't there.
I think you are running to a user restriction problem. Are you sure that the end users have access to the windows system32 folder? I do not think standard users dot not have access to write to the windows directory. Also, are you sure each user has access to your \\fileserver?
What we did here is set a specific kaseya user on each of our system with local Admin rights. We then select use credential to use this common account for our procedures.
i thought using credentials it will use the account you specify under the agent?
Ok, I'm a little confused are you selecting useCredential or impersonateUser?
useCredential will use what was set in the agent.
impersonateUser will allow you to manually set the user name, password, domain(if any) I have not had much success using this option.
here is a sample procedure we use:
Oh!!!! We are currently using Kaseya 6.5
The directory "C:\Windows\System32" is redirected on 64-bit operating systems since the Kaseya agent is 32-bit. Your files are likely being copied to "C:\Windows\Syswow64"
i checked in that directory and they are not in there.
perhaps, verify the user that you are using can read from the fileshare and also write to the specified folder. You could do a run as for CMD with your user information. Then see if you can access the fileshare. open the location and make a text file?
It's actually my machine i am testing on and i have r/w access and i am a local admin.
there was nothing under the sample procedure.
For the sake of time and best practice. I would advise to NOT store it under the system32 folder.
I would utilize your Agent Working Directory (eg. C:\kworking) as a place to temporarily hold your files.
This directory should already be setup with the necessary permissions required to be used with the useCredential() as long as:
A. the credential is an admin and has access to the share (domain creds makes this easy)
B. any active scanners have the working directory excluded. (have not seen this as an issue but it is what I advise all clients for the sake of avoiding a headache)
My procedures always include a clean up which deletes the said files after the agent procedure is finished using them. Keeps the working directory clutter free.
I am trying to copy PsTools to the workstations. They need to go into system32 i believe to work?
False - they can be anywhere as long as you use full paths when you run them. The only advantage to putting them in %windir%\system32 is that you can execute files without their paths because cmd.exe itself lives there, making it the working directory.