Managing Endpoint with Enterprise Console outside the network?

Hi,

I can see a couple of approaches that will work, one being far simpler than the other but doesn't provide you with the same level of control as the more complex solution. 

Method 1

If there is only a few clients to be managed at each site:

1. Install SEC + SUM at your site to create the distribution points/CIDs.
2. Define all the various policies of each type you require for the various companies in SEC, E.g. CompanyAAV, CompanyBAV, etc..
3. Use ExportConfig and ConfidCID to export these configurations to the XML files you can then place in the various distribution points/CIDs that have been created.  I'm not sure if you will have the same policies at each site. Either way this will work, you just might need to share out more distribution points centrally with a CID for each company/Config.
4. You can then share these update locations out centrally with Apache/IIS, etc..
5. The policies can use SMTP/SNMP to alert to viruses,at each site, that could hopefully be forwarded securely to the central site.

This would be simple to setup for a few machines at each site updating from a central location the downside would be the ease of appending to policies, inability to send clean-up tasks, without reconfiguring maybe the SAV policy but for a basic level of protection could be fine.  

For a large number of machines at each site, it could require a lot of bandwidth if all the clients were going to a remote location for updates.  Maybe install a SUM at each site and perform the same steps there or maybe a caching proxy could be configured at each site.  So once a file is grabbed from a remote location, it is cached by the proxy for subsequent requests.

Method 2

Firstly: Regarding machines appearing in SEC possibly having duplicate names.  This isn't so much of an issue, as long as they have different domain/workgroup names.  If they have the same domain name and work group name, you can use command line parameters with setup to override the computer name/domain name and description to ensure SEC sees them as unique entries.  See: http://www.sophos.com/support/knowledgebase/article/12570.html

As for central management.  I would suggest a message relay would need to be installed at each site.  Essentially a machine that all local machines at the site report to before forwarding messages to the central site.  I would also suggest this machine maybe has a SUM on to provide updates to the site also. As it is likely to be a server.  SUM could update either from a parent SUM at your site, or directly from Sophos at each site.  If each site updated from Sophos, I would suggest making the SUM at the central site the authoritative SUM (http://www.sophos.com/support/knowledgebase/article/57638.html), and ensure that that SUM is subscribed to all the same packages as all the various site SUMs are subscribed to.  If not, machines will potentially show as unknown with respect to their update status.

In order for the message relay on the site to be able to communicate with your central site, it would need to be able to make a TCP connection to 8192 and 8194.  Plus, if the child SUMs at each site were to update from the central site rather than Sophos, I would suggest sharing out the warehouse using a web server.  In which case port 80, or whatever you host the webserver on would also need to be permitted.  Ideally you would open up port 8194 on the child relay server for fast downstream messages from SEC, but I fear that machines is going to behind a router/NAT in which case, it might have to fall back to polling the central site for messages which should work fine.  The message relay at each site could always be tweaked to have a more aggressive polling time (getterinterval) to speed up downstream message take up by the sites. 

The hardest part in this sort of configuration relates to where the SEC server, or could be a message relay at the central site sits in the network.  Does it sit right on the edge or behind some device which will port forward, ports 8192 and 8194?  If you're port forwarding to the SEC server or another relay at the central site, you will need to "override the IOR" on that machine so the IOR contains an externally routable address.  This article explains how to do this: http://www.sophos.com/support/knowledgebase/article/50832.html

Essentially the remote sites should be able to connect to the central site using a FQDN, this FQDN will be in the child relays parent address.  If port forwarding at the central site is in use, you will have to override the IOR on the router the child relays will be connecting to, to contain that FQDN.  Plus the local Management Agent service, on that machine, will also need to be able to resolve that FQDN to be that same machine.

Quite a lot to process I know but once setup, each site should be able to communicate with the central site.

You may like to call Support to go over this plan and have them help you configure the management server/relay at the central site and one of the "site" relays and ensure it is communicating before moving on to managing clients at each site.

Good luck, 

Jak

Hi,

I can see a couple of approaches that will work, one being far simpler than the other but doesn't provide you with the same level of control as the more complex solution. 

Method 1

If there is only a few clients to be managed at each site:

1. Install SEC + SUM at your site to create the distribution points/CIDs.
2. Define all the various policies of each type you require for the various companies in SEC, E.g. CompanyAAV, CompanyBAV, etc..
3. Use ExportConfig and ConfidCID to export these configurations to the XML files you can then place in the various distribution points/CIDs that have been created.  I'm not sure if you will have the same policies at each site. Either way this will work, you just might need to share out more distribution points centrally with a CID for each company/Config.
4. You can then share these update locations out centrally with Apache/IIS, etc..
5. The policies can use SMTP/SNMP to alert to viruses,at each site, that could hopefully be forwarded securely to the central site.

This would be simple to setup for a few machines at each site updating from a central location the downside would be the ease of appending to policies, inability to send clean-up tasks, without reconfiguring maybe the SAV policy but for a basic level of protection could be fine.  

For a large number of machines at each site, it could require a lot of bandwidth if all the clients were going to a remote location for updates.  Maybe install a SUM at each site and perform the same steps there or maybe a caching proxy could be configured at each site.  So once a file is grabbed from a remote location, it is cached by the proxy for subsequent requests.

Method 2

Firstly: Regarding machines appearing in SEC possibly having duplicate names.  This isn't so much of an issue, as long as they have different domain/workgroup names.  If they have the same domain name and work group name, you can use command line parameters with setup to override the computer name/domain name and description to ensure SEC sees them as unique entries.  See: http://www.sophos.com/support/knowledgebase/article/12570.html

As for central management.  I would suggest a message relay would need to be installed at each site.  Essentially a machine that all local machines at the site report to before forwarding messages to the central site.  I would also suggest this machine maybe has a SUM on to provide updates to the site also. As it is likely to be a server.  SUM could update either from a parent SUM at your site, or directly from Sophos at each site.  If each site updated from Sophos, I would suggest making the SUM at the central site the authoritative SUM (http://www.sophos.com/support/knowledgebase/article/57638.html), and ensure that that SUM is subscribed to all the same packages as all the various site SUMs are subscribed to.  If not, machines will potentially show as unknown with respect to their update status.

In order for the message relay on the site to be able to communicate with your central site, it would need to be able to make a TCP connection to 8192 and 8194.  Plus, if the child SUMs at each site were to update from the central site rather than Sophos, I would suggest sharing out the warehouse using a web server.  In which case port 80, or whatever you host the webserver on would also need to be permitted.  Ideally you would open up port 8194 on the child relay server for fast downstream messages from SEC, but I fear that machines is going to behind a router/NAT in which case, it might have to fall back to polling the central site for messages which should work fine.  The message relay at each site could always be tweaked to have a more aggressive polling time (getterinterval) to speed up downstream message take up by the sites. 

The hardest part in this sort of configuration relates to where the SEC server, or could be a message relay at the central site sits in the network.  Does it sit right on the edge or behind some device which will port forward, ports 8192 and 8194?  If you're port forwarding to the SEC server or another relay at the central site, you will need to "override the IOR" on that machine so the IOR contains an externally routable address.  This article explains how to do this: http://www.sophos.com/support/knowledgebase/article/50832.html

Essentially the remote sites should be able to connect to the central site using a FQDN, this FQDN will be in the child relays parent address.  If port forwarding at the central site is in use, you will have to override the IOR on the router the child relays will be connecting to, to contain that FQDN.  Plus the local Management Agent service, on that machine, will also need to be able to resolve that FQDN to be that same machine.

Quite a lot to process I know but once setup, each site should be able to communicate with the central site.

You may like to call Support to go over this plan and have them help you configure the management server/relay at the central site and one of the "site" relays and ensure it is communicating before moving on to managing clients at each site.

Good luck, 

Jak