When ConfigMgr is configured in Mixed mode and client computers are re-imaged/re-installed; by default a new ConfigMgr computer object is created and the “old” computer object will become “Obsolete”. Well, this is by design, but it might become a problem. If the client has many direct collection memberships, these direct memberships will not be preserved when a new computer object is created. Therefore, these have to be re-created.
When ConfigMgr is configured in “Native Mode”, the client identity is automatically migrated since we are using certificates.
Well, with ConfigMgr, this problem can be handled. However, it is a manually process. In the “Site properties” dialog, on the “Advanced” tab, there is a section called “Conflicting records”. From here it can be configured how ConfigMgr should handle conflicting records. That is, clients with duplicate hardware Id’s. By default, it is configured to “Automatically create new client records for duplicate hardware IDs” as shown in the picture below.
And that is exactly what happens when a client is re-imaged; A new record is created and the “old” record is marked as “Obsolete”.
If “conflicting records” is configured to “Manually resolve conflicting records”, the ConfigMgr Admin must decide what to do with conflicting records. This is done through “Conflicting records” node in the ConfigMgr Admin Console (See picture below)
In the “Conflicting records” node, all conflicting records are listed. By right-clicking a record, 3 actions are exposed to the administrator: Merge, New, and Block.
Merge
This method combines the new detected record with the existing client record. This is equal to reusing the ConfigMgr “old” computer object. This is the method to use if we want to reuse the “old” object.
BlockThis method creates a new computer object, but it will be marked as blocked, and will remain unmanaged.
NewThis method creates a new computer object, and the “old” one will be marked as “obsolete”. This method is the default one, when “conflicting records” is configured to “Automatically create new client records for duplicate hardware IDs”.
It is important to note, that client computers having a conflicting record, will be unmanaged until the administrator actively decides what to do with the conflicting record (merge, block, create new).
So, by using the “Merge” method, we can reuse the “old” computer object. So that is very nice, but it is a manually process, and it might not be feasible to the administrator, that every time a client computer gets reinstalled, he or she have to go to the “conflicting records” node in the Admin Console and decide what to do with the computer object. So now the question is: “Can this be done automatically ?”….. Yes it can! However, the method is not documented by Microsoft, and neither can it be found it the ConfigMgr SDK, and there is a good reason: Security !!! I will get back to that later on.
However, I did a little research on the ConfigMgr server WMI-namespace, and I found an interesting class; the SMS_PendingRegistrationRecord class. I found that every time a “conflicting record” occurs, an instance of the “SMS_PendingRegistrationRecord” is created. Further, the SMS_PendingRegistrationRecord” has a method called “ResolvePendingRegistrationRecord” which takes 2 input parameters: ”SMSID” and ”action”. The “SMSID” parameter specifies the SMS Client GUID of the conflicting record, and the “action” parameter specifies what to do with the record: Merge, Block, or create new.
Input values for the “action” parameter
1 = Merge
2 = New
3 = Block
I have made a small sample script for resolving conflicting records. The script loops through all conflicting records and resolves them by using the “Merge” method. The script is just a small sample script, and provides no error handling or logging
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Dim swbemLocator
Dim swbemServices
Main()
Sub Main()
Dim oProviderLocation
Dim oLocation
Dim oReg
Dim oPendingRegs
Set swbemLocator = CreateObject("WbemScripting.SWbemLocator")
swbemLocator.Security_.AuthenticationLevel = 6 'Packet Privacy.
Set swbemServices = swbemLocator.ConnectServer(".", "root\SMS")
Set oProviderLocation = swbemServices.InstancesOf("SMS_ProviderLocation")
For Each oLocation In oProviderLocation
If oLocation.ProviderForLocalSite = True Then
Set swbemServices = swbemLocator.ConnectServer(oLocation.Machine, "root\sms\site_" + oLocation.SiteCode)
End If
Next
Set oPendingRegs = swbemServices.ExecQuery("SELECT * FROM SMS_PendingRegistrationRecord")
For Each oReg In oPendingRegs
Resolve 1, oReg.SMSID
Next
End Sub
Sub Resolve(action, SMSID)
Dim InParams
Set InParams = swbemServices.Get("SMS_PendingRegistrationRecord").Methods_("ResolvePendingRegistrationRecord").InParameters.SpawnInstance_
InParams.Action = action
InParams.SMSID = SMSID
swbemServices.ExecMethod "SMS_PendingRegistrationRecord","ResolvePendingRegistrationRecord", InParams
End Sub
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
I have tested this script and implemeted it at a couple of customers, and found no problems with it. The script is executed on the site server on regular basis (every 10 minutes or so) by using a “Scheduled Task”.
The script can not be run as a part of a Task Sequence, since there will be a delay from when the SMS Agent Host is installed on the client computer, until til it appears in the "Conflicting records" node.
As mentioned earlier; this method is not documented or supported by Microsoft and for a good reason: Automatically merging records introduces a security risk: If a rogue user that knows or guesses the hardware ID of a previously assigned client computer, this person could take over the identify of that client and gain access to the SCCM site. It would be very difficult to detect this if records are automatically merged.
So if you want to reuse your “old” ConfigMgr computer objects, you might consider using this script. Just keep the security risk in mind.
When ConfigMgr is configured in “Native Mode”, the client identity is automatically migrated since we are using certificates.
Well, with ConfigMgr, this problem can be handled. However, it is a manually process. In the “Site properties” dialog, on the “Advanced” tab, there is a section called “Conflicting records”. From here it can be configured how ConfigMgr should handle conflicting records. That is, clients with duplicate hardware Id’s. By default, it is configured to “Automatically create new client records for duplicate hardware IDs” as shown in the picture below.
And that is exactly what happens when a client is re-imaged; A new record is created and the “old” record is marked as “Obsolete”.
If “conflicting records” is configured to “Manually resolve conflicting records”, the ConfigMgr Admin must decide what to do with conflicting records. This is done through “Conflicting records” node in the ConfigMgr Admin Console (See picture below)
In the “Conflicting records” node, all conflicting records are listed. By right-clicking a record, 3 actions are exposed to the administrator: Merge, New, and Block.
Merge
This method combines the new detected record with the existing client record. This is equal to reusing the ConfigMgr “old” computer object. This is the method to use if we want to reuse the “old” object.
BlockThis method creates a new computer object, but it will be marked as blocked, and will remain unmanaged.
NewThis method creates a new computer object, and the “old” one will be marked as “obsolete”. This method is the default one, when “conflicting records” is configured to “Automatically create new client records for duplicate hardware IDs”.
It is important to note, that client computers having a conflicting record, will be unmanaged until the administrator actively decides what to do with the conflicting record (merge, block, create new).
So, by using the “Merge” method, we can reuse the “old” computer object. So that is very nice, but it is a manually process, and it might not be feasible to the administrator, that every time a client computer gets reinstalled, he or she have to go to the “conflicting records” node in the Admin Console and decide what to do with the computer object. So now the question is: “Can this be done automatically ?”….. Yes it can! However, the method is not documented by Microsoft, and neither can it be found it the ConfigMgr SDK, and there is a good reason: Security !!! I will get back to that later on.
However, I did a little research on the ConfigMgr server WMI-namespace, and I found an interesting class; the SMS_PendingRegistrationRecord class. I found that every time a “conflicting record” occurs, an instance of the “SMS_PendingRegistrationRecord” is created. Further, the SMS_PendingRegistrationRecord” has a method called “ResolvePendingRegistrationRecord” which takes 2 input parameters: ”SMSID” and ”action”. The “SMSID” parameter specifies the SMS Client GUID of the conflicting record, and the “action” parameter specifies what to do with the record: Merge, Block, or create new.
Input values for the “action” parameter
1 = Merge
2 = New
3 = Block
I have made a small sample script for resolving conflicting records. The script loops through all conflicting records and resolves them by using the “Merge” method. The script is just a small sample script, and provides no error handling or logging
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Dim swbemLocator
Dim swbemServices
Main()
Sub Main()
Dim oProviderLocation
Dim oLocation
Dim oReg
Dim oPendingRegs
Set swbemLocator = CreateObject("WbemScripting.SWbemLocator")
swbemLocator.Security_.AuthenticationLevel = 6 'Packet Privacy.
Set swbemServices = swbemLocator.ConnectServer(".", "root\SMS")
Set oProviderLocation = swbemServices.InstancesOf("SMS_ProviderLocation")
For Each oLocation In oProviderLocation
If oLocation.ProviderForLocalSite = True Then
Set swbemServices = swbemLocator.ConnectServer(oLocation.Machine, "root\sms\site_" + oLocation.SiteCode)
End If
Next
Set oPendingRegs = swbemServices.ExecQuery("SELECT * FROM SMS_PendingRegistrationRecord")
For Each oReg In oPendingRegs
Resolve 1, oReg.SMSID
Next
End Sub
Sub Resolve(action, SMSID)
Dim InParams
Set InParams = swbemServices.Get("SMS_PendingRegistrationRecord").Methods_("ResolvePendingRegistrationRecord").InParameters.SpawnInstance_
InParams.Action = action
InParams.SMSID = SMSID
swbemServices.ExecMethod "SMS_PendingRegistrationRecord","ResolvePendingRegistrationRecord", InParams
End Sub
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
I have tested this script and implemeted it at a couple of customers, and found no problems with it. The script is executed on the site server on regular basis (every 10 minutes or so) by using a “Scheduled Task”.
The script can not be run as a part of a Task Sequence, since there will be a delay from when the SMS Agent Host is installed on the client computer, until til it appears in the "Conflicting records" node.
As mentioned earlier; this method is not documented or supported by Microsoft and for a good reason: Automatically merging records introduces a security risk: If a rogue user that knows or guesses the hardware ID of a previously assigned client computer, this person could take over the identify of that client and gain access to the SCCM site. It would be very difficult to detect this if records are automatically merged.
So if you want to reuse your “old” ConfigMgr computer objects, you might consider using this script. Just keep the security risk in mind.
No comments:
Post a Comment