Endpoint Protection

I upgraded SEPM only on two SEPM servers. These were dedicated VM servers, Server 2008R2

They have been running SEPM since I first brought SEPM in. They worked GREAT, flawlessly for years and were at v11.0.7xxxx

We connect to a SQL database on a DIFFERENT server.
It was a SQL2005 several months ago, then we moved databases to a SQL 2010 server on a VM running Windows Server2008 R2 about a month ago. and SEPM 11 ran fine - NO SEPM issues at all.

I upgraded SEPM1 to v12.1 RU1 and it was fine. I had turned the services off in SEPM2 so that it could not or would not connect to the SQL database while I upgraded SEPM1. In the middle of the upgade of SEPM2, the SQL server lost its NIC - thanks mostly to Microsoft anfd VMWare tools. So the SEPM2 upgade worked, but the wizard to connect bombed due to lack of connection to SQL server.

They got the SQL server fixed and SEPM1 still worked fine-  no damage done. So I ran the wizard on SEPM2 manually, and it connected.

HOWEVER, now when I launch a console WEB OR JAVA, on the SEPM2 server OR from a desktop,
and point it to SEPM2 - I get the listed error 0x10010000

Doesn't matter web inside IE or JAVA, on the server or on a workstation, get that error and the top tabs are blank. We KNOW it's connecting as it lets me log in. No connection, no login. No connection, no display of clients and no ADMIN tab.

IF I point the browser OR the java console applet to SEPM1 life is good - it works well. So, it's not a SQL account or SQL login issue on the SQL server as ONE server works great.

So, external SQL 2010 on Server 2008R2.

SEPM1 works fine and consoles pointed to it are ok.

SEPM2 does not work fine and consoles crash and burn with that error - and crash now and then in normal use.

I HAVE already done a search on that error here and read all the "attempts" and "ideas"............ but none seem to fit since ONE server connects just fine and the console is fine pointed to it.

HOWEVER - I wonder what impact this may have on CLIENTS that report to the messy server???

IS this a console only issue, or will the 200 clients under SEPM2 also have issues??????????

Hey Symantec guys and gals - this document is dead wrong - looks like none of us with this connection issue HAVE that piece in the ODBC area - SEPM's install doesn't create it!

This doesn't work since there is no such data source as the SymantecEndpointSecurityDSN - it's not there, I see others stating same:

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

To verify communication to the SQL database

1. On the management server, click Start > Control Panel > Administrative Tools.

2. In the Administrative Tools dialog box, double-click Data Sources (ODBC).

3. In the ODBC Data Source Administrator dialog box, click System DSN.

4. On the System DSN tab, double-click SymantecEndpointSecurityDSN

Unexpected Server error [0x10010000]

Ensure that all Symantec services are started

·         Check that all database ports are available (1433 for SQL or 2638 for Embedded)

·         Verify ODBC connection

Verify communication to the embedded (Sybase) database.

1.     Verify that the "Symantec Embedded Database" service is running and that the "dbsrv9.exe" process is listening on TCP port 2638.

2.     Test the ODBC connection.

                 i.        Click Start> Control Panel

                ii.        Open Administrator Tools

               iii.        Double-click Data Sources (ODBC)

               iv.        Select the System DSN tab

                v.        Double-click the SymantecEndpointSecurityDSN and go through the wizard to ensure the following settings:

o    Name: SymantecEndpointSecurityDSN

o    Description:

o    Server: Servername\InstanceName (Can be blank as it is localized, otherwise specify default "sem5")

o    Login ID: dba

o    Password: <SEPM Login Password> 

 

               vi.        Leave the default settings for the remaining items and click Finish

              vii.        Click Test Data Source, and verify that it states "Success"

             viii.        Click OK

Verify communication to the Remote (SQL) Database.

3.     Verify that you have specified a named instance during installation and configuration. Example: \\\

4.     Verify SQL Server is running and properly configured.

5.     Verify the network connections between Symantec Endpoint Protection Manager and the SQL database.

6.     Test the ODBC connection.

                 i.        Click Start> Control Panel

                ii.        Open Administrator Tools

               iii.        Double-click Data Sources (ODBC)

               iv.        Select the System DSN tab

                v.        Double-click SymantecEndpointSecurityDSN and go through the wizard to ensure the following settings:

o    Name: SymantecEndpointSecurityDSN

o    Description:

o    Server: Servername\InstanceName (Only enter the server name or IP address if using the default instance)

o    Login ID: sa

o    Password: <SA Password> 

 

               vi.        Leave the defaults for the rest of the items and click Finish

              vii.        Click Test Data Source on the next page and ensure it states "Success"

             viii.        Click OK

·         Reboot the machine.

If the above does not resolve the issue, examine the scm-server-0.log for possible indications of the cause. By default, this log is located in C:\Program Files\Symantec\Symantec Endpoint Protection Manager\tomcat\logs\.

OK, let's get back to the basics I outlined please. If you read my post, you'd see SQL is just fine. IT's fine because SEPM1 works PERFECTLY as far as the console. If there was a SQL issue, two things would happen:
1. SEPM1 would be broken as well
2. The management service would NOT be able to write the information to the database, thus, no new entries would be made, thus SEPM1 console would show no new info. That's not happening, the info shown by the console connected via SEPM1 is current and working and the SEPM SERVICE is running fine and can connect fine.
I could add #3 here - this is an UPGRADE, and since SEPM1 and SEPM2  worked PERFECTLY with 11.07 on them, and NOTHING changed on the SQL server as far as passwords, and even AFTER the upgrade, SEPM1 worked, it's not an issue with SQL in the manner of login accounts.

Further, ALL OTHER applications that use this SQL server continue work perfectly, our helpdesk app, SCCM, and our specialized agency application use SQL via sharepoint and continue to work. It's one SEPM server, and only the console. The SEPM server can write logs and info into the database OK.
In fact, I ran a database verification test from this same server and that passed just fine meaning the verification script from Symantec, included in the tools, was able to login to the SQL database and connect, and verify the database.

So there's a basic flaw in Symantec's troubleshooting of this issue. They aren't looking at it correctly. This is a console only issue, NOT a SQL issue IF the manager service can write to SQL, it's got a connection, and if one server connects fine and shows the console, it's not a SQL issue.

It's like saying of 10 people at work, 2 can't connect to the internet - thus since 9 CAN, we know the Internet connection is not down, correct? So please don't ask us to start troubleshooting an internet connection since 9 people CAN connect. Same theory here - since one server DOES connect and display the console info, SQL is ok, otherwise BOTH would be down. And since the info in the SQL database is current up to the minute, the manager can write to SQL, thus SQL login and connection is basically OK.

OK, SQL - 1433 is ONLY for the SQL server and the default instance. I should have specified that WE use a named instance, not the default. SQL uses a random port for named instances.

Our SQL path to the SEM database (which is NOT SEM05 for security reasons) is on a named instance, at a path like this:
OURPRODSQL\INSTANCE2
So it won't be 1433.

Another note, this bit here - see my other posts on this, and other user reactions to this bit:
>>  iv.        Select the System DSN tab

                v.        Double-click SymantecEndpointSecurityDSN and go through the wizard to ensure the following settings:

o    Name: SymantecEndpointSecurityDSN

<<
THAT DOES NOT EXIST. And I'm not the only one who says this, so that needs to be removed from the document you pasted in. That SymantecEndpointSecurityDSN isn't there, doesn't exist, never has for us. I've found that "tip" in other threads, and found out that others are also saying "it's not there", so I commented in another thread that this DSN entry isn't there in SEPM11 or 12, not on either of our servers it's not. This doesn't use ODBC connectivity, so I'm not surprised to not find it anyway.

Besides - that's boilerplate stuff, and I've already searched all of connect and tried all the stuff in the other forum posts, so it's not one of those items.  Sorry, I'd like to get past the boilerplate stuff. Thanks

Were you really running SEPM 12x and SEPM 11x consoles from the same database?

No - where did that thought come from or why did you think that?

SEPM1 upgraded just fine, and upgraded the database. SEPM2 had all Symantec services stopped during the upgrade so it could not touch the database.

Then SEPM2 started the upgrade, but blew up at the final config wizard.

There was never any 11.xx console connected to the database at any time once the first server was upgraded.

I always stop services on other servers, and never mix versions on the same database.

since Symantec was absolutely no help at all in this - in fact, really, no one was in this case - I kept getting incorrect information, etc..

I ended up coming up with a new server, and started from scratch building a new SEPM2. Never was able to get the original SEPM2 to work properly again after the upgrade.

SEP 12.1 is the biggest upgrade disaster I've ever seen come out of Symantec.

by any chance is it 64 bit OS?

For 64-bit systems
The ODBC information for 64 bit systems will not appear in the Data Sources (ODBC) applet, because SEPM creates a 32-bit DSN. To edit these settings, you must make the appropriate modifications directly in the registry:

1. In Regedit, navigate to HKLM\Software\WOW6432Node\ODBC\ODBC.INI\SymantecEndpointSecurityDSN\
2. Enter the appropriate data in the value Server, as indicated in the steps above.

NOTE: to modify the 32bit data sources you can run the file odbcad32.exe from the c:\windows\syswow64 folder.

 

Please refer to the first line in the original post:

This is from my first post, hoping folks would see the detailed information I gave ->
>>These were dedicated VM servers, Server 2008R2<<

Server2008 R2 only comes in one flavor - 64 bit, so I could be clever and say, no, not by chance, but by design thanks to Microsoft LOL.

(however, are you suggesting folks may still be using 32 bit servers?  ;-)   )

Got rid of 32 bit servers long ago - well, when we ugpraded to 2008R2 as that is all MS puts out now.

The point is moot now as the lack of finding any help meant we trashed the old server and built a new one, however this would make a good future reference in case we run into this with a future upgrade or for some reason one of these decides to go funky.
I have to ask - why does it build such a connection when it has the SQL client right there on the SEPM server for connection information?

I'd further like to ask - where is this information hidden in the bowels of Symantec support, and I found a number of other customers with the exact same quandry - folks kept pasing the same old links over and over - and customers kept coming back and saying "but there IS no connection information" and there were no responses...........I literally spent hours searching, and trying to find clues here, and in the KB - there was nothing at all, not a thing.

My solution was to build a new VM server........ a few days later since I couldn't find any clues. It ended up being our only choice. (I'm also convinced the problem wasn't in that connection since it passed all connection and database testing)