After upgrading to SEPM 12.1.5, and you try to login to the SEPM console an error is displayed :

unexpected server error. ErrorCode 0x100100000

Additionally the apache reporting log file shows the following error:

2014-09-25 17:25:37    Login:start[25-Sep-2014 17:25:39 UTC] PHP Fatal error:  Uncaught <b>Source:</b> Microsoft OLE DB Provider for ODBC Drivers<br/><b>Description:</b> [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'NT SERVICE\semwebsrv'.<br>Error code: -2147352567<br>Trace: ##0 C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Php\Include\Common\ado.php(70)#1 C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Php\Include\Common\connectdb.php(61)#2 C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Login\curl_funcs.php(485)#3 C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Login\curl_funcs.php(178)#4 C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Login\curl_funcs.php(525)#5 C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Reports\sr-login.php(23)#6 {main}
  thrown in C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Php\Include\Common\connectdb.php on line 65

The console opens however the Home, Monitoring and Reports tabs show no content (blank page).

http://www.symantec.com/docs/TECH169455

above did not resolve the issue for me

Did you try a repair on theSEPM?

can you give me the steps for doing the repair please

it seems that 12.1.5 sepm changes the sepm service accounts to run under NT SERVICE\semwebsrv. I changed the log on account back to local system and the console opened without error. Let me know if this fixes the error for anyone else please.

See this article for the assistance

Symantec Endpoint Protection Manager 12.1 RU5 and higher installs its services with reduced privileges and permissions

Hi AN9,

We also have the issue after the upgrade. Same deal.. with local system it works like a charm.

However, i also solved it to give the NT SERVICE\semwebsrv user rights to the root of the drive and all folders up untill the symantec endpoint protection folder. From there it already has rights.

So to me it seems that there is a misconfiguration somewhere in the symantec software since it seems that the root for the program is relative to the drive root in stead of the application folder.

Maybe Symantec can lookinto this?

Hi Jos, another way to fix it (and retain the nt service accounts as the log on service accounts) is to grant the nt service\semwebsrv account as sysadmin dba role on sepm database

Do you also have the problem with clients not being able to connect?

For some reason the won't connect eventhough it seems everything is working now. Do still have to update the clients though.. but i would expect them to be able to reconnect to the server eventhough the have an older version installed.

My clients connected and were able to download definition updates from 12.1.5 sepm. Yes the clients should still connect even though an older version is installed.
 

did you touch this account by any chance NT SERVICE\semwebsrv ?

doing a repair will put back the necessary permissions

Rafeeq,

Did not touch it at first.

It didn't work already right after the upgrade of SEPM (SmallBusiness) to 12.1 RU5. The SEPM webserver service wouldn't start. First did a repair, no luck.

When i changed the SEPM webserver service to run under local system account, it started fine.

However as stated earlier, when i gave NT SERVICE\semwebsrv user rights to the root of the drive and all folders up untill the "symantec endpoint protection" folder, it also worked under the semwebsrv account.
After that did again a repair, to indeed make sure all rights are properly set. de webserver service still started fine. But the clients could not connect.

The only way to resolve the client connection issue was by assigning the SEPM and SEPM webserver services the local system account as user to run under.

Since we're using the Small Business version (i really don't like this version though) i don't think i can't assign DBA role to the sepm database (internal) to the semwebsrv user as AN9 mentioned.

We ran into this same issue.

we have the SEPM installed in a locatoin other than the C: drive. By default our Application drive does not have authenticated users with any permissions. If I add authenticated users with default permissions (Read, List folder contents, read & execute) to the SEPM install foldes this also alleviates the above problem.

--Jon

I had the same error 0x10010000 after upgrading from 11.0.7300 to 12.1.5.

Server 2008r2 for SEPMs, SQL 2008r2 DB, USING WINDOWS AUTHENTICATION!!!

In previous versions, when installing, you had to specify where the bcp.exe file is. I did this thru network UNC. 12.1.5 doesn't like that, so I had to install SQL CMD line tools on EACH sepm server directly. Specific featuers were Conn,SSMS. If you have SQL CD, you can simply install all the TOOLS features and sub features. If you want to run lean cmd line to install just what you need is similar to

setup /QS /action=install /features=conn,ssms /IACCEPTSQLSERVERLICENSETERMS

Another way is setup /configurationfile="configurationfile.ini" (and attached file - again, only installing what I need)

Since my SQL server was up to SP3, I ran SQL SP3 after this install - Probably didn't need to but just to be safe

Finally you don't have to re-install. Just run the Management Server Reconfiguration Wizard.

Hope that helps. If is does, please mark post as solved. Thank you.

couldn't drag and drop images so I'll just give a description.

Image Descriptions:
SEPM12sql.jpg - page 84 of Implementation_Guide_SEP12.1.pdf (Where the light went on)
ManSerConWiz1.jpg - 1st page of configuration wizard.
ManSerConWiz2 - Site and SEPM server name - I left these all default.
ManSerConWiz3 - SQL automatically chosen (from initial install), just click next

ManSerConWiz4 - DB credentials. Things to note here are I am using Windows Auth. Others reported issus with this. DB server in FQDN form. Windows User account must be in DOMAIN\ACCOUNT format. (This account created specifically for SEPM-SQL access, with password set to NOT EXPIRE)

ManSerConWiz5 - Symantec's warning about using Windows Authentication
 

Attachment(s)

ConfigurationFile.ini_.txt   8 KB 1 version

Issue

 The Symantec Embedded Database service (SQLANYs_sem5) fails to start after installing or migrating to Symantec Endpoint Protection 12.1.5 (SEP RU5).

Error
In the Windows event log:
SQLANYs_sem5
Can't open Message window log file: D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\db\out.log

In the Upgrade-0.log:
The service SQLANYs_sem5 failed to be started.

In the Management Server Upgrade Wizard:
Setting
ACL...(100%)...Done
Error occurred

Cause
In SEP 12.1.5 (RU5), Symantec changed the SemSrv and SemWebSrv services to use service virtual accounts. These services are set to an UNRESTRICTED SID type, but the SQLANYs_sem5 service remains under the RESTRICTED category.

Solution
FIRST STOP ALL Symantec Endpoint Services!

Then use the following workaround to change the SID type to UNRESTRICTED, since we are using a service virtual account for the Symantec Embedded Database service as well.

Note: A permanent solution is targeted for SEP 12.1.5 RU5 MP1.

Check the SID type of the service
1.On the computer where SEPM is installed, click Start > Run.
2.Type CMD and click OK.
3.Type sc qsidtype SQLANYs_sem5
4.Verify that the following is returned:
[SC] QueryServiceConfig2 SUCCESS
SERVICE_NAME: SQLANYs_sem5
SERVICE_SID_TYPE: RESTRICTED

Change the SID type of the SQLANYs_sem5 service to UNRESTRICTED
1.On the computer where SEPM is installed, click Start > Run.
2.Type CMD and click OK.
3.Type cd "<Drive>:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\bin"

Note: Replace <Drive> with the drive that SEPM is installed on.
 
4.Type ServiceUtil.exe -changeservicesidtype 1 -servicename "SQLANYs_sem5"

Note: Running the command returns: "Change the semsrv service SID successfully." The string "semsrv" is hardcoded, but we are changing the SID type for the SQLANYs_sem5 service. Please disregard that message.
 
Verify that the SID type has changed to UNRESTRICTED
1.On the computer where SEPM is installed, click Start > Run.
2.Type CMD and click OK.
3.Type sc qsidtype SQLANYs_sem5
Start services
After following the preceding steps, start the following services:
(I ACTUALLY HAD To REBOOT the Server to get it to work)

•Symantec Embedded Database
•Symantec Endpoint Protection Launcher
•Symantec Endpoint Protection Manager
•Symantec Endpoint Protection Manager Webserver

I am having the same issue with the SEPM console.  I get the same error on login and the home page and reporting pages are blank.

I looked at the ODBC configuration for the embedded database, and get an error 126 when attempting to go into the 'config' option for the SEP entry.  That error indicates that there is a driver issue.

Checking the registry and the ODBC driver configuration, ODBC is looking for dbodbc12.dll to support SQLAnywhere12.  In my case it is looking for D:\Endpoint Protection Manager\ASA\win32\dbodbc12.dll

However, It appears that the installation of 12.1.5 has updated the database drivers.  What is found is

D:\Endpoint Protection Manager\ASA\win32\dbodbc16.dll

If you examine the install files for 12.1.4 SEPM the data1.cab file contains dbodbc12.dll

When you look at the install files for 12.1.5 SEPM the data1.cab file contains dbodbc16.dll.

The embedded database service is running ok, and clients are working, so I suspect that if the database is accessed directly, it is ok.  Any service that is attempting to use the ODBC connection (reporting, etc.) is not ok, since the ODBC connection is broken.

My question is how the database drivers were updated, but registry settings for odbc.ini and odbcinst.ini were not refreshed.  Perhaps because of due to running (in W2k3) as Network Service instead of Local Service and not having the correct permissions to update the registry?

Perhaps it is sufficient to update the registry keys for SQLAnywhere ODBC entries and restart?

Changing to run SEPM services under Local System did not solve my problem, at least not after restarting all the symantec services, but I have not updated the ODBC registry entries nor rebooted yet.

Comments? Symantec?