Do you find the Support WebCast transcripts helpful?
Let us know!

Note: This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Heidi Moeller: Hello, and welcome to the Support WebCast Program at Microsoft. We'd like to thank all of you for joining us today. Our topic will be "Handling Duplicate Systems in SMS 2.0," and our presenter will be Bruce Jones. I'm Heidi Moeller, and I'll be your host for today's session.

We'll start this session with Bruce's presentation, and follow up that up with a question-and-answer period when the presentation is finished.

I'd like to take just a brief moment to introduce Bruce. Bruce Jones joined Microsoft five years ago as a support professional in Product Support Services. He's been supporting Systems Management Server, beginning with SMS version 1.1, and is currently with SMS Alliance Support. During this time, Bruce has written a variety of SMS-related white papers, and has been involved with resolving the duplicate ID problem in SMS versions 1.x and 2.0. Thank you so much for joining us today, Bruce. Let's get started.

Bruce Jones: Thank you Heidi, and with that introduction, I'll just jump right into the presentation. We're covering handling duplicate systems in SMS 2.0. I want to ask you: How do you handle duplicate GUIDs in SMS 2.0 right now? Are you monitoring your databases for duplicates? Are you aware of the problems that they may be causing in your site? Do you have an action plan in place to remove them from your clients and from your database?

Well, if you were an SMS admin in the days of SMS 1.2, you probably were pretty aware of this problem with duplicate SMSIDs, and you probably were aware of the tools that you could use to deal with them. What we're going to do today is look at how to resolve this same, analogous problem in SMS 2.0. So, let's move to the slide titled "Overview" (slide 2).

First, regarding the handling duplicate systems in SMS 2.0 white paper, I'm going to ask you to please download this white paper. It's in the Supplemental reading section on the Support WebCast site (http://support.microsoft.com/servicedesks/webcasts/wc081700/New_UI_Idwebcast.doc). This white paper contains many details that I haven't put on the slides, including some new queries, some batch files, and some examples, and you're definitely going to need this information. This white paper will have additional information added to it later, so please keep an eye out for it; it also will be on the http://www.microsoft.com/ Web site.

Topics that we are going to discuss today include what is a duplicate GUID. We're going to talk about how GUIDs are created, how duplicates come up about, and how we can compare these duplicates to what you might be familiar with in SMS 1.2. Next we're going to talk about what kind of problems they cause. We'll talk about high processor utilization, memory utilization, corrupt inventory, advertisements that may go to the wrong machines, and Windows NT^® clients that may fail to install. Then we're going to look at how to clean up duplicate GUIDs on the client. We'll discuss a resource utility called Newuid.exe, and we'll talk about some various methods to clean up these duplicate GUIDs off your clients.

Next, how do we clean duplicate GUIDs out of the database? We have some brand new automated procedures for you that are less painful than what you may have seen in the Microsoft Systems Management Server 2.0 Administrator's Guide. We'll give you some brand new WQL and SQL queries that will allow you to identify and clean a database in an automated way. Then we're going to pull it all together into a sample action plan that you can modify and use in your own environment. When we're done with that, we'll of course have the Q&A.

So, I would really like for you to remember three things from this session. First off, duplicate GUIDs in SMS 2.0 cause some very fundamental problems, and they must be addressed. The second thing is you must clean all affected clients and images, perhaps with the resource kit utility Newuid.exe. Third, you must clean duplicate GUIDs out of the database. And again, for your convenience, the queries and the instructions that I'm going to be referring to are available as supplemental reading with the WebCast, and will be available shortly on http://www.microsoft.com as a white paper.

Let's move on to "What Is a GUID?" (slide 3). Do you know what a GUID is? A GUID is a globally unique identifier that uniquely identifies clients in a database. It's created on the clients during client installation or during Logon Discovery. It is not created during Network Discovery. In SMS 1.2, we created a unique SMSID by going up to a file on our SMS logon server, looking in a UID file, and incrementing that number to get our unique number.

In SMS 2.0, we did something different. We created a unique GUID with an algorithm that takes the time stamp and the output of this function, called UUID, and merge them to create a statistically unique number. Some of you may have looked at the GUID and noticed that it contains the MAC address. This is not always the case, and we can't rely on that, if you're trying to use that information. There is also another special case as to how a GUID is created. When you upgrade an SMS 1.2 site to SMS 2.0, SMS 2.0 will reuse the SMS 1.2 SMSID of the machine.

Where is the GUID stored? It's stored in several places. On the client, it is stored in the registry, and you can see the path on the slide. The second place it's stored is on the client itself, in a file called Smsuid.dat, and in the file called Smsconfig.ini. In the database, the GUID is stored in three tables. I've listed two of them on the slides, and there is a third one. The System_DISC table, which contains all of your discovery data, the System_DATA table, which contains your basic hardware inventory data, and not on your slide is the System_HIST table (you can probably guess what's stored there — history).

Now that we know what a GUID is and where it's stored, let's move on to the next slide (slide 4), "What Is a Duplicate GUID?" A duplicate GUID is where different machines have the same GUID. If you were familiar with SMSIDDUP, and the duplicate SMSIDs in SMS 1.2, this is the exact same idea. In SMS 2.0, the duplicate GUID is compared to an SMS 1.2 duplicate SMSID. This is different than the duplicates you might remember from Dbclean in SMS 1.2.

Remember a time in the SMS 1.2 days when you went back and you deleted all your Sms.ini files, and then you had a bunch of duplicates showing up in Dbclean? Someone had to spend hours and hours in that utility merging all those records. Well, duplicate GUIDs are not like that. That feature is automated in SMS 2.0. Duplicate GUIDs are not one machine that has been reinstalled, and therefore has multiple GUIDs. They are not one machine whose name has been changed, but has kept the same GUID. It can be confusing, so I'll restate the definition: A duplicate GUID means different machines with the same GUID.

So, what causes duplicate GUIDs? Let's move on to the next slide, "Causes of Duplicate GUIDs" (slide 5). I'm going to compare them to the causes of SMSIDs in the SMS 1.2 days to be helpful. SMS 1.2 duplicate SMSIDs were usually caused by imaging or copying the Sms.ini from one machine to many machines. In other words, somebody grabbed an image of a machine on your network, which had an Sms.ini file on it, and they used it as a master image, and then created 30, 40, or 50 other machines from that master image. Because all those machines had an Sms.ini on it, all those machines had the same SMSID. The other way this happened in SMS 1.2 was by resetting the UID file on the logon servers — setting the counter back down so it would give out the same range of SMSIDs over again. Now, if you remember, in SMS 2.0 we no longer use that system for allocating GUIDs.

One thing that often creates duplicate SMSIDs in SMS 1.2 days was that somebody would deinstall a site server, and then reinstall it, and not deinstall the clients, or not remove the Sms.ini — and we would give out the same SMSID again, from the counter.

Let's move forward to SMS 2.0. What are duplicate GUIDs caused by? The first thing they can be caused by is an SMS 1.2 site that has duplicate SMSIDs. Because SMS 2.0 uses the SMSID as its GUID, if you have duplicates in the SMS 1.2 site, those are going to carry forward into the SMS 2.0 site. The second thing that causes duplicate GUIDs in SMS 2.0 is imaging, or creating master images of a machine that already has a GUID.

There is a very rare case that's kind of interesting: using a repackaging technique during GUID creation. If you're running something like the SMS Installer, or Win Installer, or some other product that repackages a software application, during that repackaging process, the GUID is created. Then that package will pick up the creation of the GUID, and when that package is executed on all your machines, it will create that same GUID everywhere the package is run. This is very rare, but it has happened. The biggest offender by far has been, and is now, imaging. Even in companies where imaging is not supposed to be allowed, it happens anyway, and you, as the SMS administrator, can end up with a variety of problems. Which brings us to the next slide (slide 6), "Commonly Reported Problems."

The first one is kind of interesting. The SMS Administrator console will only display the last discovered client of those clients that all share a GUID. Now, if many different computers have the same GUID, they start replacing each other in collections as each of their discovery records is processed. Let me give you an example: if a computer A has been discovered most recently, it will appear in your All Systems collection. Then say computer B sends a discovery data record up, and it has the same GUID as computer A. When this discovery record is processed, computer A will disappear from the All Systems collection and it will be replaced by computer B, and you might be scratching your head wondering what happened.

The second thing that can happen is with inventory records from computers with the same GUIDs. When they're processed, the inventory properties of the computers can be merged. In other words, you may see hardware information from machine B and hardware information from machine A all showing up under machine B. The next thing that can happen is that the SMS Executive, particularly the Dataloader component, can monopolize the CPU, or use a lot of memory. When you are querying on one machine that has a lot of records associated with it, because the records are all associated by a duplicated GUID, it returns a huge result set.

In one case, we were working on a problem like this, and the Dataloader component quickly consumed about 600 MB of memory soon after the Dataloader started processing MIFs. In another case, all of the available RAM was quickly taken on the machine. It can be determined very quickly if the Dataloader is the child thread consuming the RAM or causing high CPU utilization by using the SMS Service Manager. Go in and stop the Dataloader component when the condition begins, and if stopping the Dataloader causes the memory usage to go down or the CPU utilization to return to normal, duplicate GUIDs may be the cause.

Another thing that can happen is that Windows NT Remote Client Installation will not install the SMS client. When Windows NT Remote Client Installation is enabled, what happens is the machine is discovered somehow, and Data Discovery Manager will check the client property of the computer that's associated with the GUID and the particular data discovery record that it's processing. If that client property in the database is "yes," Data Discovery Manager won't create the client configuration request (CCR) for that computer, because it thinks it's already a client. Therefore, if the GUID is a duplicate, and you have a previous computer with the same GUID that successfully installed the SMS client, the client property in the database is "yes." All subsequently discovered computers that have that GUID will not have CCRs created for them. And so, of course, they will not be installed.

Another thing that can happen is excessive inventory resynchronizations. A hardware inventory resynch happens when any MIF file comes up, and Dataloader tries to update a row that doesn't exist in the SMS site database. But that case is common when two or more computers have the same GUID, because Dataloader attempts to update the database with inventory information from an entirely different computer, generating a lot of resynchs.

Another problem that can happen that's not listed on your slide is advertisements can go to the wrong machine. In SMS 2.0, a lookup file is used to target advertisements. The lookup file targets given computers using that GUID. So if you have many different computers that have the same GUID, then they can run advertisements that were never intended for them.

Now after seeing these problems, you might be tempted, when something comes up, to blame everything on duplicate GUIDs. We need to ask ourselves, "Are there any problems that might look like duplicate GUIDs, but aren't?"

Let's look at the slide titled "Similar Problems Not caused by duplicate GUIDs." One problem that we have seen very rarely is the same machine appears multiple times in the collection. The only thing that I personally have ever seen cause this has been an attempt to restore an SMS site server without following the recommended backup and recovery procedures. What happened in that case was an admin tried to back up a database while leaving the SMS services running, and as a result, it caused some corruption in the database. This same machine name appeared multiple times in a collection.

The second thing that can happen that is not attributable to duplicate GUIDs is that the discovery properties of one machine can get mixed up with those of another. In other words, when you right-click on a machine and the discovery properties pop up, you might notice that the IP address, NetBIOS name, or something like that belongs to a different computer, and not the computer that you thought.

I'll give you a hint as to what causes this. It only happens with Network Discovery. Now, how do you suppose Network Discovery might get the wrong data for a machine? Well, what if the router ARP cache had the wrong data in it? Network Discovery would simply report what the router told it. This can also happen with shared docking stations. I'll just refer you to the KB articles listed on the slides (Q259249 and Q244335). The point is this: You should watch for those problems definitely caused by duplicate GUIDs, and you should also be aware that there are other things, like a corrupted router ARP cache, that can cause problems that appear to be similar.

Now this brings us to a very important point on the next slide (slide 8). Imaging SMS client GUIDs is not supported. The problems that I've listed are the reasons duplicate GUIDs are not supported. Imaging GUIDs, or imaging SMSIDs, has never been supported. If you read in your admin guide, on page 145, "Like SMS 1.2, SMS 2.0 does not support SMS client cloning, because each client must have a unique ID, which is assigned during client installation."

Now listen to the whole statement, which is not on the slide. I'll read it again. Can you figure out what was left out regarding when unique IDs are assigned to a client here? "Like SMS 1.2, SMS 2.0 does not support SMS client cloning, because each client must have a unique ID, which is assigned during client installation." So, you might have figured it out. They are also assigned during Logon Discovery. However, the point is this: imaging is not supported, duplicate GUIDs are not supported. However, you are going to run into them, and we need to give you a way to handle them when they do occur. This is because duplicate GUIDs are introduced into an SMS site, even though unintentionally, and unknowingly, and there needs to be a way to handle them because of the problems they cause. Therefore, the white paper and this presentation provide you with a variety of methods to remove the duplicate GUIDs from both your clients and the SMS site database.

These methods should result in a supported configuration in almost all cases. However, there are going to be some rare and extreme cases where it might be necessary to have you completely uninstall your clients and remove all your inventory, or even reinstall the site to resolve the problem. I've never seen a case that extreme, but we do need to make that disclaimer. So, let's get started with cleaning up the client, which is on our next slide (slide 9).

In this session we're going to limit our discussion to SMS 2.0. I do want to tell you that, for information on how to remove duplicate SMSIDs from a SMS 1.2 site, there are some Knowledge Base articles available for you, and those are included in the supplemental reading. There is also a document on the SMS 2.0 Service Pack 2 CD called 12dupcln.doc that you can refer to.

When we get started removing duplicate GUIDs from your site, we need to plan carefully. That's because the GUID is stored both on the client and in the site database, and it's the basis on which advertisements are targeted, so you have to coordinate how and when you're going to remove the duplicate GUID from each of those two locations. Let me give you an example. If you elect to remove the GUIDs from the clients using some sort of recurring software distribution package, you don't want to remove the duplicates from the site database before your advertisement runs. This is because the target for that advertisement is a collection based on those same duplicate GUIDs.

You should remove the duplicate GUIDs from the clients first. After the duplicates are completely removed from the clients, and all the clients now have unique IDs, then you can address the database. There is that case where the site server begins to be severely affected. If you have too many duplicate GUIDs, you might have memory utilization problems, you might find a CPU utilization problem, and you might have to address the site database first.

So, how do we clean up duplicate GUIDs on the SMS clients? I'm going to introduce you to two methods to clean a client's GUID. Then we're going to talk about how to identify which clients are affected and need to have their GUID changed, and then I'm going to give you three methods to deliver a new UID to clean up the duplicate GUID on those clients: logon scripts, advertisements, and manually.

Let's look at the manual method to clean up the duplicate GUID on an SMS client. First off, not on your slide, is that, as of SP2, there is a new /scrub option for 20clicln.bat that does remove the GUID in most cases, and I wanted to refer you to that first. If you use the older version of 20clicln.bat, however, it will not clean up the GUID, and it will retain the old one. So, you want to make sure if you do deinstall the client, or run 20clicln.bat, that you remove the GUID from those three locations that we mentioned earlier.

To automate cleaning the GUID, I would strongly encourage you to consider using the Newuid.exe utility from the Microsoft BackOffice^® 4.5 Resource Kit. With that utility, there are a couple switches that you need to be aware of that are extremely important: the /s and /allocate switches. The /s switch simply makes it silent. But the /allocate switch is the one that I want to talk to you about for a minute. If you run Newuid.exe without using that /allocate switch, you can cut off all client communication with the CAP, and it will stop until you run Smsls.bat, or Smsman again, or until you reinstall, perhaps using the Windows NT Remote Client installation. That client functionality is not going to return, and the new ID is not allocated until the client runs one of the methods I just mentioned.

The other thing I want to mention about Newuid.exe is that it is customizable. The .ipf file or the SMS Installer script is also contained in the Microsoft BackOffice 4.5 Resource Kit. I am aware of a couple different versions that customers have made to do some very unique and helpful things. One customer has modified it to force an inventory update immediately after a change in the GUID, and that allows the database to be updated sooner.

Let's look at the next slide (slide 10), on how to identify which specific clients you need to clean. Now that we know how to clean them, either manually or through Newuid.exe, let's look at how to identify which clients need to be cleaned. First off, I want to let you know that, because that GUID is by design, the very unique identifier for all SMS clients, any method that we come up with to identify which clients are duplicates is going to be less than perfect. So how do we choose to identify these machines that have duplicate GUIDs?

What we decided to do, after looking at a number of options, is look for machine name differences. What we do is compare the machine names in the three tables in the database that we referred to earlier. When we find the same resource, but with different names, we know that this could be a duplicate GUID. The other thing, though, is it also could be a legitimate machine name change; again, as I said, no solution is perfect. The question for you is how do you tell the difference? You run this query, and you want to know which machines are legitimate machine name changes and which might be the result of an imaging process. How do you tell the difference?

In the white paper, I give you two queries that look for these machine name changes. One is a Transact SQL query that runs in any SQL tool. The other is a WQL query, which you can use in the SMS Admin console to create a query. Each of those generates reports telling you which machine has changed its name between those three tables. Now, how can you tell which are likely to be just machine name changes, and which are the result of somebody taking an image and creating multiple machines with the same GUID?

Well, if you said to yourself, "Look for a machine that has changed its name a lot, perhaps 30 times," that's absolutely the right answer. When you run this query and you find a machine or 30 machines that all have the same GUID, when you find evidence like that, you know that there is likely a master image out there, somewhere on your network, that you need to track down. When you track it down, clean it using the Newuid.exe. Well, now that we have a way to identify which clients have duplicate GUIDs, using these two queries, we probably are going to decide to use the Newuid.exe to clean them up.

So, let's look at the next slide (slide 11), "Three Ways to Deliver Newuid.exe." We do this with logon scripts, with advertisements, and manually. Why would you choose the logon script method? Let's say a large percentage of your clients have duplicate GUIDs, like 20 percent or 30 percent. It might simply be easier to change the GUID of all your clients, using logon scripts and Newuid.exe, rather than trying to chase down which ones do have duplicates and which ones don't. You can use the logon script method in such a way that Newuid.exe is run only one time on all existing clients, and then on every new client that logs on afterward. This is done with a tag file, and I have explained that in the white paper.

The other thing in the white paper that is interesting is that we copy Newuid.exe down locally to the client so that you don't have to load that over the network at every logon. So, you may choose the logon script method. You may choose the advertisement method. You might choose the advertisement method to run Newuid.exe with that /s and /allocate option, as a software distribution, just periodically, or through some collection rule that targets specific client computers. This method will eventually run on most of your computers over time. But because duplicate GUIDs can cause mistargeted software distributions, and because we might have problems with where they are in the table — some might be in the history table, some might be in the data table, some might be in the discovery table — you might need to run those advertisements several times before all the computers run the advertisement.

This method is helpful in removing duplicate GUIDs from computers — such as servers, for example — that never run a logon script.

What do you do for machines that never run a logon script, and for which you do not want to run an advertisement? Or perhaps you don't have software distribution enabled in the particular site that you are dealing with. For client computers that you cannot run Newuid.exe, or a logon script, or through an advertisement, you have to change the GUID manually. You can use the database queries that are in the white paper to identify those computers, and then, of course, you can run Newuid with that /s /allocate option on each reported computer. There is also a method explained in the white paper on how to perhaps do that remotely. You have to be a little careful there.

So, once we have the clients cleaned up, then we can go ahead with the database. Let's move on to the next slide (slide 12), "Four Methods to Clean the Database."

Again, I just want to re-emphasize that, if you're using software distribution, or if you're relying on reports on a daily basis, it is important to clean up the clients first before you remove the information from the database. Let's look at four methods to clean up the database. There is a Knowledge Base article, Q254735: "How to Clean Up Duplicate Computer IDs," that is going to be changed, because the information that I'm presenting to you today is an improvement over, and is to be considered a replacement for that information. That also applies to the methods that are published in the Microsoft Systems Management Server 2.0 Administrator's Guide — and the methods in that guide are to be considered replaced by this presentation. Also, you might have some difficulty in getting that method to work thoroughly on your site.

There are three alternate methods that I'm giving you today to remove duplicate GUIDs from your SMS site database. These methods are going to clean your database much more thoroughly than previous methods, and they don't require you to clean your inventory history. If you've ever run into this situation before, and you've called me or somebody else, and they've walked you through the steps to clean up your site, what we've had you do in the past is remove all your history, down to a single day. One of the benefits of the methods that we're going to present to you today is that you no longer have to do that, and you retain your inventory history.

I also want to explain that I'm not going to go into deep detail with these methods. Some of these queries are long. The WQL query, for example, has six separate queries that you need to apply, and I don't want to go line-by-line through those queries, other than just to simply mention them, and to refer you to the white paper. The three methods that we now have to clean up your database are a WQL method, a direct membership rule method, and a Transact SQL method.

The WQL method is basically creating a collection based on six separate queries. These queries compare those three tables, and then when you right-click on that collection and run delete special, it will remove the duplicates from your database. When you create that collection, you may notice that the machine count is odd, or not what you would expect, as compared to some of the other methods. That's normal, and that's okay. That's why we gave you this separate query for identifying clients apart from this method, in the white paper. So the first method is a WQL method that can be a delete special against a collection based on six queries.

There is a second method that you can use. Let's say that you just have one or two GUIDs that are affected. You run your query, as mentioned earlier, to identify clients, and you discover that you have one GUID that has been multiplied 50 times out on your network and is creating a problem for you. Rather than going through all the trouble in some of the other methods, it may be easier for you to create a direct membership rule collection based on that single GUID, and then run a delete special against it. The details again are in the white paper.

These first two methods have some sort of manual steps involved. You have to right-click on the collection. You have to run delete special and so on to get them to work. I'm excited about the third solution, the Transact SQL method, because you can automate it. You can be hands off about it and let it run. We created a Transact SQL script that you can run as an automated SQL Server™ command. I've given you specific steps in the white paper as to how to do that. You can automate it, have it run once a week, have it run every two weeks, or so on, and simply watch for the exception. Watch for the reports and have somebody monitor the output.

Now, having said that there are three methods, and there are a variety of ways to handle this problem, I want you to be aware of some things that you should be careful of while you are implementing this plan (slide 13). The first consideration is to remember that not all machines run a logon script. Therefore, you need to be very careful that you include another method, such as advertisements, or the manual method, to eliminate all duplicates from your environment.

The second thing I would like you to consider is that those deletes are, again, based on machine name changes. So if you choose to delete duplicates in the manners that I have given you, you are going to delete the inventory information from the machines that have legitimately had their machine name changed. If that's important to you, then it's important that you use a method that will not remove the history for these machines.

The third thing that I would like you to remember or consider is that you must keep the duplicates in the database if the software distribution method is used. If you start removing the duplicates from the database, we'll lose our targeting information and they won't be cleaned on the client. This is an important consideration when, an SMS site server is in trouble. Say it has high memory utilization, or the CPU is pegged at 100 percent, you may need to realize that cleaning the duplicates out, in that instance, is going to cause you targeting problems in the future, and plan on that. Again, remember that with these new solutions, you no longer have to delete history, and the Transact SQL query can be automated. Now, in light of these considerations, what we can do is take all this information and put it together into a sample action plan, which is on the next slide (slide 14).

For example, you can run daily Transact SQL reports to identify and clean new images. The query I gave you in the first part of the white paper — the Transact SQL query — run that daily, and have somebody review it, perhaps first thing in the morning, and look to see if are there 30, 40, or 50 machines that all share the same GUID. If we find that's the case, let's immediately go find that master image, stop that process, and go clean it up.

The second thing that we might do daily is run Newuid.exe in the logon script. With the logic that we've given you in the logon script, you only run it if there's a problem with cloning in your environment. The third thing that you might do, if you've run two things daily, is run Newuid.exe as an advertisement weekly, again with the same kind of logic, or against those queries where they only remove machines that have duplicate GUIDs.

You might choose to run the Transact SQL script that actually does the deletion of the duplicates every two weeks, or you might have an action item for your help desk that should a machine have high CPU utilization, or have memory utilization problems, that they contact you immediately. And you can consider running that Transact SQL script on the machine to relieve the high utilization.

The other thing that you might do is create an exception where your help desk understands that when a machine has this problem, or a mistargeted software distribution, or somebody's not logging on and logging off — they're just locking up their machine — you might have a help desk handle those exceptions manually by running Newuid /s /allocate. Whatever plan that you eventually decide upon, I really, really would like you to test it in your lab first.

Each environment has its own security configuration. You have your own unique third-party applications running. You have some customization that you've created that works a little differently than what we've tested somewhere else. So what works in one case may cause problems in another. Please configure your lab to be as close to your production environment as possible, including your security model, any third-party applications that you have running, any backup and restore procedures, virus scanners, and so on. Then test whatever solution you come up with very, very thoroughly. I want to point out that, in the white paper, there is a much more complete sample action plan than what is here, it has some additional ideas, so I invite you to look at that.

So, what will you want to remember from this session? There are three things. One is that duplicate GUIDs can cause some very severe fundamental problems in SMS sites and they must be addressed. You cannot just ignore them, because they will cause problems. The second thing that I would like you to remember is that you must clean all affected clients and images, perhaps with Newuid.exe. The third thing is that you must clean duplicate GUIDs out of your database. You must take some proactive effort on your part to go in and identify them and clean them out. Now again, for your convenience, all the queries, the details, and the instructions are available on that supplemental reading that comes with the WebCast (http://support.microsoft.com/servicedesks/webcasts/wc081700/New_UI_Idwebcast.doc), and they will be available shortly on http://www.microsoft.com/ as a white paper. You'll need to download the material to implement these strategies as outlined in this WebCast.

Some of you may have some questions, so I'm going to move this on to the question-and-answer portion of the WebCast, and ask Heidi to take it from here.

Heidi: Excellent, thank you so much. It is time to move on to the Q&A portion of this Support WebCast.

We have had several questions submitted today. I also want to welcome Wally Mead. Many of you know him from past SMS WebCasts that he has delivered for us. He is joining Bruce for the Q&A session.

Let's get started with the first question: In plain English, the Transact SQL query defined SMS 2.0 duplicate seems to state: find all records in System_DATA table and the System_HIST table that have the same machine ID, but different computer names. Could you explain why the System_HIST table is useful in finding SMS duplicates for me? Again, this stresses in plain English.

Bruce: Okay. Think of the three tables I have given you — the System_DISC table, the System_DATA table, and the System_HIST table as a waterfall — as you drop something in at the top, it eventually flows down into each lower tier. When the machine name changes, or when a duplicate GUID comes in and it hits the first level of the tier, it causes other information to flow down, and that information will begin to get out of synch as each record comes in. So, the information will be different in the _HIST table, than it will in the _DATA table, than it will in the _DISCOVERY table. By comparing each of those three tables to each other, we can find where it's out of synch, where the machine name has changed, and we can identify that here is the machine that is reporting different information than it did before.

If you'll look at those tables, you'll notice that there is a machine ID or a resource ID that stays the same between the three tables, and we use that as a primary key, or as a key to look for the machine name changes. So again, the data flows down through the three tables, and it changes with each duplicate that comes forward. And it's those changes between the three tables that enable us to identify a machine that may have been imaged where the GUID has been imaged.

Heidi: Okay, excellent. Moving on to the next question: What are the switches that we can use with the 20Clicln.bat, now that SP2 has been installed? You mentioned the /scrub; are there others?

Bruce: I checked, and there are no other options than the /scrub option for 20clicnl.bat. The /scrub is the only one that is available.

Wally Mead: Yes, there aren't any others that I was aware of, either; /scrub was just added for SP2, and that is the only other one that I'm aware of.

Heidi: Okay, excellent. Before we move on to the next question, I do want to encourage all of you to submit any feedback you have for us, if you have any comments on topics you would like to see in the future, any general comments about this session, or general comments about the Support WebCast Program. You can use the feedback@microsoft.com alias. Be sure to include "Support WebCast" in the subject line.

The next question: Besides the fact that Newuid.exe is located in the SMS Resource Kit, is Newuid.exe fully supported?

Bruce: Newuid.exe is a resource kit utility, and we're providing it as the solution for this problem. Because it comes from resource kit, yes, it is fully supported. If you make modifications to it, which you are able to do, the support limit is at the point up until which you have made those modifications. So, if you have a problem with Newuid.exe in its current form, you may certainly call Product Support Services, and an engineer will help you determine whether the problem is with how you're using the product, or in the product itself, and, if appropriate, any problems can be bugged and escalated.

Heidi: Okay, moving on to the next question: I'm still confused on why we have duplicate SMSIDs. I made sure we are not cloning computers with SMS installed, and I still have approximately 1,500 records of duplicate SMSIDs. Could you please review once again the methods on how duplicate SMSIDs occur?

Bruce: Okay, the first thing that I want to say about imaging is that I have had personal experience, sitting in board rooms of a corporation or two, where it was insisted that cloning was not happening. Upon producing a list of machine names, it was discovered that, yes, cloning was happening, and it was unauthorized. So, we need to think about that, and be careful that we have explored that avenue completely.

Cloning, or imaging, is most likely the problem. The second way that this can happen is if the GUID is based on SMSID from an SMS 1.2 site. Now, unfortunately, I wasn't able to ask you: are your GUIDs in an SMSID format, or are they in the 2.0 GUID format? If they're in the SMSID format from an upgraded SMS 1.2 client, it's because those machines are duplicate SMSIDs from the SMS 1.2 days, and you'll have to clean them up.

The third way that it can happen is if you're repackaging. If you sent some sort of software distribution that contained the actual creation of a GUID, that creation process was also repackaged, and that can cause that GUID to be overwritten on the client and be a duplicate GUID.

Let's talk for a minute about the way in which a GUID is created. In the SMS 1.2 days, we incremented it from a file on a server. Now there are all kinds of ways that that could cause overlapping SMSIDs, or duplicate SMSIDs. We could either have a reinstallation scenario, where that counter was reset, or we could have a permissions problem, where the file was locked down so it couldn't be incremented by the client. We could have all kinds of things that cause that problem. In SMS 2.0, however, there is an algorithm that uses a function called UUID. And that UUID function creates an absolutely statistically unique number. Then we take that number and merge it together with the time stamp at this is all happening, and that creates a further unique number. I have yet to see a case where we have actually had two identical SMSIDs that were created at random.

I've also talked to development about this particular thing, and asked them what were the chances of randomly creating duplicate SMSIDs. The answer that came back was that the odds are absolutely astronomical for having two GUIDs, with identical numbers, getting created on any two given machines. So I guess I would go back to challenging our own assumption that no imaging is happening, and let's make sure that it is not. Let's challenge our assumption that perhaps we didn't clean it off properly in the first place. Perhaps that Smsconfig.ini file was left on the client. That can happen if you deinstall and reinstall the clients, or that kind of thing.

Now that I think about it, there is another thing that could have caused the problem. If you had a test rollout, and that rollout had cloned GUIDs on it, and then you deinstalled it and had those machines moved into your production environment, and you were not aware that that test had happened, then that can also be a cause of cloned GUIDs. I have seen that happen a couple of times.

If this doesn't answer your question, I strongly encourage you to run the Transact SQL query. Get the results and open an incident with PSS, and they'll be able to help you interpret the data a little bit and see if we can get to the root of what your problem is.

Wally: One other comment, just to reinforce what Bruce said on the GUID creation process. SMS also includes the MAC address of the network adapter card that's in the client in the GUID itself. So, not only do you have this random number generation and this date and time stamp of when the GUID was created, but also the MAC address. As you know with MAC addresses, there is theoretically no possibility of a MAC address being duplicated on the network, because they all have unique chips provided by the manufacturer. As Bruce stated, it is virtually impossible to have a duplicate ID created by SMS itself. So, it has to be from some other method.

Bruce: Even in the case where there are a few companies that are producing network adapters that allow you to burn the MAC address in, because we merge that number with the date/time stamp, that number remains statistically unique.

Heidi: Okay, great. We're going to go ahead to the next question. It's in regard to 20Clicln.bat: What exactly does the /scrub switch do? You went over that pretty quickly and I'm not sure.

Bruce: Okay, the first thing I would encourage you to do is open the file, it's on the SP2 CD, and take a look. Basically, it deletes the Smsconfig.ini file, or it removes the unique ID from that file. It allows you to completely clean the client. As far as I recall, it does not clean it from all three locations, but that should be sufficient, in every case, to allow a unique identifier to be assigned on the client. What often happens is that somebody will deinstall and reinstall the client, and that Smsconfig.ini file is left behind on the hard drive to leave you a hook. So you can put that machine back, and associate it again with the history data in the database. So if you deinstall and reinstall a machine, you can associate whatever new inventory is with the old GUID back into the machine. Sometimes, when trying to clean clients up, and when simply deinstalling the client and reinstalling, that file is forgotten. I believe the /scrub option removes that one file, Smsconfig.ini.

Heidi: Moving on to the next question: With regard to duplicate NetBIOS, is there a way to merge resource entries on the SMS database with duplicate NetBIOS names, which have different GUIDs? This duplicate NetBIOS name is perhaps caused by the recycling of machine names.

Bruce: Having two machines with the same NetBIOS name will not cause this condition, because each of those machines should have its own globally unique identifier, or GUID. The GUID, again, is the primary method by which we make a machine unique to SMS, and it's only when that GUID is compromised, by sharing it among multiple machines, that we have a problem. So, even in the case where we have two machines that both have had the same NetBIOS name, but have a unique GUID, you should be okay.

Heidi: We only have a couple questions left in the queue. Can I simply change the GUID by changing it in the files and registry with a little VB program?

Bruce: No, you do not want to do that. The reason why you don't want to do that is because that GUID is used for a variety of functions, including some background processes that have to do with accessing the client access point (CAP). If you change the GUID manually, you can cause the client to lose its communication with the CAP, and cause it to become dysfunctional and require a reinstall. So, please use Newuid.exe, or deinstall — manually clean it up and reinstall. Do not attempt to manually change the GUID.

Heidi: We have one last question at this time: Will future versions of SMS automatically prevent duplicate GUIDs?

Bruce: There is a bug filed, a critical DCR filed, with development for this, and it is being looked at — having a client being able to determine whether or not its own machine name has changed. That is up for consideration, and what we see happening with the white paper and the methods that we have outlined for you today will determine to a large degree what the future of the product is, but not in the current version.

Heidi: Okay, we have cleared the queue of all the questions submitted during today's broadcast. Once again, I do want to encourage all of you to submit any feedback you have for us. You can use the feedback@microsoft.com alias. Be sure to include "Support WebCast" in the subject line.

Our next SMS session is on September 26. It is "What is WMI, and How Does SMS Use It?"

I do hope that you found this content useful. I want to thank Bruce and Wally for joining us. I also want to thank all of you for taking the time to join us today. I hope that you have a chance to join us again in the near future.

Have a wonderful day, and good-bye.