Improved handling of 64 bit Windows
Running scripts on 64bit clients are limited to the 32bit environment. An example is registry keys. There is no way to access the 64bit registry hive as the kbox client only sees the wow6432node, 32bit, registry hive.
In 10.0 this problem was solved natively.
Example for runkbot task to check registry key exist on 64 bit OS
HKLM\Software\ABC (No extension, this is checking under HKLM\Software\WOW6432Node\ABC)
HKLM32\Software\ABC (32 extension specified, so checking HKLM\Software\WOW6432Node\ABC)
HKLM64\Software\ABC (64 extension specified, so checking HKLM\Software\ABC, not the WOW6432Node redirect)
We added “NAT” extension in addition to 32 and 64, which would mean use the OS native (64 on 64 bit OS, 32 on 32 bit OS).
64 bit OS HKLMNAT\Software\ABC → HKLM\Software\ABC
32 bit OS HKLMNAT\Software\ABC → HKLM\Software\ABC (there is no redirect space anyway on 32 bit OS)
Aki C commented
please either release a 64bit client or build in the appropriate scripting logic to the SMA so we don't have to continually jump through hoops to accomplish what should be simple tasks to access 64bit areas of the OS.
Justin Stanford commented
Ken Galvin / Kace:
Can you please provide us an update? The last response here is from February 2015 (!) and 32-bit has been dead for some time now. This poll shows 32-bit Windows 7 at .59% of market share (https://www.pcbenchmarks.net/os-marketshare.html) and NVidia and others have discontinued support for 32-bit OS altogether.
It's simply frustrating that Kace is refusing to provide an agent for the far-dominant architecture and also refusing to give us an update here in this forum.
Closing in on 2020 and 32bit OS is used less and less. 9 years later we are still up voting this!
I also have to say that the 32Bit client OS area is gone. All machines we install since years are 64bit machines..really rarely 32bit for special environments like R&D or quality control.So 95% of all systems are running 64Bit, why we still need to suffer with a 32bit client as a default. should be wise versa. I would like to have full 64bit support and I can also accept a functionality reduced 32bit client version.
Justin Stanford commented
Ken can you please provide an update here- the last was from four years ago. I haven't seen a 32-bit machine deployed in many years and frankly we're tired of the workarounds, detailed in this thread, and having to jump through hoops to accommodate what has to be a shrinking base of 32-bit machines. Many software vendors support both, why not Quest?
The agent itself does not need to be 64-bit to improve the problem. But as it stands, you have to trick it into running a lot of custom scripting correctly on modern systems. At the very least, there should be some automated trickery to make sure that scripts are running in 64-bit context if needed. I got people writing scripts in my organization using %ProgramFiles% in batch files, and getting 64-bit programs thrown into C:\Program Files (x86). I have scripts that I need to copy files into System32, and they end up in SysWOW64. And I never know what's gonna happen when I mess with a registry value.
Some behind-the-scenes stuff can be done. If the KACE agent detects it's on a 64-bit machine, it could have an option to catch stuff that's going to run out of %SystemRoot%\System32 or similar and run out of %SystemRoot%\Sysnative instead, so it won't be redirected to %SystemRoot%\SysWOW64.
I'm new to the KACE game, coming from SCCM. On the one hand, the web interface is fantastic and I find it really easy to work with. I greatly prefer working in the back-end of KACE to SCCM. And that's really important.
But on the other hand, I get the impression that the client-side stuff hasn't gotten a noticeable update lately aside from the blue-to-orange "makeover" after the Dell-to-Quest change. So it's very jarring going from the ultra-modern sleek web interface to a user-side system that feels like it's perpetually stuck in the early 2000s, both aesthetically and functionally.
Based on the number of votes, our presenters were asked to poll the session attendees about this at our recent KACE UserKon 2018. Surprisingly, the response was overwhelming that pursuing the addition of a 64 bit agent instead of other features was not a good investment of resources. There was also a legitimate concern that offering two agents would add potential confusion and complexity as well. We will likely stay with the 32 bit agent only for the near future.
Deric Curtis commented
515 votes and number 5 in the most voted for feature request. Why is this not getting any kind of attention that we can see of?
501 votes for something that should already have happened years ago, and no further response since 02/2015. People are moving away from 32-bit. If anything, support for 32-bit should be the one getting the short end of the stick here!!
Robert Becker commented
Note that the C:\Windows\Syswow64\cmd.exe is the 32-bit command processor. This can be discovered by running that program directly from Start Run, then opening the Task Manager. C:\
Windows\System32\cmd.exe is the 64-bit command processor on x64 computers.
Robert Becker commented
Say I have a Kace script that calls a batch file. If I tell the script to run a program and specify the batch file directly, it works on an x64 computer but not on an x86 computer. I have found that on x64 computers the appliance is calling c:\Windows\Syswow64\cmd.exe. I suspect it's attempting to call that command processor on x86 computers, and that directory doesn't exist on x86 Windows.
Please change it so the script engine figures out which architecture it's looking at and runs the correct command processor.
Deric Curtis commented
When running 32bit command line in the back ground of Windows 7 64bit. I get "Interactive Services Detection". This is for processes like cmd.exe and msiexec.exe. When ran from C:\windows\SysWOW64.
Don´t forget to implement natove IPV6 support.. its already a shame to not have 64Bit nor IPV6 support.. we have 2017!!!!
Looks like the linux agent does not support 4Go+ packages. It downloads them each time it makes it's inventory. Maybe related to 32bit version of it ?
Ray Jasutis commented
I've spent countless numbers of hours troubleshooting issues because of this before I realized a the 32bit client didn't recognize the 64bit architecture. It seems support wasn't aware of the limitation either since they spent time on the phone with me troubleshooting. I can't imagine more of your clients are still using 32bit systems rather than 64bit.
Maybe you can add an option to run the script, CIR, etc as 32 or 64bit as a workaround. 64bit will point to the wow6432node key or syswow64 folder . It can't be that hard to implement as a workaround until then.
Who run a 32bit OS in 2016? maybe the new owners of Kace will see some value is supporting 64 OS reg keys.
Dude you don't have to double your workload! Check the damn box in visual studio for compiling a 64 bit executable!!!! Firefox did it. Google do it. Java did it. Adobe did it with flash. You all can't figure it out??
its not 2005 any more dell. get with the problem
Christopher Little commented
Your competitors already have this feature and have for years. This is just one of a long list of reasons I recommended my former company NOT switch to Kace from IBM Endpoint Manager.
Why is this still an issue in mid-2016? Get this resolved, Dell. Are you guys planning on killing the K1000 or something? Why are you not supporting your product?
Admittedly, it's been a while since I did software development, but at least back in 2011, creating a 64-bit version of a 32-bit application wasn't overly difficult. Is it work? Sure. But you have an ACTIVE PRODUCT. Do the work and get it done.
If you have to choose between 32-bit and 64-bit, choose 64-bit. Deprecate the 32-bit version, and support it through January 31, 2020 (the same as Windows 7). Then, support only the 64-bit version. At that point, the existing 32-bit version would continue working; it just wouldn't be supported with new updates, anymore.