Endpoint Protection

 View Only
Expand all | Collapse all

SEPM Embedded to SQL Migration path

  • 1.  SEPM Embedded to SQL Migration path

    Posted Sep 20, 2016 01:09 PM

    I'm looking for information on a full migration path from SEPM embedded DB to a SQL back end.

    I've got a lot of the documentation mentioned on the forum but, i don't see a spec sheet on what tables need to be created and or what user rights and access needs to be granted before starting the migration.

    Also, is SQL 2014 fully supported? 


    Current configuration is 2008 R2 server and my SEPM's and clients are on 12.1.6 MP5 build 7004



  • 2.  RE: SEPM Embedded to SQL Migration path

    Posted Sep 20, 2016 01:14 PM

    Symantec's official doc: http://www.symantec.com/docs/TECH102547

    I've found no spec sheet other than the above though.

    SQL 2014 should fully supported. 2016 is fully supported on MP6 which just came out the other day.



  • 3.  RE: SEPM Embedded to SQL Migration path

    Posted Sep 20, 2016 01:44 PM

    Are you planing on creating a custom database or letting the sepm create the database?  Because it is recommended that you let the installer create and initialize the database and that way you dont have to worry about permissions and tables. We do all the work for you when sepm creates it.



  • 4.  RE: SEPM Embedded to SQL Migration path

    Posted Sep 20, 2016 03:14 PM

    Thank you both for the response.

    The documentation just wasn't very clear. As I read it, it sounded like it would create all the permissions and tables but, I really wanted a deeper understanding, that's why I was hoping for the full documentation. I'm totally kosher with the wizard creating the tables but, I'll need some type of account/credentials in order for this to happen, correct? Is that information listed somewhere?



  • 5.  RE: SEPM Embedded to SQL Migration path

    Posted Sep 20, 2016 03:25 PM

    You can used a dedicated service account. Symantec recommends the account have sa equivalent permissions.



  • 6.  RE: SEPM Embedded to SQL Migration path

    Posted Sep 20, 2016 04:28 PM

    We use an SA on the server side of things, that's not a problem. Maybe I'm just having trouble comprehending this week...this SQL box will be a seperate server so, when i submit the request for the team to create the box, I'm essentially giving them nothing to go on. I'll say, give me X cores and RAM and install SQL server but don't create any tables...just give this SA account access to read/write?

     



  • 7.  RE: SEPM Embedded to SQL Migration path

    Posted Sep 20, 2016 04:36 PM

    That's correct. When you run the installer it will create the 'sem5' DB



  • 8.  RE: SEPM Embedded to SQL Migration path

    Trusted Advisor
    Posted Sep 21, 2016 04:19 AM

    Basically, in a nutshell...

    On the new box, it just need to have MS SQL installed with client tools and empty database.

    You backup the database on the old server. You run the SEPM installation on the new server and restore the database. The SEPM installer will do the whole work for you.

    Full steps can be found at https://support.symantec.com/en_US/article.TECH102547.html

    Good luck.



  • 9.  RE: SEPM Embedded to SQL Migration path

    Posted Sep 26, 2016 07:02 PM

    Last follow up question that I have.

    We have two seperate sites that replicate to each other over night. When this mirgration is complete, will we be sending transaction data to the DB live or is it the same as the embedded and it just does a mass update at night? I'm worried about creating a lot of network traffic between the two sites and causing issues with bandwidth.



  • 10.  RE: SEPM Embedded to SQL Migration path

    Posted Sep 26, 2016 07:05 PM

    You will have the option to schedule when you want replication to occur.



  • 11.  RE: SEPM Embedded to SQL Migration path

    Posted Sep 27, 2016 10:01 AM

    Right, I understand that portion.

    Our main SEPM is on another circuit and with the embedded DB, all the clients checked into it and then the data was replicated over to the 2nd site at night.

    SEPM 1 - is priority 1 and on circuit A

    SEPM 2 - is priority 2 on circuit B and the SQL box is on this circuit as well.

    So, if all my clients are checking into P1 on circuit A...it's going to be read/writing to the DB across the WAN...this doesn't seem like a good idea. I thought one SQL box would be fine since I'm replicating anyways but it may be ideal to have another box at the other site as well, yeah?