Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 5850 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SEC 5.1 Migration

tomerb

Hello,

I'm planning the migration of a SEC 5.1 installation to a new server according to the documentation found here:

http://www.sophos.com/en-us/medialibrary/PDFs/migration/sec_51_mgeng.pdf

I just want to make sure that I didn't overlook anything.

Old and new server are both Windows 2003 32Bit, so I suppose there won't be much trouble here.

At the end, the new server is supposed to have the same identity as the old one. Apart from the fact that I have to take done the old server before setting up the new one, I don't see any issues here, either.

All clients are currently offline and are meant to stay that way until the end of the migration. This means that there will be no way of pushing out updating policies before migration.

I do not have the password for the SophosUpdateMgr user, but from my understanding I don't need it.

I'm not using Sophos Encryption.

So my idea was to do all the necessary steps on the old server, copy the files, take it down, install the new server with the same identity and then perform the steps described in the documentation on the new server. Is it correct that after that the clients will get a new update policy from the new server which of course includes the new password for the SophosUpdateMgr?

:38963


This thread was automatically locked due to age.
Parents
  • 0

    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

    :38967
Reply
  • 0

    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

    :38967
Children
No Data