13 Replies Latest reply on Jul 19, 2011 7:50 AM by Jon_UK

    Inventory Scan fails to resolve coreserver


      We have 90% of our organization outside our internal network.  All these clients reach us through the management gateway.  However, we get a bunch of them that have trouble sending in their scans.  They get the following message when the scan in manually run. It is very intermittent.  We can have 2 machines in the very same office, one works one doesn't.




      Some things that may help:

      • Machines are not on our domain, therefore they cannot resolve the server name directly - I thought this may have been an issue but we have about 900 machines out there that aren't on our domain.  This problem only happens on a few of them.   They can reach us through FQDN but not via machine name alone
      • Machines are on their own local subnet - They can also reach us via IP directly.  Some of the offices are in an MPLS with us and others aren't yet.  This problem is not specific to one or the other situation.


      Any help would be great.


      Also -> Can I do an inventory scan to a file and then dump that file into the ldscan folder on our core server?

        • 1. Re: Inventory Scan fails to resolve coreserver
          mrspike SSMMVPGroup

          A few things here....



          First, the easy one, to scan to a file and manually import is easy...



          That command is:


          "%program%\LANDesk\LDClient\LDISCN32.EXE" /V /F /SYNC /O=%temp%\inv_servername.scn


          Or if 64 bit, it is

          "%programfiles(x86)%\LANDesk\LDClient\LDISCN32.EXE" /V /F /SYNC /O=%temp%\inv_servername.scn


          When you are done go to Sart > Run type in %temp%, grab the file and copy in into the C:\Program Files (x86)\LANDesk\ManagementSuite\ldscan folder on your core (path might vary)



          If a system is NOT already on your core and you want to get it to work via the gateway this helps with that.





          Now, to the reason your systems are not checking in via the gateway,  you really should use the fqdn as show below in your agent




          1 of 1 people found this helpful
          • 2. Re: Inventory Scan fails to resolve coreserver

            Thank you for the information.  I was able to get the scan to file to work and dumped it into the LDSCAN folder.  LD successfully imported the data.


            I can certainly change the agent to have FQDN going forward.  Is there a way to manually force a specific server so I can test to confirm that it will actually work?


            ie: ldiscn32 /f /s=server-name.test.local gives me an error ->  Command line syntax error.


            Or is there somewhere in the registry that I can modify the servername to relfect the FQDN of the core.  I have tried two locations so far and the scan software doesn't seem affected:


            1. HKLM\Software\Intel\LANDesk\EventLog\ServerName ________
            2. HKLM\Software\Intel\LANDesk\LDWM\CoreServer    ________




            Maybe I am just entering it wrong but I am sure I have tried many combinations of the paramters.


            Thanks in advance.

            • 3. Re: Inventory Scan fails to resolve coreserver

              On my machines, this is what the Inventory Scan shortcut looks like. I use FQDN and it works like a charm with MG machines.


              "C:\Program Files\LANDesk\LDClient\LDISCN32.EXE" /NTT=<coreFQDN>:5007 /S=<coreFQDN>  /I=HTTP://<coreFQDN>/ldlogon/ldappl3.ldz /V /SYNC

              • 4. Re: Inventory Scan fails to resolve coreserver
                zman Master

                In addition to what what James and Ken have suggested, there is a good article on troubleshooting LDMG and Broker issues http://community.landesk.com/support/docs/DOC-2131

                • 5. Re: Inventory Scan fails to resolve coreserver

                  Apologies if I'm over simplifying the problem but for the ones that wont resolve the core name only via the FQDN how about adding a host entry into the windows\system32\drivers\etc hosts file ?

                  • 6. Re: Inventory Scan fails to resolve coreserver

                    That last reply about the hosts file is what messes me up.  We tried that in previous instances where we had this problem.


                    The strange thing is that we have about 50% of our offices completely external to us.  No MPLS, no network connection between at all - other than the public internet.  We have had the problem with reaching the inventory scanner happen on both machines that can reach us through the network AND on machines that are outside our network.  All agents on all machines do not have the FQDN right now.  They only have the servername.


                    The problem machine that generated this posting for me, is actually inside our network but not on our domain.  It is configured to use our DNS.  It can reach us successfully using the FQDN (and I have successfully got the Scan to run using the command provided by one of you above).


                    However, we have other machines in the very same office that are identical as far at network access and such goes, that can reach back to our server without any FQDN or any changes.  As a matter of fact, when we first rolled out landesk, we had about 900+ machines that were completely outside our network and we able to drop their scan files to our server without any issues, WITHOUT using FQDN.


                    Any way to clear up this confusion?  Does the management gateway have anything to do with this situation?



                    • 7. Re: Inventory Scan fails to resolve coreserver
                      MarXtar ITSMMVPGroup

                      If the machine is within your network just not a member of the domain, then the issue is almost guaranteed to be name resolution.


                      Is your dhcp for that machine configured to provide a dns default domain name?


                      dchp dns domain.jpg


                      If DNS will only serve the dns request if the correct domain suffix is provided then it would explain why the non-domain machine would fail.


                      Mark McGinn

                      MarXtar Ltd



                      The One-Stop Shop for LANDesk Enhancements

                      - Wake-On-WAN - Distributed Wake-On-LAN, Scheduled Power Down, and SWDist Sequencing

                      - Inventory Change & Root Cause Analysis

                      - Self-Service Password Reset

                      - PC Power Management

                      - Help/Service Desk Integration

                      - LANDesk Data Manipulation/Integration/Bar Coding

                      - LANDesk Executive Reporting Pack

                      - Network Asset Discovery and Management

                      - LANDesk Software Store

                      • 8. Re: Inventory Scan fails to resolve coreserver

                        I guess the part I need help understanding is how the clients get their files back to the core server.   If we had 900+ machines originally on separate networks where they CAN'T talk to the core server in ANY way,  how do those files get there.  They cant talk via servername. They can't talk via FQDN. They cant even talk via IP. They are in completely separate worlds.   I don't understand how those machines were able to drop their files back to the core.

                        • 9. Re: Inventory Scan fails to resolve coreserver
                          MarXtar ITSMMVPGroup

                          If you have a gateway in place and there is no other way in which the clients can see the core server over IP and port 5007, then the scans must have come via the gateway (unless at some point somebody did a store and forward type model using the file output you mentioned earlier or they scanned when built centrally before shipping out).


                          The fact that you have inconsistent results probably means that name resolution and/or agent config is not consistent enough to allow the clients to connect.


                          If the agents are configured with just the coreserver name, then something at some point tagged on the appropriate suffix for them to communicate. I'd suggest that you build an agent config that has the FQDN in it so that you take that out of the quation and use it to try to get the affected machines reporting via the gateway (where no direct IP connection exists).


                          Break it down into manageable chunks so that you remove each potential issue as you go along.


                          1. If the PC can see the core directly over IP then focus on name resolution issues
                          2. If the PC has no direct IP connection then focus on getting FQDN resolution so they can talk via the gateway


                          Mark McGinn

                          MarXtar Ltd



                          The One-Stop Shop for LANDesk Enhancements

                          • 10. Re: Inventory Scan fails to resolve coreserver


                            Can you check and see if machines have different default DNS search suffixes (ipconfig /all should show this). It is possible that you need to use the FQDN for you core in the agent configuration (also where it has the address of the web console server in the console Configure | Services)



                            • 11. Re: Inventory Scan fails to resolve coreserver

                              Thanks for all your help everyone.  It seems to have been resolved by using the FQDN.  I'm still not sure how the ones get deposited through the gateway but it doesn't really matter now. 

                              • 12. Re: Inventory Scan fails to resolve coreserver
                                zman Master

                                Glad to hear you have worked through this, please mark this as answered/closed.

                                • 13. Re: Inventory Scan fails to resolve coreserver

                                  I'd imagine the ones coming in through the gateway appliance are doing so using the core certificate as a way of getting through the appliance to the database.  Then the appliance in turn is resolving anything NAT'd through the DMZ and past onto the core as the two will have some kind of trust relationship similar to a AAA Server pass through.