This content has been marked as final. Show 6 replies
You are checking that you are applying the policy with the server box rather than the workstation box selected and then saving it before moving on?
This catches a lot of people out
Yes, I am doing that.
after altering the policy for a specific machine and then waking it up does the agent log show the altered policies being merged or is there nothing in the agent log for it?
Did you find a solution do this? We had a similar (very strange) issue on some of our clients. Even though these clients were communicating fine with ePO and were configured to use "policy A" via the ePO server, they would not stop running the "McAfee Default Policy" hence blocking port 25! We had to duplicate "Policy A" and re-apply that policy in order for the clients to stop applying the McAfee default policy.
Any else ever see this problem?
However I did discover that the server running ePO as a VMWARE image was very underpowered, a 32MB swap file and only limited memory allocated to the ePO Server.
I also discovered (i.e. I never checked) that there were many thousands of backlogged tasks to do with pushing the agents out.
I cleared out all the old tasks, gave it more memory etc and the ePO server now seems very much more responsive.
I recently made a global change to allow a WSUS server application to send out notification mail, whilst the change is in the directory policy (to allow w3wp.exe to send mail) its not reached the WSUS server.
But other problems with the ePO agent remain, which may be part of the issue with the email exception list not sticking, so I have only just today brough the ePO server up to 220.127.116.11 level, and I will be trying the 'new' ePO agent shortly.
If you post another message in a couple of weeks I will let you know if the issue is resolved.