2 Replies Latest reply on Dec 7, 2016 8:08 AM by phoffmann

    xdd is enabled on all subnets but I get only unmanaged devices for 2 subnets

    HermiM Apprentice

      Hi,

       

      All managed devices have a LANDesk agent with Enabled XDD via ARP and all subnets inside the company are displayed under "Self-electing subnet services" tool. When I check the list of unmanaged devices to get computers which were discovered by XDD via ARP I found only devices which belongs to 2 subnets. I found out that there is an XDD IP filtering applied by default by LANDesk core server and I want to adapt this settings to my network.

      In the documentation they said that I have to add a DWORD registry key to the core server to disable this feature (HKEY_LOCAL_MACHINE\SOFTWARE\LANDesk\ManagementSuite\XDD\Filter ) or create new DWORD Registry key to adjust the first and second octet monitoring ranges (HKEY_LOCAL_MACHINE\SOFTWARE\LANDesk\ManagementSuite\XDD\FilterThreshold1 and HKEY_LOCAL_MACHINE\SOFTWARE\LANDesk\ManagementSuite\XDD\FilterThreshold2)

       

      The problem that in LANDesk core server there is no registry entry named "XDD" following that path. Is that okay.

       

      With this feature does the client send information to the core server but the core server ignore them (so they will not displayed under unmanaged devices discovery list) or this settings will be uploaded by all XDD-enabled devices this way they will not try to discover any device which not belong to the default ip range?

       

      LDMS version is 2016.3 and I am in testing phase

       

      This is what I found in XDDClient.log for the elected device in one subnet (please note that in another elected device for another subnet I have the same error messages in the XDD log but devices from that subnet are listed in UDD)

       

      Wed, 16 Nov 2016 10:04:13 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Wed, 16 Nov 2016 10:42:28 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Wed, 16 Nov 2016 10:47:20 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Wed, 16 Nov 2016 10:52:17 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Wed, 16 Nov 2016 10:59:22 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Wed, 16 Nov 2016 11:07:21 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Wed, 16 Nov 2016 11:11:59 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Wed, 16 Nov 2016 11:16:17 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Wed, 16 Nov 2016 11:30:33 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Wed, 16 Nov 2016 16:56:37 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Wed, 16 Nov 2016 19:49:01 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Thu, 17 Nov 2016 08:13:28 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Thu, 17 Nov 2016 09:59:57 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Thu, 17 Nov 2016 10:03:35 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

      Thu, 17 Nov 2016 10:25:29 ERROR: PostCGI: GetRogueClientHostName failed to get the rogue machine name, error was [11004].

        • 1. Re: xdd is enabled on all subnets but I get only unmanaged devices for 2 subnets
          michael.odriscoll SupportEmployee

          Hi Mahmoud,

           

          Thanks for posing to the Community.

           

          Did you find any information on this which may be useful to share with the Community?

          You could try opening a support ticket for assistance https://support.landesk.com/CaseLogging.aspx

           

          Michael

          • 2. Re: xdd is enabled on all subnets but I get only unmanaged devices for 2 subnets
            phoffmann SupportEmployee

            So first up - here's a useful doc around this -- Configuring and Installing Extended Device Discovery (XDD) Best Known Method

             

            ... the registry keys are NOT usually present by default - you need to create them (so that's fine - your core doesn't have a problem ).

             

            Personally, I find it easiest to just create "HKEY_LOCAL_MACHINE\SOFTWARE\LANDesk\ManagementSuite\XDD\Filter" and set that to "0" to disable IP-filtering.

             

            ============

             

            IP filtering always is set at the Core level. Meaning - any XDD client will always "rat out" new devices & send files to the Core server (if you stop the Scheduler service, they'll be visible in this directory (assuming an install to the default location) -- "C:\Program Files\LANDesk\ManagementSuite\xddfiles\" and are called stuff such as "8c51.270c7ed98bb91d1.xdd".

             

            Note that unless you're either monitoring with debug tools OR have the Scheduler service stopped/disabled, you're not likely to see them, as they are quite tiny (as in - 18 bytes for instance) and get processed every 10 seconds odd.

             

            So clients "always tell" on their discoveries, it's the Core that decides whether you want to know about this guy or not.

             

            ============

             

            Regarding your other point - the bits about "could not get client name" are essentially informational. When we discover an ARP request from an unknown device, we try to resolve the device name via DNS. What you're seeing there is essentially "Hey, I couldn't resolve strange-new-guys name in DNS ... just letting you know".

             

            It's neither a problem nor an "error" - it's just an informational message.

             

            Hope that helps?

            2 of 2 people found this helpful