Thanks fribergb, I hope we soon have a better way for you to submit enhancements.

1. I agree, this feature would be great.  I wrote the VBScript to help those out who need this feature now and cannot wait for an integrated solution.

2. I thought with 8.8 we had AV doing a self heal.  Are you one 8.8 and still seeing it not recover?  I hope not, cause our development team work hard to make it so it can auto-recover.

3. I think this is already fixed pretty well, though i won't say there is not room for improvement.  We have done a ton of work here.  Here is a list of the work that has been done:

- If the device already exists in the database, OS Deployment will use the same GUID as it had before and not create a duplicate.

- Also, LANDesk has changed its duplicate device detection settings so if you left the GUID, when every machine has the same GUID after OS Deployment, when they contact the Core Server, the Core will not let them overwrite each others inventory scans, but will tell the device to generate a new inventory scan.  Which is pretty much the feature you are asking for just in a slightly different way than you asked for it.

- If you leave the GUID, you lose the feature where if a device exists, it will get the previous GUID immediately so we added an option to fix this.  We have an option to restore old Device IDs.  So our settings have an option to check for this and will delete the older device when maintenance runs as well as change the device ID back. 

Note: If we simply generated a new GUID with sysprep, we would still have duplicate devices, because if you imaged an existing machine, you would get a duplicate, but then the duplicate would delete when maintenance runs and the old device ID would be restored.

Note: We have been seeing a problem where duplicates sometimes are not removed when maintenance runs, so if you see this, give us a call at support.

- As for whether to include the agent, even if we did what you ask, we still would recommend NOT having the agent in the image. There are many applications that you shouldn't include in your image.  Any application that is updated regularly should not be included, and the LANDesk agent falls under that category.  It has updated settings pretty often.  Then we are continually enhancing our software all the time which leads to a lot of upgrades. 

Also, any installation that uses anything unique that is not updated via sysprep has this problem, the agent falls under that category, but as explained there is a work around.  I have heard of VPN clients all getting the same MAC address on all their machines because they included it in the image which can be problematic.

The LANDesk agent is easily included as long as you delete the GUID registry keys.  Many people experience problems they do not know or understand because they include software they shouldn't include in the image.  But sometimes they never realize the source of the problem is that they included the software in the image.

- One of the best parts of OSD is that LANDesk integrates to install the agent at the time the image is laid down so you always get the latest agent with the latest settings and latest patches.

4. I love your idea here.  To be able to sort on heartbeat.  But just one thing to note is that doing this may not save you traffic.  The Console sends the same discovery traffic to see if a device is on that a scheduled task sends.  But then again it may save you traffic because if sometimes you see both the Console discovery then you grab the device and schedule the task and so discovery happened twice.

We also need to work on an issue where when we do discovery, we may mark Machine X as on when really Machine Y is on with the IP Adress that Machine X has listed in inventory.

5. I have to say that our GUI could improve in the way you have stated and I agree with you completely.

For AV, we now have a folder of that has the last working stuff backed up.  If we cannot start, we are supposed to restore the last working state.  I haven't been keeping track of how well that is working because I am not on that team.

For OS Deployment, there is a lot of complexity to this and there probably shouldn't be.  It should be easier to understand and just make it work.

Overwriting a record is by default no longer allowed by default and hasn't been for a while.  Of course you can change the settings to allow it but by default it is disallowed. We have our inventory's Device IDs settings set by default to disallow an inventory from overwriting a record if either the name or MAC address changes. So if you build the image with an agent and leave the GUID, then that GUID will probably already point to a device in the database.  Lets say that device is Box B with a database ID of 431.  So what will happen is that Box A is reimaged.  After mini-setup, it boots, local scheduler kicks off and inventory scan which contacts the Core Server prior to sending a scan.  The Core rejects the connection saying the device is using a GUID that already exists for another device (id 431) and it is told to regenerate the GUID and use that GUID the next time it scans.  It usually scans once a day, so tomorrow it scans again with a new GUID and enters the database with a new database ID (say it gets database ID 7001) and new GUID.  Box A now shows up twice for 1 day.  As database id 5 and the new database id 7001.  Well, at 11 pm (the default time maintenance runs) the first instance of Box A is removed automatically eliminating detection.

Now, the preferred method is to not have the agent or at least have the GUIDs deleted.  If you have Box A with an ID of 5 in the database and Box A is re-imaged with an image that either has no agent, or has an agent with the GUIDs deleted, that device will be named the same and have the same GUID and the same database ID of 5.

Now as for the "Restore old device ids" I haven't tested what happens with that checked in during the process of OSD.  Will it stay database id 5, or will it be database id 7001 with the same GUID as id 5 used to have before it was deleted?  Sorry, I don't know.  I wish I had time to do more testing.

So i think there is room for improvement but I also think a lot has been done already to make this problem go away.

But what has done is very complex and confusing.  That is why I so adamantly tell everyone to not include the agent on the image, and use our integration to install it.

We definitely needs some improvement in this area.  Right now we check for a file (ldsican.cfg) on the C:\ drive when we install the agent, and if it is there, we use the GUID in that file.  We create that file during OSD and use the existing GUID if it is an existing machine. Unless you are installing the agent during OSD, that file is not used. One simply change we could do is make ldiscn32.exe also look for that file and update the GUID registry keys to match the GUID in that file if that file exists.

But still, without any manual effort after imaging, you should not have any duplicate or overwritten devices if you image with the agent on the image, though it may take a one to three days depending on how often a scan occurs.

More of a suggestion for the web site, but including CRC values for large downloads. So the file can be checked and any corruptions found prior to install. LD Service Packs linked in the community and software within the portal. Would be v helpful, thanks

"4. I want to sort machines by whether they are available or not. I can't sort on "heartbeat" so I have to choose a group of machines to run a script on, then manually select the ones that are online ALL THE TIME. Otherwise the core server is wasting time and network bandwidth constantly trying to reach machines that are off. I typically NEVER want to run a script on machines that are not available... tho sometimes I do. So being able to sort the off-line machines out would be great. Or better yet "Show Off-Line Clients Yes No" on menu bar would be great!"

We saw this and created Power State Notifier Lite - see http://www.marxtar.com for details. It does what you want and more, plus its FREE.

Your number 1 item, we will also do this in the near future (and more)

The things i would like to see is:

Global Messaging w/out scripts. Just a button you click on and type your message and hit send. This is especially handy if the email system is down.

Also antivirus w/ safemode support

One feature I would like to see is a single common log file that LANDesk will maintain a record of all possible reboot/shutdown events that were triggered by LANDesk or a task that was launched by LANDesk, what task is responsible for the reboot, and how the reboot/shutdown was called (via Winrestart.exe, Shutdown.exe, Windows API, etc)

We have occasional helpdesk tickets saying things like "My computer rebooted at 7:30ish this morning, why? Was it LANDesk again?"

Of course, even if this is NOT LANDesk causing the reboot, users will blame LANDesk anyway.  Without an actual record of reboots kept by the Agent, I cannot prove to my boss that LANDesk is innocent. 

I go and look at what has run recently on that machine, and can't find any Scheduled Tasks/Policies that have a reboot in the Task, nor in the package itself, so I look at LANDesk log files that were modified at 7:30ish and find nothing except for the usual "Service shutdown has been requested, setting shutdown event" in the POLICY.CLIENT.INVOKER.LOG (which simply notes that a reboot has started and the Invoker process will exit). The only thing relevant in the system's Event Log is USER32: SYSTEM: Winlogon.exe has initiated a restart...

What worries me into thinking LANDesk IS guilty is the fact that the SYSTEM account (which LANDesk agent runs as) initiated the reboot, I just can't find anything logged that proves or disproves it.

More and more of our users are starting to view LANDesk as "Big Brother".  One group of TabletPC users distrust LANDesk so much that they were able to win a political fight and have the Agent permanently removed from their Tablets.  I don't want this to become a growing trend, but unexplained reboots do NOT help the situation, no matter why the reboot actually occurred.

Thanks!

JSMCPN - did you have a look in the SERVICEHOST.LOG ?

If the reboot didn't come through a soft-dist task, then it may have come through a console-initiated task ... in which case, it would be tracked in the SERVICEHOST.LOG (you'll be able to search for command-lines launching POWEROFF.EXE ) :).

That may help you a little along the way.

Paul Hoffmann

LANDesk EMEA Technical Lead

"Figure out some way to make the PXE Boot Menu available for off-line imaging (booting from either CD or USB flash drive and saving or restoring from an image stored on an external disk.)
=> Provisioning does this to a degree (can provide you with a bootable CD/USB flash drive) - or are you talking 100% off-line, no network connectivity at all?"

Offline (100% off the network) imaging would be a great enhancement.  We have over 9000 pc's in our environment, most all of them are remote sites.  Our help desk is reimaging anywhere from 5-20 pc's a month for a variety of reasons, hardware failures, windows corruption, virus issues, other issues, and of course user error.  Previously we used Ghost, and would create bootable media to overnight to the remote sites.

I found a few landesk documents that started to go into this, but they were rather vague.  I am working/testing on some scripts to try and automate this to work with winpe and landesk to make it simple to use for our help desk and remote locations.  I will get with our technical support reps with LanDesk and make a formal request that way.

So far LanDesk is working great, just wanted to throw my one cent (previously two cents but due to budget restrictions, etc, etc...) into the mix.