6 Replies Latest reply on Sep 15, 2010 7:51 AM by Attila Polinger

    failed epo 4.5 upgrade to patch 3

      Hi

       

      We're running ePO 4.5 (build 753) on Windows 2003 R2, SP2.  Was installed about a year ago and been running mostly OK.  Recently we've noticed a number of issues which have now all come to a head and exploding......

       

      • on the ePO server itself, McShield.exe uses 80+% of cpu and EventParser.exe uses what little is left so cpu runs at 98-100% until you either reboot or kill EventParser.exe process (stopping Event Parser service doesn't work and service gets stuck in "stopping" state.  This has been happening periodically for  a month or more.
      • have always used Windows authentication with ePO and this has stopped working in the past 2 days, currently can only use the original ePO ID that was created at install to logon to server.

      About 2 weeks ago we undertook a domain migration from DomainA in ForestB to DomainY in ForestZ.  Windows authentication has been OK since then but has just stopped working. 

       

      If I create a new user ID or take an existing ID in ePO and change the domain field to Domain Y, and then try to edit the ID, ePO faults with "an unexpected error has occurred".  If I try to use that ID to log into ePO, it returns "An error occurred connecting to the database" and logon fails.

       

      Orion.log shows:

      2010-09-14 15:15:38,623 WARN  [http-8443-Processor23] server.OrionLoginModule  - Root cause of LoginException java.sql.SQLException: Unable to find user in domain: domainY.net
      The IDs I'm trying really DO exist in DomainY and in different OUs/containers - it doesn't find any of them

       

      • unable to upgrade the build to Patch 3.  This keeps failing with one of 2 different errors - either it can't stop the EventParser service when it needs to (probably because it's very busy for whatever reason - see first item in list) or this error:

      [ErrorLog]
      ErrorString=FAILURE: In LaunchAppAndWait while trying to run the following program: "D:\EPO\jre\bin\java.exe"

      Return code: 1 Error Message: Incorrect function.

       

      ActionName=Prod_InstallEpoCore
      Task=Checking in epo

       

      Having searched this site for help, this error suggests that Tomcat needs 8.3 naming convention and provides a registry fix for it.  However, this registry entry already exists on the ePO server so it's not that. 

       

      I've just about run out of ideas - if anyone out there has any ideas that might help I'd be extremely glad to read them.

       

      Thanks very much

        • 1. Re: failed epo 4.5 upgrade to patch 3

          Regarding EventParser, this is only a semi-educated guess, but is your ePO database getting very large?  If so I think there are some threads and KB articles for reducing the size.

           

          Jay

           

           

          Message was edited by: jguenrdc on 9/14/10 3:26:56 PM CDT
          • 2. Re: failed epo 4.5 upgrade to patch 3

            Hi Jay

             

            How big is "very big"?  the database is approx 50GB - is that big enough to be classed as very big?

             

            cheers

             

            Mouse

            • 3. Re: failed epo 4.5 upgrade to patch 3

              Again, this is just a semi-educated guess because my database is very small (I have < 30 PCs).

               

              However, based on posts like the ones below, yours might be considered large:

               

              https://community.mcafee.com/message/132702

              https://community.mcafee.com/message/141824

              https://community.mcafee.com/message/44052

              https://community.mcafee.com/message/107684

               

              Hopefully, someone with more knowledge on your issue can either concur or lead you in the right direction.

               

              Jay

              • 4. Re: failed epo 4.5 upgrade to patch 3
                Attila Polinger

                Hello,

                 

                As for the errors, please let me offer some advice:

                 

                #1: Would you check and perhaps exclude event files from default oas scanning or use the low-risk high risk processes policy to do the same exclusion..

                #2:I would advise to change the database account ePO uses to an SQL account and record the change in the ePO. This way you kind of make yourself independent from trusts and domains and related authentication errors in the future. (Btw: where is your database: on a remote server or on the ePO server ?)

                #3: I also suspect that the third error might come from this authentication failure and trying with SQL account might resolve that, too.

                 

                Hope this could help.

                 

                Attila

                • 5. Re: failed epo 4.5 upgrade to patch 3

                  Hi Attila

                   

                  Following Jay's suggestions last night I have modified which events we upload from clients and removed the top event (16 million entries, the next highest was only 50,000) which is of low risk and I have just finished backing up the database, purging events older than 4 months, and shrinking the db.  it's now down to only 23GB as against 50GB.

                   

                  However, it's made absolutely no difference to authenticating any domain ID.

                   

                  #1     I added the bin/server/logs folder as an exclusion on the ePO server.  I assume the purpose for this is to reduce the CPU activity on the ePO server itself?  Late yesterday afternoon I disabled the on-access scanner on the ePO server and the cpu no longer sticks at 100% utilisation, although it does frequently peak at about 85% for a few seconds before dropping back down to about 15 - 20% for a few more seconds.  The process now responsible for the high usage is EventParser.exe.  Clients will still be uploading the irrelevant notification that I have now removed but once they've downloaded the updated policy I'm hoping the EventParser will not be as busy - this will probably take an hour or two, as clients only connect in to upload events and check for new policies/tasks every hour.

                   

                  #2     The database is on a remote SQL 2005 server - ePO is authenticating with SQL using a domain account (I've used the https://localhost:8443/core/config url and reset the account and it's tested OK).  However, I have just now created a SQL account and configured that in ePO and that also tests OK.  ePO is now configured to use that account instead.

                   

                  #3     That was also my thought but when I log in using the original ePO ID created at installation, I can access the database OK so I believe that SQL authentication is working properly.

                   

                  I can see for the time being I'm going to need to create a few users in ePO itself, rather than use AD authentication.  That, at least will allow other people to use the system.  Unfortnately for this issue, I'm now on leave for the next week and won't have the time to resolve any of the issues we're experiencing on a permanent basis until after I return.

                   

                  Meanwhile, thank you to both Attila and Jay for your suggestions and if any one thinks of anything else, I'd appreciate hearing them.  I'll be checking back on this page for the rest of today, in case of any further responses and as soon as I return from leave.

                   

                  thanks all

                   

                  Mouse

                  • 6. Re: failed epo 4.5 upgrade to patch 3
                    Attila Polinger

                    Hi RoaringMouse,

                     

                    I initially wanted to suggest to exclude the files that are being created in the EventParser folder and McSchield and EventParser service are figthing for each one of them. This is done via the default OAS exclusions or using the low-risk-high risk policies and specifying EventParser.exe process and the exclusions for it.

                    So it is not the bin/server/logs folder (I could not find it on my ePO system, by the way).

                     

                    I recommend still trying to use AD accounts as ePO users, and define LDAP servers on which ePO can try the authentication. In addition, you can try specifying a global catalog port (if the LDAP servers you defined has a GC role) rather than standard LDAP port to see it makes a difference.

                     

                    Attila