Endpoint Protection

I am using Symantec EndPoint Protection 12.1, and i get these warnings messege when i open Manager Console (Unexpected server error. ErrorCode: 0x10010000) and Home,Monitors and Reports option shown blank. I do not know how to remedy the problem. 

Please help.  Thanks.

try this

http://www.symantec.com/business/support/index?page=content&id=TECH105218

Hi

First i would like to thanks for your prompt responce. I have tried all these following thing as the mention in given url, but unfortunatlly problem is remain same. I can give you some snap shot of Symantec Error & log files if you give me your email address.

Thanks once again for your support.

under the logs folder , u can find smc-server0.log..post it here.

i am having the same issue on a fresh install...here is my log...

Attachment(s)

scm-server-0_3.doc   1 KB 1 version

i have SEP software installed on a windows server 2008, 32 bit box, with the sql database residing on a seperate sql server, windows server 2003 standard R2, 32 bit. I verified the ODBC connections and it test connection is successsfull. using sa for sql authentication back to the database....I also have IIS 7.0 installed on the app server so not sure if that is causing a conflict with apache or a pure database connection issue?

Guys I had the same issue with a fresh install as follows:

* Windows 2008 R2 (VM1) --> SEP 12.1 Management Console with remote DB to...

* Windows 2008 R2 (VM2) --> SQL Server 2008 R2 (default instance)

* Using Windows Security --> AD service account granted dbo rights to sem5 database

This all looked good during the install with no errors...until I logged in and got the error listed above.

The fix.....?

...Grant "Log on as a service" rights on your management server (VM1 above) to the service account you're using to access SQL. Then change your Symantec Endpoint Protection Manager service to log on as this account. This will allow proper passthrough Windows authentication to work when the SEP manager service attempts to access the remote SQL database using and AD account.

 Good luck!

I too am at the same point, with the same set up _Grimm has.  I understand that switching the log on as a service for the WIndows SQL account will fix it, but the install guides mention no where this needs to be done if you go the windows security route for your SQL setup.  Any word from a official Symantec rep this is indeed what you need to do?

Update:

I tried waht _Grimm suggested and in my situation, this did not fixt the problem.  The management service won't even start this way.

I would advise to do these:

1. make sure that SQL tools are installed on SEPM
2. create new account for the SEP database in SQL studio and grante it sysadmin rights and the owner of it
3. run the SEPM configuration wizard and if it finished successfully, everything should work fine.

P.S. after creating the new DB user, you need to log off from SQL studio and login again with the new user as it will requires to change the password.

I have tried reconfiguring.  The acocutn has sysadmin and DBO privs on the database.  I don't want to go with SQL authentication by creating local acounts in SQL.  Windows authentication is supported, and should work.  I tried again with a new Windows Authentication account, same issue. 

SQL tools are installed on the SEPM, the install would have complained if they weren't and wouldn't let you setup the SQL database.

I had similar issue when I have upgraded SEPM 12.1 beta to the latest. somehow the Windows authentication was causing the problem and decided to use SQL authentication and it worked

I had similar issue when I have upgraded SEPM 12.1 beta to the latest. somehow the Windows authentication was causing the problem and decided to use SQL authentication and it worked

Yeah, this just a clean install.  We aren't doing an upgrade.  I understand that SQL authentication may work (actually I am betting it will).  But if they say Windows authentication is supported, than thats the route we want to go.

"Unexpected Server Error after installing Symantec Endpoint Protection Manager with Windows Authentication on a remote SQL Server"

http://www.symantec.com/business/support/index?page=content&id=TECH162444

Mandar1, yeah, thats basically the problem.  Funny thing is I opened a support case on this, and they act like it was something I did to cause the problem.  (they haven't referrenced that support article yet)

I did find a solution though.  It seems that even though the credentials are provided during the install and work, when the ODBC connection is created, it creates it under the account you are logged in under to do the install.  Unless this is the actually account you plan to the use for your Windows authentication on the SQL database, your ODBC connection will require modifications after the install.

I tested  under a new VM, using the SQL account to do the install, and the ODBC connection was set up correctly.  I don't consider this best practice, as this requires making the SQL account an admin on the management servers.  Also, not listed as a step you need to do in the documentation.

If you already did your install under another account (as I was), add the SQL acocunt as an admin on your management server(s).  Log in, copy all the ODBC connection settings to a notepad document, delete it, and create it again under the SQL account.  Then everything will work as it should. 

Looks as if the SQL account will have to be left as an admin on those servers as I bet it will be required to be used for future upgrades as well so the ODBC connection doesn't get messed up again.  A good secure password should help the security risk until they get it fixed, but still not something that should have to do be done.

I solved this problem by adding the database user to the local admins group. I didn't have to mess with the ODBC settings.

This is definitely a bug and needs to be fixed. I don't really want to have the database user having local admin access to the server. Just seems to violate best practice.

Right there with my CaryC.

The database user SHOULD NOT have to be an admin on the manager servers.  I stil have that support case open, and the support rep doesn't seem to even think that is against best practice or anything.  Kind of dissapointing to get my point across.  It should just be an account for the database, and the database only, with no other permissions neeed outside of SQL.

Hi CaryC

thank you for your tip.

Adding the AD-DB user to the local Admin group of the sepm-server has fixed my problems.

Anyway this should'nt be neccesary to run a reporting component ...

Greetings

Ralf

Just to share my experience...

I added the DB user to the local admin group on the SEPM server and logged into the SEPM.  I was able to log in successfully.

I then removed the DB user from the admin group and was able to continue to access the SEPM without issue.

I'm not sure why it would need the admin rights the first time and not subsequently, but that seems to be working for me.

EDIT:
I may have spoken too soon.  I tested this when using the cosole on the physical server.  I just tried to log in from my workstation and I still got the error.  I added the user to the local admins on my workstation and the error persisted.

So, I readded the admin account to the server's local admins and the problem was again resolved.