How long has it been?

I've had some clients that took 20-30 minutes to update, mainly due to slower lines.

First Try this on few machines

Network Threat Protection displays 'Waiting for updates' after migration to Symantec Endpoint Protection (SEP) RU5/6/6a

http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/ae8e7ba853b074a30325771c004d6d7f?OpenDocument

Did you try the fixes from the article?  If so did Method A work for you nadonl?  We are also using 11.0.5 RU5 using only AV & TruScan and i'm testing adding NTP to the mix using 11.0.6 MR1 and i'm having exactly the same issue on the first couple of test machines.  With regards to the above article Managed Client Method A did not work for me and Method B is a nightmare scenario of de-installing and re-installing across the Enterprise.

I think this is going to be another Symantec situation where they know fine well that this scenario will affect all clients and method B will be the only solution.  They put method A in there just to give you hope.  I notice that the article states the cause as:  Corrupt installation and/or WPShelper service not present.  Again, I don't believe the corruption part.  This again looks like Symantec Spin.  I've only assigned the new package to 2 clients but both are exhibiting this behaviour.

Modifying the SEP client usually works for us.

Ctrl Panel > Add/Remove Progs > SEP

Modify install

- Uncheck component with problem to uninstall

Repeat the procedure only this time, check the component  to install.

1250 machines.  Thanks for taking the time though.

I don't get this issue when I deploy the package from the Migration & Deployment Wizard but all clients added to the group with the package assigned do have the issue.  This is not good.

I firmly believe that Symantec know that in this scenario all machines will be affected and that Method A in their fix will never work; this is a bug that only a full re-install will sort. Thankfully we have SCCM and i'll use that to roll it out.
 

I am having the same problem when I try to add the IPS module to a machine that did not have it in the past.

I have found that by changing the LU policy to allow a manual live update from the client you can fix this. If you run Autoruns prior to the Live Update you will see that the driver file is missing. The entry is in the registry to load the driver however the file for WPSHelper is not in the c:\windows\system32\drivers folder. After you run the Manual LiveUpdate the driver gets inserted in the drivers folder and the defs get updated and you are good to go. The driverquery command works really well to confirm what is loaded vs what is not loaded.

This one can take time to register in our environment while the others updates straight away,

So I found a way around this. Before changing the installed feature set on the device you want to add IPS to change the Live Update Policy to point to Symantec and allow manual updates. When you add the package for the IPS it will look to symantec for the first ntp def and you are good to go!

STF that sounds promising but i'll need to do it in small batches over time as the initial download will be reasonably substantial.

I had an issue with our 64 bit clients not updating the new anti virus and network threat protection definitions and the PTP definitions would always say "waiting for updates".  I was looking at the files on SEPM in C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Inetpub\content\{812CD25E-1049-4086-9DDD-A4FAE649FBDF} and noticed that one of the sub directories only had the full.zip file and it had an old date.  I tried to delete the file but received error message about the disk either being full or the file in use. There was plenty of free space and the file was not in use.  I rebooted the server and when I went to look for the file I noticed that it was missing.  I then went to the 64 bit Windows 7 clients I saw that they were now getting the latest updates.