We have ours buried in the Program Files\Kasyea\Maintenance\Temp

That way, ideally, no one would find it but those who know what they are looking for.

Grant

Legacy Forum Name: General Discussion,
Legacy Posted By Username: GrantB

We place ours on the root (C:\MLMS) but we also hide the folder.

God Bless,
Marty

Legacy Forum Name: General Discussion,
Legacy Posted By Username: Missing Link

i am using windows\temp

Legacy Forum Name: General Discussion,
Legacy Posted By Username: rudi

As of late January, Kaseya recommended you place the temp directory for desktops/laptops somewhere under C:\windows\system32 (ie C:\windows\system32\mgmt\mspname).

For servers, they recommended should be c:\temp, if for nothing else ease of exclusion from backups.

Legacy Forum Name: General Discussion,
Legacy Posted By Username: smbtechnology

Thanks for the responses.

Legacy Forum Name: General Discussion,
Legacy Posted By Username: SteveR

Our agent temp directory is located in C:\Windows\Managed\MSPname and our Agent install directory is C:\Program Files\MSPname. So far we have had zero issues with permissions problems but we also create a seperate administrator account/credential for all deployments.

Legacy Forum Name: General Discussion,
Legacy Posted By Username: CeruleanBlue

There are some considerations when choosing the agent temp directory for managed machines. Files and applications will be written down if they are not found at the agent temp directory for all "canned" Kaseya server scripts. If a temp directory is being cleared via script or user, these components will be written regularly using bandwidth. Using c:\temp may result in users deleting unknown files.

Using folders under "C:\Windows" can prevent the Kaseya monitoring counters from creating the log files required to collect monitor data. If this is the case you should find errors in the System/Application event logs and Kaseya will report the counters are "Not Responding".

Using folders with spaces in the name (C:\Program Files") can present a problem if quotes are not used in Kaseya scripts. If a script does not wrap paths or variables in quotation marks appropriately, you will find the behavior described in this KB article:

http://portal.knowledgebase.net/article.asp?article=276799&p=11855

Unfortunately I have not found a way to hide the agent temp directory from any user.

Hope this helps.

Rob
Kaseya emPower Out-tasking

Legacy Forum Name: General Discussion,
Legacy Posted By Username: rob.hendrix

rob.hendrix

Unfortunately I have not found a way to hide the agent temp directory from any user.

Hope this helps.

Rob
Kaseya emPower Out-tasking

It's not exactly a great solution, but this will keep most prying eyes in the dark. You can hide the actual folder by marking it "hidden" and "system" by using the attrib command. See script below...

Going further you might even be able to use the "XCACLS" command to set the security settings to the folder only the agent can access the folder at all. Does anyone know what the agent identifies itself as? If it is "SYSTEM" then you can use CALCS to deny access to everyone EXCEPT "SYSTEM" and of course you own companies Administrator account. Microsoft KB Article on xcacls.exe

I haven't tested this yet, so use at your own risk.

Script Name: Hide Agent Temp Folder

Script Description: This script will mark your agent temporary directory as a hidden and a system folder.



IF True 

THEN

   Get Variable

     Parameter 1 : 10

     Parameter 2 : 

     Parameter 3 : agenttemp

         OS Type : 0

   Execute Shell Command

     Parameter 1 : attrib +S +H #agenttemp# /S /D

     Parameter 2 : 1

         OS Type : 0

   Write Script Log Entry

     Parameter 1 : Agent Temporary directory is now hidden.

         OS Type : 0

ELSE

Legacy Forum Name: General Discussion,
Legacy Posted By Username: CeruleanBlue

The agent will normally access the temp directory as System UNLESS you specify a task to run as USER then it will either be as the logged on user or what ever user you specify. So locking this directory down is a good idea as long as you account for it in your scripts.

God Bless,
Marty

Legacy Forum Name: General Discussion,
Legacy Posted By Username: Missing Link

rob.hendrix

Using folders under "C:\Windows" can prevent the Kaseya monitoring counters from creating the log files required to collect monitor data. If this is the case you should find errors in the System/Application event logs and Kaseya will report the counters are "Not Responding".

Why would this be? Does it require a permissions change, if so that's not a problem.

Legacy Forum Name: General Discussion,
Legacy Posted By Username: rwitt

I am using windows\temp for sometime without any problems at all.

Legacy Forum Name: General Discussion,
Legacy Posted By Username: rudi

There are, at least in principle, other issues as well.

For one, depending on drive partitioning, etc., the C: drive may inaccessible or may not even exist. It would be better to use a system shell variable like %SYSTEMROOT% or %ALLUSERSPROFILE%, which would automatically compensate.

As well, permissions issues (especially with Vista) may prevent writing to %SYSTEMROOT% or "C:\Program Files", and it isn't recommended by Microsoft application programming standards anyway. The %ALLUSERSPROFILE% area is, I beleve, the recommended are for application user data these days. Although if it's running as SYSTEM, maybe this isn't an issue.

/kenw

Legacy Forum Name: General Discussion,
Legacy Posted By Username: Ken Wallewein

Kenw -
I don't consider MS programming standards for my management solution. I like it when software vendors follow them, but for the systems I manage the agent is going to run as a local admin and not have to use the privileges available to the current user (which I believe is the idea most of the programming standards are supposed to allow software to run with least user access privilegs).

Legacy Forum Name: General Discussion,
Legacy Posted By Username: rwitt

rwitt

Kenw -
I don't consider MS programming standards for my management solution. I like it when software vendors follow them, but ...

That's actually kind of funny. Best practices are for the common folk, not for me, eh?

a) Vista is starting to implement security measures that ordinary admin-level rights won't touch.

b) It doesn't address the issue of systems that don't have C: drives or where Windows is not on them -- many Citrix server, for starters, and there are others.

c) The whole point of Kaseya and Microsoft best practices is to eliminate having to manually deal with exceptions to the rule. They waste a lot of our time and devalue this whole approach to administration.

/kenw

Legacy Forum Name: General Discussion,
Legacy Posted By Username: Ken Wallewein