5.2.0.644 on Win2003 to Win2008 What version should i install latest?and which migration guide.

So Stage 1: Getting a 5.2 migration Guide.  That was easy......

Go to the url for the 5.3 migration guide and I changed the 53 to 52 in the url and that worked :)

So i've got the 5.2 Upgrade Guide https://www.sophos.com/en-us/medialibrary/PDFs/documentation/sec_52_mgeng.pdf

I guess the only question is should I try to find 5.2 to install on the Win2008 server it's going to, or should that be running the latest version whatever it is.

Question 2:

Old Server no idea on the SophosUpdateMgr password.  But it looks like this was lost a while ago and we have created a user called av with a password that I know. Which has access to all the shares. It looks like this is the username/password used by the clients to access the server. 

If that is correct is it ok to just change the SophosUpdateMgr password

Hello StephanieGelder,

unless you are in an AD environment the account has to be created locally before migration and you are prompted for user and password (e.g. SophosUpdateMgr) during install. If your policies have some other user defined you'd have to create it on the new server - endpoints use the user from the policies.

You want to both migrate and upgrade, as you can't upgrade to 5.5 on 2003 you'd have to install 5.2 on the new server (currently it's not available in Downloads) - do you have the \sec_520\ directory on the old server? After migration you'd then upgrade to SEC 5.5.0 on the new server.

Christian

Hi christian.

Thanks for your advice.  No i don't have the sec52 directory on the old server that got deleted at some point when it was running out of space in the past.

Arrgh so I somehow need to get hold of the 5.2.0.644 to put on the other server.

For the record.

I asked Sophos Support what to do.  Because my old one is unsupported it was hard luck we don't have the download on the servers any more. 

The support option is to reinstall a new server running the latest version of the enterprise console, and then use this:-

https://community.sophos.com/kb/en-us/116737

To redirect all the existing endpoints to the new server. So what do you guys think?

I've got a copy of 5.3 if that works on 2003 then I can upgrade it to that and also install that on the new server? Or is it easier to just have a clean start but then i need to ensure that every pc when they login to our network runs the script to update it's Sophos to point to the new server.

Hello StephanieGelder,

IMO it's not the best advice - you'll lose all configuration (group structure and membership, policies) and historical data. This might or might not be acceptable. Furthermore, as your old server is available, there are other ways to redirect endpoints (AFAIK at least Windows, possibly Macs as well) to the new server which don't require accessing them. OTOH even with "standard" migration you have to redirect them.

Of course, taking 530 as intermediate is a possible scenario. The upgrade shouldn't take long (with moderately size virtual hardware my last one took less than 20 minutes), the rest is the same as for 520. So this is probably the easiest route. Just for completeness, migration and upgrade can be performed in one step (but that's an unsupported scenario).

IMO the redirection is the essential task. The recommended reProtect Computers isn't feasible in all environments (as is the scripted approach). Last but not least just giving the new server (assuming you have migrated the certificates) the old server's name as alias also works in most cases.

Christian

Thanks for that Christian.

My answers are all a bit slow coming i'm afraid as i'm doing 500 other things at the same time as usual. We never get the time we need to concentrate on things.

So the Original one on Win2003 is now running 5.3.0

I have the same installer and am about to put that on the new server. 

Looking at our Updater it uses the Sophos Manager internally in Sophos and i've no clue what that password is.

Looking at our clients.

So the clients have their update info as :- \\dcesrv\SophosUpdate\CIDs\S018\SAVSCFXP..... etc...

Some have SophosUpdateMgr (which I don't know the password for) and some have AV (which I do know the password for)

The drive is shared out from the server and SophosUdateMgr and AV both have permissions on this so either can see the correct directory.

Now I need to sit down and read, and re-read the migration instructions :)

Hello StephanieGelder,

what I would do (not exactly by the book) and have done (not exactly, actually I omit some things and keep the old server running - I lose the message from the endpoints from the point of the database backup until they show in the new server, for me this is acceptable). Do you use Patch? If so, please see near the end.

Whatever you do, if you migrate the database you have to amend the updating policies because a) they point to the old server and b) you have to review the updating credentials. Thus you might as well change them so they all use the same user, whether the (newly created) SophosUpdateMgr or some other user. Thus you don't need the old password.

1. Stop the management services on the old server. Export/backup the old server, import certificates, install and subsequently import the DB, create "SUM user", install management server and console. Start. Review subscriptions and updating policies (perhaps they can be consolidated) and make necessary changes. Protect the management server itself.
2. If everything is fine upgrade to 5.5.0  
   
3. Configure RMS in the new CIDs as described under 1.2 item 6 and 1.3 in Enterprise Console: configuring message relay computers (no relay is involved, it just a description of the procedure - just copy the mrinit.conf in the new CIDs "down" to the \rms subdirectory)
4. Export the (hopefully not many) updating policies on the new server - a little bit tedious. Put each as sauconf.xml in the appropriate CIDs (i.e. the applicable Snnn\SAVSCFXP\sau subdirectories) on the old server and use ConfigCID.exe to apply them (this can be done CID by CID)   

Once a CID is configured the endpoints will download (still from old) the new updating policy from the CID, apply it, and use it with the next update. They will then fetch the new mrinit.conf, reconfigure RMS, and start talking to the new server.

Apart from leaving the old server running I don't export the policies (and configure the CIDs) in step 4 but change them manually on old.

As for Patch: You'd have to change the PrimaryServerUrl on the endpoints (either directly in the registry with some tool or by reprotecting/reinstalling)

Last but not least a rather arcane (and naturally unsupported) method is creating an alias "old" (NetBIOS/Windows networking and/or DNS) for the new server.

Christian

Hello StephanieGelder,

what I would do (not exactly by the book) and have done (not exactly, actually I omit some things and keep the old server running - I lose the message from the endpoints from the point of the database backup until they show in the new server, for me this is acceptable). Do you use Patch? If so, please see near the end.

Whatever you do, if you migrate the database you have to amend the updating policies because a) they point to the old server and b) you have to review the updating credentials. Thus you might as well change them so they all use the same user, whether the (newly created) SophosUpdateMgr or some other user. Thus you don't need the old password.

1. Stop the management services on the old server. Export/backup the old server, import certificates, install and subsequently import the DB, create "SUM user", install management server and console. Start. Review subscriptions and updating policies (perhaps they can be consolidated) and make necessary changes. Protect the management server itself.
2. If everything is fine upgrade to 5.5.0  
   
3. Configure RMS in the new CIDs as described under 1.2 item 6 and 1.3 in Enterprise Console: configuring message relay computers (no relay is involved, it just a description of the procedure - just copy the mrinit.conf in the new CIDs "down" to the \rms subdirectory)
4. Export the (hopefully not many) updating policies on the new server - a little bit tedious. Put each as sauconf.xml in the appropriate CIDs (i.e. the applicable Snnn\SAVSCFXP\sau subdirectories) on the old server and use ConfigCID.exe to apply them (this can be done CID by CID)   

Once a CID is configured the endpoints will download (still from old) the new updating policy from the CID, apply it, and use it with the next update. They will then fetch the new mrinit.conf, reconfigure RMS, and start talking to the new server.

Apart from leaving the old server running I don't export the policies (and configure the CIDs) in step 4 but change them manually on old.

As for Patch: You'd have to change the PrimaryServerUrl on the endpoints (either directly in the registry with some tool or by reprotecting/reinstalling)

Last but not least a rather arcane (and naturally unsupported) method is creating an alias "old" (NetBIOS/Windows networking and/or DNS) for the new server.

Christian