Duplicate Computer names in a smart group?

@AVmcclint This isn't an uncommon when a Mac repair involves a motherboard swap. Normally we delete Macs sent for repair from Jamf Pro, so we don't run into it often and I use the Excel/PivotTable approach you mention to find problem machines. You could write a script to pull your inventory via the Jamf Pro API and search for duplicates that way, but it isn't something I've needed to do enough that I've looked at actually doing that.

No, there's not anything built in; nor is there an easy (or recommended) way to do this in Jamf Pro -- e.g. your Smart Group theory would be a monster to maintain.

I've used the Excel Conditional Formatting to do it and have moved to using a SQL query now.

Also, I highly recommend against simply deleting the original record.  The inventory record holds lots of information that you may need at some point (FileVault Recovery Keys, Activation Lock Bypass Codes, Recovery Lock passwords, Initial Enrollment Date (not referring to the Last Enrollment Date here, uploaded files, etc.).  I actively discourage deleting records in my organization.  Instead, you should update the original record with the new UUID/UDID.

For some orgs deleting the original record is not an issue. We don't use Jamf Pro as an inventory system, so the initial enrollment date isn't important. Regarding previously set FileVault Recovery Keys, Activation Lock Bypass Codes, or Recovery Lock password, none of those will still be valid if the motherboard is replaced so that info in the original computer record isn't useful.

The FileVault PRK and Activation Lock Bypass Codes are still valid if the device isn't wiped.

Replacing a motherboard on any Mac with a T2 or Apple Silicon processor is tantamount to wiping the device. Really any Mac with SSD storage soldered on the motherboard, but especially those since the contents of the storage are encrypted by the T2 or ASi SOC.

While true, what if a backup is created and restored?

Restoring the contents of the drive isn't going to restore those keys, and restoring the contents of the drive after a motherboard replacement won't result in the Mac coming back under management because the UUID will have changed.

The UUID/UDID changing is what causes duplicate records resulting in two managed device records.  That new UUID becomes managed in our environment every time.

Are you saying you're restoring a backup and the repaired Mac starts checking into your Jamf Pro instance with a new computer record without being enrolled again? Or that you're re-enrolling the Mac which creates the new computer record? The latter is what I have been saying should happen, the former is what I don't believe is possible.

We have (or have had in the past) devices that are repaired (main boards replaced), come back, and when they're turned on and check in, a new record is automatically created in Jamf Pro for the device.  The device is not re-enrolled.  It's literally the same instance of the device (device certificate, MDM push tokens, Management account, etc.).

There are times where a tech isn't even involved/aware that a device was repaired, the user took it themselves to an Apple Store to be repaired.  They get it back, a new record is created, I go yell at our deskside techs about another duplicate record that needs to be fixed, and they go "I had no idea it was repaired."

I no longer deal with these kinds of day to day activities, but this is what is relayed to me from techs that are.

The excel thing probably works well enough... Alternately you could write an API script to:

1) get all the serial numbers of all the devices in your environment

2) iterate through the list of serial numbers searching the device API endpoint for that serial number

3) Any "normal" search should return only a single result; but a duplicated serial number should return two results... so look for those? Then delete the endpoint with the older enrollment / last checkin dates.

I don't love this as it feels like a lot of work through the API... but it would give you an automated way vs the excel sheet. 

You'd have to hit the `/computers` endpoint, then iterate over each ID to then get the serial numbers (e.g. via the `/computers/subset/basic` endpoint) and collect them into a list/array, but once you got that....you have all the serial numbers, no need to look up the serial number(s) again to see if there's duplicates....as you could determine duplicates from that list.

That said, I would highly recommend against "automating" the deletion of records....that's a very dangerous thing to do.

If, after determining which records should be removed, you want to use the API to perform the actions, fine, I do that, but....not having a human review what should be removed...that just seems....not safe...

Oh and just to mention....additional scenarios you may want to consider:

• It's possible to have two physical devices with the same serial number...we've had it here....
  • A device had it main board replaced, and the wrong serial number was written to the new board and it matched another device we had
• It's possible to have Macs report NO SERIAL NUMBER AT ALL
  • Again, main board replaced and the serial number was not written to the board -- we had numerous devices in this state a few years ago
• And finally, there can also be duplicate Mobile Device records (due to duplicate Serial Numbers)
  • How this happened...?  Multiple times?  No idea.  But had three different serial numbers, with duplicate records, one had three separate records...