I currently have SCCM installed and am trying to use WQL queries with SCCM using the win32reg_addremoveprograms class. My issue is, when I test using a powershell query, the 32 and 64 bit queries both return 64 bit applications and no 32 bit applications. Example:

Get-WmiObject -Query "Select * from Win32Reg_AddRemovePrograms64 where DisplayName like '%Java%'" | select DisplayName

Get-WmiObject -Query "Select * from Win32Reg_AddRemovePrograms where DisplayName like '%Java%'" | select DisplayName

Both of these return the same list, and they are all 64-bit applications, and I do have java 32 and 64 bit versions installed.

Is this a Powershell issue?  I don't think so.  Use Get-ItemProperty, or use the Registry Editor to verify that the results are correct. 

If the results of Regedit differ from the results of your WMI query, the problem lies with WMI, not Powershell.  Any scripting language that accessed this WMI class would get the same re

When running Powershell (x86) I only get 32-bit applications when querying Win32Reg_AddRemovePrograms64 and Win32Reg_AddRemovePrograms. When running Powershell (x64) I get the 64-bit applications. Is this still a WMI issue or is something else going on?

im guessing that java installs both runtimes for application compatability.. or maybe you have multiple version... im not sure... its probably a java issue... we have a ton of problems with java runtime here at work...   the reason that 32bit powershell only finds the 32bit apps is because windows limits its exposer to things..   so are the two lists the EXACT same, or do you just have a duplicate of java?    

The lists are the EXACT same, and this is not a duplicate of java. This is the case when doing any query using those classes. I believe it has to be an SCCM issue, due to the fact of doing a Win32_Product query gives me both 32 and 64 bit applications and is not dependent on what version of powershell I run.

hmm I went to look it up in MSDN to see if there were tech details, I dont see it... I wonder why that is... perhaps its not supported? kinda weird    

Yes, you are right. You must be running script on 64 bit computer. I am looking for more detail around it. However you may find following link interesting. It is exactly the same you are trying to achieve but with different approach.

Ref: http://www.windowsitpro.com/article/scripting/Auditing%2032-bit%20and%2064-bit%20Applications%20with%20PowerShell-136129

Hi,

I tested in my lab, the same result

Get-WmiObject -Query "Select * from Win32Reg_AddRemovePrograms64 where DisplayName like '%c++%'" `
| select DisplayName
Get-WmiObject -Query "Select * from Win32Reg_AddRemovePrograms where DisplayName like '%c++%'" `
| select DisplayName                             
  

When run the command with Powershell x86, only find out the 32 bits software.

When run the command with Powershell X64, onlu find out the 64 bits software.

Best Regards,

Seems to me that this is not working as intended and is an oversight. This was primarily for me to test WQL statements for SCCM. My main issue in SCCM though is, when I do WQL queries for my task sequence logic, only the 32-bit queries work, as I believe the SCCM process is a 32-bit process which would explain why it never works for the 64-bit wql queries.

Thank you for your response. I had read this article, and it is a solution to being able to get all the information, but it does not solve my root issue, and is more of a patch than a solution.

I dont know SCCM but my guess would be that the agent is a service, and the service would have to be the same as the OS (64/32) so im not so sure thats the case, unless it spawns something else and just uses the 32bit by default... more of an SCCM thing really..   so it sounds more so like your question is about SCCM and how its running these tasks...    

This is an old topic but I hope someone picks up. I ended up with the same trouble just recently.

What I can add to this, is that when you run wbemtest and check the classes' class contect, both show the same regkey path:"local|HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall"So I was trying to run wbemtest from a x86 powershell console - well to my surprise it cannot run. Even if you go to %systemroot%\system32\wbem and do a dir, wbemtest.exe is not shown... lol.

If you export from HINV classes (in client settings) and check the generated mof file though, the respective classes have this context entry:

  SMS_Context_1 ("__ProviderArchitecture=32|SInt32"), - for win32reg_addremoveprograms

and

  SMS_Context_1 ("__ProviderArchitecture=64|SInt32"), - for win32reg_addremoveprograms64

I do not understand mof this deep, but i believe this would define the architecture context in which querying the class would happen. Anyway though, this still disturbs me a lot as I assumed one will be for regular uninstall regkey parsing, the other would be the same under wow6432 node.

I guess this is to avoid issues on x86 architectures? Or bad design?

@Chris - have you come to any conclusion since then?

Cheers

cgsilver

• Edited by cgsilver 2 hours 31 minutes ago