glpi-project / glpi-agent

GLPI Agent
GNU General Public License v2.0
240 stars 60 forks source link

Software Inventory - Windows - Installation Date is not refreshed #593

Closed Frflamingo closed 8 months ago

Frflamingo commented 8 months ago

Bug reporting acknowledgment

Yes, I read it

Professional support

None

Describe the bug

The "installation date " property of a software is never updated , only fetched at first discovery

To reproduce

On windows

Expected behavior

Installation date should be refreshed at each inventory ie should be date2

Operating system

Windows

GLPI Agent version

1.5

GLPI version

10.0.11

GLPIInventory plugin or FusionInventory for GLPI plugin version

GLPI Inventory v1.3.4, GLPI Inventory v1.3.3

Additional context

No response

g-bougard commented 8 months ago

Hi @Frflamingo

I presume this will works for some software but not for others. As far I know, windows doesn't care about storing an installation date most of the time. Then to estimate an installation date, the agent is simply checking at which date the related registry key is created. In the case of a reinstallation, if the related registry key is not removed during uninstall step (and I guess this happens most of the time), then the first installation date will remain.

Can you try to fully uninstall the software, then install it again, and finally check what installation date the agent is reporting ?

If you want to investigate your case, I can guide you to check for a given software what to check. To start, just run glpi-inventory --partial software from an administrative console and from the agent installation folder. This will provide you a json inventory as output. Then just share the json node related to the software you want to investigate.

You can also share for that software the way you're reinstalling it. Maybe this can help to reproduce or maybe we can help you to use a process which will help the agent to detect a reinstall.

If I'm right, we probably won't be able to fix as we are not a package manager and windows doesn't provide such a tool for your case.

Frflamingo commented 8 months ago

hello I have a task that is updating the registry key every day . It is indeed reflecting in the add/remove panel , but on Glpi only the first date is shown

Frflamingo commented 8 months ago

My guess is that we should retrieve this registry key as some others and update if necessary "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall" + Key + "InstallDate"

Frflamingo commented 8 months ago

i could also find this one : https://forum.glpi-project.org/viewtopic.php?id=288375

g-bougard commented 8 months ago

Hi,

my concern, as I tried to explain, is we still trying to make the right assumption but I guess sometime this may fails. And if you have a real case, please share it providing the glpi-inventory partial inventory extract from the agent as I told you.

For software extracted from HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall, most ones have an INSTALLDATE key, and we use it firstly as installation date. Maybe this is wrong ? For few ones, that key is missing: on my windows test vm, this is the case for 7zip & firefox. For example, firefox is often updated and in that case we get the LastWrite attribute from its key registry and this just works, we have the installdate set to the last update. You can find that date when exporting as "txt" file using regedit. Here is an example from my test vm after the last update:

Nom de la clé :          HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Mozilla Firefox 121.0.1 (x64 fr)
Nom de la classe :        <Sans classe>
Heure de dernière écriture :   1/15/2024 - 3:06 PM
Valeur 0
  Nom :            Comments
  Type :            REG_SZ
  Données :            Mozilla Firefox 121.0.1 (x64 fr)

...

Here the LastWrite is 1/15/2024 and I find 2024-01-15 in the json partial inventory for that software. Of course, this is what I see in GLPI. The same is done on HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall.

So:

I have a task that is updating the registry key every day . It is indeed reflecting in the add/remove panel , but on Glpi only the first date is shown

Okay... can you provide the datas we need to show glpi-agent is not making the job ? We need:

Also can you explain what you mean by I have a task that is updating the registry key every day ? What that task is doing exactly ?

Frflamingo commented 8 months ago

hey . The extract of the command is below (made a subset of it) { "arch": "i586", "from": "registry", "guid": "XXXXX", "install_date": "2024-01-30", "name": "XXXXX", "publisher": "XXXXX", "system_category": "application", "uninstall_string": "N/A", "version": "1.0" },

The result is show here image

And the registry is like image

Also the LastWrite Time is seen as : Class Name: <NO CLASS> Last Write Time: 30/01/2024 - 09:00

Frflamingo commented 8 months ago

So from what i see , it looks the agent is properly gathering the info , but it is not updated server side .Could it be rather a glpi inventory plugin issue ?

g-bougard commented 8 months ago

You first need to check when the last inventory was received. You can also download the last received inventory from the asset page and check what is reported for your software, it should be 2024-01-26. But as I can see too, the software still provides the InstallDate and glpi-agent will use it first.

So I'm closing the issue as there's no issue. But you still can update it if you don't understand why the expected data is not reaching GLPI and I'll try to help you to find what's going on.

Frflamingo commented 8 months ago

Inventory is refreshed very 2h (i know) - Last update on 2024-01-30 09:44

Is the last inventory received accessible through Asset-> Computer -> Download inventory file ? If yes this is the result

{ "arch": "i586", "from": "registry", "guid": "XXXX", "install_date": "2024-01-29", "name": "XXXX", "publisher": "XXXX", "system_category": "application", "uninstall_string": "N\/A", "version": "1.0" }

Whcih is correct .... so indeed looks like a server side issue

Thank you