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.
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.
Thank you for your interest in this feature request. Please continue to vote this up to move it up in priority for future release consideration.
What I did was disable reboot notification for my sites that complained too much about mulitple reboots. Sometimes it was 3-4 reboots to complete a monthly patch cycle. I ask that they reboot before they go home each night. I also send myself notification of users who haven't rebooted in over 5 days. I then manually send those users an email asking they reboot nightly. It's a pain, but it gets the job done.
Please figure out a way to minimize the number of reboots needed during patching.
Note that the date does appear on the download page now. But this has been added to the feature request list. We encourage others to vote as we use this input for prioritizing our release plans.Ray Jasutis shared this idea ·
This would be a HUGE timesaver. When creating a script, managed install, schedule, etc. it has to be imported to each org individually. When a change is made, to the script, managed install, schedule, again, the change needs to be made individually to each orgs.
The K1000 supposedly automates tasks. The way orgs currently are designed involves a lot of manual work for a K1000 admin.