Protection Content/Proactive Threat Protection/TruScan Lists are not updating on ~20% of our Clients.
We have a new SEP 11 RU 5 installation that has ~10300 clients across ~183 location. The SEP 11 setup has two management servers using a SQL database installed on a seperate SQL server. At each location, we have Windows 2003 server which functions as a GUP.
We have been made aware that on a large number of our clients the Proactive Threat Protection definations were not updating. I ran a Protection Content Versions report and found the Commerical Application List Versions has the same date as the Proactive Threat protection definations that were not updating. The contents of the Protection Content Versions report for the Commerical Application List Version ran on 2010-30-23 is shown below:
Protection Content Versions
Commerical Application List Versions
on 2010-03-23
2010-03-22 rev. 018 7772 79.90%
2010-03-19 rev. 016 359 3.70%
2010-03-18 rev. 018 128 1.30%
2010-03-17 rev. 019 100 1%
2010-03-16 rev. 020 115 1.20%
2010-03-15 rev. 019 3 0%
2010-03-12 rev. 019 512 5.30%
2010-03-11 rev. 017 97 1%
2010-03-10 rev. 016 283 2.90%
2010-03-09 rev. 020 87 0.90%
Total 9456
Total 9726 100%
Older than 03-09 270
How do I get the cleints that are not updating to update?
Sincerely
Bruce Singer
Comments
On the clients where the PTP
On the clients where the PTP is not updated are you getting and errors in the event viwer related to that?
Prachand Kumar MCSE-2003 Symantec Technical Specialist (SCTS)
On the clients where the PTP
On the clients where the PTP is not updated are you getting and errors in the event viwer related to that?
I have not checked all ~2000 workstations, but for the clients I have checked, the event viewer's application log filtered symantec antivirus only shows information entries for
New virus definition file loaded. Version: 120328c. and
Symantec Endpoint Protection services startup was successful.
No entrires about TruScan or Proactive Threat .
Turns out that it was closer
Turns out that it was closer to 30% of the clients than 20% which is about 3000 machines for us. It was suggested un-installing the PTP and re-installing it again would correct the problem. That did not work on my test cases. The only thing I found that worked was uninstalling the entire SEP 11 client and then re-installing it which worked most of the time.
We had the Un-install Password option enabled and you can't get a script to automatically un-install SEP 11 with the Un-install Password option enabled. To get around this issue, for each of the largest groups I created another group with the same policies except the Un-install password option was not enabled. I started moving the accounts where the PTP/TruScan definitions were not updating to the "Un-install" groups. To my surprise, while in these "Un-install" groups, the PTP/TruScan started updating.
I did some more testing but the only thing that seemed to work was move the accounts to a new group where the "Un-install" password was not enabled. Once the workstation updated its PTP/TruScan definitions, it could then be moved back to the original group and would continue to update.
I used this process to resolve the issue on about 2200 workstations. {I had already re-installed on ~500 workstations before I found out they were updating while in the install groups}. Currently, Protection Content Versions reports ~800 workstations that are not on the current date which is just a little larger than our number of Laptops. The Laptops often run behind because they are not always connected to the network.
************************************ Posted March 29th *******************
We have been made aware that on a large number of our clients the Proactive Threat Protection definations were not updating. I ran a Protection Content Versions report and found the Commerical Application List Versions has the same date as the Proactive Threat protection definations that were not updating. The contents of the Protection Content Versions report for the Commerical Application List Version ran on 2010-30-23 is shown below:
Commerical Application List Versions
on 2010-03-23
2010-03-22 rev. 018 7772 79.90%
2010-03-19 rev. 016 359 3.70%
2010-03-18 rev. 018 128 1.30%
2010-03-17 rev. 019 100 1%
2010-03-16 rev. 020 115 1.20%
2010-03-15 rev. 019 3 0%
2010-03-12 rev. 019 512 5.30%
2010-03-11 rev. 017 97 1%
2010-03-10 rev. 016 283 2.90%
2010-03-09 rev. 020 87 0.90%
Total 9456
Total 9726 100%
Older than 03-09 270
March 29th, 2010 We have a new SEP 11 RU 5 installation that has ~10300 clients across ~183 location. The SEP 11 setup has two management servers using a SQL database installed on a seperate SQL server. At each location, we have Windows 2003 server which functions as a GUP.
Update as of 2010-07-22
On Tuesday after the 4th of July weekend, we had 5500 machines {~55%} that the PTP were not updating automatically. It took me the rest of the week to get LiveUpdate run on those 5500 machines twice and the next Monday we were down to ~2500 machines {~25%} that were not updating automatically. I was talking with another State Agency that uses SEP 11 RU5. Once I informed them how to determine if you are having the problem, they found out they were. They were able to get a large number of their clients to start updating by increasing the GUP Cache size from the default to 4 GB's. I already had our cache size set to 2 GB's but I increased it to 4 GB's and now we have about 1300 machines {~13%} that are not updating automatically.
Currently, I have stopped running LiveUpdate everyday. Instead I am trying to get SEP 11 reinstalled on those 1300 machines to see if it solves this issue.
We are also currently in the process of upgrading to RU6a. We have the two management servers and the SQL database updated. Our SCCM team is in the process of developing a SCCM package to roll the new client. {No, we don't update the clients from the management server because of limited bandwidth to the clients.}
I would try (if bandwidth
I would try (if bandwidth permitting), putting the clients in a group that is not attached to a GUP. The clients will get the content updates through the SEPM. Are all the clients running RU5 (11.0.5002.333)?
Mike
I would try (if bandwidth
I would try (if bandwidth permitting), putting the clients in a group that is not attached to a GUP. - We are a state agency and have very limited bandwidth to these sites. We need a GUP for bandwidth management.
The clients will get the content updates through the SEPM. We don't have great bandwith to the SEPM server.
Are all the clients running RU5 (11.0.5002.333)? - Yes
Sincerely
Bruce Singer
I've a much, much, smaller
I've a much, much, smaller implementation - under 100 clients - and I just had a user mention to me that she gets the out of date definitions message all the time. I looked at her PC and the virus defs are good but the protection ones are from October.
Bruce Singer - where is the Protection Content Versions report you mention? Boy, do I hate hate hate how the reports are in this thing but I've gone through it and cannot find this one so any help would be appreciated. Naturally, I'm worried that I have more than just this one out of date.
Bruce Singer - where is the
Bruce Singer - where is the Protection Content Versions report you mention? -- Logon to SEPM. Select the Reports ICON from the Left Edge. For Report Type, chose Computer Status. For the report Type select Protection Content Versions. I also chose the Advanced options and choose Online Staus of OnLine.
Hope this helps.
Sincerely
Bruce Singer
The Protection Content
The Protection Content Versions report is only a summary report. You can find the scale of the problem from the report but can not find which clients have the problem from it. I use Clients - Search for Clients - TruScan Permitted Applicaton List - < - Date of cleints want to find in YYYY-MM-DD format to find which clients are not working correctly
To try and keep my Protection
To try and keep my Protection Content/TruScan definations updated, I have manually be running LiveUpdate on the machines whose definations are older than one day. This has kept number not updating to about 1200. We have 700 laptops which may or may not be on the network every day. That leaves about 500 machines that will not update unless I manually run Liveupdate on them.
I have tried reinstalling, ect but I am still having ~12% of the machines not updating. I went on vaction for a week and LiveUpdate did not get run. The number of machine not updating climbed from ~1200 to 2700. I spent the first part of the week getting Liveupdate run on these machines. This moring, I came in and we had 3450 machines not updating. See the Protection Content Version report below:
Date of Report 2010-06-24
2010-06-23 rev. 018 6464 61.50%
2010-06-22 rev. 016 3453 32.80%
2010-06-21 rev. 017 59 0.60%
2010-06-18 rev. 023 97 0.90%
2010-06-17 rev. 016 35 0.30%
2010-06-16 rev. 017 47 0.40%
2010-06-15 rev. 019 21 0.20%
2010-06-14 rev. 018 25 0.20%
2010-06-11 rev. 009 33 0.30%
2010-06-10 rev. 019 20 0.20%
Total 10518 100%
Total on Report 10254
Not on Report 264
# Not Updating 4054
We are currently Using SEP 11 RU5. Planning to upgrade to SEP 11 RU6a.
At this point, I am strongly considering removing the Network Threat Protection from the install so I don't have to explain to the Auditors why 40% of our clients are not up-to-date.
You might check the clients to see if they reflect the same numbers. I have pcs duplicated on sepm due to system recovery, and the old dup shows for the outdated clients. Sometime the clients just don't update the server. Might be some of the numbers you are seeing.
I ha
same issue we are facing need your help
Dear Bruce.A.Singer,
we are facing the same issue.
can you please share that script with us uninstall and reinstall PTP .
thanks is advance.
and one more thing dont migrate your client to RU6a
wait for RU6MP1 it will be released on august.
Update - 09/21/2010
I have found out a couple more things about this issue.
1. Changing the LiveUpdate Policy for a Group causes the majority of the workstations in that group that were not updating their PTP's to start updating their PTP's again. While we have ~70 locations/Groups, 10 of these groups contain ~85% of our workstations. I have changed the LiveUpdate policy on these 10 groups multiple times when the number of PTP's not updating grows large and has significantly lowered the number of workstations that were not updating their PTP's. This is significantly better than re-installing SEP 11 on the workstations.
2. I started a case with Symantec support and they directed me to a Knowlege based article which suggested a workaround of using the commands SMC -Stop and SMC -start to get the PTP's to update again. This is not a permanent fix, but it will get PTP's updating again. I have done some limited testing and it appears this workaround is working for a significant portion of our workstations. It also suggested a workaround of setting the register key HKEY_LOCAL_MACHINE\Software\Symantec\LiveUpdate\SyknappsContentListReady" to the DWORD value of 1. This I have not yet tested.
PS, If you machine stops working as a GUP, restart the SMC seems to bring the GUP functionality back on-line as well.
PPS, my guess is changing the LiveUpdate Policy causes the SMC client to restart which is why changing the LiveUpdate Policy works to renable GUP's and PTP downloads.
2. I started a case with
2. I started a case with Symantec support and they directed me to a Knowlege based article which suggested a workaround of using the commands SMC -Stop and SMC -start to get the PTP's to update again. This is not a permanent fix, but it will get PTP's updating again. I have done some limited testing and it appears this workaround is working for a significant portion of our workstations. It also suggested a workaround of setting the register key HKEY_LOCAL_MACHINE\Software\Symantec\LiveUpdate\SyknappsContentListReady" to the DWORD value of 1. This I have not yet tested.
----------------------------------------------------------------------------------------
On item 2, issuing the SMC -Stop and SMC -start works on ~60% of the machines. On the other 40% of the machines, the SMC Serive is "Hung" and will not process the commands. I have to reboot the machines to get the SMC Service working again. See my Update Post below for more info on this issue.
As for the registry key change, over time I made the registry change to the majority of our workstations and was not able to tell it had any effect.
Upgrade to SEP 11 RU6 MP1- Will Solve PTP Issue
Hi Bruce,
Some good news for you....
Important changes were made in the most recent release of SEP- these have resolved the PTP updating issues in every case that I have encountered.
Here's the relevant change in the Release Note for RU6 MP1 (http://www.symantec.com/business/support/index?pag...):
With thanks and best regards,
Mick
We are currently in the
We are currently in the process of upgrading to SEP 11 RU6 MP1. We have about 6870 machines using RU6a and 3540 using RU6 MP1. We have ~270 machines with the RU6a clients with AV definitions are up to date but the PTP defintions are 1 day old or older. This is about 3.93% of the clients. We have ~30 machines with the RU6 MP1 clients with AV definitions are up to date but the PTP defintions are 1 day old or older. This is about 0.85% of the clients. It looks like the upgrade has helped the issue, but not solved it.
Sincerely
Bruce Singer
We have upgraded 3488 of our
We have upgraded 3488 of our 10391 workstations to SEP 11 RU6 MP1. As of this morning, we had ~270 machines that had updated AV's but PTP's were not. Of these, ~10 were SEP 11 RU6 MP1 machines. It looks like upgrading has helped the problem, but not totally solved it.
Symantec asked for Debug Logs from machines having the PTP update problem. I wrote a script to remotely change the registry, issue the SMC -Stop command, wait 60 seconds and then issue the SMC -Start command to enable debugging mode. I also wrote another script to copy the log file to a server, change the registry to turn off debugging, and then restart the SMC client. On ~ 20 machines, I would run the first script and then wait 30 minutes. I would then run the second script to collect the logs and turn debugging off. Only about 40% of the machines actually created logs which indicated that the SMC client was "Hung" and not processing commands. This really indicated there was an issue with the SMC client. It also meant that any logs I collected were not from the SMC clients having problems.
I also ran the script on ~20 machines where the AV's and PTP's definitions were up to date. This time, only ~60% of the machines created the logs, not the expected 100%. To see what was happening, I changed my restart SMC script to watch the status of the SMC service using WMI. What I noticed was that ~60% the SMC service status would first be STOPPED PENDING, STOPPED, and then RUNNING as the client restarted. This is what I considered normal. However, on ~35% of the machines the SMC Service Status would changed to STOPPED PENDING but would never change to STOPPED. On last 5%, the SMC Status never changed from RUNNING.
I changed my RestartSMC script to check if the SMC Service Status changes to STOPPED. If after 5 minutes, if the SMC Service Status does not change to STOPPED, it reboots the computer. After the SMC Service has STOPPED and is now is "RUNNING", I have the SMC client issue a Heartbeat.
Every night, I was running LiveUpdate on all machines that had AV or PTP definitions older than one day. I changed this script to run the RestartSMC service as described above, then run LiveUpdate, and finally run a Heartbeat. I have been successfully running this process for about 4 days.
Before I changed to this process, I was manually looking at about 10 -20 machines a day that were on but the SEP MC was reporting had out of date AV or PTP definitions. Of these machines, ~50% had updated definitions, but had not updated the SEP MC. Another ~40% I was able to get updated by running LiveUpdate and then Update Policy. The remaining 10% had numerous other problems which included freeing up disk space re-installing the SEP 11 client.
Last night, there were only 3 machines that were on and had out of date definitions. One of them I had already installed SEP 11 which did not work and I have a request in to re-image the machine. One of them I was unable to use any remote tools on it, but it was responding to a ping. I have sent a request to the local office to reboot the machine. The last one had only AV's out of date. LiveUpdate was not able to update the AV definitions, but I managed to get them updated by downloading the jdb file to the machine.
Since I started running this updated script on Thursday, we are running about 3% of the online machines that have PTP’s older than 1 day. I believe the majority of these machines are Laptops or machines that are turned off over night and have not yet had a chance to update their PTP’s. It looks like I finally have a method to keep the PTP definitions updated without having to change the LiveUpdate policy for all the groups.
It looks like the issue is with the SMC client. The upgrade to RU6 MP1 helps the situation but not totally solves it.
Sincerely
Bruce Singer
Would you like to reply?
Login or Register to post your comment.