is anyone experiencing this?  we still have the same issue!

I just made the change, i will keep you updated if this resolved anything.  I don't recall having to do this in 10x... it's very fustrating for our users. 

Hello,

 

10.x clients operated in a pull fashion only, reporting to the parent server based on an interval the administrator specified. In SEP, you have the option of either. Push maintains a constant connection to the SEPM server, and is the default communication setting. The client will upload data to the SEPM every 5 minutes (default) unless the heartbeat interval is increased. The benefit to push is the clients will receive policy updates immediately, but does create a very chatty network in large environments.

John,

Not quite...VDTM (or push) was the default for SAV 10.  However, the push basically was a server-initiated transmission that told the client what to do - update, scan, etc.  This required that the client actually be LISTENING thus it had a listening port, TCP 2967. 

 

In SEP 11, there are no listening ports on the client, thus all communication is actually initiated by the CLIENT.  This is a much more secure architecture.  But, at the same time it does not allow for a true PUSH mode unless there is a persistant connection.  The Push mode in SEP 11 is equivelent to having secure tunnels opened to every client, hence referred to as ONLINE mode.  It's really geared for a smaller number of clients although it has (I have been told) been tested into the thousands of clients - and of course mileage will vary depending on Server hardware, network infrastructure, etc.

 

I did switch to pull mode at 45 min, and guess what it still flooded the network, the only thing we have deployed are antivirus and antispyware, nothing else.  There has to be other people experiencing this?  Right now we are going to make our users leave their computers on once a week so they can at least get weekly updates. 

I think that last post gives a clue to what might be going on here. 

 

If a clients definition set is only X old, with X being the number of previous updates you've set your SEPM server to store, then they update using the tiny microdefs.  If the clients definitions are older than that, then the client gets the full blown update package which is 100MB just for the AV stuff.  So, if computers are turned off frequently during the time frame/s you've set for updating and they are only able to get updates infrequently, then your going to have a lot of data flying around your network.

At first we had them going daily as the ones on our LAN, however the ones were we have the problems are on the WAN.  When we tried to do them everyday, it kept flooding the network.  i don't want my users to leave the computers on all the time, so we have decided on once a week, during the night, to minimize interruption.

Another thing that you can do is to use the location based awareness of SEP to your advantage to help.  Set up a second location for policies.  Set your locations by subnet.  Make a separate LiveUpdate policy for the new location.  You want to set it up so that if a system has an IP address that falls within the scope of your internal LAN addressing scheme or the range that you've specified for VPN clients, then you want them to pull updates from your SEPM server.  Anything else and they'll pull updates directly from the Symantec LiveUpdate server.  If you set things up this way, the remote clients will get updated definitions on a timely basis, without tearing up your available bandwidth.