As you may know, duplicate SMS Ids (GUIDs) can cause untold problems in an SMS implementation. These problems can be difficult to troubleshoot and may not appear to be related the duplicate SMS Id issue. In this article I'll give you a recipe for ridding your enterprise of this spoiler.
Actually, I got this information for a Microsoft Support Engineer but because it was so helpful to me I thought I'd pass it on.
The idea is to build a collection based on a query that will pull all duplicate SMS Resource Id and advertise a package that will run NewUid.exe /allocate from the BORK.
The query is as follows:
select distinct r.Name, r.OperatingSystemNameandVersion,
r.ResourceDomainORWorkgroup, r.LastLogonUserDomain, r.LastLogonUserName,
r.SMSUniqueIdentifier, r.ResourceId from SMS_R_System as r,
SMS_GH_System_SYSTEM as h, SMS_G_System_SYSTEM as g where g.ResourceID =
h.ResourceID and g.Name <> h.Name and r.ResourceID = g.ResourceID
Note that this is different than the query listed in the SMS Administrator's Guide and will return different information. The query in the Admin Guide is quite useful though for identifying PCs with the problem.
NOTE: The query may not seem like it is returning all of the correct machines. This is correct, it is returning a unique list of duplicate ID's which is what we want to base our distribution on. Example: If you have 50 machines ghosted with one ID and another 20 using a different ID and the rest of your machines are unique. The query will only return 2 machines. IGNORE the machine names returned by the query/collection. The client's will look for their GUID(even though they are all sharing it) on the CAP.
1. Create a new collection "Delete Duplicate Systems." Create a new membership rule and cut and paste the query above using the "Edit Query Statement" dialog. Be careful to remove any carriage returns from the query text. If they are not completely removed the membership rule may be removed because of incorrect syntax. See Q234262 for a description of this problem.
2. Create a package and advertisement, targeted at the collection you just created, to run NEWUID.EXE. For specific command line options see the BORK 4.5. A recommended command line for the program would be NEWUID.EXE /allocate which will cause the allocate a new GUID to the client without reinstalling the client software.
3. When you have verified that all the clients have run the advertisement, run the "Delete Aged Inventory History" task under 'database maintenance\tasks' Set this to delete anything older than 1 day. After this has run return it to the previous value. We need to delete history otherwise the query will report 'false' duplicates.
Essentially what this query is doing is comparing the current resource ID of a system to the resource ID in inventory history and returning all systems where the name in history is not equal to the name in the current inventory. So if history is not deleted and the query is run even after changing the GUIDs on the client, the query will show 'false' duplicates. This is because there is still a machine in history (sms_gh_system_system wbem class) with, let's say, a resource ID of 555 and there is also a machine in current inventory sms_g_system_system wbem class)with a resource ID of 555. However the name in history is different from the name in current inventory because these machines are\were duplicates. Even after cleaning the GUID on the actual machine the names will still be different in history. Once you delete history, the query won't return any 'false' duplicates, but it will also mean that you won't be able to find any of the legitimate duplicates once you've deleted history. We'll have to wait for inventory to run again to get history back, then you can run the query again. So, the duplicate GUID cleanup will be a continuing process until all have been removed from your environment