Video Screencast Help

To Be Embedded or Not To Be???

Created: 12 Apr 2013 • Updated: 12 Apr 2013 | 4 comments
This issue has been solved. See solution.

I'm upgrading the current SEP 11 to SEP 12.1.2 supporting about 1500 clients.  The SEPM will be built on a VM with Win2008 R2 as the OS.  Now I know by reading that the embedded DB can support up to 5000 clients, but I'm not feeling comfortable suggesting the embedded.  Reason 1, I installed SEPM w/ embedded DBin my test environment, and I'm having a bit of a struggle accessing the DB through the SQL Client Tools I installed.  Reason 2... The current SEPM DB is embedded on the SAME VM (don't know which genius thought of that).  If that VM gets corrupted, the whole SEPM is crashed.

So if I make the recommendation to a separate SQL Server, the impact of the DB should be minimal and much more secure.

Suggestions?  Recommendations?  Solution.  Thanks!!!

Operating Systems:

Comments 4 CommentsJump to latest comment

Brɨan's picture

I would always make the suggestion to go SQL if you can since it is a dedicated box. With embedded it's on the same box as the SEPM taking up resources. But if you have fantastic hardware than the impact is minimal. But that's just my personal opinion. I have a few SEPMs running the embedded db but do have good hardware so everything is running smoothly. I've been on the other side though where the SEPM was also used as a combo box and it was a struggle to get things running as they should.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Rafeeq's picture

embedded does not need any sort of instance licenses.

I'm sure you might be saving periodic snap shots.

Embedded DB can be backuped based on schedule.

You can use the dbsqlc.exe to query embedded db it can be found in

C:\Program Files\Symantec\Symantec Endpoint Protection Manager\ASA\win32\

Double-click on dbisqlc.exe to launch the application.

its my personal opinion. whatever is comfortable you can use that.

SebastianZ's picture

1. Obviously if you need access to the DB itself - access to SQL DB will be a lot easier from management studio than the one to the embedded database with any sql tools.

2. From failover point of view - SQL Server is a way to go as well - there is no option to put the embedded database on a different VM or physical machine. If only the SEPM VM crashes and you have the DB on SQL on a different VM - the disaster recovery will be quite easy and straightforward. If it is on the same machine as you mentioned you face the risk of loosing all configuration.

3. Having 1500 clients is I believe enough justification for going to SQL Server DB as well.

ra.moody's picture

Thank you all for your comments.  Your points are well taken.