Incorrect Computer CI being associated with Hardware Asset
Steve_Clarke
Customer Adept IT Monkey ✭✭
Hi All,
We are seeing an issue where incorrect Computer CI's are being assocaited with Hardare Assets.
This appears to be occuring when the computer CI was discovered previously under another name. We have multiple workstations that have been rebuilt with a new name (old SCCM and AD objects have been deleted) however SCSM still retains these old CI's.
When doing a Computer CI search I can find these previous CI's which all of couse have the same serial number.
It appears that when the Cireson workflow is associating the CI's (which I belive happens by serial matching), it appears to pick one of these legacy computer CI's and not the latest iteration..
I hope someone could shed some light on how Cireson determines which Computer CI to associate with the Hardware Asset when there are multiple CI's that have the same serial number as it does not seem to be updating the Hardware Asset with the latest one in our case.
Thanks in advance..
Steve
Best Answer
-
Brett_Moffett
Cireson PACE Super IT Monkey ✭✭✭✭✭
I have raised this as a bug with the product team as there is currently not a limiting search for CI's when associating them. This results in a situation where you may have multiple CI's with the same information and the workflow "Flapping" between them on a daily basis.
A fix is to ensure you do not have competing CI's and this is usually fixed by ensuring the workflow account and AD Connector accounts have rights over the Deleted Items container in AD as suggested by @Michael_Baldry
Keep an eye out for a new version of AM that should fix this issue in the not too distant future.7
Answers
I believe that the deleted computers from the SCCM connector should get detected automatically (ours do, at least), but you may need to grant a bit more access to the account used for the AD connector, if you pull computers in from there too.
Thanks Michael. I will double check the permissions for the connector account.
I have also enabled additional logging to try to work out what is happening (we can see that the workflow is attaching a different CI every time the workflow executes) so that may shed some further light on what is going on.
So the logging didn't show much. Just that the opposite CI had been associated.
It is looking like this is a bug. If you have more than one Computer CI with the same serial number then the workflow will associate a different CI with the Hardware Asset each time the workflow executes.
Clearing out old CI's would obviously help. But there will still be periods where multiple CI's exist with the same serial shortly after a workstation is rebuilt (and the new AD/SCCM objects are imported via the connectors)
A fix is to ensure you do not have competing CI's and this is usually fixed by ensuring the workflow account and AD Connector accounts have rights over the Deleted Items container in AD as suggested by @Michael_Baldry
Keep an eye out for a new version of AM that should fix this issue in the not too distant future.
I found that if the computer is renamed post OSD (in Windows) this issue doesn't occur and the existing CI in SCSM gets updated to the new name. As a workaround I've disabled the option for computer name when re-imaging a computer in SCCM. I'm not sure how feasible that is for you, but it did the trick for me. In saying that, it will be nice to have something in the tool that will prevent this as I'm guessing every other customer would be in the same boat here?
Hi Haseeb, sorry I missed the notification for your comment.
Glad to hear you found a way around this in your environment. Unfortunately I think there would still be some scenarios in our environment where we would end up in this situation.
You are right that everyone will be in the same boat with this one. Luckily the delete option Brett described above should work for any moving forward (I am yet to thoroughly test) and the Asset MP update should take care of the rest.
@Brett_Moffet have you heard any updates in regards to this fix?
When computers get renamed SCSM does not remove the old Computer CI and therefore there are two Computer CI's that remain inside the SCSM DB.
If the Computer CI has the Active Direction Unique GUID then the Cireson AM workflows will look at the two entries and work out which one to associate.
However, when it comes to Software Asset Management the Cireson workflow looks at the Computer CI's directly. This can cause a false result for counting of software assets as it would count the same computer twice (or more).
The solution is to not rename computers...
Or, remove old or stale computers from SCSM.
This can be done easily with a quick PS script like this:
<p>#Delete Service Manager Computers if they dont exist in AD</p><p><br></p><p>$CMDBWindowsComputers = Get-SCSMObject -Class (get-scsmclass -name Microsoft.Windows.Computer$) | Select -ExpandProperty PrincipalName</p><p>$ADcomputers = Get-ADComputer -Filter * | Select -ExpandProperty DNSHOSTNAME<br></p><p>foreach($Computer in $CMDBWindowsComputers) {<br></p><p>$ExistsInAD = $ADcomputers -contains $Computer</p><p>IF($ExistsInAD -eq $False) {</p><p>Get-SCSMObject -Class (get-scsmclass -name Microsoft.Windows.Computer$) | Where{$_.PrincipalName -eq $Computer} | Remove-SCSMObject -Force</p><p>Write-Host $Computer 'HAS BEEN DELETED' -BackgroundColor Red</p><p>}</p><p>}</p><p><br></p>Hi Brett,
Just in regards to your comment about the solution being to "not rename computers".
The computers in our enviornment were never renamed. They were decomissioned (Formatted/Computer account deleted from AD/SCCM object deleted from SCCM etc.). After this the computer CI still exists in SCSM (Unless we give SCSM rights to read the deleted objects container in AD from what Michael_Baldry said above althought I still have not tested this yet.)
When the new computer is built I am assuming it does have a different AD GUID. However the SCCM connector will run and result in the old and new computer objects having the same Hardware Serial attributed to them.
We have a general rule of never renaming workstations in our environment. They are always re-imaged and given a new name in the process.
As per Haseeb_Malik's post above, renaming a computer in their environment (post build) actually helped prevent this issue. The reason being is that the re-imaged workstation re-connects to the old AD object. They then rename the workstation (post-build) which updates the old AD object, which then gets updated in SCCM and SCSM. As a result no new workstation object ever gets created, preventing a duplication scenario.
When you say "Cireson AM workflows will look at the two entries and work out which one to associate", can you please advise if this has changed recently because that did not appear to be the case previously. The AM workflow seemed to cycle through each computer CI each time the workflow ran (which you would remember seeing when you were here).
Hopefully I have not misunderstood what you are saying but I just wanted to clarify that I believe that re-naming workstations is not necessarily what causes this issue.
This can be done easily with a quick PS script like this:"
We have same issue, quite many computers are doubled.
That script way we cant do, many of computers are at internal network only. I try to delete dublicates from Service Manager Console and web interface but those didint dissapear. I that wrong way do get rid of or is there some other way to delete junk HW from SCSM DB ?
The solution I came up with was a PowerShell script (SMA job) that runs after the SCCM connector but before Cireson Asset Workflows. It simply deletes all of the "stale" SCCM objects out of SCSM. In short, grab all of the duplicate SCCM Configuration Items, sort them by their last modified date, delete the oldest ones.
$scsmmgmtserver = "mgmtservername" $deployedClass = get-scsmclass -name "Microsoft.SystemCenter.ConfigurationManager.DeployedComputer$" -ComputerName $scsmmgmtserver $allDeployed = get-scsmobject -Class $deployedClass -ComputerName $scsmmgmtserver | group-object $_.displayname | ?{$_.count -gt 1} | sort-object lastmodified -Descending foreach ($deployedObject in $allDeployed) { $deployedObject.Group | sort-object lastmodified -Descending | Select-Object -Skip 1 | foreach {remove-scsmobject $_ -ComputerName $scsmmgmtserver -Force} }