Finally got a hold of the tech.  We did a webex and he couldn't find anything.  I'm going to run a fresh install and send him a wireshark log from it.  I'll post findings here in case anyone else gets the same issue.

Do you have the other option checked also? or just "Use the default..."? If it's the only option in your policy then you will have to work with Symantec on that.
Just check the clients connectivity to SEPM and policy serial numbers.

Symantec support is currently focused on our use of AD and a possiblity of problems with the policies.  I personally think that is a dead end.  Support is requesting we update to MR4MP1a to see if that helps.  As a large enterprise, we can't just "move" so we are taking it to the test lab.  If you get an answer to your case, I would be VERY interested in the resolution. 

Ok, here's what I got from the tech (after he spoke to the senior tech and I think a developer).

This is by design.  The first "heartbeat" during the setup will force the client to phone home to liveupdate.  After that the client will get its updates from the management server (he webex'd and and verified my settings are correct).

The only way around this is to block internet access to the clients during the setup so the first "heartbeat" fails which forces it back to the management server. 

Or I can just do fewer machines at a time.  According to the firewall group 200 clients moved 6GB of data from liveupdate over 20 minutes.

This is going to be a long roll-out.

I'm sure you've already thought of this but I just thought I'd mention it.  Just make sure that the policy/policies that were actually exported in the setup.exe have the Liveupdate policy that you want.  For example say you have a group called Desktops set up to get updates from the SEPM and the policy is configured properly.  However when you first install SEP, even if it is placing a computer in a group based on AD, it is still using the policy for whatever the default group is until it has time to realize that it needs to move groups and possibly change policies.  So if the default group is set to go to Symantec for updates it will do that the first time, until it has time to realize it should be moving groups and using the SEPM.  I realize this probably isn't the problem, I just thought I'd mention it.

Sutton

Hi delifeath, yeah, that was one of the first things I checked.

Daniel, akamai is from yahoo right? Correct me if I am wrong... You might have full bandwidth usage and updates are not completing.

Hi Daniel, you are right the liveupdate.symantec.com is hosted on akamai. But weird is i tried installing manually a sep package it didnt ask me to do a liveupdate, then I restart then my av client is updated.

Well, it's not asking to do the liveupdate.  That's why I didn't know it was going outside. 

All through testing I figured it was just getting everything from the management server.  When I did a pushout to 200 clients the WAN team sent a nasty-gram to my boss and his boss about the sudden massive spike in traffic.  I ran a protocol analyzer on my machine and ran several installs with every combination of liveupdate settings on my management server.  A couple of minutes into the install the machine will start to hit an external IP address that is always a akamai address and download a bunch of files.  Judging from the amount and size of the zips it's not just pulling the current rev, it's pulling program files as well.

I had the symantec tech webex to my machine and ran an install with the protocol analyzer running to show it to him.  That's when he escalated it up the line and was told, yeah, that's how it's supposed to work.

That's interesting...you could possibly make the downloads smaller by adding the new vdefhub.zip and ipsdef.zip into the install packages (if they're even being downloaded).  I can't believe it's pulling program files, etc. and the tech's didn't know about it....

Sutton

Hi Daniel, i see your point, but in our case, what we do is we limit clients not use network bandwidth max is 3%(Qos) for workstations. And we prioritization

Maybe that's why we didnt encounter any spikes. Any spikes on the network will trigger alarm on our network team. (We do not want that, =))

you should be able to control this feature... its set in two places.

The first, if you use an MSI install, you can use the parameter RUNLIVEUPDATE=0

The second is in the SetAid.ini file, which is the option CONNECT_LU_SERVER=0

this is also documented here: http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/ae142cf6efe920cf88257376005f1474?OpenDocument

Paul, I've passed your parameters on to our package guy.  He's going to extract a new msi for me to test.  I'll post how it goes.  Thanks.

Paul, initial testing looks much better.  The actual install is running without connecting to liveupdate.  It does connect briefly a few minutes after the install completes but passes very little data.  Could this be registration traffic?

The proof-in-the-pudding will be when I try another roll-out (on fewer machines this time).

Is this information in your tech's knowledge base?  We would have saved a lot of time if the tech could have found this information first thing instead of telling me there was no way around it.

Thanks for your help.

yes, the information is in our KB, which is accessible both internally and externally.  To be honest though, I'm not sure how easy the article would be to find if you don't know what to search for (I used "RUNLIVEUPDATE" since I know the property name)

I've not checked, but I would expect that it shouldn't run LU at all, there is no registration required for LU, but I haven't tried it myself so can't comment fully without testing.

Let us know how your next rollout goes.