We ran into a situation today that defies (official) explanation so far. We have set up a single ePO 4.5.0 server with 39 superagent repositories. Most repositories are basically covering their own subnet at the end of a WAN link (for some higher use sites, we have enabled redundant repositories). For obvious purposes, we want our clients to only get their updates from the repositories local to their subnet, and avoid introducing WAN traffic at all costs.
To that end, we have put in a place a policy for each and every site that specifically restricts the available repositories at that site to ONLY the local one. All other repositories are set to DISABLED status, including the ePO server. The specific settings we used were:
1) Use THIS repository list (as opposed to use "other" repository list)
2) Use ORDER in repository list (as opposed to either the ping time or subnet distance options)
3) And we ticked off the Exclude new distributed repositories by default, just in case we added new SA repositories, we didn't want to have to come back and edit this policy.
This worked fine for about 6 weeks. Today, we received alarms of high WAN traffic directed at the ePO server. Turns out clients were coming to the ePO server for the daily DAT update - something specifically prohibited by the policy.
We were shocked to find out that the policy had somehow changed by itself. A review of the audit logs confirmed that no human interaction had occurred. In four of our policies, the proper/designated SA site had changed state to DISABLED, and the ePO server had become ENABLED.
From our client's perspective, all appears well. They recieved a policy that stated the ePO server was now fair game to use as an update server. But what baffles us, and our McAfee engineer as well, is exactly how the policy changed?
Right now, we have no answers.
One thing the four sites that changed did have in common is that they were the sole repository for that site. As I mentioned before, some of our sites have a redundant set of repositories, and those were not affected.
My theory is that somehow the superagent site became "de-registered" briefly, resulting in it being dropped as a valid repository as far as the policy was concerned. Then the ePO server, recognizing that a policy existed without a valid repository, valiantly stepped in and defaulted the ePO server itself as back to ENABLED status.
That's just a theory. The SA sites in question had been successful in their last sync, so there was really no reason for the ePO server to drop them. In any event, this should have triggered an admin alert. Definitely NOT desirable is a default/uncontrolled action to ENABLE the ePO server. This caused a huge traffic problem on our WAN. We'd much rather that if a policy was not valid, that an alarm be raised and await human intervention. This ePO default action is a dangerous one.
Anyway, I'm sharing our story in hopes that somebody else has seen this behavior. The McAfee engineer basically said that unless it happens again, it's not going to be escalated to the programming team for analysis (yes, that was a GOLD support answer, folks). We did enable additional logging levels, but unfortunately we're stuck waiting for this bug to strike again.
Any help or corroboration would be appreciated.
ePO Server 4.5.0
Clients: 6000+ at 8.7 SP3
on 5/26/10 9:50:01 PM CDT