SEC 5.1 Migration

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

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