I have several client computers that will be deployed with McAfee Agent and VirusScan software, but that will be unable to contact the ePO server. The Agent configuration has our ePO server as the first repository, and then McAfeeHttp as the second repository. Will the software be able to automatically update the DAT files based on this configureation? Ideally, it should fail to reach our ePO and then go out to the internet and retrieve the updates. I'm guessing that this is the case, but I want to make sure.
Please check the following :
When you install VirusScan locally it installs an agent anyway. The difference is that it's unmanaged by ePO so there should be no need to install a separate agent if these machines can never communicate to an ePO server.
Default update configuration will have them attempting to update from McAfee Http then McAfee Ftp but this can also be changed locally.
You would only have the ePO server listed as a update site if they had an agent installed from an ePO server and could communicate to that ePO server to get an updated sitelist.
..But there's no point in installing a separate managed agent if they can never speak to the ePO server...
The computer already has an agent that can talk to the ePO server, it was imaged using the default company image which includes the ePO agent. The intention is to segregate the computer since it will effectively be used for guests to access the internet and a printer. Thus, it's configured now to speak to ePO (thus ePO as the first location for updates), however, we're planning on putting it in a network location where it can't. I'm wondering if I don't reconfigure it at all, if it will still pick up updates off the internet as a fallback?
It should do, yes.
Bear in mind the agent logs will also be full of connection errors to the ePO server it cannot reach if you do nothing else.
Before you move it you might want to consider removing it from the ePO console system tree to put it back into a local 'unmanaged' state while it can still connect to ePO to pick up that change request.
Remove from system tree, but don't uninstall the agent would be the choice.
Just to clarify a point here - what my learned colleague meant to say was "remove from system tree and choose the 'uninstall agent on next communication' option"
By choosing to remove the agent, what will actually happen on the client machine is that it will receive the uninstall command, but since VSE is also installed, the agent simply shifts to unmanaged mode, which is what we want.