Humm - careful here. Just because a device "still" (I suspect rather "again") exists in "all devices" doesn't mean it's the same one you've been working on previously.
What I suspect is happening is something like this:
Step 1 - You provision your device -- it gets a unique DB entry assigned (that's in the root of inventory called "ID"). Let's say it's "123" for arguments sake.
Step 2 - "Stuff happens" and the ID 123 entry gets deleted. This means all of its assoiated provisioning history gets deleted as well.
Step 3 - The device send in a "new" inventory scan (probably a delta scan to begin with which will fail - the Core will tell the client to send a sync scan) ... meaning you get a NEW unique entry (i.e. "124" now.
Symptomatically, this would explain some what you're seeing (minus the "device getting deleted" part). That could be down to config or some such ("Days to keep inventory scans" is a popular item for people to misconfigure to something too aggressive).
From a technical bug possibility - first recommendation would be fo ryou to either update to SP3 or a newer version entirely (since 9.6 has begun its path to EOL). Being on SP1 you're quite a bit behind the curve, and if there was a defect around that, chances are it'd have gotten picked up & fixed somewhere with SP2 / SP3.
Keep an eye on the "ID" field of devices you provision to at least confirm whether from a process flow my suspicion is correct (which I suspect to be the case). If it is, you may want to poke support to have a look at your Core to figure out what might be causing the device deletions if you're not confident about it yourself (usual cause being people mis-configuring the "Days to keep inventory scans" field as mentioned).
Hope that helps.
Thanks for your reply.
I just got another case. A computer that I personally staged yesterday. The client was still visible in the OSD task from Aug, 4. Now it is gone in both tasks (current & old). So I checked the "record creation date" field of that computer account within Inventory. That's precisely yesterday 5:12pm, the exact moment the template started installing the applications, so right after the OS deployment. That means to me, the account was not deleted & re-created.
I will check the ID field next time.
The "days to keep inventory"...is it in
then "Enable scheduled task history maintenance" - "Number of days to keep scheduled task history:"
I have several configurations there. How can I determine which one is really used?
I can see Agent Settings are combined into Agent Configurations. But how will such configuration get to the computer? By task? Included in the Agent EXE?
I took over the LANDesk system in January. We are building Windows 10 & SCCM. So there is no intent to upgrade anything in LANDesk. That's the problem. But I know that first answer of support will always be to upgrade first. But I just can't.
No - the thing in the agent settings you're looking at is a client-side history of scheduled tasks & statuses (i.e. "I installed Office-365 Last Tuesday. It succeeded").
The "Days to keep Inventory scans" is under CONFIGURE SERVICES, in the INVENTORY-tab. See here:
And then here in the settings in the Inventory tab (note - "0" means "don't delete" based on age)::
Also - please be aware that 9.6 SP1 is *QUITE* a bit behind the curve. I'd recommend updating to at least SP3 ... but be aware that 9.6 has started going EOL, so you may want to look at uplifting a major version sooner rather than later.
OK, right. That's set to 90 days....
As I said, we're implementing SCCM. So the LANDesk thingy is going to be dead, soon ;-)
It has to live & work until at least mid 2018, though....
Strangely the next attempt on the same computer was successful now.
Computer account is still there. Same ID.
The only difference:
I removed the computer account from the console manually before I started the 2nd deployment attempt.
My main point in raising the "need to upgrade" is based on Win-10 - with the "twice a year major upgrade" shenanigans that "can't really be avoided" (and Microsoft has so far fairly consistently broken some 60% of desktop app stacks with each update that I've seen), our client & Core also need to be up to date (hence our mirroring Microsoft's release schedule so that we can fix whatever they end up breaking fairly quickly).
To 2018 that's still a fair time away, but depends on your org's Win-10 schedule I suppose.
OK - so if devices aren't being deleted based on that, what you may want to do is to turn on "store scans" -- just in the event of an existing entry being (somehow) massively over-written by an incoming mini-scan from provisioning. "Shouldn't" happen, but it may be something that was fixed in the ... year+ of fixes that SP2 / SP3 would have ... at least storing inventory scans allows you to replay them (copy them into LDSCAN for re-processing) and thus get a better feel for what happens when.
From a provisioning point of view - this here will give you a basic idea of what happens -- [Tech Brief On-Demand Webinar 2016] Provisioning with LANDESK Management Suite -- which should mostly still be applicable to 9.6.
The first and biggest question at the moment really is whether the ID changes. If the ID changes, that means "old device entry is being deleted" (somehow) and a new one is being created.
If the ID stays the same, and somehow the existing device entry is being overwritten by a "minimal scan" essentially, that's a separate item all together -- but at least it'd be a case of knowing better what's happening.
Symptomatically, it's much the same, but beneath the covers there's quite a bit of difference.
Ah - I refer to those instances as "Murphy's Law of the demonstration effect".
I.e. "Here - let me show you how it breaks ... oh - it's working fine now".
All been there. Frustrating, but I'll take it ... .
You are probably falling foul of duplicate device detection which runs overnight by default.
Building the machine creates a duplicate. The old one still exists but is out-dated. That night the duplicate routine sees that two machines exist with the same name/MAC address and deletes the old one. There is an option to merge the unique IDs so that history isn't lost. Wonder if that is unchecked.
MarXtar Ltd/MarXtar Corporation
Ivanti One Development Partner
Try MarXtar State Management for Ivanti to Better Understand and Manage your Assets