New to Sophos - looking for tips

Wow, where to start... :)

If I was tasked with a 15,000 deployment, here are some of the first questions I would want answering.  I'm not sure if you're looking to start afresh but here goes.

1. Establish the topology of Sophos deployment, distributed / compact install.

For 15,000 I would be looking at a distributed install, that is dedicated database server and dedicated management server.

Without that the specification of a single box would have to be quite pretty impressive to support 15,000 machines and even then relays would have to be used. 10K is the "supported" case for a single box.  After which it goes up to 25K with message relays.

I would suggest 2008R2 for SEC and 2008R2 running SQL 2008 sp2.  I would avoid plain Windows 2008 for the SEC machine and choose 2003 R2 over that if R2 wasn't available. 4GB of RAM would be a minimum for each.  Dedicated physical drives for SQLdata and possibly event logs, i.e. mdf and ldf.

So at this point, I have SEC 4.5.1 installed with a remote database.

If 2003 R2 was used following:

http://www.sophos.com/support/knowledgebase/article/14243.html

should be done.

2. Next I would want to know the packages I need to service all my endpoints.  E.g. Linux. Windows 2000+, Mac.

The next question is if I require the latest in all cases or to stick on latest -1 as a more cautious approach.  I guess the "importance" of the machines being covered is one reason for choosing a fixed version.  Bandwidth might be another, as a fixed version would not have such a large monthly download.  Having said that, the number of subscriptions includes complexity so I would try and keep the number of subscriptions to a minimum.

So for this example, I will have Windows, Mac.  I will choose the latest for Mac, I will choose the latest for Windows plus a fixed version of the windows package.  This should be 2 subscriptions.  I would label them something like:

"Recommended" (default)
"Fixed 9.5.3 Windows 2K+"

I would apply these to the local SUM, wait for the distribution points to be populated and using the "bootstrap locations" dialog in SEC make a note of the update paths and the versions they have.

3. As I foresee multiple SUMs in this environment I would then make this SUM the Authority as per:

http://www.sophos.com/support/knowledgebase/article/57638.html

It is important to note that, the SUM that is authoritative should be subscribed to all subscriptions throughout.

4. Not sure if ADSync is appropriate but I would suggest avoiding it if possible.  Enabling it fixes you with applying policies to AD containers essentially, so unless your AD tree divides everything up in "AV policies", "updating policies" etc, it's probably not for you.

The next step would be to protect the SEC server and database server with Sophos.  I would recommend exclusions for the database server. So I would first create groups in SEC at least.  

\Site1\Sophos\SEC

\Site1\Sophos\DB

For example, I would assign the DB group and AV policy for SQL servers.  This mainly includes following:

http://www.sophos.com/support/knowledgebase/article/60468.html

Once both the servers are protect and managed in SEC, I know RMS and everything is working so a good platform to build from.  I appreciate I have the distribution points on the SEC server.  This should be ok depending on a number of factors.  E.g. Updating interval, server location, other roles (hopefully none other than Sophos).  If this becomes a problem I would want to offload the distribution points to a filer or dedicated file server/web server.

5. The next task is setting up RMS and updating infrastructure for the clients.

With 15,000 machines, we need message relays:
http://www.sophos.com/support/knowledgebase/article/14635.html

I will assume for this example there are 3 sites of 5000 machines.  In this case I would be looking to install a Sophos server at each site.  It would run a SUM and a message relay.  

I would advise for the most elegant solution, that message relays are used throughout so even at the SEC server site, a relay is put in.  This will enable the SEC server to have a low number of connections to the message router.  The danger of having the local 5000 clients all reporting to the server along with the 2 remote relays is that the 2 relay connections are just treated like clients, so if there is any contention for resources, the remote sites will suffer.  It also makes troubleshooting easier.  Plus during an outbreak you can potentially shut off reporting independently of site.

At this point I now have:

At the main site 3 servers: SEC, DB, RelayServer. (possibly a file server)

At 2 the child sites, 1 machine. SUM and Relay.  The 2 child SUMs should be subscribed to the same subscriptions as on the parent.  Creating subscriptions per SUM is not required.

Again, if 2003 R2 was used for the relays:

http://www.sophos.com/support/knowledgebase/article/14243.html

should be done.

In creating the relays, Sophos would be installed, so in SEC I should see all 5 machine managed and appropriate groups created.  At this point the updating and messaging infrastructure should be setup.

6. Now comes the task of finding machines, creating groups, defining policies and protecting the clients.  The techniques for this can be varied to "catch" them all.

AD search should be used if AD is well managed and current.  This is a fast way of getting the machines records.

Once happy with the group structure and the majority of machines records are in the right groups, I would start defining policies.  This way as soon as the machines are protected they should pickup their intended policy.

For machines that aren't on much, e.g roaming Sales laptops (not a dig at Sales people :)), I would think about AD start-up scripts, something along the line of:

http://www.sophos.com/support/knowledgebase/article/13090.html

this is also acceptable in my view for machines being imaged.  Typically they go through a test phase after being imaged, so at this point Sophos should be installed by the start-up script and I can ensure it is in the right SEC group and thus have the right policy before shipping it to a user.

When setting up deployment scripts, the first step is establishing the deployment string required.  As I've mentioned before in another post, protecting a test machine and grabbing the deployment string from the created scheduled task is my preferred method.  It saves messing about with obfuscationutil and ensures I get all the right switches.  Having said that, looking at:
http://www.sophos.com/support/knowledgebase/article/12570.html

is worth while, as there are a few extra ones that might be added.

I would probably use SEC to deploy to machines that are typically always on, like servers and workstations.  Remembering that the account you deploy with in SEC needs:

1. To be able to log onto the SEC server.

2. Needs admin rights on the target machine, best test is if it can create a scheduled task on the machine and access the registry remotely.

I think that's about it.  I've possibly glossed over the setting up of the message relay CIDs but as long as you don't start protecting clients before they are all setup and working you can take your time ensuring this part of the infrastructure is working.  After protecting the first client from the "relay" CID, check the parent address of the machine in the registry key under:

hklm\software\sophos\messaging system\router\parentaddress.

This should point to the relay and not the SEC server.

That's about all I can think of for now.  If I can offer one piece of advice, keep it as simple as possible and ensure the updating and messaging infrastructure are in place and working before moving on to clients.

Good luck,

Jak

Wow, where to start... :)

If I was tasked with a 15,000 deployment, here are some of the first questions I would want answering.  I'm not sure if you're looking to start afresh but here goes.

1. Establish the topology of Sophos deployment, distributed / compact install.

For 15,000 I would be looking at a distributed install, that is dedicated database server and dedicated management server.

Without that the specification of a single box would have to be quite pretty impressive to support 15,000 machines and even then relays would have to be used. 10K is the "supported" case for a single box.  After which it goes up to 25K with message relays.

I would suggest 2008R2 for SEC and 2008R2 running SQL 2008 sp2.  I would avoid plain Windows 2008 for the SEC machine and choose 2003 R2 over that if R2 wasn't available. 4GB of RAM would be a minimum for each.  Dedicated physical drives for SQLdata and possibly event logs, i.e. mdf and ldf.

So at this point, I have SEC 4.5.1 installed with a remote database.

If 2003 R2 was used following:

http://www.sophos.com/support/knowledgebase/article/14243.html

should be done.

2. Next I would want to know the packages I need to service all my endpoints.  E.g. Linux. Windows 2000+, Mac.

The next question is if I require the latest in all cases or to stick on latest -1 as a more cautious approach.  I guess the "importance" of the machines being covered is one reason for choosing a fixed version.  Bandwidth might be another, as a fixed version would not have such a large monthly download.  Having said that, the number of subscriptions includes complexity so I would try and keep the number of subscriptions to a minimum.

So for this example, I will have Windows, Mac.  I will choose the latest for Mac, I will choose the latest for Windows plus a fixed version of the windows package.  This should be 2 subscriptions.  I would label them something like:

"Recommended" (default)
"Fixed 9.5.3 Windows 2K+"

I would apply these to the local SUM, wait for the distribution points to be populated and using the "bootstrap locations" dialog in SEC make a note of the update paths and the versions they have.

3. As I foresee multiple SUMs in this environment I would then make this SUM the Authority as per:

http://www.sophos.com/support/knowledgebase/article/57638.html

It is important to note that, the SUM that is authoritative should be subscribed to all subscriptions throughout.

4. Not sure if ADSync is appropriate but I would suggest avoiding it if possible.  Enabling it fixes you with applying policies to AD containers essentially, so unless your AD tree divides everything up in "AV policies", "updating policies" etc, it's probably not for you.

The next step would be to protect the SEC server and database server with Sophos.  I would recommend exclusions for the database server. So I would first create groups in SEC at least.  

\Site1\Sophos\SEC

\Site1\Sophos\DB

For example, I would assign the DB group and AV policy for SQL servers.  This mainly includes following:

http://www.sophos.com/support/knowledgebase/article/60468.html

Once both the servers are protect and managed in SEC, I know RMS and everything is working so a good platform to build from.  I appreciate I have the distribution points on the SEC server.  This should be ok depending on a number of factors.  E.g. Updating interval, server location, other roles (hopefully none other than Sophos).  If this becomes a problem I would want to offload the distribution points to a filer or dedicated file server/web server.

5. The next task is setting up RMS and updating infrastructure for the clients.

With 15,000 machines, we need message relays:
http://www.sophos.com/support/knowledgebase/article/14635.html

I will assume for this example there are 3 sites of 5000 machines.  In this case I would be looking to install a Sophos server at each site.  It would run a SUM and a message relay.  

I would advise for the most elegant solution, that message relays are used throughout so even at the SEC server site, a relay is put in.  This will enable the SEC server to have a low number of connections to the message router.  The danger of having the local 5000 clients all reporting to the server along with the 2 remote relays is that the 2 relay connections are just treated like clients, so if there is any contention for resources, the remote sites will suffer.  It also makes troubleshooting easier.  Plus during an outbreak you can potentially shut off reporting independently of site.

At this point I now have:

At the main site 3 servers: SEC, DB, RelayServer. (possibly a file server)

At 2 the child sites, 1 machine. SUM and Relay.  The 2 child SUMs should be subscribed to the same subscriptions as on the parent.  Creating subscriptions per SUM is not required.

Again, if 2003 R2 was used for the relays:

http://www.sophos.com/support/knowledgebase/article/14243.html

should be done.

In creating the relays, Sophos would be installed, so in SEC I should see all 5 machine managed and appropriate groups created.  At this point the updating and messaging infrastructure should be setup.

6. Now comes the task of finding machines, creating groups, defining policies and protecting the clients.  The techniques for this can be varied to "catch" them all.

AD search should be used if AD is well managed and current.  This is a fast way of getting the machines records.

Once happy with the group structure and the majority of machines records are in the right groups, I would start defining policies.  This way as soon as the machines are protected they should pickup their intended policy.

For machines that aren't on much, e.g roaming Sales laptops (not a dig at Sales people :)), I would think about AD start-up scripts, something along the line of:

http://www.sophos.com/support/knowledgebase/article/13090.html

this is also acceptable in my view for machines being imaged.  Typically they go through a test phase after being imaged, so at this point Sophos should be installed by the start-up script and I can ensure it is in the right SEC group and thus have the right policy before shipping it to a user.

When setting up deployment scripts, the first step is establishing the deployment string required.  As I've mentioned before in another post, protecting a test machine and grabbing the deployment string from the created scheduled task is my preferred method.  It saves messing about with obfuscationutil and ensures I get all the right switches.  Having said that, looking at:
http://www.sophos.com/support/knowledgebase/article/12570.html

is worth while, as there are a few extra ones that might be added.

I would probably use SEC to deploy to machines that are typically always on, like servers and workstations.  Remembering that the account you deploy with in SEC needs:

1. To be able to log onto the SEC server.

2. Needs admin rights on the target machine, best test is if it can create a scheduled task on the machine and access the registry remotely.

I think that's about it.  I've possibly glossed over the setting up of the message relay CIDs but as long as you don't start protecting clients before they are all setup and working you can take your time ensuring this part of the infrastructure is working.  After protecting the first client from the "relay" CID, check the parent address of the machine in the registry key under:

hklm\software\sophos\messaging system\router\parentaddress.

This should point to the relay and not the SEC server.

That's about all I can think of for now.  If I can offer one piece of advice, keep it as simple as possible and ensure the updating and messaging infrastructure are in place and working before moving on to clients.

Good luck,

Jak