This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Awaiting Policy Transfer & SavService.exe 99% CPU

Hi all,

We are experiencing a strange issue wiith the clients (Version 9) and EC (Version 4) where they do not seem to be reporting correctly and getting hammered with 99% of the CPU.

One of the issues was the number of messages that were still waiting to be processed in the Envelopes folder, there was roughly 1GB's worth of files sat waiting to be processed.  This was rectified by following supports instrcutions, but unfortunatley there is still an issue with clients reporting to the console.  A lot of machines are showing awaiting policy transfer or differs from policy, although they dont seem to be different from the policy if you check locally.

The second issue is based around the policies being applied from the console.  If we modify the policy in the console and apply it to the clients a number of machines sit get hit by the savservice running at 99%.  The only way I have found of stopping this from happening is to remove the messages from the envelopes folder and then end the process on the clients.  If the policy is then reapplied the same happens again.

This has been logged with support but I was hoping some of you guys might have some idea's.

Thanks

:2091


This thread was automatically locked due to age.
  • I used to have this problem with Enterprise 2 and Sophos 5 when it was released; I've not seen it at all with Enterprise 3 or 4. I would routinely end up with 2GB of envelopes and the Sophos chaps had to remote desktop to my server in the end to run diagnostics and fiddle with the registry. It was never fully resolved until Enterprise 3 was released and now I have about 1MB of envelopes.

    Your endpoints aren't using virtual network adapters are they, or aren't using DHCP to be assigned fresh hostnames and IP addresses every time they're turned on? A good way of confusing ES3/4 is to install a virtual network adapter after managing a client - it'll keep trying to talk to the wrong interface and never get through.

    :2108
  • Hi Chris, thanks for the reply.  We are using DHCP to assign new IP's but the lease is a fairly standard length of time and last for a few days, and none of the clients are using virtual network adapters.  There doesnt seem to be a pattern to them either which is annoying to say the least, there is a mixture of desktops and laptops.

    I have had the issue before when clearing the envelopes sorts the clients out but this time we seem to have about 85 connected machines that are still awaiting policy transfer.  I am going to try and uninstall a couple more of them today and see what happens after a redeployment.

    As for the 99% CPU issue, I seem to have got to the bottom of this.  It only happened when a policy modifiation was done, so applying the default policy to the clients worked OK and didnt cause the spike.  So it looked like the AV & HIPS policy that was deployed was corrupt or something.  Creating a new policy and reapplying the exceptions seems to have resolved it.  Now a new policy with the same exceptions works OK and can be modified and applied freely without causing an issues.

    :2112
  • RE: "A lot of machines are showing awaiting policy transfer or differs from policy, although they dont seem to be different from the policy if you check locally."

    and I have the local clients are not 'tracking' the scheduled scans and reporting them to the console.

    All of my problems started after my conversion from console v3 to v4 and setup new policies for the clients

    to get/upgrade from the v7.6 to v9 clients...

    The clients appeared to have 'upgraded', but something is corrupt and they are not tracking/reporting anymore...

    but they do checkin and get updates.

    When I've tried to manually uninstall- usually a component (autoupdate/RMS/AV) will error out and fail.

    So follow instructs from support and run into DLL's that cannot be deleted from the disk

    and/or incorrect permissions in the registry.

    So, suspect some pieces really did not get upgraded - and was trying to run with incompatable 'mixed' component versions.

    I'm slowly get them all fixed, but a real pain to manually do each.

    :2126
  • I see. Yes, I had similar to that once too. I made a new schedule and it stopped all my schedules from working because it was corrupt, even though you could inspect the settings for it and it was all fine. Good news on fixing it by making a new identical policy (rather than copying the faulty one which presumably would have been corrupt too).

    One more thing to check regarding your clients is to look in your 3/CertificationManger/IssuedCert folder. How big is your CMIssuedCertifices.log file? It should be very small, i.e. a few hundred KB. Once I looked there and it was getting on 10MB so I had to wipe them out and start again which you can do by:

    1. Stop Message router.

    2. Stop certification manager.

    3. Delete your envelopes and CMIssuedCertificates.log file.

    4. Delete your table_router.txt file from your router folder (contents should be one line per PC).

    5. Start up certification manager.

    6. Start up message router.

    The above will make all your clients ask for a connection certificate again and clear out the history of client connection. I've not needed to do that since the ES2 days but if your certificates file is enormous it's worth doing.

    As for your trouble MALeonard, I bet you're really annoyed with that. You upgraded properly and then found it hadn't done it. I've only done an upgrade once (ES2 to ES3) - this time round I started again on a new server and migrated my clients across.

    :2133
  • ^You might want to hold off on my advice to delete certification files.

    I just tested on my ES3 system and it regenerates them fine. On my ES4 system it doesn't generate anything at all again. Oops.

    :2145
  • Hi MALeonard, I am also experiencing the same problem re: Awaiting Policy Transfer on the endopoints after I have migrated to Version 9 and SEC (Version 4). May I know if your issue has been resolved? If so, how did you resolved it? Thank you very much. Hi Chris_D I have tried your suggestion by deleting the envelopes and table_router.txt (not including CMIssuedCertificates.log file.) Yet, same problem occur. Any more ideas? Thanks!
    :3932
  • Came across this today. Most machines in enterprise console 4 running v9 client where showing up as awaiting policy transfer.

    check out http://www.sophos.com/support/knowledgebase/article/65502.html

    selecting the machines and forcing them to comply with the device control policy sorted the issue.

    :4354
  • I have exactly the same problem, Enterprise Console Version 4 and SAV 9, tried to force comply and nothing changed??  Anyone else have a solution to this?

    :4536
  • Hi Guys,

    Any luck or solution on this?

    Many thanks!

    :6499
  • Dear all :

        i Have Same Issue , i configured device control policy and i comply with device control policy , but  it showing  "Awaiting policy transfer ". PLs anyone Guide me to fix this Issue

    :18803