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.Dave Dewire commented
If you want to deploy a vbs or powershell script, you would use wscript.exe or powershell.exe with the script name. Since the Kace client is running as a 32 bit process, it automatically calls the 32 bit version of wscript or powershell. Since windows redirects 32 bit processes to the 32 bit system folder and the 32 bit registry keys, you can not do anything that requires 64 bit functionality. For example, if I need to run a powershell script to make changes to my Microsoft App-V 64 bit client, those powershell commands are not available in the 32 bit versions of powershell. I must call the 64 bit version of powershell. If My vbs script needs to read/write to the Wow6432 node, it must be done from the 64 bit version of wscript. In order to do that with the 32 bit kace client I first have to run a script that determines if its a 32 or 64 bit OS, then from there call the actual script using the correct versions of wscript or powershell. Anotherwords in order to run a vbs or powershell script thats is 64 bit specific, I have to use 2 scripts instead of one because the Kace client is not 64 bit. The only other option is to use multiple distrubutions or scripts with explicit paths for the correct 32 or 64 bit wscript or powershell paths and then limit the OS that they can each be ran on. If I had a 64 bit Kace client, I wouldnt have to do either of those things. Im sure there must be other examples.
103 votesDave Dewire commented
I agree, the current permissions are to simple. I just had someone rename an asset type and it doesn't even log who did it let alone prevent them from doing it.
This request is under review for a future release. Please continue to vote to voice your support.