You may have duplicate IDs in your environment if you "clone" workstations that have the Systems Management Server client installed or if you have remnants from a previous Systems Management Server client installation (such as the Sms.ini or Smscfg.ini file).
Duplicate IDs can cause behaviors such as high central processing unit (CPU) usage, incorrect inventory reporting, advertisements run by the wrong clients, and other unexpected events. To help avoid these behaviors, it is important to clean up duplicate IDs as soon as possible if you encounter them.
You can also run the following query in SQL query analyzer against the SMS site database:
After you find the duplicates, allocate a new ID to these workstations. There are two methods for allocating a new ID to a client.
Manual methodTo manually clean up a client, run the 20clicln.bat file to uninstall the Systems Management Server client. When this process is finished, delete any instance of the Sms.ini or Smscfg.ini file on the workstation. After this is complete, reinstall the client by using normal installation methods. A new ID will be allocated to the client. BR/>
The version of 20CliCln.bat that can be downloaded as part of the SP2 support tools can be run with a command line switch of /scrub which removes the Smscfg.ini file and enable a creation of a new GUID. It does not remove the Sms.ini left over from a SMS 1.2 client.
Software distribution methodIf you have numerous computers that need a new Systems Management Server ID, you can use the Microsoft BackOffice Resource Kit 4.5 Newuid.exe utility. Create a package by using the utility with the Newuid.exe /s command, which causes the utility to run silently. You need to create a collection that contains all of the workstations that have a duplicate ID. Use a query based on the following sample query:
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
When you run Newuid.exe, use the Newuid.exe /s /allocate command enables the clients to get a new ID and retain client functionality. The /s switch causes the installation to run silently.
Note When the /allocate switch is used, Newuid.exe attempts to run Smsboot1.exe from a logon point. Access to a logon point requires that a user be logged on. If no user is logged on, the GUID that exists is deleted, but a new GUID is not allocated until Smsls.bat or Smsman.exe is executed.
Note You do not receive confirmation that the clients have successfully run the program if you do not use the /allocate switch. After Newuid.exe has been run without the /allocate switch, all client communication with the client access point (CAP) stops until the client either runs Smsls.bat or Smsman.exe or has been reinstalled by using the Microsoft Windows NT Remote Client installation. Client functionality does not return and the new ID is not allocated until the client has used one of these installation methods.
After you have cleaned up the duplicate IDs, purge the inventory history in your database. Use the Delete Aged Inventory History task under Tasks under Database Maintenance in the Systems Management Server console to delete all history older than one day. You can set this value back to its previous value after you have all of your client inventory back and have you have verified that there are no more duplicates in your environment.
By changing the settings for the Database Maintenance Tasks, all data in your database older than one day may be removed. This is fine in many situations, however, if you only have a small percentage of your inventory which is duplicated, this may not be appropriate.
In such a case, use the white paper, Managing Duplicate Microsoft Systems Management Server Unique Identifiers, which may provide a better solution.Note This paper discusses the process of only removing the history information for the duplicate computers, not the entire database.
Article ID: 254735 - Last Review: Jun 19, 2014 - Revision: 1