If its happening on some and not all, then it might be a problem wiht the agent configuration on those machines. If you have multiples of agent configurations, you might want to try to standardize to one that has the settings you do want. You can deploy those changes as an agent update.
If its happening to all the machines, then I would check the services on the core and make sure that the database is reachable.
It is just happening on some machines, not all of them. I do have multiple configurations however, most of the machines use the default agent configuration. Like I mentioned, I have push the agent to the machines over and over again and it does not resolve the issue. The machines still will not update.
Can you connect to or ping the machines? Can you connect to them with Computer Management? Have you tried running the inventory scan script against them? Edit the inventoryscanner script and add a /F to the line below and save it as a new script. This will run a full inventory.
;--- assumes that ldappl3.ini is in same dir as the .exe
REMEXEC1=<qt/>%LDMS_CLIENT_DIR%\LDISCN32.EXE<qt/> /NTT=%server%:5007 /S="%server%" /I=HTTP://%server%/ldlogon/ldappl3.ldz /NOUI /NOCD /F
I did this but it did not fix my issue. I have also restarted the Inventory Server service on the core and that hasn't fixed anything.
This is affecting my machine too. The machine I am using reports the last startup time as 12/29/10 even though I have started up the machine multiple times since then, including this morning 1/10/11.
run this on one of the systems:
"C:\Program Files\LANDesk\LDClient\LDISCN32.EXE" /V /F /SYNC /O=C:\inv_servername.scn
Or if 64 bit, it is
"C:\Program Files (86)\LANDesk\LDClient\LDISCN32.EXE" /V /F /SYNC /O=C:\inv_servername.scn
Now, take the .scn file, copy it into the ldmain\ldscan folder, does it process?
(for trouble shooting, delete all old files in the scan folder and in the sub folders)
If it does not process and goes into the error scan folder, you need to look at the .scn file in notepad and see if you can tell why and where it is failing. You can post it here for more help.
If it does process, that leads me to think you have a scheduling or communication issue... let me me know
I had this same thing happen in SP3 so although the thread is rather necrotic (Ex Firmis e mortu Orem) it still may apply.
The problem and How I corrected it
The Problem: The agents deployed get out of sync with the core. Evidently there is an exchange of private or public key information whenever there is an inventory? I could not get the full lowdown, but I got enough of it to determine how to correct it.
The Fix we employed.
First we have our agents set to run a scan every 4 hours so this may take longer if you scan once a day.
The guys at support asked me how I got it fixed so this is what I sent themFirst here is what I see:1) There is an application error on the Core server that complains as follows:Database exception: SCA48FC.SCN, LDInv.dll
Violation of PRIMARY KEY constraint 'XPK_System_Capability'. Cannot insert duplicate key in object 'dbo.System_Capability'.Error comitting on table SYSTEM_CAPABILITY: VIOLATION OF PRIMARY KEY CONSTRAINT 'XPK_SYSTEM_CAPABILITY'. CANNOT INSERT DUPLICATE KEY IN OBJECT 'DBO.SYSTEM_CAPABILITY'.
Increased column size might be necessary, Thread ID: 8676.2) I look at the file SCA48FC.SCN in the core server @ <COREServerInstallDrive>\Program Files (x86)\LANDesk\ManagementSuite\ldscan\ErrorScan3) Once open in Notepad I can see the device ID and all4) I go to the Device ID and look in <DeviceName>c$\Program Files\LANDesk\LDClient\sdmcache\ldlogon\AdvanceAgent to ensure that the agent made it down to the server5) I then look in the registry to confirm that the currently installed agent matches the new agent and not the old at:\HKLM\Software\LANDesk\ManagementSuite\WinClient\Configuration Name6) If the agent displayed in step 4 and step 5 match the New agent that we are deploying then I delete that device and let it add back to the system within the next four hours (Our agents are set to run an inventory every four hours)7) Within four hours the inventory on the core is correct and matches the device.
We are experiencing the same issue. LANDesk Support has asked for our database to see if there is a bug. Support suggested we drop the System_Capability table and then run coredbutil to bring it back. We are waiting to see what they find from our DB first.
i did that on the test core for a slightly diffeerent problem. There were some 11 vectors in a table that could not be updated because the permission was not correct to allow their change. Once we deleted these entries then it all worked fine and we never had the error on the core again. However, that error is slightly diffeent in that it was being generated by a response from the database to the corein reference to a particular table and the dbo not having rights to that table. One of the support guys knew just what to do and we went into the appropriate table, deleted the 11 entries within it, restarted the SQL instance and pressed on with pride.
We are also seeing this error:
Violation of PRIMARY KEY constraint 'XPK_System_Capability'. Cannot insert duplicate key in object 'dbo.System_Capability'.
Error comitting on table SYSTEM_CAPABILITY: VIOLATION OF PRIMARY KEY CONSTRAINT 'XPK_SYSTEM_CAPABILITY'. CANNOT INSERT DUPLICATE KEY IN OBJECT 'DBO.SYSTEM_CAPABILITY'.
Deleting the device from the database and rescanning allws the database to be updated but the root cause is still there. The message suggesting increasing field size is bogus as the data being inserted into the 225 char field is 4 characters: e.g. System Capability - (Capability Number:1) - Technology Name =ASIC
Digging further we find the device in question has two entries in the System_Capability table:
select * from dbo.System_Capability where Computer_Idn = '10761'
System_Capability_Idn Computer_Idn Capability_Number Technology_Name
3 10761 1 AMT
6214 10761 2 ASIC
At some point* it no longer reports the AMT system capability (as it's not AMT compatible?) but only reports ASIC as Capability_number:1 which is in conflict with the primary key constraint:duplicate key and therefor the scan is rejected. Deleting the computer removes both these records so a fresh scan will inject OK (as will dropping and recreating the System_Capability table) but the way I see it this needs to be fixed at source by LANDesk or we will have devices that are never updated as the scan is always rejected unles we remediate each one as it's found.
*I'm making an assumption that the point it no longer reports the AMT system capability is when we rebuilt from XP to Windows 7.as this seems to be the point at which last scanned sucsesfully.
I know this thread says "UNANSWERED", however - as is the case from time to time - no one has moderated this issue. I pointed out that the support team at LANDesk actually fixed this by deleting a couple of elements from a table in their SQL DB. I watched the guy remote in, delete the files and proceed to fix it all. -
"One of the support guys knew just what to do and we went into the appropriate table, deleted the 11 entries within it, restarted the SQL instance and pressed on with pride"
I would call them and reference this point here - it may jog their memory. If you cannot access them (no phone support or some such) reply to this thread and I will call in and have them update this thread with the fix that they used.
Joe, I'm not getting drawn into a post answered presumed dead.debate.
The offering from this thread is, at best, a bodge to get a rejected scan into the database and there are many ways to do this and these have to be repeated every time the event occurs. I have added a little more detail to help anyone else reading this to chose the best way for them to proceed. The problem is; the a scan is being rejected due to something that is essentially a code error. This needs to be 'fixed' as receiving inventory data regularly and reliably is fundamental and key to running any device management system.
I have raised a case with LANDesk and will pursue to a permanent fix.
UPDATE: We confimed with LANDesk this occurs when system capability reporting changes on the same device, i.e. when it's upgraded from XP to Win7.
LANDesk have logged this as defect number 30071 and advise is is being resolved in V9.5 and V9.0 SP4 by "dropping the constraint XPK_System_Capability, so that the database will no longer raise an error if a machines sends an scan with a doubled capability."
They also advised "Product support thinks that it should be safe for you to alter your database in the same way. If you choose to do so, please backup your database. Then run the following SQL command: "alter table system_capability drop constraint XPK_System_Capability " . "