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

Fresh Install of EC 5.3 on Windows 2012

Hi There,

We currently have EC 5.1 running on Windows 2003 with 2000 connecteed clients. I would like to do a fresh installation on Window 2012. Any tips

Thanks

:57859


This thread was automatically locked due to age.
  • Hello Joetobai,

    a fresh installation

    without migrating the database (and therefore any settings)? Keeping to server's identity (in terms of certificates, not necessarily IP and/or name)? Windows endpoints only?

    Christian

    :57861
  • It will have to be a different IP Address & was hoping to have the Database in a Centrialized Database Server so I was thinking maybe a fresh install is the way to go, I dont mind re doing the policys & Groups but I'm open to suggestions

    Thanks

    J

    :57863
  • Hello J,

    so right now the database is local and you want to have it on a central server? IP changes, likely name as well, doesn't it?

    *mumblemumble*

    The clean and supported way is obviously starting with an empty (remote) database and re-doing p&g. Or upgrading to 5.3 on the 2003, moving the database, and then do a migrate-install on 2012 (with the remote database).  

    What would be your ideal scenario (fantasise ... ok - exclude: it magically just happens and someone else does it :smileyhappy:)?

    Christian

    :57864
  • New Server Name, new IP, new location of Database, I'm thinking fresh install. Any major downsides to this approach ?

     Thanks

    J

    :57868
  • Hello Joetobai,

    any major downsides

    either you lose all historical data and have to re-do Groups and Policies (you'd have to amend the updating policies anyway), or you must move and upgrade the database manually. Are you using Patch, BTW?

    I'd suggest you reuse the server's certificates. On the new server configure the CID according to section B. You'd then (on the old server) assign to one or more groups an updating policy pointing to the new server. Once the endpoints have correctly updated from there they should appear in the new server's Unassigned group. The advantage is that you can take your time moving the endpoints.

    Christian

    :57871
  • Not Using Patch, so its ok to run the Old & New together for a period & move clients over a period of time.

    Thanks

    J

    :57877
  • Hi All,

    I'm moving clients from the OLD console to the new but they seem to appear in the new server but then after a period of time appear back on the OLD console, any help would be great.

    Thanks

    J

    :57952
  • Hello J,

    how do/did you move them from old to new?

    Christian

    :57954
  • I updated the Mrinit.conf file to point to new Server & ran ConfigCid.exe, so then I move clients on old Server to a folder which is updated via the Update path which has been edited, after which they appear in the New Console which is all gd but then after 15/20 mins they appear back on Old Console. If I do a "protect computer" on the clients on the OLD Console they will stay on New Console. Hope that makes sense


    Thanks


    J

    :57958
  • Hello J,

    updated the Mrinit.conf file

    where? On the old or the new server, in the root (SAVSCFXP) of the CID or the RMS subdirectory? Did you create an additional CID?

    the Update path which has been edited

    points to the new old server?

    Reminds me of this old article, but ... what's your updating interval? As the endpoints initially go to the Unassigned group on the new server - do you move them to a specific group once they appear?

    I'm trying to envision how the behaviour you describe could be evoked ...

    • add a CID on old, edit mrinit.conf and put it in the RMS subdirectory
    • let endpoints update from this CID on old, RMS will reconfigure (mrinit.conf.orig will be saved) and start to communicate with new
    • endpoints appear on new, are moved to a group which instructs them to update from new
    • as there is no mrinit.conf in the RMS subdirectory endpoints will fall back to mrinit.conf.orig
    • endpoints re-appear on old

    Clearly at this point the updating policy on the endpoint does not comply with that on old - wonder whether and when this is detected though. Maybe I've overlooked something though.

    Anyway, if you - on new - put  mrinit.conf also in the RMS subdirectory (running ConfigCID afterwards) the endpoints should "stay".

    Christian

    :57960