Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 1 subscriber
  • Views 8152 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

Install new Server with Enterprise Console and manage all preview Endpoints

FFN

Hi

I'd like to install the Sophos Enterprise Console 5.2 on a new VM. After the new clean installation with local DB I'd like to configure the console with new policies (new exclusions etc.). I don't like to move all the old stuff like described in this guide:

http://www.sophos.com/en-us/medialibrary/PDFs/nonindexed/sec_50_mgeng.pdf

Because then I will have all the old sins ;) in my new clean installation.

So far so easy. But now my question: Is it possible to easy add all the endpoints (more then 400) previously managed by my old enterprise console into the new installed enterprise console? And how?

I tried it the way described in the guide (link above), by just right click "protect". But this didn't work.

:40417


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

    Hello FFN,

    how will you test?

    Assuming everything works with the old server. You turn it off and let the new one take over. It rewrites the CIDs (unless it balks at overwriting) - but if this doesn't work as intended your clients won't be able to update. This is not what I call a test :smileywink:.

    write to the same location

    SUM verifies the consistency of the CID but when "someone else" modifies the contents SUM might (again might, I've never tested it) fail to update the share next time.

    When a server creates a CID it writes the appropriate mrinit.conf (which, BTW, you can edit) to it. After creating the inital mrinit.conf a server doesn't modify (or edit) it. The server also can't tell the clients to turn to a different management server. As said, for "redirecting" to work the servers must use the same credentials (otherwise the clients will not accept the reconfiguration). What the "old" server can do is telling the clients to update from some other CID (which is maintained by the new server and contains the appropriate mrinit.conf ). This CID must have the mrinit.conf also in the \rms subdirectory though. Otherwise you'd configure the CID maintained by the old server with the mrinit.conf for the new one. As said, I'd recommend different "old" and "new" shares.

    As for the error - you should be able to work after acknowledging the popup.

    Christian

    :40593
Reply
  • 0

    Hello FFN,

    how will you test?

    Assuming everything works with the old server. You turn it off and let the new one take over. It rewrites the CIDs (unless it balks at overwriting) - but if this doesn't work as intended your clients won't be able to update. This is not what I call a test :smileywink:.

    write to the same location

    SUM verifies the consistency of the CID but when "someone else" modifies the contents SUM might (again might, I've never tested it) fail to update the share next time.

    When a server creates a CID it writes the appropriate mrinit.conf (which, BTW, you can edit) to it. After creating the inital mrinit.conf a server doesn't modify (or edit) it. The server also can't tell the clients to turn to a different management server. As said, for "redirecting" to work the servers must use the same credentials (otherwise the clients will not accept the reconfiguration). What the "old" server can do is telling the clients to update from some other CID (which is maintained by the new server and contains the appropriate mrinit.conf ). This CID must have the mrinit.conf also in the \rms subdirectory though. Otherwise you'd configure the CID maintained by the old server with the mrinit.conf for the new one. As said, I'd recommend different "old" and "new" shares.

    As for the error - you should be able to work after acknowledging the popup.

    Christian

    :40593
Children
No Data