AnsweredAssumed Answered

SIM version update question

Question asked by Mark.Walther

on Feb 7, 2019
Latest reply on Feb 13, 2019 by hameed.iqbal

Like • Show 2 Likes2
Comment • 8

What is the mechanism or method that clients that are reporting via the SNOW Integration Manager connectors get the updated SIM version? I am using VMWare, XenServer, and SCCM to name a few and not all clients are reporting the newest version I have loaded. But they show as active and reporting daily. And it is not specific to a connector.

For example, SCCM, we have over 800 devices reporting and 3-4 are reporting an older version, and show active. Why are they not getting the new version?

I am at SIM version 5.13.0 (1625). Is there a way to force the update?

Thanks,

No one else has this question

Outcomes

8 Replies

carola.iberl Feb 8, 2019 1:03 AM
Mark Correct
Correct Answer
Hi Mark,

I had the same problem with SIM VSphere scanner
After I updated SIM on a server that connected to a big datacenter a lot of ESX hosts showed the new version in SLM, but also many still showed the older version. That's not possible because it was only one scanner and the hosts get a current lastscandate.
So I checked this in the database and saw already in InventoryDB the version was not updated correctly. I created a ticket at Snow, but later closed it, because it took too long for me to get support.

I removed the hosts in SLM. Next day they appeared again with the correct new version, so for me this looks like a problem in Inventory server when processing incoming data.

For me this solution was no problem, because we assigned the licenses to the cluster not the hosts. But when you have assigned licenses directly to your computers you would need to reassign them.
2 people found this helpful
Like • Show 3 Likes3
Actions
- hameed.iqbal @ carola.iberl on Feb 8, 2019 5:13 AM
  Mark Correct
  Correct Answer
  Hi Mark and Carola,
  I have tried to look at this more closely and below are my observations:
  1st on how the logic of aggregation works in SCCM
  The SIM SCCM connector works on the principle of delta aggregation. That means each time it finishes the schedule aggregation, it will save the scanned date of the device that is the newest in SCCM database. This is saved under 'HKEY_LOCAL_MACHINE\SOFTWARE\Snow Software\Inventory Provider' on the server where SIM is installed. The registry value is called 'LastAggregationDate'.
  And so in the next delta aggregation the SCCM connector will compare the saved value in registry under LastAggregationDate with 'v_GS_SoftwareUsageData + v_GS_LastSoftwareScan + v_GS_WORKSTATION_STATUS | MAX(EndTimeLocal) + MAX(LastScanDate) + MAX(LastHWScan)' in SCCM database for each device. And so only the devices that have a newer 'LastScanDate' then the ones saved in registry will be included for aggregation.
  In your case the logical reasoning that I can come up with SIM version information not being updated in SLM for some devices could be that during the aggregation period those devices were not yet updated in SCCM database and hence not included in the aggregation and they would they would therefore show the previous SIM version info.
  
  As for the VMO connectors like VSphere, they work on the logic of complete aggregation from the corresponding VSphere/VCenter environment in each schedule aggregation. So there is no entry of 'LastAggregationDate' saved in registry when a schedule/manual aggregation is executed. So in this case when the SIM version is updated; in the next schedule aggregation, this should be updated on all ESXi servers in both Snow Inventory and SLM as I would expect that all ESXi servers are aggregated in each schedule aggregation.
  However, I did some testing scenarios on a test server that had SLM 8.3.06 and Snow Inventory 6.0 installed and I am not able to reproduce the issue you have described.
  I did the below test scenarios:
  1. Set the SIM VSphere connector on daily aggregation and aggregated data from VCenter environment h SIM through to SLM.
  2. Next day, before the daily aggregation, updated the SIM to new version and allow the daily aggregation to complete.
  3. Checked and confirmed in Inventory that SIM version info is updated as expected.
  4. Waited for DUJ to completed and confirmed that SIM version info is also updated on ESXi servers there as well.
  
  However, If you guys could provide us some more insights/observation that could help in more investigations, that would be great.
  
  Regards
  Hameed
  5 people found this helpful
  Like • Show 4 Likes4
  Actions
  - Mark.Walther @ hameed.iqbal on Feb 8, 2019 7:30 AM
    Mark Correct
    Correct Answer
    Thank You for the insights into the process SIM uses to update the client version.
    
    In my case it happens more with SCCM than it does with VMWare connectors. It seems like the VMWare SIM versions catch up quicker than SCCM.
    
    Right now I have 1611 computers being inventoried from a 5.13 SIM version, 1 on 5.12, 2 on 5.10 and 3 on 5.9. All in active status. The SCCM aggregation runs without error.
    1 person found this helpful
    Like • Show 1 Like1
    Actions
    - hameed.iqbal @ Mark.Walther on Feb 8, 2019 8:03 AM
      Mark Correct
      Correct Answer
      Ok, can do the below:
      - Sort the 'Last scanned' column un SLM UI under computers tab from newest to oldest.
      Confirm that devices that are still reporting 5.12, 2 on 5.10 and 3 on 5.9 have the newest 'Last scanned' or have somehow older values? Ifvthe values are older compared to the newest value then these devices have not got the upadtes in SCC yet and are therefore not yet reporetd by the connector.
      The fact that that these devices are still showing active 'status' could be due to the settings in Snow MACC on when to put the devices in inactive/quarentine status.
      1 person found this helpful
      Like • Show 3 Likes3
      Actions
      - Mark.Walther @ hameed.iqbal on Feb 8, 2019 8:17 AM
        Mark Correct
        Correct Answer
        The three at 5.9 last scan dates are 1 at 2/3/2019, 2 at 2/6/2019 showing active.
        Two at 5.10 last scan dates are 2/6/2018 showing active.
        The three at 5.12 are in quarantine last scan date of 12/23/2018, so those will fall off soon.
        1 person found this helpful
        Like • Show 1 Like1
        Actions
        hameed.iqbal @ Mark.Walther on Feb 11, 2019 4:54 AM
        Mark Correct
        Correct Answer
        Mark, You can actually preview the devices that are to be aggregated in the SCCM Connector settings. Open the SCCM connector settings, click on 'Data source options' and then in the bottom click ' Preview' (screenshot below). The logic that I had explained initially is based on the column 'AdjustedScanDate'. 'Use config value' option is enabled by default and is based on the settings provided under 'Initial aggregation length'.
        3 people found this helpful
        Like • Show 2 Likes2
        Actions
carola.iberl Feb 11, 2019 8:35 AM
Mark Correct
Correct Answer
Hi hameed.iqbal
First Many Thanks for your detailed explanation. Then I think Mark presumably has another problem than I had.

I noticed that problem only for 3 of our clusters, the other clusters were ok, also after an upgrade of SIM to a newer version.

But meanwhile I removed all that hosts, that showed the wrong old SIM version in SLM. After that they reappeared with the correct new version and now I think my versions are ok.

I cannot tell you what was the reason, but in that cases always the old SIM version was a 4.* version (e.g. 4.3), that was updated to a 5.* version.

If you think it will be helpful, I will create a new support ticket in case this problem appears again.
2 people found this helpful
Like • Show 2 Likes2
Actions
- hameed.iqbal @ carola.iberl on Feb 13, 2019 6:56 AM
  Mark Correct
  Correct Answer
  Hi carola.iberl
  Sure, if you experience this behaviour again then just raise it with Snow and will take it from there :-)
  /Hameed
  2 people found this helpful
  Like • Show 1 Like1
  Actions

SIM version update question

Outcomes

Related Content

Recommended Content