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.
Thank you for your input. Offering both 32 and 64 bit clients would double our Windows agent QA testing time and we are sensitive to the impact of extending test times as it impacts our ability to release full-featured updates at our desired pace. A surprisingly large amount of our customers still need 32bit support today. We are going to continue monitoring this closely to determine the best time to drop 32 bit support (of course older versions of the agent would still be available once we moved to 64 bit). In the meantime, it would be helpful to know specifically what difficulties a 32bit client is causing so we might consider work-arounds in parallel with the 64bit only decision.
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.
Mike Morales commented
100% of our workstations and servers are x64. We have over 350 endpoints. I am in favor of a 64-bit Agent...!
Searching for 64-Bit registry keys that simply do not exist in Wow6432node means that I can't run scripts based on the presence of certain registry keys. This is a HUGE deal when you're trying run a script against machines or servers in a pending reboot state.
Says it does not exist, when in fact it does.
I find that calling 64-bit processes through the 32-bit KACE agent results in broken functionality and "work arounds" are either hit or miss. One of my projects involved Bitlocker and this issue caused me much grief.
I am also understanding to the KACE teams reluctance to release a 64-bit agent. In the mean-time I believe other solutions (such as making the agent aware of 64-bit processes) would be a great step forward.
Graham Wilton commented
The agent is entirely DOS and batch file based, even though the world has been vbscript since Windows 2000 and PowerShell since Vista. Kace don't understand why a 64-bit client is needed confirms what I already knew from using this product for 3 years. Kace do not understand the basic environment the tool is used for. I get round the limitations by ignoring the Kace user interface and features and write all my logic in PowerShell, compiled to an EXE to avoid black command screen pop-ups.