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