Windows Vista clients doesn't inventory 32-bit software #901
Comments
eduardomozart
changed the title
|
Hi @eduardomozart Also did you have the right inventory with older agent version ? Did you try the agent 32bits version ? Also is it possible this old FF version is installed only in the user profile ? If this is the case, it won't appear in inventory as you have The About the Office licensing not detected, this is normal on Vista as I can read in MSDN |
|
Hello @g-bougard, thank you for your answer! I'm sending below the Firefox is being listed into this subkey, so I'm not sure what's happening, maybe the code is trying to access About the Office, I have another issue open about it, and I would like to discuss about it's detection methods there. I would like to upgrade these machines to a newer version of Windows and, believe me, I'm doing my best to do so. Sadly our IT budget is small and we have softwares that only runs into Windows, so I can't adopt Linux distros (it doesn't run even through Wine). Only last year I get to replace all our Windows XP machines with Windows 7, but licensing Microsoft software into my country is extremely expensive, it's more than the income of one labor worker for 1 entire month per license. I still have four Windows Vista machines into our environment that I pretend to replace it for Windows 7 machines soon, but it's still a problem because Windows 7 is already EOL, but it's better than Vista. I still have two Windows XP machines to replace. |
|
Hello @eduardomozart Can you report the output of the following command ? About the other issue about Office, I still wait for an answer to my questions. |
|
Hello @g-bougard! The OSPP.vbs that is embeded into Microsoft Office also uses a similar approach: https://stackoverflow.com/questions/55485073/how-to-programmatically-distinguish-excel-2019-from-2016?rq=1 I searched through the FusionInventory-Agent repository but couldn't find any reference to the I still didn't replied the Office opened issue because I'm rewriting the OfficePack script from OCS Inventory NGS with my findings about Office edition and product key detection. It's a VBScript file, but I pretend to write a logic that can be easily ported to Perl so it can be integrated into FusionInventory-Agent into the future. Here's the output for the |
|
Hi @eduardomozart About your about, it shows the expected Anyway if I check carefully your agent log, I can find some software with ARCH set to i586 so they were inventoried at the same place than where should have been FF. And this is really weird as this includes the agent itself but it seems to be the 64 bits release (Name is "FusionInventory Agent 2.6 (x64 edition)"). But can you double-check you really have Firefox 32bits installed the same way on that WINVISTAVM-PC-2021-02-13-13-38-57 PC ? I mean are you sure the log has been generated on the same computer that the one you reported registry key and wmi output ? |
|
If you check the agent log you firstly joined, I can see 8 softwares with ARCH set to i586. These softwares must have been listed reading |
|
Yes, I can confirm it is the same machine. I'm attaching the Process Monitor log for this machine. As you can see, the Perl executable is querying "HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall" key, but doesn't "HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/Windows/CurrentVersion/Uninstall" (note the Wow6432Node). The Firefox isn't being shown into the Process Monitor log, but it exists into "HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/Windows/CurrentVersion/Uninstall" key. There's some code detection that is avoiding the agent from querying this key or the query isn't being executed at all. I have other Windows 7 and Windows 10 x64 machines and it doesn't happens. |
|
You're saying:
But the agent will set "i586" as ARCH only for software seen under "HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/Windows/CurrentVersion/Uninstall" (note the Wow6432Node). So something is wrong in what you're reporting. Maybe Vista is just lying as in your process LogFile we can see FusionInventory-Agent is read from "HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall" (without Wow6432Node). Maybe Vista has some hidden binding to match Wow6432Node into the normal registry key, but in someway it fails to register FF using that bindings... And even if this is the case, why FusionInventory-Agent x64 is reported as 32 bits ? |
|
Here's the Uninstall log from "HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall" (without Wow6432Node): You can compare this file with the Wow6432Node-Uninstall.reg.txt uploaded earlier and you can see that those "I586" software are into "HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall" key (without Wow6432Node) instead of "HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/Windows/CurrentVersion/Uninstall" (note the Wow6432Node). I'm not sure how FusionInventory-Agent are reporting them as "I586" software if it only considers softwares that are into "HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/Windows/CurrentVersion/Uninstall" (note the Wow6432Node) as being "I586", as it's clearly querying the "HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall" key (without Wow6432Node) instead. Maybe it's another bug underneath? |
|
Indeed now I see in your log the same list of softwares with x86_64 and i586 as ARCH. This means to me Vista is doing some bullshit when we request "HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node". After few readings, can you try the following patch ? diff --git a/lib/FusionInventory/Agent/Tools/Win32.pm b/lib/FusionInventory/Agent/Tools/Win32.pm
index b59980324..245bcdada 100644
--- a/lib/FusionInventory/Agent/Tools/Win32.pm
+++ b/lib/FusionInventory/Agent/Tools/Win32.pm
@@ -381,8 +381,9 @@ sub _getRegistryRoot {
my (%params) = @_;
## no critic (ProhibitBitwise)
+ my $WOW6432Flag = $params{keyName} =~ /Wow6432Node/ ? KEY_WOW64_32 : KEY_WOW64_64;
my $rootKey = is64bit() ?
- $Registry->Open($params{root}, { Access=> KEY_READ | KEY_WOW64_64 } ) :
+ $Registry->Open($params{root}, { Access=> KEY_READ | $WOW6432Flag } ) :
$Registry->Open($params{root}, { Access=> KEY_READ } ) ;
if (!$rootKey) {If it works, can you also test it on all other platforms you're using ? |
|
Hello @g-bougard, I applied your patch into Win32.pm file but the issue still persists. Debugging the perl.exe process through Process Monitor, it isn't enumerating the "HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/Windows/CurrentVersion/Uninstall" (note the Wow6432Node) and still log the same list of softwares with x86_64 and i586 as ARCH. The Process Monitor shows that the "HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall" (without Wow6432Node) is being enumerated twice. I created a zip file containing the FusionInventory for GLPI xml file, the FusionInventory Agent log file ( |
|
We rewritten agent 2.6 in new language. I close this issue. If you will have the problem with version 3.0 (when it will be released), create a new issue. Thanks |
GLPI: 9.5.4
FusionInventory for GLPI: 9.5.0+2.0
FusionInventory Agent (Vista machine): 2.6 (x64 edition)
Windows Vista (SP2) x64 isn't inventoring 32-bit software. Into the screenshot below, Mozilla Firefox is being shown into "Add/Remove Programs" list from Windows:
But, as can be seen into the agent log with the config
debugset to2, it isn't being detected during the inventory task:fusioninventory-agent.log
It also affects other sofware, like Office. Into this case, it's a virtual machine that I didn't installed Office into it, but other machines with Windows Vista isn't reporting the Office 2010 installed and also it doesn't detect it's serial number during the WMI query to SoftwareLicensingProduct.
After executing the inventory task, the following message is also thown into Command prompt:
It happens right after the XML file is printed into XML file, but I'm not sure if it's related to this issue.
Here's the machine inventory exported from FusionInventory for GLPI (no problem sharing it - I created a virtual machine with Vista with no serial attached into it, so we can use it to debug the issue):
41.xml.txt
No error is being thrown into Apache
errors.logandaccess.log, neither<GLPI_ROOT>\files\_log\php-errors.logfile.Here's my full GLPI information:
The text was updated successfully, but these errors were encountered: