After a new install, a reboot is usually the best practice. That should be your solution. We always do it although it is a pain..
Hope this helps.
Kinda of defeats the object of being able to deploy the application silently via ePO if I need to get the end user involved to immediately reboot the PC in order to restore functionality. Even more so when deploying a patch.
I have been having pretty much the same problem but on a much larger scale. I depolyed SP2 to clients (pcs and servers) via a ePO update task and after the install it took out my exchange servers and several other servers running key applications. That was on Friday of last week. This morning then when I came into work we had a large number of servers that were unable to communicate with the domain. We resolved many of these with just a restart but others had to be put into a workgroup and then re-join the domain.
Any body have any ideas why this happens? I'll be expecting some grief and a grilling from higher up with a reason to why this happened.
Sorry for bring up this old thread, but I was wondering if others had experience the same issue with Patch 2 and 3.
Certainly we have continued to see this issue as we've deployed the Patches (either via ePO or by installing them manually).
I did try to open a support case with McAfee. They initally denied it was possible and that any blocking would be present in the Access Protection Logs. Later they decided that they'd like to do a remote session with a PC to see the issue. My issue however with this is trying to predict which PC(s) will repeat the issue.
very interesting, would be ugly... How about when you have a machine that has the issue (you may have done all of these, but this comes to mind)
do a MER, good to have if mcafee asks.
assuming you can point to exactly what isn't working with dns.
ipconfig /release and renew ???
before ipconfig , mcafee agent monitor and send collect props, is that talking good?
interesting deal... let us know how it goes...