Sorry to resurrect this thread, but this is giving me some heartburn too. During provisioning I pre-place an AD object in the OU where the object will live so it can be discovered and sorted by collection query by its OU to do some of the same things as Mats. I also put this object into Software Update collections and Maintenance Window collections pre deployment so when the OS is installed and the client is registered it starts life discovered and in all the right collections to get updates its maintenance window and everything else.
I've read this thread and others and added the steps to my process to use the Microsoft.ConfigurationManagement.Messaging.dll to make the extra DDR to combine the ImportMachineEntry to what gets discovered in AD, so I end up with a record with three "agents"; "Manual Machine Entry", "SMS_AD_SYSTEM_DISCOVERY_AGENT" and "My_AGENT" (from the dll invocation). All well and good, that's the object that gets put where it needs to, MWs and all. Only trouble now, is that when the client registers during deployment, the "MP_ClientRegistration" and "Heartbeat_Discovery" agents create a new object and the two never merge. The one with the actual client is just left in All Systems and doesn't get sorted or discovered. Is the key here, as Mats suggests, to have heartbeat before AD discovery? Makes for inconsistent results if I have delta discovery turned on and my AD object gets discovered before client registration. I could turn up the interval on delta discovery, which lessens the chance this could happen, but it doesn't eliminate it. I could turn off delta discovery altogether and set the schedule for discovery to happen when no one would be deploying anything, but that adds time to completing a deployment. Both seem like a step backwards. I'd like a common object key that would merge all types of records. FQDN maybe? I don't know. Looking at my two objects in v_R_System in SQL only shows netbios_name0 and name0 as common between the objects and that doesn't appear to work anymore. MAC address isn't in v_R_System, despite it being in both records when you look at their property sheets in the console. I'm on 1606 at the moment, is this still an issue in 170x? Would it be helpful for me to open a case for this as well and mention the others? I'd like to figure out something or have this fixed too. Todd -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Olsson Mats (4004) Sent: Friday, December 23, 2016 1:28 AM To: [email protected] Subject: RE: [mssms] RE: Merge vs New Record The Issues we had where rather bad. For example if you use ad groups for your software installation collection rules your software deployments won't work. The AD based record will be in the collection but Since the agent on the client will be using the DDR from the heartbeat discovery it will NOT get a policy to install that app. If you do the same for patch management or Antivirus (for example different av-policies for different machine groups in AD) you will have really bad issues since now you won't get those updates We did do a workaround that solves the most of it. It still do happened that we get a dubble record sometimes but it's not a few a day that we had with MS "out-of-the-box" SP1 Best Regards Mats -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Marcum, John Sent: den 22 december 2016 12:45 To: [email protected] Subject: Re: [mssms] RE: Merge vs New Record What issue does this cause? Personally I never see duplicates but even if they are there I'm not going to see them in reports of collections and they are going to age out pretty quickly. Typos compliments of Siri Sent from my iOS device On Dec 22, 2016, at 1:37 AM, Olsson Mats (4004) <[email protected]<mailto:[email protected]>> wrote: [External Email] Sure :) We want this fixed so the more merrier :) Case 113121111017627 I have spoken directly with Aaron about this to so I kind of know that the product team is aware of the issue Best Regards Mats From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Robert Spinelli Sent: den 21 december 2016 17:16 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Merge vs New Record I opened a case with MS on Friday and they have been less then helpful. Olsson you wouldn't happen to still have a case number I could give them to reference do you? If you want to send it directly to me that is fine. Thanks Rob From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Adam Juelich Sent: Wednesday, December 21, 2016 10:58 AM To: [email protected]<mailto:[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) <[email protected]<mailto:[email protected]>> 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:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Robert Spinelli Sent: den 21 december 2016 13:50 To: [email protected]<mailto:[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 ________________________________ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer.
