Hi, we have an issue where a computer with the same name is twice in SCCM. First entry : computer name : mtl-cnf-ac392, not client second entry : computer name : mtl-cnf-ac392, client, approved, assigned, not obsolete, active :yes When I look at Agent time for each, first was discovered by AD discovery yesterday, while the second was created in last december. Only the second has an heartbeat entry that was done many hours after the AD discovery for the first entry What could do that? how can I prevent it? Thanks!

There are many reasons why this can happen, the trick it to look at which discovery method create the first record and then determine what is causing it to be created. So what discovery record create the first record. http://www.enhansoft.com/

also check if there has been any changes to the Machine SID ? can you check if both the computer has Same SID or different ? take a look at this article explaning what makes the computers duplicate http://support.microsoft.com/kb/837374//Eswar Koneti @ www.eskonr.com

Hey guys, Thanks for the reply... here an export of the v_R_system tab for the computer name that I see double entry ResourceID ResourceType Active0 AD_Domain_Name0 AD_Site_Name Always Internet0 AMTfullversion0 amtstatus0 client0 client_type0 client_version0 cputype0 creation_date0 decommissionned0 distinguishedname0 hardware_ID0 internetenabled0 isclientamt30compatible0 user_domain0 user_name0 managedBy0 Name0 Netbios_name0 obsolete0 operating_system_name_and0 Previous_SMS_UUID0 Primary_Group0 Resource_domain_or_workgr0 Smbios_guid0 sms_unique_identifier0 sms_Uuid_change_data0 Community_name0 suppressAutoProvision0 unknown0 user_account_control0 35814 5 1 NULL MTL 0 NULL NULL 1 1 4.00.6487.2000 NULL 2011-02-21 12:06:07.000 0 NULL 2:65592FE8145389F109AE709918EC0D948ECFC4D0 0 NULL <our domain> <username> NULL MTL-CNF-AC392 MTL-CNF-AC392 0 Microsoft Windows NT Workstation 6.1 Unknown NULL <our domain> 4C4C4544-0038-3910-8052-B4C04F594B31 GUID:057F2E64-0AD3-434D-B97A-8F3BD74277A1 2011-02-21 17:07:02.000 NULL NULL NULL NULL 35842 5 NULL NULL MTL NULL NULL NULL NULL NULL NULL NULL 2011-02-22 02:02:31.000 NULL CN=MTL-CNF-AC392,OU=Desktops,OU=Computers,OU=MTL,OU=NCSA,<our domain> NULL NULL NULL NULL NULL CN=Salle MTL - Toronto,OU=Meeting Room,OU=Resource Accounts,OU=Users,OU=MTL,OU=NCSA,<our domain> MTL-CNF-AC392 MTL-CNF-AC392 NULL Microsoft Windows NT Workstation 6.1 NULL 515 <our domain> NULL NULL NULL NULL NULL NULL 4096 So this is pretty messed up because of the way some info concerning the computer are in one row, and other in the other row... but all the info should be on the same line. Like the managedBy or distinguishedName0 only show on the computer that is NOT a client0=1. Those should be catched on the working computer. We have maintenance task to get rid of non client, I just want to understand what is going on with thise. I have many other example like this one. NOTE : in the process of building a computer, when a computer is removed from a user, we delete the account from AD. SCCM will eventually clean the computer with maintenance task. Sometime, computer are rebuilt the same day our the next day and than added again to AD. Would this be the cause of all this? Also, the client is instaled after the OS installation. Duplicate SID shoudln't be in cause for this. Thanks again guys! really appreciate the help from this forum! Jonathan .

v_R_System does not help in that case because it does not list the agents that discovered the client. It might be available in the System_Disc table, but I am not sure, because I've no ConfigMdr database next to me right now. You should basically list the stuff that is shown in the properties of client.Torsten Meringer | http://www.mssccmfaq.de

Had this issue early and there are more than one reason why the duplicate machines show up so we ended up creating a SQL task just for handling duplicate machine deletion which runs daily. /* *********** BEGIN *******************/ /* Kills duplicate NAMES in databases */ create table #dups ( ItemKey int ) insert into #dups(ItemKey) select sd.ItemKey as " ItemKey" from System_DISC sd where name0 in ( select name0 from System_DISC group by name0 having count(*) > 1 ) union select d.MachineID from System_DATA as d where name0 in ( select name0 from System_Data group by name0 having count(*) > 1 ) insert into DeletedItems(ItemKey,SiteCode) select #dups.ItemKey, assgn.SMS_Assigned_Sites0 from #dups join System_SMS_Assign_ARR as assgn on #dups.ItemKey=assgn.ItemKey insert into DeletedMachines(SMSID) select sd.SMS_Unique_Identifier0 from System_DISC as sd join #dups on sd.ItemKey=#dups.ItemKey where sd.SMS_Unique_Identifier0 is not NULL delete sd from System_DISC sd join #dups on sd.ItemKey=#dups.ItemKey drop table #dups /*********** END *************/

The query above is completely unsupported and this is NOT the way to handle duplicated computers! I would not use this query. http://www.enhansoft.com/

been using it for more than 2 years and works fine for me.This is not the only example where at times you need to directly edit the SQL database cos sometimes it doesnt really work from the console. I will let you take that call.Choice is urs unless someone has a supported way

Thanks Grafity for the suggestion, but as Garth said, editing the DB is not a real option. Actually, I'm more looking for answer than to ways to work around this. If I can understand the process it will be good for me and I'll figure a way to work them out (at least from reports). Torsten : I've looked at System_Disc and its almost the same information as in V_r_system. anyways, here the information from the System_Disc ItemKey DiscArchKey SMS_Unique_Identifier0 Netbios_Name0 Name0 Operating_System_Name_and0 Resource_Domain_OR_Workgr0 AD_Site_Name0 User_Name0 Client0 Client_Type0 Unknown0 Client_Version0 Community_Name0 User_Domain0 Previous_SMS_UUID0 SMS_UUID_Change_Date0 CPUType0 Hardware_ID0 Obsolete0 Active0 Creation_Date0 AD_Domain_Name0 SMBIOS_GUID0 AlwaysInternet0 InternetEnabled0 Decommissioned0 AMTStatus0 AMTFullVersion0 IsClientAMT30Compatible0 SuppressAutoProvision0 Primary_Group_ID0 User_Account_Control0 rowversion ManagedBy0 DistinguishedName0 35814 5 GUID:057F2E64-0AD3-434D-B97A-8F3BD74277A1 MTL-CNF-AC392 MTL-CNF-AC392 Microsoft Windows NT Workstation 6.1 <our domain> MTL <user name> 1 1 NULL 4.00.6487.2000 NULL <our domain> Unknown 2011-02-21 17:07:02.000 NULL 2:65592FE8145389F109AE709918EC0D948ECFC4D0 0 1 2011-02-21 12:06:07.000 NULL 4C4C4544-0038-3910-8052-B4C04F594B31 0 0 0 NULL NULL NULL NULL NULL NULL 0x0000000008F4CC45 NULL NULL 35842 5 NULL MTL-CNF-AC392 MTL-CNF-AC392 Microsoft Windows NT Workstation 6.1 <our domain> MTL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL 2011-02-22 02:02:31.000 NULL NULL NULL NULL NULL NULL NULL NULL NULL 515 4096 0x000000000822E7BD CN=Salle MTL - Toronto,OU=Meeting Room,OU=Resource Accounts,OU=Users,OU=MTL,OU=NCSA,<our domain> CN=MTL-CNF-AC392,OU=Desktops,OU=Computers,OU=MTL,OU=NCSA,<our domain> from what I understand from the Creation_date is that the computer was installed around noon and the client was installed on it. Client gets installed as part of the OS deployment. But what I don't understand is the other entry that seems to be created after the AD discovery, which runs at 2AM. So 2 minutes afters, it gets created... isn't supposed to validate if there is already an entry in sccm for a computer in AD? Thanks again for the help guys!

Editing the db is completely un-supported, there are not supported ways or queries that can be used on the ConfigMgr db. If you don’t use the SDK and edit data within ConfigMgr, you could end up with orphaned data within the db. If you ever need to edit the db then CSS are the only ones that can help you. http://www.enhansoft.com/

I know that editing the DB isn't supported. I don't plan on doing such. Anything on the previous question? WHy the second entry get created by AD discovery while it already exist because of a client installation done after an OS install? thanks

My original question still standards, In the console, when you right-click and select properties on the device, which discovery method created the record? http://www.enhansoft.com/

Hey Garth, The computer that is a client was created by MP_ClientRegistration, whichI beleive to be the installation of the client at the end of a task sequence. The computer that is NOT a client was created by SMS_AD_System_discovery. What is really strange is that the MP_ClientRegistration occured before the AD discovery Is that what you are looking for? thanks

So it sound like a timing issue, delete the extra PC, and only into the issue if the PC comes back. BTW I gather for the PC names that you are in TO or Montreal. I’m in Ottawa. http://www.enhansoft.com/

Hi Garth, you guest it rigth ;) We are in montreal! but to get back to main subject, how can this be a timing issue? Computer was install around noon and the client did communicate with SCCM to create its record while the other one was created a day later by the AD discovery? thanks

There is a running joke about “why” questions, “Don’t ask why questions”. What the real question do you really care why it was create? If you delete it and it doesn’t come back, do you care? http://www.enhansoft.com/

Actually I do care.... well not me.. but managers do *sigh* We have a third party that fetch the information from the DB of SCCM about computers... When they import the information, the see a computer client and another one not client. Which cause them problem... additional to that, not all the info is on the entry client... some info that I need are only visible on the not client like the managed by.... Wondering something... I've been able to do an SQL query to catch the double entry. But it's pretty hard to figure a way to do so in for a collection query. Any idea how I could do that to at least view them easily?

Actually I do care.... well not me.. but managers do *sigh* We have a third party that fetch the information from the DB of SCCM about computers... When they import the information, the see a computer client and another one not client. Which cause them problem... additional to that, not all the info is on the entry client... some info that I need are only visible on the not client like the managed by....

Well, all I can say , is duplicates happen and it that it will be a ton of work over months and months of trial and error to determine the root cause for this. Plus you will need to engage MS services to work out all the timing details and how to resolve it. IMO, it would be better for them to watch for PCs being deleted from ConfigMgr and remove them for the other database. Otherwise what are you going to do when PCs get a new GUID after you “fixed” them. http://www.enhansoft.com/