Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Unexpected server error. ErrorCode: 0x10010000

Created: 16 Oct 2012 • Updated: 16 Oct 2012 | 7 comments

I have a fresh install of SEP 12.x and when I start the SEPM console I get the error message "Unexpected server error: ErrorCode: 0x10010000.  My system is Windows 2008 R2 SP1 and I am connecting to a remote sql 2008 server through Windows Authenication with a AD domain account and NOT a local SQL account.  The only way I can get the error message to go away is to add the domain accoount that has rights to the remote database to the local administrators group.  I do not want to do this.

Any other thoughts?

Thanks

Cory B.

Comments 7 CommentsJump to latest comment

Mithun Sanghavi's picture

Hello,

Try Logging into the SEPM using a user account that has full rights to access both the SEPM and the external SQL database.

OR

Run the management server configauration wizard and in the SEPM configuration to SQL, change to SA authentification from Windows authentication.

Check these Threads with similar Issue:

https://www-secure.symantec.com/connect/forums/unexpected-server-error-errorcode-0x10010000-1

https://www-secure.symantec.com/connect/forums/errorcode-0x10010000-also-sepm-console-blank-home-montiors-and-reports-tab

Hope that helps!!

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

cb2012's picture

I am logging into the system through RDP with a account that is already a domain administrator to both the SQL and Symantec box.  I can not change the authentication method from Windows to sql.  Windows Authentication from what I understand is a supported configuration option for connecting to the SQL Database and our local Security policies also require it.  So it should work with Windows Authentication.  changing it to SQL local authentication is just a work around just like adding the user account to the local administrators group is a work around.  I would prefer to find a solution versus implementing a work around.  If that make sense.

Thanks

Cory B.

cb2012's picture

I think I might have found some more information.  I noticed the file C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\apache\logs\ssl_error.log file gets a new entry into the file each time I get this error message as well.  The error message reads: ( I changed the IP address for security reasons).

"[Tue Oct 16 12:57:56 2012] [warn] [client 110.21.217.166] (OS 232)The pipe is being closed.  : mod_fcgid: can't write to pipe"

If I add the domain account that I am using to the SQL Database with Windows Authentication to the local administrators group on the symantec server there is no new log file entry created  when I start the SEPM console and I do not get the error message.

Is this the issue?

Thanks

Cory B.

cb2012's picture

I Found it!  I Found it! I Found it! I Found it! I Found it! I Found it! I Found it! I Found it!

I gave the AD account that has rights to the SQL database Full rights to the "C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\temp" folder and the error message went away!  It appears that the Symantec installation is not properly applying the security permissions it needs to for that SQL AD service account to modify/create/delete files in that folder.

.Brian's picture

Good to know. Thanks for updating us on the resolution.

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.

cb2012's picture

Well I fixed it for a executing access to console locally when RDP'ing to the server.  Now if I try and access the console through the web access "http://servername:8443" I still get the error message.

Any thoughts on this?

Thanks

Cory B.

cb2012's picture

I have rebooted and now nothing it working again!  I don't get it.  Symantec????

would it have anything to SPN's on the AD SQL Account?  There is a permissions issue somewhere....Most likely now I will be calling Symantec Support tomorrow....