Kaseya Community

Determining 64-bit vs 32-bit systems...

  • I'm having a heck of a time determining what type of bit level my workstations are running at from a Kaseya procedure. In particular there are times when I need to gain access to sub dirs of "Program files", but with 64-bit systems, that may mean "Program Files (x86)" and I'd rather not have to duplicate all of the commands, each for "Program files" and then for "Program Files (x86)" for all of my scripts. I'd much rather check for 64-bit, and set a variable.

    I had though to check for the existence of environment variables that are unique to 64bit systems (Like %ProgramFiles(x86)%", and I can do that from cmd.exe locally on the computer, but I cannot do the same through "Execute Command Shell" because it forces me to run in 32-bit mode or 64-bit mode... if I run in 32-bit, I don't see %ProgramFiles(x86)% set, and I have no idea what happens if I choose to run in 64-bit mode on workstations that aren't 64-bit (I assume it will fail).

    How are you guys doing it? get variable, wmi property? SQL view data? I'd like to avoid using WMI as there may be circumstances where WMI is broken on the machine, and I'm loath to use SQL view data as it may not be up to date, or the data may not have populated yet.

    Legacy Forum Name: Determining 64-bit vs 32-bit systems...,
    Legacy Posted By Username: Zestysoft
  • One method I have used involves this registry value:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\PROCESSOR_ARCHITECTURE

    If it contains "x86" then you are dealing with a 32-bit operating system.

    Another way is with a SQL view: #vMachine.OsInfo# (contains x64?)

    We can also get tricky with environment variables, launching different command prompts (syswow vs sysnative), or testing the Wow6432Node registry key.

    Legacy Forum Name: Scripts Forum,
    Legacy Posted By Username: SMason
  • SMason
    One method I have used involves this registry value:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\PROCESSOR_ARCHITECTURE

    If it contains "x86" then you are dealing with a 32-bit operating system.

    Another way is with a SQL view: #vMachine.OsInfo# (contains x64?)

    We can also get tricky with environment variables, launching different command prompts (syswow vs sysnative), or testing the Wow6432Node registry key.


    I really like this subject... OK not really, it hurts my head as there are so many ways of doing this...

    Just to chime in on the second method, it isn't always 100% just yesterday I was trying to stuff XP SP3 down the gullet of an XP 64bit machine (via script mind you) because Kaseya didn't pick it up as a 64 bit machine... Well it didn't until I re-audited it... IMO the last couple of options that SMason suggested is the better ways of doing this... The reason why I didn't like the first is I'm not sure how that'll affect machines with 32bit OS's on a 64bit proc.

    Legacy Forum Name: Scripts Forum,
    Legacy Posted By Username: thirteentwenty
  • We test for the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node registry key.

    Always use the %programfiles% variable in your scripts and *never* hard code C:\Program Files\

    Legacy Forum Name: Scripts Forum,
    Legacy Posted By Username: XeviouS
  • XeviouS
    We test for the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node registry key.


    I've started using this key to test also, it seems to be the most reliable... how ever I do recall in another post someone saying that they key is sometimes in a 32bit registry also, but I haven't seen it...

    Legacy Forum Name: Scripts Forum,
    Legacy Posted By Username: thirteentwenty
  • That key will exist on a 32-bit operating system if a poorly-coded program (or script) had created it. This happens when the author thinks they are being clever by writing a 32-bit key on a 64-bit operating system. However, if there was no check to begin with, that key will be created wherever the program/script is run. Sad

    Legacy Forum Name: Scripts Forum,
    Legacy Posted By Username: SMason
  • This really depends on what you're trying to do. For most cases, use the Kaseya view and you'll be fine...test #vMachine.Osinfo#. It's rare you should be running a script prior to that being populated (not that you can't, just that you shouldn't).

    Also, you don't have to get variable for it, SQL view information can be pulled without the get.

    As an example:

    Script Name: Is it 64 bit?
    Script Description:

    IF Check Variable
    Parameter 1 : #vMachine.OsInfo#
    Contains :x64
    THEN
    Write Script Log Entry
    Parameter 1 : Is 64 Bit
    OS Type : 0
    ELSE
    Write Script Log Entry
    Parameter 1 : Is not 64 Bit
    OS Type : 0


    Legacy Forum Name: Scripts Forum,
    Legacy Posted By Username: Intech-Jason
  • That's pretty slick... I can confirm that #vMachine.OsInfo# does the trick pretty well. I just built a quick little 7-Zip deployment script in K2 using that. If x64, write and run the 64-bit MSI. If no x64, write and run the 32-bit EXE. Nice!

    Legacy Forum Name: Scripts Forum,
    Legacy Posted By Username: GreyDuck
  • Someone previously suggested,

    Check for the existence of the C:\Program Files(x86) folder. You can directly test for it.

    Alternatively, if this is for a specific program, you can test for the existence of a file in that program in either location.

    Legacy Forum Name: Scripts Forum,
    Legacy Posted By Username: dwujcik