Home Asset Management

Incorrect Computer CI being associated with Hardware Asset

Steve_ClarkeSteve_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

Answers

  • Michael_BaldryMichael_Baldry Customer Advanced IT Monkey ✭✭✭
    Does your SCSM service account have rights to view the "Deleted Items" container in Active Directory? Travis Wright has a good blog post describing what happens when stuff from the connectors gets deleted here: https://blogs.technet.microsoft.com/servicemanager/2011/04/29/what-happens-to-a-user-in-the-cmdb-when-it-is-deleted-in-active-directory-ad/.

    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.
  • Steve_ClarkeSteve_Clarke Customer Adept IT Monkey ✭✭

    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.

  • Steve_ClarkeSteve_Clarke Customer Adept IT Monkey ✭✭
    edited August 2016

    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)

  • Haseeb_MalikHaseeb_Malik Member IT Monkey ✭
    edited September 2016
    Hi Steve, we were getting the same problem in our environment. I found that if the computer was re-imaged via SCCM and renamed during the setup wizard (we use UDI wizard) a new computer account is created in AD and SCCM, which results in a new Computer CI being created in SCSM and you know the rest :).

    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? 
  • Steve_ClarkeSteve_Clarke Customer Adept IT Monkey ✭✭

    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?

  • Bryan_McCartneyBryan_McCartney Customer Adept IT Monkey ✭✭
    We ran into this issue in our environment as well.  As a workaround (to refresh manually) we opened the SCSM console -> Configuration Items -> Asset Management -> Hardware Assets -> All Hardware Assets.  Delete all of the Assets listed, then synchronize your Configuration Manager connector.  Only the existing CI's will import (with the correct/updated name).
  • Brett_MoffettBrett_Moffett Cireson PACE Super IT Monkey ✭✭✭✭✭
    edited January 2017
    Hi @Bryan_McCartney, this discussion came up again the other day with another customer and I thought it worth a revisit.

    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$) |&nbsp;&nbsp;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>
  • Steve_ClarkeSteve_Clarke Customer Adept IT Monkey ✭✭
    edited January 2017

    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.

  • Erkki_TuovilaErkki_Tuovila Customer IT Monkey ✭
    "Or, remove old or stale computers from SCSM.
    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 ?
  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited November 2017
    I too discovered this behavior as well and worked it out to the following scenarios:

    • SCVMM or Azure: A VM evacuates a physical host, SCCM runs its inventory, SCSM syncs SCCM, a new SCCM object is created in SCSM as the only changed property is the underlying Hardware ID field (no less it's Key field). A new object is created, a new relationship is made. When Cireson Asset Workflows execute, they seem to flip through all of these related SCCM objects on the backend of the Windows Computer object because they have different Key fields. In a few cases, I had several SCVMM and Azure VM's with over 1000 SCCM objects.
    • Desktop PC: A physical PC is re-imaged through SCCM. None of the properties change except the Display Name of the Object. Cireson Asset Workflows run and cycle through all related SCCM objects, and the Hardware Asset changes shape as its respective Windows Computer has. In this scenario, I found several re-imaged devices that cycle through several related Configuration Items before settling.

    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}
    }
Sign In or Register to comment.