1 2 Previous Next 16 Replies Latest reply on Jul 6, 2010 5:34 AM by JoeBidgood

    Duplicate nodes: some inconsitency or what?

    Attila Polinger

      Hi all,

       

      Using ePo 4.0 Patch 6 and agents 4.0.0.1494.

       

      One of our goals to find hosts with no Virusscan installed and deploy the package onto them.

      Monitoring this effort of ours we run a VirusScan version summary statistics report (see attachment db_VSE_versions.png)

      I must add that we regularly clear duplicate nodes by running a relevant server task daily.

       

      Please notice that we "have" some 23 nodes that has no VirusScan version information (supposedly they are without VirusScan). See db_breakdown_1.png. I picked one host that you see highlighted.

      Breaking down the report for this host further you can see that this host is actually a duplicate (db_breakdown_2.png), one entity of which is managed, the other is unmanaged.

       

      Our assumptions:

      Finding and clearing duplicate nodes by a server task may not have a full scope (is that true?).

      VirusScan version report runs on a db view (ePO_ProPropsView_VIRUSCAN) that might encompass other tables, thus might incorporate potential duplicates from Detected Systems ( ? or related) table.

       

      What we would like is to find a bulletproof method to eliminate duplicates regardless what tables they are in, if their counterpart is managed. Also, possibly modify the virusScan version report so it is free from unwanted duplicates.

       

      /We also use rogue system sensor/.

       

      Thank you for any idea.

       

      Attila

       

       

      Message was edited by: Attila Polinger on 7/1/10 9:48:19 AM CEST
        • 1. Re: Duplicate nodes: some inconsitency or what?
          JoeBidgood

          Can you run the following query against the ePO db and post the results here?


          SELECT * FROM ePOLeafNode WHERE NodeName = 'X001309'


          Thanks -

           

          Joe

          • 3. Re: Duplicate nodes: some inconsitency or what?
            JoeBidgood

            Okay, thought it might be this

             

            One of the entries is a machine that had an entry created in the db - for example from an AD sync, or was manually added - but it was then deleted from the tree (with the "uninstall agent" option selected) before the agent had a chance to communicate. (Or possibly even before an agent was installed on the machine.)  This has put this entry into an orphaned state.

            This problem was fixed in Patch 5, I think, but the fix prevented new machines from falling into this trap: it didn't clear up old entries. Try this:

             

            1) Back up the database

            2) Run this query:

             

            DELETE FROM ePOLeafNode WHERE Type = 24

             

            See if that cures the problem for you.

             

            HTH -

             

            Joe

            1 of 1 people found this helpful
            • 4. Re: Duplicate nodes: some inconsitency or what?
              Attila Polinger

              Joe,

               

              do not I need to stop any ePO service for the operation? Logging in with the account ePO uses for DB administration I get this error when I try to run the script you gave me:

              Msg 229, Level 14, State 5, Line 1

              The DELETE permission was denied on the object 'EPOLeafNode', database 'ePO4_xxxxxxxx', schema 'dbo'.

               

              Attila

              • 5. Re: Duplicate nodes: some inconsitency or what?
                JoeBidgood

                That's a very worrying message... it implies that the account you are using does not have the required permissions. There's no need to stop any services for an operation like this.

                 

                Can you successfully execute the query using the sa account (if you are using SQL authentication) or using an NT account that is a member of the local Administrators group on the SQL server (as this group is usually granted sa privileges by default)?

                 

                If so I strongly suggest you change the account being used by ePO - I would imagine you may be having a number of problems if the account being used does not have the required rights.

                 

                HTH -

                 

                Joe

                • 6. Re: Duplicate nodes: some inconsitency or what?
                  Attila Polinger

                  I'm not allowed to do either of that, because the SQL server and management is not in my responsibility or competence. But I can have the account in question granted necessary rights by SQL admin, if necessary.

                   

                  I saw that the sa user had public and sysadmin roles whereas the account I used/ePO uses has only public (there could have been some confusion among our SQL admins and one may have removed a previlously existing role from this account).

                  (Also my account has dbo in User Mapping section of account properties for the ePO database.)

                   

                  Is granting sysadmin role on top of public role for this account (SQL account) enough for proper operation?

                   

                  Attila

                  • 7. Re: Duplicate nodes: some inconsitency or what?
                    JoeBidgood

                    Is granting sysadmin role on top of public role for this account (SQL account) enough for proper operation?

                     

                     

                    I would certainly try this before anything else. Make sure you restart the ePO services after the account is changed to clear any open sessions.

                     

                    HTH -

                     

                    Joe

                    • 8. Re: Duplicate nodes: some inconsitency or what?
                      Attila Polinger

                      Hello,

                       

                      I have just tried running the DELETE statement with the SQL account from SQL Management Studio after granting sysadmin role to the account. Actually the same denial occurred.

                      I consulted one of our SQL admins and his tip is that the denial could be due to SQL constraints, which prevents unhierarchical deletion from occurring so that no orphan records can be created.

                       

                      :-(

                       

                      Or are you saying that existing ePO connections to the database affect operations made using the same account that they use within an SQL client application?

                       

                      NB: the SQL account has been db_owner to the database. The test was performed by granting temporarily the sysadmin role (in addition) and NOT stopping/starting ePO services after sysadmin has been granted temporarily.

                       

                      Attila

                      • 9. Re: Duplicate nodes: some inconsitency or what?
                        JoeBidgood

                        I don't think it's constraint related - you would get a different error message (about constraint violation) if that were the case.

                         

                        As a diagnostic step, try using the actual sa account - NOT any other account that allegedly has sa rights. Does it work?

                         

                        Thanks -

                         

                        Joe

                        1 2 Previous Next