That's fantastic, Mike. Thank you so much! On Wed, Dec 21, 2016 at 10:40 AM, Murray, Mike <[email protected]> wrote:
> I have a duplicate computers collection that updates daily. I go through > and remove the old record if it finds any. Query: > > > > select R.ResourceID,R.ResourceType,R.Name,R.SMSUniqueIdentifier,R. > ResourceDomainORWorkgroup,R.Client from SMS_R_System as r full join > SMS_R_System as s1 on s1.ResourceId = r.ResourceId full join SMS_R_System > as s2 on s2.Name = s1.Name where s1.Name = s2.Name and s1.ResourceId != > s2.ResourceId > > > > *From:* [email protected] [mailto:listsadmin@lists. > myitforum.com] *On Behalf Of *Adam Juelich > *Sent:* Wednesday, December 21, 2016 7:58 AM > *To:* [email protected] > *Subject:* Re: [mssms] RE: Merge vs New Record > > > > Eesh. > > > > Is there a way to do a query for duplicate devices to at least keep an eye > on it and mitigate the issue? > > > > On Wed, Dec 21, 2016 at 8:57 AM, Olsson Mats (4004) <mats.olsson@ > forsakringskassan.se> wrote: > > This is a known issue introduced with SCCM2012 SP1. > Before SP1 the netbios name was a “mergable” property and since that value > existed in the AD DDR, in the heartbeat DDR and in a ImportMachineEntry DDR. > > After SP1 there will be a problem if the AD DDR is created before the > Heartbeat DDR. > I have had a case on this with Won’t fix from MS. We did file a DCR too > with no result. > > We have a rather complex workaround for this. > We first create the record in AD and record the SID from this object. > > After that we create a DDR with ImportMachineEntry WMI method > Finally we have to use SMSResGen to create a third DDR with the SID from > the AD entry and the Mac address from ImportMachineEntry. > > > Now SCCM can merge The AD and SMSRegenEntries on AD sid and it can merge > the SMSResgen Entry and the ImportMachineEntry on mac and the result is one > record in the SCCM database. > > > > The Quick simple fix would be for MS to restore the Pre SP1 functionality. > Another fix (better one) would be to modify the merging behavior so that > SCCM did merge the records based on FQDN by default > > > > > > *From:* [email protected] [mailto:listsadmin@lists. > myitforum.com] *On Behalf Of *Robert Spinelli > *Sent:* den 21 december 2016 13:50 > *To:* [email protected] > *Subject:* [mssms] Merge vs New Record > > > > Does anyone know how SCCM decides to create a new record or merge with an > existing record? What does SCCM key off of to decide? I know I had a blog > or something way back when but can’t find it. > > > > If we have following: > > > > Machine1 record created by AD System Discovery > > Machine1 record created when client is installed (heartbeat) > > > > We’re seeing issues where the 2 records don’t merge and we end up with 2 > records for the same machine. One record showing machine with client > (heartbeat) and one record from AD system discovery showing machine with no > client. We will end up having: > > > > Machine1 record (client installed – heartbeat discovery) > Machine1 record (client not installed – AD system discovery) > > > > If I delete the machine1 record created by AD system discovery from SCCM > and then make a change on the AD object, delta discovery kicks in, creates > a new ddr from AD System discovery and then merges with Machine1 record > (client installed – heartbeat discovery) > > > > I did find article below but this is for machines that are being using > unknown computer support: > > > > https://blogs.technet.microsoft.com/enterprisemobility/2011/09/09/ > known-issue-and-workaround-duplicate-records-when-you- > use-unknown-computer-support-with-active-directory-delta-discovery/ > > > > Thanks > > > > Rob > > > > > > > > > > > >
