Hi, we need admin access to run the xxxxsdat.exe files on user workstations so I tried adding it to the Windows startup script.  I am able to get it to run, but the process hangs using zero CPU.  If I elevate a command prompt to admin and run the same script file (we've tried kix and DOS batch) it works fine.  Since startup scripts run as local system I'm at a loss.

If there a flat file that we can just copy to a specific location on each machine (Vista) to update the definitions?  What location would we copy it to?

This file would be like the .xdb file in Symantec AntiVirus that you copy to update clients manually.

In the past, when I've needed an application (typically an installation) to run frequently as a local administrator, I've set it up as a Scheduled Task that runs "At System Startup" or "At Logon" (although you can customize the frequency of the task to meet your needs).  When scheduling the task, you can provide the credentials of a service account with local administrator privileges so that the local user does not need elevated rights.

I'm assuming that you're running McAfee VirusScan Enterprise.  Is there a reason that you are manually applying DATs, as opposed to just scheduling an Update Task?

Thanks for the reply.  Wouldn't the startup script have the same rights as a local admin?  I guess not.  And I believe scheduled tasks are disabled on workstations due to policy.  We do have an update task but 'should it fail' we want a brute force method as a backup.

When you create a Scheduled Task, you specify the credentials to use for processing the executable.  Because the task runs within the context of that user, if the supplied user ID does not have administrative privileges, the task will not run as an admin.

>> We do have an update task but 'should it fail' we want a brute force method as a backup.

Again, I'm going to assume you're running a managed, enterprise solution:  If the update task fails (typically because it cannot reach a repository) how are you delivering the DAT locally?  The client should also show up as non-compliant in the ePO if it is out-of-date.  Although, it's typically recommended that the fallback repository in the AutoUpdate Repository List be set to the McAfee HTTP site so that updates can be obtained even when the master repository (your ePO) is inaccessible.
 

Yes we are managed, enterprise edition.  Sorry.  We would deliver the dat from a local server copied there via another script or manually if needed.  Workstations are not able to update directly from McAfee due to policy reasons.