When doing an uninstall which requires a reboot of the machine I cannot reconnect all of the time because the IP address isnt updating quickly enough in LANDesk yet a Netmeeting works fine. Whilst this does happen in main offices the major issue is home and remote users comming on to the network over Cisco VPN. Any ideas how I can force the console to update quicker?
be sure that the checkbox "When Ip address change" (agent configuration / standard landesk agent / inventory scanner / run invenntory scan) is flagged.
Moreover you can change comunication method priority in configure / agent status option, in order to move on the top dns method (be aware that your dns infrastructure have to work very well).
Thanks for the input. I have tried all the more obvious fixes and my Agent config is set the way you suggested but still no joy. I did put it down to our network DNS being slow to resolve but when Netmeeting worked I started to look at the console. Thought I would throw it up on here in the hope someone else may have come accross the same issues.
1 of 1 people found this helpful
By default, clients should send a MINISCAN when booting up (it's one of the things the CBA does when loading up) - that contains network information. I'd be surprised if this doesn't work ...
There's a few potential things to look at:
1 - The Core is rejecting the scan-file (because it's an errorscan), hence no update takes place.
==> Check the NT Application Event Log on the Core, to see if any scans have been rejected. This could explain what's going on.
2 - For some reason the client doesn't actually update IP address
==> Sounds idiotic, but I've seen this (and other weird things), so double-check that the client has the IP you think it ought to have.
3 - The client DOES change IP, but the inventory doesn't pick it up
==> This would be EXCESSIVELY odd, but it's a possibility.
The way to check this is to either enabling the "store scans" option on the Core (and looking through them for the files your particular client sent), or you can just create an output scan-file by using the "/O=output.txt" command-line option (and then check the inventory scan file for the network information).
That should help you figure out at least what particular problem you're looking for that causes this.
It should be noted that "you're using the latest inventory scanner, right?" is a given question/check at this point?
P.S.: Stating your version of LDMS and Service pack would help ... also - do you use the "use connection address" option in the Inventory Service's advanced settings?
- Paul Hoffmann
LANDesk EMEA Technical Lead
Option three sounds most like the issues I have been having, after reboot when I try to RC the machine I get the prompt that the IP Address may not be correct for that PC I am wanting to control and asks if I wish to continue. If I hit yes the console directs me to who ever has the lease on the IP address at that time. I sometimes have to wait a couple of hours for the core to be able to connect to the origional machine.
I will work through the steps you have suggested and post a response on Monday.
Since you're also using VPN's, bear in mind the "use connection address" option - that one's easily overlooked (it's in the inventory-tab of CONFIGURE SERVICES). Checking the status on that one can have quite drastic results on what you get back as an IP .
Hope you had a good weekend. I have been through your list of things to check with not much success. The "Use connection address" option is set to 1 already and I have told the core to store scans and I looking through them to see if I can see anything, one thing I have noticed is a lot of users seem to have connections through both wired and wireless resulting in the machine having two IP addresses. The lan connection by default should be set as prefered but on one machine I deployed some software to earlier today the core deployed to the wireless IP. Is there a way to tell the core to use the lan connection as prefered?
Having both LAN and Wireless adapters enabled at the same time will cause all sorts of connectivity problems both for the end user and connecting with LANDesk. Workstation OS's can't route so having 2 IP's bound to the machine at 1 time can cause random headaches; well, at least this is what I have noticed with 2000/XP machines. I can't comment so much on Vista/7.
A few things you can do to help reduce this headache:
- Run an Unmanaged Device Discovery to scan machines and update connectivity records in the LANDesk database. You can do this to update all records, or by subnet or even a single machine by IP. If this is a constant problem, you could configure this as a Scheduled Task, but it will add unwanted network traffic and additional server load while it is running.
- Create a column set that includes IP address so that you can visibly see the IP address of the machine so as to make it easier to identify if you can connect to it or not. If you can see the machine has 2 IP records, you should be able to determine which one is more likely in use especially if you are on the phone with the client.
- Create a query to filter out or in IP addresses or subnets.
- Change your console to use IP or DNS under Agent Status Options. By default, it is set to both and there may be IP address record differences in DNS vs LANDesk.
- Set the LANDesk agent to run an inventory when the IP address changes.
- This one is a little more difficult, but encourage end users to physically disable either the wired (unplug it) or wireless (turn off the adapter) depending on which state the machine is in. In the end, its better for them anyways.
- Try disabling the Windows Firewall or the firewall that might be included with your VPN solution on machines that exibit connectivity problems and see if it makes a difference. Whether configured or not, I have seen them act up and cause problems.
Thanks for the info, I have put a proposal together for users to try and use one connection but I dont hold out much hope, I did try this a while ago but as we all know users know best :-)
I will run through your other suggestions too though, thanks again.