2 Replies Latest reply on Mar 8, 2010 6:23 PM by Striek

    RE: new/old installation ePO SQL issues.

      Hoping someone can point me in the right direction - I've had ePO sat working quite happily for the last 6 months but on the 29th of December the server required a reboot.. for some reason ePO hasn't worked since then (although typically i've only just realised something is amiss). There is literally nothing in the logs to indicate why ePO stopped working (the server was just routinely rebooted, no security updates etc were installed)

       

      I checked the ePO logs and found a number of different errors..

       

      epoappsvr.log - Missing DB connection info in C:\PROGRA~2\McAfee\EPOLIC~1\Server\conf\orion\DB884C~1.PRO

       

      server.log - 20091229100407    E    #6704    DAL        COM Error :80004005 in DAL2_CConnection::GetConnection
      server.log - 20091229100407    E    #6704    DAL        Meaning = Unspecified error
      server.log - 20091229100407    E    #6704    DAL        Source = Provider
      server.log - 20091229100407    E    #6704    DAL        Description = Unspecified error
      server.log - 20091229100410    E    #6704    DAL        DAL2_CConnection::GetConnection: giving up retrying connection.

       

      I thought I'd take a backup and un-install the software, at which point it said 8.3 filenames were disabled. Well that's odd as I had to enable it for the installation in the first place.. so I enabled 8.3 filenames again (thinking it would fix the missing db connection info) but still no joy.

       

      epoappsvr.log - 20100130093819    E    #7364    DAL        COM Error :800a0e7a in DAL2_CConnection::GetConnection
      epoappsvr.log - 20100130093819    E    #7364    DAL        Meaning = Unknown error 0x800A0E7A
      epoappsvr.log - 20100130093819    E    #7364    DAL        Source = ADODB.Connection
      epoappsvr.log - 20100130093819    E    #7364    DAL        Description = Provider cannot be found. It may not be properly installed.
      epoappsvr.log - 20100130093822    E    #7364    DAL        DAL2_CConnection::GetConnection: giving up retrying connection.
      epoappsvr.log - 20100130093822    E    #7364    DAL        CConxIndex::~CConxIndex(): hr=0x80004003,
      epoappsvr.log - 20100130093822    E    #7364    RManJNI    Failed to get all the handlers for the default handler assignment.

       

      server.log - 20100130093236    E    #10168    DAL        COM Error :800a0e7a in DAL2_CConnection::GetConnection
      server.log - 20100130093236    E    #10168    DAL        Meaning = Unknown error 0x800A0E7A
      server.log - 20100130093236    E    #10168    DAL        Source = ADODB.Connection
      server.log - 20100130093236    E    #10168    DAL        Description = Provider cannot be found. It may not be properly installed.

       

      So I thought fine, I'll un-install and set up from scratch.... so I removed ePO, removed the SQL Express 2005 instance.. installed SQL Express 2005 and then tried the ePO installation again.. which STILL fails to authenticate on the SQL server! I even tried getting it to talk to a SQL instance on a different server and it refuses. Now from what I can see, there is nothing wrong with the SQL setup, I can telnet into it, I can manage it using the SQL Management Studio, I can connect to it using OSQL with -E or -U and appropriate credentials.. but ePO still won't talk to it. It seems to connect fine.. but not sure what it's doing after that, failing to authenticate? Why if other things can authenticate just fine?

       

      EPO450-CommonSetup.Log: 20100130154344 validating account DOMAIN\Administrator
      EPO450-CommonSetup.Log: 20100130154344  success, token = 620
      EPO450-CommonSetup.Log: 20100130154344 LogonUser () successful.  Token = [620]
      EPO450-CommonSetup.Log: 20100130154344 ImpersonateLoggedOnUser () successful.
      EPO450-CommonSetup.Log: 20100130154344 Current username: [DOMAIN\Administrator]
      EPO450-CommonSetup.Log: 20100130154344 SQL::connect to server SERVER\MCAFEE
      EPO450-CommonSetup.Log: 20100130154344 Testing NT Authentication to SQL Server.
      EPO450-CommonSetup.Log: 20100130154344 Failed to connect to SQL Server [SERVER\MCAFEE] with error code [0x800a0e7a]
      EPO450-CommonSetup.Log: 20100130154344 Description for error code is [Provider cannot be found. It may not be properly installed.]
      EPO450-CommonSetup.Log: 20100130154344 Failed in connectToSQLServer with error code [0].
      EPO450-CommonSetup.Log: 20100130154344 Current username: [DOMAIN\Administrator]
      EPO450-CommonSetup.Log: 20100130154344 RevertToSelf () successful.  Impersonation was stopped.
      EPO450-CommonSetup.Log: 20100130154344 Current username: [DOMAIN\Administrator]
      EPO450-CommonSetup.Log: 20100130154344 Exiting function ValidateAccountAndSQL with return code: 2

       

      EPO450-Install-MSI.LOG1: 15:43:44 ePO450CALog: SQL UDP and TCP validation successful. MSDE/SQL server [SERVER] with Instance [MCAFEE] was found to use port [1433]
      EPO450-Install-MSI.LOG1: 15:43:44 ePO450CALog: Successful connection to MSDE/SQL server [SERVER] for instance [MCAFEE] on port [1433].
      EPO450-Install-MSI.LOG1: 15:43:44 ePO450CALog: Failed to connect to the SQL server.

       

      I have thus far...

      Confirmed that the username and password are basic alphanumeric.

      https://kc.mcafee.com/corporate/index?page=content&id=KB58251 (regsvr32 oledb32.dll)
      https://kc.mcafee.com/corporate/index?page=content&id=KB53306 (cliconfg settings)

      Disabled Named Pipes, ensured TCP/IP is above named pipes in the order list, re-enabled everything, tried binding to different ports, set up a new domain admin user with full rights on the SQL DB, tried using the SA user / password.
      ...actually to be honest, I've lost track of the myriad of things I've tried... this makes no sense to me and is pretty frustrating.

       

      From what I can see, everything else is willing to talk to SQL and authenticate except for ePO. Has anyone got any bright ideas? Any pointers appreciated (i'm guessing this is something really simple but meh!)

        • 1. Re: RE: new/old installation ePO SQL issues.

          Just in case anyone has similar problems - I've posted the resolution to my particular problem at http://community.mcafee.com/message/111934#111934

          "Just in case anyone else has similar problems, everything was pointing  to sqloledb.dll being the culprint (other mcafee articles suggested  re-registering it etc) - and I had tried that, but hadn't taken into  account that this was a Server 2003 x64 box. Checked "c:\program files  (x86)\common files\system\ole db" and sqloledb.dll and sqloledb.rll  didn't exist there. I found another Server 2003 x64 box and copied the  files from that installation, registered.... and everything has worked  fine since. I've NO idea why this occured in the first place.. this was  originally installed about 6 months ago and had been working perfectly,  it suddenly stopped communicating to the DB after a reboot. Strange..  but at least it's finally resolved."

          • 2. Re: RE: new/old installation ePO SQL issues.

            In my case, I was testing the upgrade from a 2008 server to a 2008R2 server when this happened. I copied "C:\PROGRA~2\McAfee\EPOLIC~1\Server\conf\orion\db.properties" to "C:\PROGRA~2\McAfee\EPOLIC~1\Server\conf\orion\DB884C~1.PRO" and that resolved the problem. It appears that the Tomcat process tries to create this file (I assume after reading the db.properties file in the same directory), but can't find the path to it. Here is the error I was able to wring out of my server:

             

            Date & Time:    08/03/2010 7:07:55 PM
            Event Class:    File System
            Operation:    CreateFile
            Result:    NAME NOT FOUND
            Path:    C:\Program Files (x86)\McAfee\ePolicy Orchestrator\Server\conf\orion\DB884C~1.PRO
            TID:    3352
            Duration:    0.0000176
            Desired Access:    Generic Read
            Disposition:    Open
            Options:    Synchronous IO Non-Alert, Non-Directory File
            Attributes:    N
            ShareMode:    Read
            AllocationSize:    n/a

             

            Giving Everyone write permissions to this directory had no effect, so I'm assuming it isn't a permissions problem. I still have no idea why this happened, and didn't happen under Server 2008 (R1).

             

            P.S. Other than this issue, the ePO Server survived the upgrade without a hitch so far.