Share your thoughts – Update vs Delete on SM-CM Asset Information Sync

Share your thoughts – Update vs Delete on SM-CM Asset Information Sync

  • Comments 37
  • Likes

In the interest of staying agile and ensuring closer engagement with our customers, I’d like to open up a design question to all our readers.

The team’s been working on a fix for a scenario which was not fully considered in the original design and we’d appreciate your input as we’re adjusting the spec.

Problem Description

If the software installed on a computer gets updated (version changes), the old relationship in SCSM gets deleted and a new one is created in its place. So say Office is updated from Office 2010 to Office 2013. The old relationship between the device and Office 2010 is deleted and a new one with Office 2013 is created in its place – this so far is expected behavior. *However*, when software is reinstalled (e.g. the version remains the same, such as when a user reinstalls Office 2013), upon ConfigMgr connector sync, Service Manager ends up deleting the old relationship but *does not* create a new one in its place, thus causing the reported software installs between SCSM and ConfigMgr to go out of sync.

Possible Approaches

During the sync, we check CMDB to see if the computer/software relationship has the same version, and if so…

  • Approach 1: we keep the old relationship, but update it with the new InstalledDate property
  • Approach 2: we delete the old relationship and create a new one in its place with all new information

Here’s how you can help

We’d like your help to get a better understanding of the expected behavior from your point of view. Which of the two approaches outlined above work better? Also, what are the pros and cons (if any) of the above approaches from the license tracking, reporting and auditing standpoints. Please share your responses in the comments section below :)

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Approach 2-

  • Invest time and resources on the big performance issues we all experience would be my preferred option.

  • Perf issues are being planned for. There are some low hanging fruits as we ramp up.

  • Hello, first just wanted to mention how encouraging it has been to hear the upcoming development of Service Manager and this post is certainly a great step in the right direction.

    I am not quite sure of the advantage of #2 over #1 unless there are some performance benefits for the connector itself to do #2. For #2, it mentions that it would delete the old relationship and create a new one with “all new information”. I’m not quite sure what that means, but I would think the information wouldn’t be any different than updating the InstallDate property on the already existing relationship (basically Approach #1).

    The other concern for #2 is when you get to a very large scale. We are working with a client that has 10 million+ software relationships in SCCM globally. I can only imagine how often a delete could occur and the overhead it would cause on the system groom jobs that take the relationships where IsDeleted = 1 and drops them from the database (DiscoveryDataPurging). Also, the History log on the Computer CI would look fairly odd when it was deleting and recreating those relationships. That’s further impact on the ECL table and other system workflows/grooming jobs (GroomSubscriptionLogs, GroomChangeLogs, etc.).

    My vote would be for #1. I would also like to add that when it comes time to start discussing overall connector enhancements, I would love to comment on the fact that we’ve built custom CM connectors that utilize SSIS and SQL table compares for the processing and are able to discover deltas between CM and SM in a matter of seconds.

    Thanks again!

  • You could leave this as an option in the Configuration Manager connector, could you not?

    Deleting the old and creating a new relationship seems like a good default, then let people change it if they have requirements for doing so.

  • Hi !
    My guess would also be Approach 2 - because this is a perfect reflection of reality. Are there any performance considerations between 2 and 2 ? I guess Option 2 is more performance intensive ?
    R.

  • Approach 2 for me. One other sync "bug" between SM and CM we have to deal with is volume/dIsk. E.G. when we remove a volume from a server the volume still is related to the server object in SM. This should be removed from the server object as well.

  • Hi,
    Approach 2 sounds more reliable for the asset data. It is more reliable to have the latest informations visible on the object directly.

  • Approach 1.

  • Approach 2. I want the most reliable and accurate data as possible in SCSM.
    Keep all information in one place is the big benefit of the software imo.

  • Approach 2

  • I'll make a case for Approach 2.
    In my mind, when software is _reinstalled_, it is first removed, then installed (otherwise, it simply might be repaired). Those are two distinct operations (transactions). They should be represented by two distinct changes (transactions) in the CMDB. The relationship between a computer object and the software object is first removed, then re-added. The "new" relationship then has the new softwareInstall date.
    Since relationship properties have no history of their own, simply updating a relationship property loses the fact that a change occured. Thus, a relationship property update is not a true representation of the two transactions that occured.

    Here's a quick business use case to support approach 2.
    Let's say I want to create a workflow that reacts only to software re-installations (not just installations). With approach 2, I can easily react to a "relationship added" event, then inspect the object history to see if that "new" relationship was recently removed before it was added.

    Personally, I prefer my data to precisely and concisely represent the state of my environment as well as the changes that occur.

    By the way, I like that you folks are posting these questions and updates. Keep it up! :)

  • Approach 2

  • I would vote for number 2, the history can be held in Configuration Manager, but the benefit of having the latest relationship is fundamental for supporting IT Service Management processes in SM.

  • I believe approach #1 would be best as it would seem to have the least amount of overhead. Approach #2 removing and adding a relationship involves processing the relationship changes (including any secondary effects to the related objects) and additional history tracking on those objects. From a discovery point of view the item was there and the same item is still there. If someone is interested in detecting the change, a subscription to changes in the install date could accomplish that. For systems that use the existing relationship, causing a re-drive/re-processing for a non-event is just overhead.