1 of 1 people found this helpful
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
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:
- HKLM\Software\Intel\LANDesk\EventLog\ServerName ________
- 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.
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
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 ?
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?
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?
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.
The One-Stop Shop for LANDesk Enhancements
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.
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.
- If the PC can see the core directly over IP then focus on name resolution issues
- If the PC has no direct IP connection then focus on getting FQDN resolution so they can talk via the gateway
The One-Stop Shop for LANDesk Enhancements
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)
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.
Glad to hear you have worked through this, please mark this as answered/closed.
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.