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

I am currently working on a lab within the Endpoint users module. I have dragged the policies to the appropriate group and have restarted the server. I am getting the message 

"Differs from Policy" under policy compliance. When I look under Update Details I see the message "Awaiting policy transfer". I have followed all of the instructions given in Lab booklet

and I cannot figure out why I am getting this message. I thought it may take a little time, but it has been 2 hours. HELP



This thread was automatically locked due to age.
Parents
  • It sounds like you're using Sophos Enterprise Console (SEC) rather than Sophos Central to manage these clients so this post is technically in the wrong place.  it should be here: https://community.sophos.com/products/endpoint-security-control/.  That said....

    Understanding the Remote Management System (RMS) component is key.  As a brief overview...

    When you install SEC, the installer checks to see if the management server is on computer with a static or dynamic IP.  The result of this is that the file mrinit.conf; that's in the root of distribution points (view bootstrap locations) is either configured with a parent address of: "ip, fqdn, netbios" or "fqdn, netbios".  This ultimately ends up being how the clients address the server.

    When you install the endpoint, you run setup.exe from the distribution point. This happens if you manually run setup.exe on the endpoint and go through the UI or pass the command line switches or if you use the SEC deployment wizard to create a scheduled task to run the task. 

    The first task setup.exe performs is to copy over mrinit.conf and cac.pem to the "remote management system" directory on the client (program files).  AutoUpdate is then installed and based on the switches (passed to setup.exe) it configures which packages to pull down.  After the files of the packages are pulled locally (UNC) AutoUpdate starts installing them.  The first package to install is RMS.  The MSI of that runs the command line utility clientmrinit.exe which reads the cac.pem and mrinit.conf and moves this data into the registry of the client:

    HKLM\software\(wow6432node)\sophos\mesaging system\router!ParentAddress.

    These config files aren't really used again until future updates.

    Once RMS is installed, it performs the following steps:

    1. Contacts the parent router on the first address in the parent address, on TCP port 8192.  If that fails then it tries the next, and so on, so typically:

    Fixed IP:
    ip, fqdn, netbios

    DHCP:
    fqdn, netbios

    2. This steps reads from port 8192 the IOR (telnet port 8192 to see the string or it's in the router logs - to parse: www2.parc.com/.../) the parent router is hosting.  This string holds the address of the server the and the SSL port to connect back to, by default TCP 8194.

    Note: It is for this reason both 8192 and 8194 on the server need to be open to the clients.

    3. The router service on the client then attempts to get a certificate.  Evidence of this having taken place is the pkc and pkp values under the router key:
    HKLM\SOFTWARE\[Wow6432Node]\Sophos\Messaging System\Router\Private\

    For this to happen, on the server the certification manager service and message router service need to be started.

    4. If both of these exist, then the client router can start accepting connection from the local agent service (ManagementAgentNT.exe) on the client.  This will enable the agent to get a certificate.
    Evidence of the agent having a certificate are the pkc and pkp keys here:
    HKLM\SOFTWARE\Wow6432Node\Sophos\Remote Management System\ManagementAgent\Private\

    In order for the agent to get its certificate quickly, TCP port 8194 incoming should be granted on the client.

    Once the agent and router are certified, then the client can send in a status message.  The status messages contains XML sections for each of the managed components.  E.g. SCF, SAU, SAV, etc..  It's these sections that the management server uses to know which policies can be sent to the endpoints.

    So when you're in SEC and you make a comply policy, the Sophos Management service creates a message, which is handed to the Sophos Message router service on the server.  Before messages can be sent to the clients router service over the network it is stored in the envelopes directory (\programdata\sophos\remote management system\3\router\envelopes..)  The server router messages the client router on 8194 to say, I've got a message outstanding for you come and get it.  If this poke fails, then the message is just queued for the client to pick up on its next poll.  The client pols the server every 15 mins +- 50%.  The reliance on this poll means that even if you don't open port 8194 on the client it will still get downstream messages they just maybe delayed by that time.  Once the client has the message the envelope is removed.

    So messaging goes from Router to Router (\ProgramData\Sophos\Remote Management System\3\Router\logs\) checking these will help understand connectivity issues.

    Hopefully this adds some information you can use to troubleshoot what is going on.

    Regards,

    Jak

Reply
  • It sounds like you're using Sophos Enterprise Console (SEC) rather than Sophos Central to manage these clients so this post is technically in the wrong place.  it should be here: https://community.sophos.com/products/endpoint-security-control/.  That said....

    Understanding the Remote Management System (RMS) component is key.  As a brief overview...

    When you install SEC, the installer checks to see if the management server is on computer with a static or dynamic IP.  The result of this is that the file mrinit.conf; that's in the root of distribution points (view bootstrap locations) is either configured with a parent address of: "ip, fqdn, netbios" or "fqdn, netbios".  This ultimately ends up being how the clients address the server.

    When you install the endpoint, you run setup.exe from the distribution point. This happens if you manually run setup.exe on the endpoint and go through the UI or pass the command line switches or if you use the SEC deployment wizard to create a scheduled task to run the task. 

    The first task setup.exe performs is to copy over mrinit.conf and cac.pem to the "remote management system" directory on the client (program files).  AutoUpdate is then installed and based on the switches (passed to setup.exe) it configures which packages to pull down.  After the files of the packages are pulled locally (UNC) AutoUpdate starts installing them.  The first package to install is RMS.  The MSI of that runs the command line utility clientmrinit.exe which reads the cac.pem and mrinit.conf and moves this data into the registry of the client:

    HKLM\software\(wow6432node)\sophos\mesaging system\router!ParentAddress.

    These config files aren't really used again until future updates.

    Once RMS is installed, it performs the following steps:

    1. Contacts the parent router on the first address in the parent address, on TCP port 8192.  If that fails then it tries the next, and so on, so typically:

    Fixed IP:
    ip, fqdn, netbios

    DHCP:
    fqdn, netbios

    2. This steps reads from port 8192 the IOR (telnet port 8192 to see the string or it's in the router logs - to parse: www2.parc.com/.../) the parent router is hosting.  This string holds the address of the server the and the SSL port to connect back to, by default TCP 8194.

    Note: It is for this reason both 8192 and 8194 on the server need to be open to the clients.

    3. The router service on the client then attempts to get a certificate.  Evidence of this having taken place is the pkc and pkp values under the router key:
    HKLM\SOFTWARE\[Wow6432Node]\Sophos\Messaging System\Router\Private\

    For this to happen, on the server the certification manager service and message router service need to be started.

    4. If both of these exist, then the client router can start accepting connection from the local agent service (ManagementAgentNT.exe) on the client.  This will enable the agent to get a certificate.
    Evidence of the agent having a certificate are the pkc and pkp keys here:
    HKLM\SOFTWARE\Wow6432Node\Sophos\Remote Management System\ManagementAgent\Private\

    In order for the agent to get its certificate quickly, TCP port 8194 incoming should be granted on the client.

    Once the agent and router are certified, then the client can send in a status message.  The status messages contains XML sections for each of the managed components.  E.g. SCF, SAU, SAV, etc..  It's these sections that the management server uses to know which policies can be sent to the endpoints.

    So when you're in SEC and you make a comply policy, the Sophos Management service creates a message, which is handed to the Sophos Message router service on the server.  Before messages can be sent to the clients router service over the network it is stored in the envelopes directory (\programdata\sophos\remote management system\3\router\envelopes..)  The server router messages the client router on 8194 to say, I've got a message outstanding for you come and get it.  If this poke fails, then the message is just queued for the client to pick up on its next poll.  The client pols the server every 15 mins +- 50%.  The reliance on this poll means that even if you don't open port 8194 on the client it will still get downstream messages they just maybe delayed by that time.  Once the client has the message the envelope is removed.

    So messaging goes from Router to Router (\ProgramData\Sophos\Remote Management System\3\Router\logs\) checking these will help understand connectivity issues.

    Hopefully this adds some information you can use to troubleshoot what is going on.

    Regards,

    Jak

Children
No Data