Issues Upgrading and Identifying Sophos Consoles & Clients

Hi,

When you say there were about 3-4 consoles on different servers and you mention you found a server which held the DB.  Do you have one Sophos management server on the network with multiple remote SEC consoles installations on various clients?  

Do you know how many EMLibrarys you had?  

You would manage EMLibrary through EMLibrary Consoles (MMC snapins), I just would like to check if you mean Enterprise Consoles or EMLibrary Consoles.  I've always found SEC as simple and intuitive as it gets for a console, EMLibrary console I can perhaps understand the confusion.

There is nothing centrally to identify other remote SEC console installations, other than maybe remote connections to the mgntsvc.exe process on the management server but even this would require them to be actively connected.  Upgrading remote SEC consoles is just an upgrade of the "Management console" role but as your not migrating any data, it can be as easy to just remove the console and reinstall the latest version.  All the data is held on the management server a remote SEC console is just a front end,

Regarding the EMLibrary message you have opening the console: Before SEC 4, EMLibrary was the application which downloaded the software and deployed it to the distributions points (then known as CIDs).  As of SEC 4, Sophos Update Manager (SUM) replaced this component and creates distribution points based on subscriptions.  EMlibrarys and SUMs can exist in the same environment until you are able to migrate them all over to SUM.  In a simple install there is typically only one EMLibrary or SUM on the management server, it's only when you have remote sites, distributed networks where you might consider using additional EMlibrarys or SUMs.  Deploying SIUM to the machines running EMlibrary should upgrade them to SUM as long as it's deemed a "simple" configuration.  SEC will tell you the outcome either way.

The warning you get when you open the console suggests that a SEC group may have a legacy updating policy linked to it or there is a child EMLibrary still updating and sending in status messages.  If you look in the table EMLibraryServers in the SOPHOS45 database you can see the computerids and the last status time, which can be joined to the computerID in the computersanddeletedcomputers table.  This could help you find a rouge EMLibrary that is still running that might need to be upgraded/de-commissioned if the message times are still recent.

As for clearing up the database.  I would wait until you are happy with the updating infrastructure and clients that are still in the system have updated.  It might be then worth considering using the PurgeDB.exe tool to purge machine records which haven't sent a message in with X number of days.

Updating the clients should be an automatic, once SUM is configured and subscribed to a recent package, such as SAV 9.5 recommended, and created the corresponding distribution point, see "Bootstrap locations" in SEC.  If the policies of the clients are correct they should just pull down the latest version and install.  

I would check the following:

1. SUM is configured correctly to get the latest package (via SEC).

2. Check it has pushed the software to the distribution point.

3. Check the updating policy is set to use the same subscription.

4. Link the updating policy to the SEC groups.

5. Check that the updating policy has been received by the endpoints and they now point at the correct distribution group.

6. Check the latest version is installed on the client and it is reflected in SEC.

I hope this helps.

Jak

Hi,

When you say there were about 3-4 consoles on different servers and you mention you found a server which held the DB.  Do you have one Sophos management server on the network with multiple remote SEC consoles installations on various clients?  

Do you know how many EMLibrarys you had?  

You would manage EMLibrary through EMLibrary Consoles (MMC snapins), I just would like to check if you mean Enterprise Consoles or EMLibrary Consoles.  I've always found SEC as simple and intuitive as it gets for a console, EMLibrary console I can perhaps understand the confusion.

There is nothing centrally to identify other remote SEC console installations, other than maybe remote connections to the mgntsvc.exe process on the management server but even this would require them to be actively connected.  Upgrading remote SEC consoles is just an upgrade of the "Management console" role but as your not migrating any data, it can be as easy to just remove the console and reinstall the latest version.  All the data is held on the management server a remote SEC console is just a front end,

Regarding the EMLibrary message you have opening the console: Before SEC 4, EMLibrary was the application which downloaded the software and deployed it to the distributions points (then known as CIDs).  As of SEC 4, Sophos Update Manager (SUM) replaced this component and creates distribution points based on subscriptions.  EMlibrarys and SUMs can exist in the same environment until you are able to migrate them all over to SUM.  In a simple install there is typically only one EMLibrary or SUM on the management server, it's only when you have remote sites, distributed networks where you might consider using additional EMlibrarys or SUMs.  Deploying SIUM to the machines running EMlibrary should upgrade them to SUM as long as it's deemed a "simple" configuration.  SEC will tell you the outcome either way.

The warning you get when you open the console suggests that a SEC group may have a legacy updating policy linked to it or there is a child EMLibrary still updating and sending in status messages.  If you look in the table EMLibraryServers in the SOPHOS45 database you can see the computerids and the last status time, which can be joined to the computerID in the computersanddeletedcomputers table.  This could help you find a rouge EMLibrary that is still running that might need to be upgraded/de-commissioned if the message times are still recent.

As for clearing up the database.  I would wait until you are happy with the updating infrastructure and clients that are still in the system have updated.  It might be then worth considering using the PurgeDB.exe tool to purge machine records which haven't sent a message in with X number of days.

Updating the clients should be an automatic, once SUM is configured and subscribed to a recent package, such as SAV 9.5 recommended, and created the corresponding distribution point, see "Bootstrap locations" in SEC.  If the policies of the clients are correct they should just pull down the latest version and install.  

I would check the following:

1. SUM is configured correctly to get the latest package (via SEC).

2. Check it has pushed the software to the distribution point.

3. Check the updating policy is set to use the same subscription.

4. Link the updating policy to the SEC groups.

5. Check that the updating policy has been received by the endpoints and they now point at the correct distribution group.

6. Check the latest version is installed on the client and it is reflected in SEC.

I hope this helps.

Jak