Archive for November, 2010

Duplicate Computer Records In SCCM

Have you ever wondered why when rebuilding a machine in SCCM you end up with another computer record? Quite often I am ask why this is the case and if it can be fixed. Now it turns out that the answer isn’t completely straight forward so I endeavour to explain here what is happening and how to get better control of duplicate computer records.

Client Installation and Discovery

For things to work in SCCM and SCCM GUID is generated by the client so that the computer can be uniquely identified by SCCM. When a client is installed (actually each time ccmexec.exe starts) 3 values are check to determine identification information. These 3 values are:

  2. Machine SID
  3. Hardware ID – HardwareID is made up of 10 hardware attributes of a machine that are hashed and combined together. See for more information about these hardware attributes.

If any of these values change or if the client does not yet have a GUID a new SCCM GUID is generated. You can see this process in the ClientIDManagerStartup.log.

Once an SCCM GUID is generated it is sent, along with other information, as part of a DDR(Data Discovery Record) to the SCCM server. The SCCM server uses this information to determine if a new record should be created.

Conflicting Records

When a machine is rebuilt a new SCCM GUID is created by the client but the HardwareID is the same. When this information is sent to the SCCM server the server identifies that en existing record with a matching HardwareID already exists. As a result a new record is created and the existing record is set to obsolete. Information about this process can be found on the new resource record under the properties PreviousSMSUUID and SMSUUIDChangeDate.

The default behaviour for SCCM is to create a new resource record when conflicts are detected. This behaviour can be handled manually allowing an administrator to merge the records rather than creating a new one. Information on this process is available at

An Example

I have a freshly built Windows 7 machine deployed by an MDT Task Sequence in SCCM. I’ve run the following Powershell command to get all the attributes of the machine.

Get-WmiObject -Computer SCCMServer -Namespace root\sms\Site_000 -Query "SELECT * FROM SMS_R_System WHERE NetbiosName='VM-JBH-MOE01'"

The important attributes:

HardwareID: 2:68FB352A952243E79D938BE6EBA1B293DFA6E6E5
SMSUniqueIdentifier: GUID:9DBFD114-9B37-48A0-9747-EB15FA277DFE

After PXE booting the machine and running the Task Sequence again I see a new record with the following:

HardwareID: 2:68FB352A952243E79D938BE6EBA1B293DFA6E6E5
SMSUniqueIdentifier: GUID:467FBD75-6341-4D9C-8E7E-1FD227A081B0
PreviousSMSUUID: GUID:9DBFD114-9B37-48A0-9747-EB15FA277DFE
SMSUUIDChangeDate: 20101119042938.000000+***

Notice the PreviousSMSUUID matches the SMSUniqueIdentifier above.

Also of note is this line in Ddm.log on the site server:

1 records with Hardware ID 2:68FB352A952243E79D938BE6EBA1B293DFA6E6E5 were obsoleted by VM-JBH-MOE01.

A Final Note

So why doesn’t this happen all the time? Well SCCM does try and match up there records if it can and when rebuilding using a “Refresh” scenarios the SCCM GUID is saved and reused. In a later post I’ll show you how to reuse the SCCM GUID when using MDT in SCCM.

See the following for some more information:

Read more

Output SCCM Task Sequence Variables

When debugging Task Sequences it is often crucial to know the exact value of Configuration Manager’s built-in task sequence variables. There variables are available during the execution of a task sequence using the Microsoft.SMS.TSEnvironment COM object. There is a great post on the Deployment Guys site that explains how to use the above COM object and provides a script to use for debugging during a Task Sequence.

Read more