Sometimes Predefined computers (that are imported or added on the SMP console) are booted up and instead of running the job assigned to them create a new entry in the CMDB and do nothing (until the duplicate entry is found and the job is targetted to this entry).
The duplicate entry contain the same mac address as the pre-defined computer.
What is causing the duplicate entry and what is preventing the pre-defined computer record from being used?
When a predefined computer is added to the SMP database the computer record is added to the 'Pre-defined computer' filter. However after a number of delta collection updates the computer can be moved oout of the 'Pre-defined computers' filter, which causes the creation of a duplicate entry when the physical machine actually boots up in PE environment.
This problem is rooted in a number of filter definitions and some software magic (i.e. something happens for some reasons that we have not been able to track down).
The 'Pre-defined computer' definition is simple: it includes all computers from Inv_AeX_AC_Identification that have an OS Name 'Unknown Windows' and that have no data in the Inv_Client_Task_Resources table. This in itself is fine, however we have found during testing that the pre-defined computers that are moved out of the 'Pre-defined Computers' filter (without ever booting) add an entry in this table. The entry appeared after the computer was added to the 'All Task Devices' filter, a hidden filter than includes all machines of type 'Computer' and 'Virtual Computer'.
The software magic is that in a standard test environment when the computers are added to the 'All Task Devices' no entries is writen on the Inv_Client_Task_Resources, however it is the case in the customer production environment.
As we could not find the link between the 'All Task Devices' filter and the entries added into Inv_Client_Task_Resources we went for a qork around, which took 2 steps to get it right.
We first modified the 'All Task Devices' filter to be be visible and editable (removed the attributes 'Readonly' and 'Hidden' from the item xml after we exported the item). Then we added a filter exclusion to ensure computer in the 'PRe-defined computers' filter would be excluded from the 'All task devices'. This would ensure that computers are taken out of the filter only once they are no longer reported as 'Unknown Windows' in the AC Client Identification dataclass.
However good the idea was to start with it proved to not be as robust as epxected. For some reasons that we did not research in particular we had computers following of the 'Pre-defined computer' filter every now and again and appearing in the 'All Task Devices.
Thus come step 2. To make the solution as robbust as possible we implemented the exclusion at the SQL level. The filter SQL definition was modified to ensure no resources in the 'Pre-defined Computers' filter would be present in the SQL data set returned during collection update.
Here is the SQL before change:
select vr.[Guid] from [dbo].[vResource] vr join [dbo].[TaskResourceTypes] trt on trt.[ResourceTypeGuid] = vr.[ResourceTypeGuid]
select vr.[Guid] from [dbo].[vResource] vr join [dbo].[TaskResourceTypes] trt on trt.[ResourceTypeGuid] = vr.[ResourceTypeGuid] left join CollectionMembership cm on cm.CollectionGuid = 'BA2E721E-CB8B-4C5A-B24C-5788D0EBA069' -- Deployment Solution Pre-defined Computers and vr.Guid = cm.ResourceGuid where cm.resourceguid is null
In addition to the SQL changes we removed the 'NoReplication' attribute, which allowed us to ensure the changes made on the parent would be reflected on all child servers. This final work around (xml attached) is proving to resolve the problem properly.
Deployment Solution 7.5 SP1 and prior