SEC 5.1 Migration

Hello tomerb,

by same identity you are referring to the name/IP and the certificates (for the CertificateManager, not Encryption), aren't you? This is always a little bit ambiguous. The same certificates are needed so that the clients' RMS will successfully connect to the new server (BTW: why staying on 2003?).

I do not have the password for the SophosUpdateMgr user

This is (obfuscated) in the ManagementTools.reg. I haven't done it this way (as I've always used a known password), it should be possible to use this when SophosUpdateMgr is a domain account, but if you're using a local account you have to create this account (and it will have a different password).

there will be no way of pushing out updating policies

As long as RMS can connect when the clients come online again the will be able to fetch the new policies (in fact they need them only for the new password as all other settings remain the same). They will probaby fail on the first update request but once they have applied the new policies everything should be fine.

All clients are currently offline

... so it's too late for an alternate approach: Create another updating account (as described in section 6.1) set it as updating account in the policies and assign the policies while the old server is running. This way the clients won't see any change and can update immediately. But anyway, if you do an "in-place" migration RMS is the important part (unless you can easily reprotect the clients from SEC).

HTH

Christian

Hi Christian,

by same identity you are referring to the name/IP and the certificates (for the CertificateManager, not Encryption), aren't you?
Yes, that's correct. Basically, the server hardware is beginning to make trouble, so there's need for a replacement. You may call it a disaster recovery - only that the disaster hasn't happened (yet).

The same certificates are needed so that the clients' RMS will successfully connect to the new server
That's right. (I know too well what you're talking about as we had a real disaster recovery about a year or so and we didn't have those certificates...)

(BTW: why staying on 2003?).
Insufficient arguments for spending money on a 2008+ licence. ;-)

This is (obfuscated) in the ManagementTools.reg. I haven't done it this way (as I've always used a known password), it should be possible to use this when SophosUpdateMgr is a domain account, but if you're using a local account you have to create this account (and it will have a different password).
The unknown password dates back to SEC 4.5, where the account and password was created automatically during installation.

As long as RMS can connect when the clients come online again the will be able to fetch the new policies (in fact they need them only for the new password as all other settings remain the same). They will probaby fail on the first update request but once they have applied the new policies everything should be fine.
Correct. That's exactly what I had thought.

... so it's too late for an alternate approach: Create another updating account (as described in section 6.1) set it as updating account in the policies and assign the policies while the old server is running. This way the clients won't see any change and can update immediately.
I've read that and you just confirmed, that my understanding was correct. No, there's no need to do that.

But anyway, if you do an "in-place" migration RMS is the important part (unless you can easily reprotect the clients from SEC).
Re-protection is not (that) easy. ;-)

Finally, I just stumbled over this article, which looks even simpler:

http://www.sophos.com/en-us/support/knowledgebase/114299.aspx

I just did the backup part and it completed without error. Can I just do a complete install of the SEC and restore the data afterwards or do I have to stick by the order mentioned in the migration documentation (install database, restore database, Install other components, restore other data)?

Thanks in advance

Thomas

Hello Thomas,

do I have to stick by the order mentioned in the migration documentation

you don't expect me to dissent from the official documentation and suggest otherwise, do you :smileywink:? Last time I've actually migrated a whole production server was, IIRC, before 4.0 - so any experience from then does not apply. I did clone servers for Beta tests though, of course with a different name/IP but the same certificates (in order to be able to move the clients around without reprotecting them). I'd say just doing a full install and then restoring the database could work (on one occasion, think it was for 5.0, I've also imported the old (downlevel) database and manually upgraded it without problems). Please note that this is unsupported - but this might not scare you as you are DR-tested :smileyvery-happy:

Christian 

you don't expect me to dissent from the official documentation and suggest otherwise, do you

Of course not. It has always been my intention to stick to the official documentation. All I'm asking is: Which one?

We have the server migration guide http://www.sophos.com/en-us/medialibrary/PDFs/documentation/sec_51_mgeng.pdf dated June 2012. Since what I was doing was a very special case of a server migration, using that seems to be a good idea. (I went through it without any errors and I'm very optimistic that when the clients come back on, everything will work as expected.) The downside of this documentation is, that it's quite a lot of work.

Then there is the backup/restore guide http://www.sophos.com/en-us/support/knowledgebase/114299.aspx which seems to exactly describe my use case and is much simpler. It was last updated two weeks ago. It does, however, at one point refer to the migration guide, though not in a way that explicitly suggests that all the steps described there are to be applied. ;-)

To make it short:

I consider creating a scheduled task based on what's written in the backup/restore guide and copy that data to an external device. After that I'd like to be fairly confident to be able to make a DR using that data on a fresh install. ;-)