When reinstalling a computer which is already present in Configuration Manager 2007 it sometime obsolete the existing client record specially when reinstalling it using PXE boot. When I wanted to use Direct Membership only in a project instead of using AD-groups for instance for targeting this became a major issue.
I then found this excellent script which merge conflicting records in SCCM it can be found here: http://kristianfthomsen.spaces.live.com/blog/cns!59A30145A64F8A9F!156.entry?wa=wsignin1.0
As the site has been down the script can be downloaded here: https://ccmexec.com/wp-content/uploads/2011/04/merge.vbs.txt
The blog post tells to schedule it as a schedule task, but I love status filter rules, it is amazing what you can do with them, so I created a status filter rule which will trigger the script as soon as a duplicate record is created.
The status filter rule looks like this: 
The only negative with this solution is that the advertisement history for the client is kept after a reinstallation which can be a bit confusing sometimes.
If you want to implement the script as a status filter rule, these are the steps:
- Download the script and place it in a folder on the Primary Site server in this example: “E:\sccmtools”
- Change the site settings to “Manually resolve conflicting records” under the Advanced tab in site properties in the SCCM Console.
- Create a new status filter rule with the following properties as displayed earlier:
Component : SMS_DISCOVERY_DATA_MANAGER
Message ID: 2642 - And on the next page select that it should “Run a Program” : “cscript.exe E:\SCCMtools\merge.vbs”
Then you will not have any obsolete records in your SCCM site anymore.
Fantastic post, cant wait to give this a try 🙂
Can you please provide the merge script. The site that was hosting is no longer available.
Hi,
I will update the post with the script
/Jörgen
Beautiful 😉
Can you clarify what is meant by “The only negative with this solution is that the advertisement history for the client is kept after a reinstallation which can be a bit confusing sometimes.” Does this mean that the imaged computer would not receive advertisments for software that was installed BEFORE it was imaged?
HI,
The client will run all advertisements again no problem, but if you look in the advertisement history you will have all the history left from before you reinstalled the computer. For instance if you run an advertisement for Office 2007 and after reininstallation you install Office 2010 you will have the advertisement status history for Office 2007 still in the reports and database.
/Jörgen
Thanks for clarifying. Knowing this, I can see this script really solves a problem with ConfigMgr 2007 when it comes to imaging known computers. I have seen alot of duplicate/obsolete accounts which prevents advertisement to the new client until the obsolete account is deleted. You can delete the odsolete accounts daily with ConfigMgr but this actually PREVENTS this from occuring (even better) so advertisement happen almost immediately (R3). Nice job and thanks for sharing.
Hopefully this issue imaging known computers is resolved in ConfigMgr 2012. Anyone know?
Are these settings supposed to be configured on the secondary site servers as well? Or just the primary?
Thanks
it is only needed in the primary sites.
/jörgen
Hello. This seems nice. But I do have too edit the .vbs with correct settings for my site?
Hi,
No modifications the vbscript is needed, there is no site specific information in there.
/Jörgen
I have set this script up per the instructions and it does not seem to be working. I have duplicate machine listings. The machines have different versions of the client. Does this make any difference. I hope to get this to work as this is exactly what I need.
Hi,
Kathy, are you sure the objects in your environment are obsoleted? otherwise they will not be merged..
/jörgen
Yes they are obsolete. We are getting ready to deploy Windows 7 and applications and the once Windows 7 creates a new client then the one that is in the application collection is obsolete and the package will not deploy. There is no message id 2642 as is suggested in the status filter I think that may be my problem. If it does not generate that ID then it will not run the script, correct?
Hi,
Again Kathy, that is correct the script is triggered by the status message, do you have any records in the “Conflicting Records” node in the SCCM console?
/Jörgen
Yes I did this morning and the other packages that I tried to deploy showed no status since yesterday.
It’s not working for me either. I have had the script in play for about a month now and the conflicting records are showing up, they are just not automatically resolving themselves via the script. I am having to manually Merge them. Any insight. One thing i am a bit confused on…how long does it take for an obsolete record to actually be marked obsolete?
Further update to this. I checked in event viewer and filtered 2642 event ids for the SMS_DISCOVERY_DATA_MANAGER component and found nothing…any idea as to why these would not be generated?
I can manually run the script and it works just not through the status filter rule.
You must set Site properties\Advanced\”Manually resolve conflicting records” to get the event ID 2642 for the SMS_DISCOVERY_DATA_MANAGER component.
Hi, this looks really promising, but my problem records are technically not Obsolete, they have a blank in that column and no SMSID at all, they dont even have the same site code, but they do have the same hostnames and obvious causes me grief for the same reasons as an Obsoletely marked record would.
Will the script merge my records even if the Obsolete column is blank for the problem records?
Thanks
Hi,
Same deal with me, I can manually run the script and it works just not through the status filter rule.
I can see the 2642 event in status filter under SMS_DISCOVERY_DATA_MANAGER. Do I need to restart a service?
Issue fixed, by using the full path: C:\Windows\SysWOW64\cscript.exe D:\SCCM\Scripts\merge.vbs
I am still not able to find any 2642 events although i am getting conflicting records…im so confused, i have changed the pathing according to andy and hopefully that will fix it
Also, what is the difference between the script above and the one provided here:
http://blogs.technet.com/b/configmgrteam/archive/2011/08/17/known-issue-and-workaround-duplicate-records-when-you-use-unknown-computer-support-with-active-directory-delta-discovery.aspx
Okay i see the event id 2642 and i have setup the status filter rule…however the script is not running, i am using the path:
C:\Windows\SysWOW64\cscript.exe E:\Source\Scripts\merge.vbs
Any additional suggestions?
Hi
I setup the filtered rule as explained, and it is working like a charm!!
running SCCM 2007 R3 and scriptpath is C:\Windows\SysWOW64\cscript.exe E:\Source\Scripts\merge.vbs
Thanks!,
Hello,
i have clients in some dynamic collections (AD) and also in static collections. Is the client after the merge in all related collections?
Regards Eric
Hi,
Yes the client will still be member of exactly the same collections as the old SCCM object is kept.
/Jörgen
Dim swbemLocator
Dim swbemServices
Main()
Sub Main()
Dim oProviderLocation
Dim oLocation
Dim oReg
Dim oPendingRegs
Set swbemLocator = CreateObject(“WbemScripting.SWbemLocator”)
swbemLocator.Security_.AuthenticationLevel = 6 ‘Packet Privacy.
Set swbemServices = swbemLocator.ConnectServer(“.”, “root\SMS”)
Set oProviderLocation = swbemServices.InstancesOf(“SMS_ProviderLocation”)
For Each oLocation In oProviderLocation
If oLocation.ProviderForLocalSite = True Then
Set swbemServices = swbemLocator.ConnectServer(oLocation.Machine, “root\sms\site_” + oLocation.SiteCode)
End If
Next
Set oPendingRegs = swbemServices.ExecQuery(“SELECT * FROM SMS_PendingRegistrationRecord”)
For Each oReg In oPendingRegs
Resolve 1, oReg.SMSID
Next
End Sub
Sub Resolve(action, SMSID)
Dim InParams
Set InParams = swbemServices.Get(“SMS_PendingRegistrationRecord”).Methods_(“ResolvePendingRegistrationRecord”).InParameters.SpawnInstance_
InParams.Action = action
InParams.SMSID = SMSID
swbemServices.ExecMethod “SMS_PendingRegistrationRecord”,”ResolvePendingRegistrationRecord”, InParams
End Sub
Jörgen
Could the script not be amended to clear the advertisment history to prevent the shortcoming you mention?
Jorgen this is very nice something I wish I wouldve found 2 years ago, anyways do you know if this is used in the same fashion on 2012 we are in the process of migrating and Im not yet very familiar with the way 2012 handles this.
Hello Jorgen, question for you regarding this process. We have 2 07 primaries; 1 is parent (for reporting) and the other is child (where all operations occur). I am assuming this would need to be setup on the parent but curious if it needs to be on both or just one. Please let me know when you have a chance. Thanks….
work in SCCM 2012? I have the same problem.