I have seen a couple of references to losing network connectivity for up to 30 minutes when upgrading the HIPS 7 client to HIPS 8. Is this in fact "normal" and if so, is there a workaround?
KB59945 - McAfee Product Management Statement - Impact of NDIS drivers during McAfee Host Intrusion Prevention installation
During the Host IPS 7.0 installation the NDIS drivers are installed, which have a timeout of 30 minutes. NDIS installation usually only takes a few seconds to minutes, but could take longer. Host IPS 7.0 uses NDIS 5.0, which requires a network tear down.
Host IPS 8.0 uses NDIS 6.0, which for Win Vista and higher, a network tear down is not required. Win XP and 2003 are limited to Microsoft's NDIS 5.0 architecture though.
1. Make sure you are running the latest network adapter drivers and software from the hardware vendor.
2. Disable any NIC teaming, if used. While NDIS install can work successfully with NIC teaming enabled, it's recommended to disable it to prevent any unintended network outages.
3. Uninstall Microsoft QoS, if you are not using it.
Although there is a 30 minute timeout, I have had a very high failure rate with a HIPS 8 deployment on XP either due to a hang or because the users aren't patient enough for a 30 minute timeout. If the uninstall reached a 30 minute timeout, there obviously is a problem anyway. We have had some improved results with the above recommendataions by Kary. For us the key appears to be disabling QoS on each network connection. The belief is that the QoS driver isn't releasing the stack when called, causing a hang, and eventually the timeout.
For more info: 72097 McAfee KB implicating QOS in stack errors: https://kc.mcafee.com/corporate/index?page=content&id=KB72097&cat=CORP_HOST_INTRUSION_PREVENTION_8_0...
This is a problem with the NDIS 5 implementation, not a McAfee issue. Per Platinum Support, the issue impacts a small subset of customers, and is dependent on the customer environment. Of course MS doesn't support NDIS 5 upgrade on XP either. I'm testing on a larger group to see if they are successful with the QoS disable method.
There is an MS script that may facilitate this methodology for larger deployments called NVSPBIND: http://archive.msdn.microsoft.com/nvspbind