I would like to be able to give my users the flexibility to schedule installs of patches at a time that suits them ... for example, when the popup appears on the client PC, offer them a range of options such as:
-- install now
-- remind me in 1 hour
-- remind me at 11:00am
-- install when I next shut down

It would be great if end users could initiate patching. Right now they can OK or Snooze a patching message, but are not notified again until the snooze interval is up. Right now we have that set at 60 minutes. But if a user is heading to a meeting, it would be great to allow them to begin patching when they leave their desk.

I find that patching fully from Microsoft Updates may require 4 reboots on an OS like Vista SP2. Patching that OS with Kbox, might require 10 or 15. End-users don't like reboots. Optimizing patch deployment to a system would be greatly welcomed to reduce the restarts a workstation/server needs.

With the new model of Windows updates, we need to be able to easily push these feature updates such as Anniversary Edition via the KACE in order for it to fully replace the current functionality of a WSUS server.

Regarding the Patching Schedule Reboot Options, I was hoping to see an option that is between “Force Reboot” and “Prompt User”. What I was looking for was “If there is a user logged on, then prompt user” and “If there is no one logged on Force Reboot”.
We have a few hundred machines (student and faculty/staff) that get patched every night. I want to make sure that the machines get patched (and may need a reboot) and not wait till someone uses the machine to reboot, so forced reboot is great. But, then again, I don’t want a student working on his thesis to lose his work as he stepped away from the computer.

Regarding the Patching Schedule Reboot Options, I was hoping to see an option that is between “Force Reboot” and “Prompt User”. What I was looking for was “If there is a user logged on, then prompt user” and “If there is no one logged on Force Reboot”.
We have a few hundred machines (student and faculty/staff) that get patched every night. I want to make sure that the machines get patched (and may need a reboot) and not wait till someone uses the machine to reboot, so forced reboot is great. But, then again, I don’t want a student working…

To increase our patching run rates and to better manage network bandwidth, we’d like the ability to pre-stage required patches on systems and kick off the installation at a designated time; preferably, the appliance tells the agent to start its patching cycle at the designated time (especially for devices off-network like laptops).

It's my understanding that staging doesn't occur with just a detect; the updates are only copied down during the deploy phase.

What if Lumension / Kace issued a patching notice / update to admins who register for it? It could be a weekly email thing. In it Lumension could outline newly released patches (MS, et al.) and the projected release dates from Lumension down to our Kboxes. As admins we would know that certain patches we are looking for are in the pipeline and their ETA dates. Now, as admins, we are no longer in the dark wondering where our patches may be. It would keep emails or support tickets from being produced based on 'missing patches'...of which I've sent several lately. If a support ticket of this type were put in going forward it could then become more of a request to add something that may have been overlooked. This email could also alert admins to patches that we weren’t even aware were coming down from the software manufacturer.

Just spit balling a thought that just ran through my head:

What if Lumension / Kace issued a patching notice / update to admins who register for it? It could be a weekly email thing. In it Lumension could outline newly released patches (MS, et al.) and the projected release dates from Lumension down to our Kboxes. As admins we would know that certain patches we are looking for are in the pipeline and their ETA dates. Now, as admins, we are no longer in the dark wondering where our patches may be. It would keep emails or support tickets…

K1000 should (through inventory detection) be able to determine that the machine has BitLocker enabled and during a patch deployment of that machine, there should be an option to suspend BitLocker (manage-bde –protectors –disable c:) before the reboot so the patch job does not get stuck at waiting for a user to enter the BitLocker PIN. If multiple reboots are required the K1000 can continue to disable BitLocker in a Detect & Deploy job until all patches have been installed. After which BitLocker can be resumed. This would be a HUGE help if it can be added to the product. Thanks.

K1000 should (through inventory detection) be able to determine that the machine has BitLocker enabled and during a patch deployment of that machine, there should be an option to suspend BitLocker (manage-bde –protectors –disable c:) before the reboot so the patch job does not get stuck at waiting for a user to enter the BitLocker PIN. If multiple reboots are required the K1000 can continue to disable BitLocker in a Detect & Deploy job until all patches have been installed. After which BitLocker can be resumed. This would be a HUGE help if it can be added to the product.…

Company with about 500 machines off which > 400 work from remote locations often.

When a machine is not connected to the company network, it would download it's microsoft updates directly from microsoft. When inside the company network it would download it's updates from the replication shares.

With a Pacthing Workflow you can add in functions such as separate OS and Application patching schedules, Notifications, Scripts, Machine actions, etc. and have them all run within a set overall time and recieve vaulable notifications as the process is running or if something isn't working.

Currently I have to run scripts before and after certain servers are patched to manage applications/services so a Detect and Deploy job with multiple reboots doesn't corrupt data. Whenever a schedule time needs adjusted, changes have to be made all over the place to prevent potential unplanned outages and have functional patching sessions for my servers.

How would this ideally look:
Workflow: Provide a if/then ability for each step based off success/failure.
Workflow Schedule: Allow the time to be set to run and end at a specifc time just like a patching schedule, make the time value available throughout the workflow builder to help keep all steps managed.
Scripts: allow them to run with specific domain service accounts (Securely stored passwords would be a requirement)
Scripts: Powershell is a must.
Scripts: setup a time frame for them as well with some way to kill the process if it doesn't complete in time.
Notifications: set a notification option inside every step of the workflow.
Step Time Management: Set a minimum/maximum time for each step that runs inside a Workflow and a check against the overall workflow alloted time to verify that all the step minimum/maximum values are capable of completing in the workflow.
Machine Actions: Reboot, Shut Down, Run a program locally, etc.

Caveats:
I haven't done more than a cursory glance at scripting in KACE, maybe some of the features for Scripts already exist.
The time management of the steps would be a pain to build out and get running smoothly, but the ability to take a designated workflow that's been setup correctly and change the start time to a different date/time would save much time and aggravation and be much safer when managed from a central place vs. KACE and various other machines running scripts via Task Scheduler.

KACE needs the ability to build out a patching session as a workflow.

With a Pacthing Workflow you can add in functions such as separate OS and Application patching schedules, Notifications, Scripts, Machine actions, etc. and have them all run within a set overall time and recieve vaulable notifications as the process is running or if something isn't working.

Currently I have to run scripts before and after certain servers are patched to manage applications/services so a Detect and Deploy job with multiple reboots doesn't corrupt data. Whenever a schedule time needs adjusted, changes have to be made all over…

SMS/SCCM have the ability to advertise patches in the form of a pop-up, notifying the user that they have x days to install patches and reboot, at the end of which it will be forced. Also the ability to force the install and give the user x days to reboot or else it will be forced.

When using the reboot option, although the timer does appear on the desktop, the countdown timer doesn't decrement. If the countdown timer is set to 30 minutes, the timers remains at 30 minutes until reboot. The timer doesn't move. It's doing it in the background but the users don't see the timer decrementing and it confuses the users as they do not know how much time they have left before it'll reboot. I'd like it to show the timer counting down.

From the adminui/patch.php page, add a button to force a detect/deploy for the patch on the current machine. This would be useful for trouble-shooting failed patch deployments when only a few machines have trouble.

I would love to have the ability to run a script as part of a patch schedule and have it run before the patching begins.

The example I have in mind would be for patching BIOS on computers using Bitlocker. I could have a separate patch schedule for BIOS patching only and have a script set to run prior to patching that would suspend bitlocker and enable it after the next reboot. With it being integrated with the patch schedule, I would not have to worry about the bitlocker disable script running needlessly.

I am doing something similar with scripts, but it is a pain to manage because I have to tweak for different computer and versions of bios.

I would love to have the ability to run a script as part of a patch schedule and have it run before the patching begins.

The example I have in mind would be for patching BIOS on computers using Bitlocker. I could have a separate patch schedule for BIOS patching only and have a script set to run prior to patching that would suspend bitlocker and enable it after the next reboot. With it being integrated with the patch schedule, I would not have to worry about the bitlocker disable script running needlessly.

It would be very beneficial to have a button within each patch schedule to allow shutting down the machine after patching has happened.

For us, our maintenance department pushes power management and powering off machines, and we are finally getting to a point to be able to do patching overnight, but would like to meet them half way by shutting down the workstations after they're done patching. I am aware we can create a separate script to initiate a shutdown, but this would be a guessing game regarding when the whole group machines have actually finished patching.

Some of our machines currently have the bios that came on them from the factory, in this case A00.
The Dell Update catalog on the K1000 has bios A07.
You cannot jump from A00 to A07 without another bios in between.
Perhaps having all available bios's available in the Dell Update catalog would be good so that updates wouldn't be broken in this situation.

Let it be possible to also create patch lables on the criteria WHICH category it belongs to.
Example: Smart Label which only contains Service Packs for Windows 7.
MS is using this "form" in their WSUS solution. See screenshot.