a.kao

By Eric Holtz (MS-SMS) at myITforum.com

One of the changes that occurred with SMS 2003 SP1 was how client identity is handled. Previous to SP1, the client record in the database could be merged with the data in an incoming Discovery Data Record (DDR) even if the new record had a different SMS Unique Identifier (a.k.a. the GUID). When the new record was processed, the GUID in the database was updated. This wouldn’t work with the client authentication that was introduced in SP1 however. The GUID is what uniquely identifies the client to SMS and it must match up with the clients certificate, so an unauthenticated DDR could not be allowed to change the GUID (or any part) of an authenticated client record. So what does this mean in practice? It may mean that you’re seeing more duplicate records in your database if you’re reimaging clients. When a computer is reimaged and the client is reinstalled, the new client will send up a DDR with a new GUID, but the key properties (name, MAC Address, and in 2.0 IP Address) will remain the same. In 2.0 and 2003 RTM, as was mentioned earlier, this new DDR would be matched up to the old record through these key properties and the GUID would be updated. With SP1, instead of matching the new DDR to the old record, a new record is created instead. The result is that every time a client is reimaged, a duplicate record for that client appears in the database. (This would sometimes happen anyway if the key properties didn’t match.) In order to manage the duplicate records now being created, the concept of “obsoletion” was introduced. When processing a new DDR, if it appears to match to an existing record, the existing record is marked as obsolete by the server by setting a Obsolete bit in the client record. These obsolete records are filtered out in software distribution and software update reports and the obsolete clients can be deleted through the “Delete Obsolete Client Discovery Data” site maintenance task. Clients can be marked as obsolete for two reasons: * If the new DDR contains a “Previous SMS Unique ID” property and an existing record has a GUID that matches this property, then the existing record is marked as obsolete. This will happen if the client generates a new GUID because of a major hardware change (convincing the client it is on a new computer). * If the new DDR contains a HardwareID and a single existing record has a matching HardwareID, then the existing record is marked as obsolete. (If multiple records match, we assume that the clients BIOS does not support the properties that make a HardwareID unique). This will happen when a client is reimaged. The HardwareID is a new discovery property that is made up of: * The serial number & asset tag from system enclosure (taken from the WMI Win32_SystemEnclosure class) * The serial number of the motherboard (taken from the WMI Win32_Baseboard class) * The serial number of the BIOS (taken from the WMI Win32_BIOS class) * If the computer is not a laptop, the MAC address from first enabled adaptor (Win32_NetworkAdaptorConfiguration) is also used. As you can see, older laptops that do not support serial numbers in their BIOS may generate a non-unique HardwareID, causing some records to be mistakenly marked as obsolete. In this case the mistaken obsoletion is fixed when the existing client submits a DDR, proving the record is not obsolete and clearing the flag. For this reason, the “Delete Obsolete Client Discovery Data” has a waiting period for mistakenly obsoleted clients to submit their DDR before we delete them. If your computers support the properties that make for a unique Hardware ID, then you can have the task delete the obsolete clients with the minimum waiting period. Overall there are a number of ways of dealing with obsolete client records: * Don’t generate them at all: The Transfer SMS ID utility (a.k.a. tranguid.exe) found in the SMS 2003 Toolkit allows you to migrate the GUID from one image to another (though it won’t work if client auth is turned on). The Operating System Deployment feature pack (OSD) also has an option to migrate the GUID, and this will work with client auth. * Filter out obsolete clients: The views used in advertisement and software update status reports already filter out obsolete clients and you can modify other reports do to this as well. The obsolete bit is shown in the collection membership view as well, so that they can easily be identified. This strategy allows mistakenly obsoleted clients to return without causing much disruption. * Delete obsolete clients: If you think the obsoletion process is working (if all your laptops have valid serial numbers or asset tags in the BIOS) you can delete the obsolete clients, with or without a waiting period. Accidentally deleted clients will come back (but they will experience an interruption in software distribution). There’s a few other miscellaneous things that I should mention. Some people may also have noticed an active bit, this is also affected by obsoletion (by being turned off when the client is marked as obsolete) but this bit is mainly reserved for use by the client health tools. Another thing worth mentioning is how direct collection membership rules are affected. Direct membership rules point to a particular client record, so if that record is marked as obsolete because of a newer record, that rule will still point to the old, obsolete record and not the newer record. You’ll need to update the membership rules if the client is still supposed to be in the collection. Also if you’re running the “Delete Obsolete Client Discovery Data” task, you may find that these direct membership rules are disappearing since they get deleted when the client is deleted. This posting is provided “AS IS” with no warranties, and confers no rights.