SEC - "Awaiting Policy Transfer" randomly appearing

Question

SEC Version: 4.7.0.13 Client Version: 9.7 ---------------------------------------- Hey, this has been something on going for sometime now and I was hoping I might be able to find a permanent solution. Basically what happens is I get random computers that one day decide to report the message "Awaiting Policy Transfer". Rebooting the machines does not correct the message, forcing the machine to do an update does not correct the message either. So far the only thing that seems to work is to push the client back down to the computer. The message is cleared and then sometimes with the same machine it reappears, other times it does not. It is not specific to any one computer, it just seems to be completely random with no rhyme nor reason to why it appears. I have done the stopping and starting of the "Sophos Message Router" service test to see if the clients are communicating back to the SEC. When I stop the service, I do receive a "red x" over the client in question and the "x" goes away when I start the service back up. The message doesn't seem to ever clear itself once it appears, the number of clients that report this message seems to climb unless I push the client back down to the computer. I am going to continue to monitor to see if the clients eventually do correct themselves, but I suspect they do not. Does anyone else have this issue or have you run into this issue? If so, how did you correct it? Any advice would be great! Thank you :16273

jak · Accepted Answer

Hi, You don't mention if performing a comply with policy for the policy in this state helps? Does it? Is it always the same policy that is in this state? I.e. Is is SAV, AutoUpdate, SCF? As far as I can tell this is how it should work: Looking in the Agent log on the client....If you restart the Sophos Agent service on the client, within about 20 seconds, it will send back a status message which will detail for each of the managed components if they are compliant with policy or not. If we take the SAV policy (PolicyType="2") as an example we see in the Agent log: I SAV state observer received a status: .... So we can see that the agent is reporting "Same" (Res="Same") for policytype 2 (SAV) for the policy with ID {94E7A42F-30FD-41FD-8345-23DE0C0C9CA3} So if my machine is in a group with a SAV policy called "Clients" I could run the following SQL: select name, correlationid from Policies where type= 2 and name ='Clients' and get back something like: name correlationid Server {94E7A42F-30FD-41FD-8345-23DE0C0C9CA3} So we can see that the "version" of the policy that the client should have is:{94E7A42F-30FD-41FD-8345-23DE0C0C9CA3}. So this machine in this state would show as "Same as policy" for the component SAV. If however I update the SAV policy, this will change the ID of the policy in the policies table. Essentially it appears a new GUID is generated, so it has a new revid. The machine then goes into a state of "Awaiting policy transfer". as the value the client has reported is for {94E7A42F-30FD-41FD-8345-23DE0C0C9CA3} and now the policy revid is another GUID. It will not show as Differs from policy until the client actually sends back a Res="Diff" for a given policy ID. Could it be that the following is happening for these machines: 1. Machine complies with SAV policy (using SAV policy as the example policy that is in this state). 2. Machine goes offline - red cross. 3. Policy change is made for the policy of SAV linked to the group the machine is in. 4. Set-Config message is created for the machine but as it's not connected the message is queued on the server with a TTL of 4 days. 5. The client logs on on the 5th day, the set config message has been deleted, so it doesn't get the message, the client hasn't reported Differs yet (Res="Diff"), but it still reports the old policy id. Therefore the system thinks it's still in the awaiting policy transfer state. In this case a comply with the policy that is in this state to the machine, if, the machine is on, should fix it? If the machine is not "connected" then the create message, timeout message scenario could repeat, leaving it in this state. Does this sound plausible as a theory? Regards, Jak EDIT, looking into this a bit further I've found the following 2 registry keys that can be enabled on the management server machine: HKLM\SOFTWARE\[Wow6432Node]\Sophos\EE\Management Tools\MessagingDoActionTimeout HKLM\SOFTWARE\[Wow6432Node]\Sophos\EE\Management Tools\MessagingSetConfigurationTimeout These two DWORD values are read by the management service when it attempts to create the messages but don't exist by default it seems. They appear to override the default TTL for a message. So to change the default TTL on a set-config message you could create the above MessagingSetConfigurationTimeout DWORD key, The value is in seconds. The downside is that the envelopes directory is more likely to fill if you perform set configurations to machines that are unable to recieve the message as the TTL value is higher. So this might be something to consider implementing if the above theory is correct and that clients aren't getting set config messages as they are timing out before they client can get them. :16283