Managed computers + AD sync help

Hi,

You should be able to sync a single SEC group with a single OU.  It will however, always sync any childs of the OU, there is no way to prevent that.  

AD sync is really 2 stages,

1. Setting up the configuration that get stores in the database table dbo.SyncPointData.  

You use Enterprise Console to run the AD Sync wizard on a particular SEC group and in effect construct the LDAP string to associate with it. Any interaction with AD at this point is all done in the context of the user using SEC.  These LDAP queries are then stored in the table mentioned above, along with a SEC group ID and other flags to denote sync interval and configuration regarding auto deploy.

2. The sync with AD takes place at start-up of the Sophos Management Service and then at the interval chosen for the sync point.

As the Sophos Management Service performs the sync and this is running as local system, the machine account is used, so this will need access to the DC queried.

That's pretty much all there is to AD Sync.

As for the problem where endpoint machines can be pinged, are known to have SAV installed yet show as disconnected in SEC; you have to turn to Remote Management System (RMS) logs and configuration to understand what's happening there.  In short, RMS on the client is responsible for sending to SEC information about the computer.  The Sophos Message Router (RouterNT.exe) on the client communicates with the same service (RouterNT.exe) on the server (assuming you're not using message relays).  The client always initiates the communication with the server.  So the first thing to check with one of these clients is that the client is pointing at the right address, i.e. the SEC server and can resolve it.  

Check 1:

Ensure that all the Sophos services are started on the server and client.

Check 2:

On the client, open up:

HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Sophos\Messaging System\Router \ParentAddress
Is the parent address correct?

Check 3:
Stopping and starting the Router service should toggle the 'connected' state of the machine in SEC.  Does it?

Check 4:

Maybe worth checking the client communication report:. E.g.
"C:\ProgramData\Sophos\Remote Management System\3\Router\NetworkReport\ReportData.xml"

That might offer some help.

There are many more possible checks but that should start you off.

Updating errors do occur, are typically transient and should auto-clear providing there is not some hard error due to configuration issues.  

For example a machine goes away from the network, attempts to update, fails, the messaging system, stores a failure message on the client.  Later, the client returns to the network, RMS communication is restored and it sends in the message, you get an error displayed in SEC, shortly after AutoUpdate updates ok, sends in a 'ok' message and the failure is cleared.  

Maybe the first check of AutoUpdate happens before the machine has network access, generates a failure message and then has to wait until the next update interval to clear, meanwhile the machine has connected and sent in the failure message.  So the shorter the clients update interval the quicker it will clear a transient failure.  

You really need to work out the reason for the failures to know if there is anything you can do.  For example, if the second scenario is likely then for these machines you could add the registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\[WOW6432NODE]\Sophos\AutoUpdate]

"StartupDelay"=dword:0000000a  

Where in this case, the Alupdate update process would kick off 10 seconds after the service starts.  You could adjust this key to a suitable amount of time it takes for the clients to establish network connectivity.  This delay should cut down on the reported error before the success.

Regards,

Jak

Hi,

You should be able to sync a single SEC group with a single OU.  It will however, always sync any childs of the OU, there is no way to prevent that.  

AD sync is really 2 stages,

1. Setting up the configuration that get stores in the database table dbo.SyncPointData.  

You use Enterprise Console to run the AD Sync wizard on a particular SEC group and in effect construct the LDAP string to associate with it. Any interaction with AD at this point is all done in the context of the user using SEC.  These LDAP queries are then stored in the table mentioned above, along with a SEC group ID and other flags to denote sync interval and configuration regarding auto deploy.

2. The sync with AD takes place at start-up of the Sophos Management Service and then at the interval chosen for the sync point.

As the Sophos Management Service performs the sync and this is running as local system, the machine account is used, so this will need access to the DC queried.

That's pretty much all there is to AD Sync.

As for the problem where endpoint machines can be pinged, are known to have SAV installed yet show as disconnected in SEC; you have to turn to Remote Management System (RMS) logs and configuration to understand what's happening there.  In short, RMS on the client is responsible for sending to SEC information about the computer.  The Sophos Message Router (RouterNT.exe) on the client communicates with the same service (RouterNT.exe) on the server (assuming you're not using message relays).  The client always initiates the communication with the server.  So the first thing to check with one of these clients is that the client is pointing at the right address, i.e. the SEC server and can resolve it.  

Check 1:

Ensure that all the Sophos services are started on the server and client.

Check 2:

On the client, open up:

HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Sophos\Messaging System\Router \ParentAddress
Is the parent address correct?

Check 3:
Stopping and starting the Router service should toggle the 'connected' state of the machine in SEC.  Does it?

Check 4:

Maybe worth checking the client communication report:. E.g.
"C:\ProgramData\Sophos\Remote Management System\3\Router\NetworkReport\ReportData.xml"

That might offer some help.

There are many more possible checks but that should start you off.

Updating errors do occur, are typically transient and should auto-clear providing there is not some hard error due to configuration issues.  

For example a machine goes away from the network, attempts to update, fails, the messaging system, stores a failure message on the client.  Later, the client returns to the network, RMS communication is restored and it sends in the message, you get an error displayed in SEC, shortly after AutoUpdate updates ok, sends in a 'ok' message and the failure is cleared.  

Maybe the first check of AutoUpdate happens before the machine has network access, generates a failure message and then has to wait until the next update interval to clear, meanwhile the machine has connected and sent in the failure message.  So the shorter the clients update interval the quicker it will clear a transient failure.  

You really need to work out the reason for the failures to know if there is anything you can do.  For example, if the second scenario is likely then for these machines you could add the registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\[WOW6432NODE]\Sophos\AutoUpdate]

"StartupDelay"=dword:0000000a  

Where in this case, the Alupdate update process would kick off 10 seconds after the service starts.  You could adjust this key to a suitable amount of time it takes for the clients to establish network connectivity.  This delay should cut down on the reported error before the success.

Regards,

Jak