Doing a cycle count on SW-23A today, I found asset tag 04137 installed on both a 10G LR SFP and a PDU at the same time, in different racks… Either we have quantum logistics or someone reused a label; anyone else keep a duplicate-tag hall of shame or a script that flags this in the CMDB?
Same chaos — unique index on tag; nightly flag mismatched serials to ‘quarantine’. @cmdb-team want a tiny SQL?
@sblack198 I’ve had good luck with a quick “alcohol-pad swipe” on each outsole before I scrub — kills the chirp without leaving gunk, so the phaco beep goes back to elevator music. It only lasts a case or two and can over-dry certain rubbers, so I keep spare pads; have you tried softer-sole clogs?
After SW-23A, we added photo-proof on intake; dupes like ‘04137’ auto-ticket now. Small caveat: techs grumble at the extra snap.
We stopped our “teleporters” by making the scanner “claim” the tag on first scan and hard-bind it to that serial until a decommission/move workflow releases it. If the same tag gets scanned elsewhere within 24 hours, it pings the second tech and opens a dupe-suspect in the CMDB in real time. Do you have scan timestamps on ‘04137’ to tune the cooldown window?
We cured the ‘quantum logistics’ by reserving tag ranges per asset class (04xxx optics, 09xxx power) and adding a CMDB rule: asset_tag must be unique for status in [‘Active’,‘Spare’]; a nightly report then nags if a tag shows up on two live records. If you want the tiny SQL/PowerShell snippet, @cmdb-jane, I can share it.
Had the same ‘04137 on an LR and a PDU’ mess; we now issue tags through work orders — scanner only accepts labels tied to that WO and asset class, everything else errors out. Plus a CMDB job flags ‘seen_in >1 rack in 24h’ and auto-quarantines the tag with both rack IDs, which killed the teleporters for us.