Came across a quick and easy way to test if a mchine is 64bit or not.
echo the windows variable %programfiles(x86)% and pipe it to a txt file then create a variable with the contents of that file. If it is a 64bit machine it should return "c:\programfiles (x86)" if it is a 32bit it will return "%programfiles(x86)%"
Probably well known but first I've seen it and works well so thought it'd be nice to share.
I have used a similar way of using %PROCESSOR_ARCHITECTURE%. If it is 32 then X86 is returned, if it is 64 then x64 is returned. Have tested on different hardware and seems to work well.
The issue with the above method is that a 32bit O/S can still be installed on the 64bit system. I use something similar to the original post in that I look for the WOW64 directory in the windows directory.
Check for file existance
If the machine's been audited, do an IF check on #vMachine.OsInfo# and if it contains 'x64' then it's a 64-bit OS. No muss, no fuss, no false positives because some poorly-behaved software installer has been dinking around in the registry or filesystem.
I think Matt's one wins!
I would agree with GreyDuck's statement on using registry values and the filing system.
Matt's way can fail though if for some reason somebody decides to create the file in the path he checks for on a 32Bit OS, something like a Trojan could do this to hide it self. I have used the 64bit Registry values in the past but I have seen similar flaws where lazy code writers create installers that creates the Wow3264 Registry key path on 32Bit systems, Nvidia's Video driver installer do this and I'm sure there must be others.
I found an oddity earlier this month where an XP machine was reporting as Windows 2003 Server, which I believe may be a Kaseya DB issue as I had to remove the agent from Kaseya without uninstalling it forcing it to rechecking as just redoing the audits did not work. This means the Database Views is not completely flawless, but worth while fixing when discovered.
With the majority of processors becoming 64bit compliant you will eventually see the 64bit tag removed from OS Info descriptions so I betting on WMI values outlasting it.
I use Get WMI Variable;
root\cimv2:Win32_ComputerSystem.SystemType (see: msdn.microsoft.com/.../aa394102%28v=vs.85%29.aspx)
When I execute commands I do an If Check on the WMI value for both x86 and x64 versions and if neither exists the commands won't run and I get a logged alert. This would normally occur if WMI was damaged so also not a completely flawless option :( This WMI value however exists in all the OS's I have to work with XP and up, not to be confused with "root\cimv2:Win32_OperatingSystem.OSArchitecture" that only exists from Windows version 6 (Vista,7 and 2008) and up (found out this the hard way). Kaseya gets lots of its machine information from WMI so in case WMI has failed it would be worth doing something about it to fix it. Also this WMI property value is read only and would be difficult to alter. I have also checked that values don't change for 32bit OS on 64Bit hardware as it still reports the OS bit version rather then the CPU.
So I would say that using the "Win32_ComputerSystem" 's "SystemType" property value is on par with using the Database view #vMachine.OsInfo# in its simplicity to use with the possible potential of being more future proof.
The way I am doing it the moment is;
Check Variable Exists
Download file, install etc..
Check out the registry string on both a 32bit and 64bit system and you'll see why I'm using it.
I remember reading a post here in the forum can't remember by who I think it was Ben from Kaseya and he said that this value is not always as described not sure if it is a variant of OS.
I don't use it so am not 100% but I do remember reading it in the forums (could be the old forum)