What tasks are being used to keep the Laptops current with the latest DAT files ? Would like a recommendation on what others are doing. It would be great if McAfee could determine when and Internet connection is made and automatically perform an update. Problem I'm having is user's use the hibernation mode a great deal, I don't want to stack update tasks up if I schedule one hourly. Any help is greatly appreciated.
I don't think you would be stacking tasks. The task won't run until the agent detects it's connected to the epo server. I think ours checks every 2 hours with the server, and that check is very small on bandwidth. that may not completely answer your issues, but it's a start.
Did you find a way around this? We have a similar problem where if a laptop is off the domain but has an internet connection it wont update the DATs, slightly worrying if somebody goes away for 3 weeks and take their laptop with them as they cant update till they are back on the network and it can talk to the epo server and get updates from one of the distributed repositories.
Ideally we want a way that it knows it isnt going to be able to get the updates from an epo repository and falls back to the internet to download but cannot see a setting or figure out how to make it behave that way, can anybody shed any light on the issue?
ThanksMessage was edited by: csteels on 24/03/10 03:25:44 CDT
On my understanding, the default agent setting include a repositories list whcih include the following
So, if the client cannot connect to your ePO server, it will fallback to get the updates from McAfee.
Thats how I assumed it would work, but when Im not on the network it doesnt seem to fail over to http? Is there a specific agent policy I need to set for it to work?
I don't think so. At least, I didn't do anything about it and it works on our notebooks while outside the company network.
I'll do some testing when I get back in the office Friday and see if I can figure out what its doing (or why it isnt doing what you'd expect)
We have 31 distributed repositories and the agent policy is set to go to the closest (or fastest) subnet so Im not sure if that could be causing a problem, either way my laptop has failed to update when Ive been connected to wi-fi points out of the office this week so something I need to get working soon
I can tell you what I do here that seems to work fairly well...
As far as ePO can see, we only have one distrubited repository but that location is setup as the hub of a DFS share. When ePO sync's the master repository to the distributed repository, it only has to sync to the hub location of the DFS share. When DFS detects the changes made to the hub, it replicates those changes out to all of our remote repositories (over 30) setup as part of this replication set. Each client automatically resolves to the closest DFS share location based on the DC they logged in to. My clients Repository list looks like this...
1. DFS Share name (exp. \\antivirus\software)
2. ePO master repository (just in case the client can not resolve or access the DFS share)
3. DFS Share hub location (I keep this one disabled but it's on the list be default because it's on the distrubuted repository list)
3. McAfee's FTP site
For "Repository list selection:" I have "use this repository list"
For Select Repository by:" I have "Use order in repository list"
A user who is not on our internal network but has internet access will fail to connect to 1 and 2, will bypass 3 and finally connect to 4 to pull the updates. We have been using this arrangement for a few years now with very good results.
Here's maybe one other thing you can look at: we have our internal users set for a UNC share as well, using DFS, replicating to file servers around the company. For remote users, who are not on our LAN, we have a DMZ server configured for updating, so there's always a place they can go to update - internal LAN, DMZ server for off network connection, and direct to McAfee as a fallback.