2 Replies Latest reply on Feb 18, 2011 1:09 AM by Attila Polinger

    I guess this could be a sorting bug or I don't know what else...

    Attila Polinger

      Hello,

       

      we have ePO 4.5 Patch 3 on Windows server 2003 on the internal network.

       

      We have a system tree group, where we collect our DMZ hosts by using IP sorting criteria. That sorting did not work properly ever since the group was created. Now I consolidated the criteria by creating a tag on DMZ IP range and adding it to the DMZ group criteria resulting in the group now having two sorting categories.

       

      The tag applies all DMZ host successfully. However when I ran a test sort on these hosts, half of the would sort into the DMZ group and half of them would sort into the global Lost and found.

       

      When I remove the IP sorting criterion from the group and leave just the tag in place, test sorting produces the same mixed results, that is, a portion of the 10+ computers would go to correct DMZ group, and rest of them would go to global Lost and Found. The two sets (this and above) might be different though.

       

      A cherry on cake that hosts that would correctly sort into the group sort into the group's Lost and Found and not within the group itself (true, that the group is a second level one and no other subgroup exists within.). This is the funniest logic I've ever seen.

       

      DMZ hosts can successfully report into ePO and we do not want to hold an AH or ePO for these 10+ hosts. I'd rather see sorting working correctly than manually placing ever changing number of computers into the group regularly.

       

      I would appreciate if someone got me on the right track, how to do this properly or confirm if this is a bug within sorting logic.

       

      Attila

       

       

      Message was edited by: Attila Polinger on 16/02/11 12:22:22 CET
        • 1. Re: I guess this could be a sorting bug or I don't know what else...
          joeleisenlipz

          Occasionally, I have seen weird results sorting as well. When sorting into sub-groups, I try to give the parent group sorting criteria that matches any of the sub groups as well. As an example...

           

          My Org.

          ---Internal (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)

               |--- Production (10.0.0.0/8)

               |--- Development (172.16.0.0/12)

               \--- Testing Lab (192.168.0.0/16)

          --External (tag:DMZ, tag:VPN)

              |--- DMZ (tag:DMZ)

              \--- VPN (tag:VPN)

          --Lost&Found

           

           

          Also, you can control the Sorting Order between groups on the same level. So in the example above, when I select My Org., I can tell the External group to be evaluated first, then if the system doesn't match it'll continue to the Internal, and eventually fall through to the L&F if it doesn't match anything.

          1 of 1 people found this helpful
          • 2. Re: I guess this could be a sorting bug or I don't know what else...
            Attila Polinger

            Thanks for the tips Joel. I was not yet fully aware of Sorting Order rearranging feature until your post. However I still do not feel sorting works well, because I have no other group that would qualify as landing place for DMZ clients. I wonder if this is one thing the Sorting Order can help with...

             

            All our DMZ clients report correctly into ePO, and receive the DMZ tag. Yet when I test sort them, not all of them would go into a single group that has a sorting criteria no other group has.

             

            I continue investigating...

             

            Attila