We started with Service Desk 7.3.2. Over the years we have suffered with some flaws in the LDMS import. Recently my imports stopped working and Service Desk remote control rarely worked. We had duplicate systems and retired systems in our list for the user. It was kind of no fun.
Service Desk is great at gathering data. In the case of LDMS workstations though, that is a problem. In our LDMS implementation, any machine not scanned in 45 days is deleted from LDMS. Service Desk keeps it forever. Later the workstations checks in with LDMS and it gets a new ID so a duplicate record is created in Service Desk. I suspect many are like us in that there is a workstation CI attribute on the incident and it's tied to the Raiseuser and shows only the machines they use often. In our case we can see a dozen systems or more. Most of the systems are out of date and retired. So the logical solution is to create a filter by last updated date. Great idea but that fails because the records never update with the last scan date. Why? Because can't you put a date/time attribute from the Workstation import into the lastscan date/time attribute of the CI. There is a problem with the DLL and the time is scraped from the date so you can't import. Without the lastscandate all other parts of the record don't change so there is no import which means the last changed date NEVER changes. Originally I added a string attribute to accept the last scan date just so the object gets updated and then the last updated attribute gave me a date to filter. But there is a better way.
It seems that SQL does a much better job at importing the data and is a whole lot faster as well. I import 42,000 users every night using SQL and it takes 37 minutes. My 6700 LDMS workstation records took 44 minutes to import. Now that I moved to SQL, it's 7 minutes. I created a query which my SQL DBA made into a view for me. The query will almost certainly need to be adjusted but it's a good start for you:
SELECT a.Computer_Idn, b.AssetTag, a.DeviceName, c.StorageTotal, f.Address, a.UpdateLastScanDate, b.Manufacturer, b.Model, e.OSType, e.Version,
a.LoginName, d.BytesTotal, b.SerialNum
FROM
LanDeskMS.dbo.Computer AS a
LEFT JOIN LanDeskMS.dbo.CompSystem AS b ON b.computer_idn = a.Computer_Idn
left JOIN LanDeskMS.dbo.LogicalDrives as c ON c.Computer_Idn = a.Computer_Idn
left JOIN LanDeskMS.dbo.memory as d ON d.Computer_Idn = a.Computer_Idn
left JOIN LanDeskMS.dbo.Operating_System as e ON e.Computer_Idn = a.Computer_Idn
left join LanDeskMS.dbo.TCP as f on f.Computer_Idn = a.Computer_Idn
where a.DeviceName is not null and c.DriveLetter = 'C'
Then a Data Connection and import need to be created. Below is the mappings I used based on my databases and my attributes. You will most likely need to make minor changes but I think this at least points you in the right direction.
Finally I had to create a filter and add it to my Window. Later I will add it to the object so it works in Webaccess. I made the Primary Owner equal to the RaiseUser.Title and the Last Update is within the previous 45 days. The filter is based on Incident and Incident and filtered by Configuration Management and Workstation.
One of the other issues I noted in the import routine is that I have 700 less records in SQL. After investigation it turns out that the LDMS connection returns up to 3 records for a single machine. When I added a where clause that only uses DriveLetter C:, I get 700 less records to import. It seems that the LDMS connection doesn't have a filter for additional drives (A:, D:, E:, etc) so multiple records can show up.
It seems that consultants have been using SQL for importing data a while now so new installs of Service Desk may not need to make these changes. I ran across this so I hope it helps others out. My import is running better and my list of systems list just computers that exist in LDMS and are active so it's generally just 1-2 systems.