Firstly, I'm in no way an ePO expert. I have an ePO 4.5 server, and this issue existed with ePO 4.0 as well. Every now and then the server will lock up and restart. I'm not entirely sure that this is caused by the ePO service, but it does seem to happen mostly when I'm doing something within the ePO GUI. The server will stop responding and then restart, and then display a message to tell me that the problem was caused by a device driver. So here's what I've come up with:
1. ePO has some type of driver that it installs on the system, which is conflicting with something else on my system
2. Some driver already installed on my system is conflicting with the ePO service
3. Something else is happening unrelated to ePO
Has anyone else experienced this problem? The server ePO is installed on also runs BackupExec 12.5, McAfee VSE 8.5i, shares files and printers, and is the main DC. At first I suspected there being an issue between BEWS 12.5 and ePO, but the restarts have happened with all the BEWS services stopped.
What I'd really like to do is migrate ePO to a standalone server within a VMWare environment, but according to the article I found about migrating servers (https://kc.mcafee.com/corporate/index?page=content&id=KB66616), it's meant for disaster recovery purposes only since you have to make sure the new ePO server is named the same as the old. I'd rather create a completely new ePO server and migrate the agents to respond to it instead of the current server, but doesn't anyone know if that's possible?
1. ePO doesn't install any drivers.
The article (KB66616) states "the IP address, computer name or DNS name must stay the same or the currently deployed agents will not be able to locate the new server." What this means, is that as long as one of these is the same as before you should be ok. Looking further into this, you can change the a record to point to the new IP of the new server. Once all the agents have checked in, you can change the a record to reflect the correct name.
As for the locking up, I'm not sure what could be causing that. It could be hardware failure as well. Is the entire system unresponsive or just a particular process?
Thanks for the quick response. The server pretty much blue screens and restarts, then I get the message once it's back about how Windows encountered a serious error, blah blah blah. Then it goes on to tell me how it was caused by a device driver, but it doesn't bother mentioning which one. The event logs aren't
The problem with the server migration is that this server is the main server for a lot of stuff, so I have different things pointing to it by IP address and others by DNS name. I'd rather not have to go around trying to track down each and everything thing that is pointing to it. One thing I ran across looked like it may be possible to install a second ePO server on a new machine, then deploy agents from there to overwrite the existing agents in order to get the agents to check in with the new server instead. However, I'm not sure if that will work due to my limited knowledge of ePO. Does that sound like something that may work, or would that cause issues having two master ePO servers in the same environment? Or would there be a way to install an ePO server as a secondary repository, promote it to the master repository, then deactivate the original server with what would then be a secondary repository?
VSE 8.5 installs drivers though, doesn't it? That was another thought I had, in case having VSE 8.5 and ePO installed on the same machine needed some special configuration that I don't have in place.Message was edited by: rslygh on 11/4/09 12:20 PM
ePO does not install any low level 'Filter' drivers that interfere with the Operating System function.
That being said, it would be advisable to apply the latest VirusScan 8.5i Patch (Patch 8).
Also there is an updated filter driver for VSE 8.5 Patch 8 : HF482720 which is highly recommended for improving performance of the filter driver.
Please refer to PD22136 for details on the issues fixed in HF482720.
Secondly, update any third party drivers (hardware & other filter drivers) to their latest available versions.
If none of the above suggestions seems to make any difference, make sure to enable a kernel memory dump by following the steps suggested in KB56023 and open a ticket with McAfee Support for further investigation.
Hope that helps.
Turned out to be something conflicting with an old network monitoring driver file that was getting loaded by the system, but wasn't needed. I'm not completely sure what changed that the driver decided to start acting up, but I went in and trashed it and haven't had a restart in a week. Thanks for the helpful responses!