Check your inventory service setting to ensure you are restoring old device IDs.
1) In the 32 bit console on the core server go to Configure | Services
2) Click on the inventory tab
3) Click the button labeled Devices
4) Put a check in the box labeled "Restore old Device IDs"
5) Click OK and OK then click YES to restart the inventory service
The option "Restore old Device IDs" is already checked... (MAC addresses match is not checked, only Device Names match is checked)
What I found out is that this seems to be a problem with Windows Vista.
The Client is in the Inventory with "old Device ID". Then the client is reinstalled with "new Device ID" and scanned:
Registry Scan.scn (local Output on Client) Core Server 1. Scan new Device ID new Device ID old Device ID 2. Scan old Device ID old Device ID old Device ID
-> old Device ID on Client and Core
Registry Scan.scn (local Output on Client) Core Server 1. Scan new Device ID new Device ID old Device ID 2. Scan new Device ID old Device ID old Device ID
-> Client and Core Inventory Device ID are different
In my opinion this seems to be a bug...
Hey Jibber, here is some clarification on the restore ID's.
The key that is used for this function is HKEY_LOCAL_MACHINE\SOFTWARE\Intel\LANDesk\Common Api\UniqueID.
So if you are changing the one in the software\landesk hive only, then restore old ID's will do nothing.
It is on the second scan that everything is synced up and it is all done on the fly. As shown below:
1) Change the ID in the intel reg hive, send an inventory scan. The server writes a record in the DB so that next time it will force the client to SYNC up when it passes parameters.
2) Send a second scan, the registry is Updated on the client with the old ID.
The Inventory Server is smart enough to not create duplicate machine records during the process, so you wont have to worry about maintenance cleaning anything up.
Thanks Brandon for your detailed answer.
It seems that the sync process is blocked by Vista's User Account Control (UAC).
- Open the Local Security Policy (secpol.msc)
- Expand the Local Polices Folder.
- Drill down to Security Options folder.
- Scroll down, and locate the family of settings beginning with 'User Account Control'.
- Focus on: User Account Control: Run all administrators in Admin Approval Mode. Double click and set to: Disabled.
- Restart you Vista computer.
- Scan the computer twice.
- Client and core have synced
But now I have the next problem: The client which now has successfully synced with the core server cannot receive policies. If the client was not in the inventory before it can receive policies.
Fri, 28 Aug 2009 09:12:59 [START] Policy synchronization stated.
Fri, 28 Aug 2009 09:12:59 Sending update request to core server.
Fri, 28 Aug 2009 09:13:04 Web request returned -1 The web request has not been made.
Fri, 28 Aug 2009 09:13:04 [STOP] Error: policy update request has failed.
What I found out now is that this happens only, if the client connects over the gateway.
If I delete the content of the folder "C:\Program Files\LANDesk\Shared Files\cbaroot\broker" and then call brokerconfig and request a new certificate, the client receives the policies.
Is the certificate linked to the device id? Why can the client do an inventory scan but not receive policies. I would expect all or nothing...?!
Jibber, the certificate that the client obtains needs to be unique for each device. IE you cant deploy an image with a client and a broker cert and have it work. Beyond that its hard to say what leads to the scenario you are describing. Policy has more checks in it when communicating to the core especially through the gateway although aqcuiring a new certificate doesnt really explain what went wrong.
You may want to open a case with support on this as I suspect it may require direct troubleshoting on an affected machine to root cause the issue.
The certificate is not in the image. We use configurebroker, so the client receives his certificate automatically with the first inventory scan. This works fine. But after the second inventory scan the client receives the device id from the already existing device in the inventory and then the certificate is not valid anymore. If I delete the certificat und request a new one by hand everything works as expected.
Problem is, that this process should be automated. The technician who installs the device should not care about whether the device is already in the inventory or not...
I have already an open case with support.
1 of 1 people found this helpful
You could turn off Restore old ID's so it doesnt change device ID's on you. Because restoring old ID's requires 2 scans in order to complete, the first scan gets processed and an entry goes into the DB to restore its ID, the second scan the device gets its ID when initial parameters are passed. And configure broker happens on the first scan, there is no way for one to know about the other.
Hope this helps
Thanks for your answer. Turning off the restore of old id is actually the best workaround. I will give an update if I receive a better solution from support.
As an update here - this is fixed in 9.0 (shipping version - no additional patch is required).
We're looking at this in 8.8 still, trying to figure out how much work would be involved in getting this one resolved (without the workaround suggested here). Will try to update here as new developments arise .
- Paul Hoffmann
LANDesk EMEA Technical Lead