GuidesAutomating the Cleanup of Duplicate SMS GUIDS

Automating the Cleanup of Duplicate SMS GUIDS

ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.





by Dana Daugherty

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.  

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, Dana Daugherty gives you a recipe for ridding your
enterpris 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 maintenancetasks’ 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 arewere 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

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends & analysis

Latest Posts

Related Stories