Is there a report that would should if a patch would require a restart?

[WTargarean]

Even better, can we add a column in the Remediation Bulletin to indicate if a restart will be required for a patch bulletin

[Dmitri Gornev]

Hi WTargarean,

it works the other way around - the need to reboot after update installation is not prepopulated in Patch datafeed but being analyzed on a client side by deployment engine based on exit code returned by update binary and then sent to SMP server (shown in reports like Windows Software Update Delivery Summary and Restart Status there).

[WTargarean]

Can we log a feature request for the feed to indicate if a software does indeed a reboot before even deployment?

[Mike Grueber]

We can certainly create an enhancement request, but I am not sure whether the request is realistic if this information is not included in the bulletin description.  If the information is included in the bulletin description, I believe it would already be visible in the ITMS console.

Can you help us understand how you would use this information?

[WTargarean]

Knowing whether an update requires a restart before deployment helps patch managers plan and schedule deployments more effectively. For example, it allows them to avoid disruptions during critical periods such as month-end activities, or to defer and bundle patches into a single deployment payload when a reboot is required.

[Johannes Engstle]

Hi, 

I agree with WTargarean, I think that this would be a very valuable information.
Users receive a large number of restart prompts nowadays (Windows, Driver, Firmware Updates), so we are trying to reduce the number of reboots as well.
This information could definitely help to improve the situation.

[Hannah Massie]

I'm fairly certain this information is not published by Microsoft within the bulletin information or elsewhere. What happens is the installation of any patch will write the reboot required flag in the registry by the installation executable, which is then reported back to the SMP by the patch software. 

I therefore assume every critical or important OS patch requires a reboot and have set up my process so that my critical servers have a client patch  remediation policy applied that will install patches but not automatically reboot the system to apply them (every other system has a policy that will automatically reboot). I can then see which servers have to be rebooted and can plan the reboot process for each one as necessary, closing apps properly and 'out of hours' (which could be automated by tasks). I created a report that shows for any patch policy the number of success, fails, pending reboots, pending execution, reschedules, etc.

I also use auto cadencing of patch installs, automatically applying the one policy to a sequence of target groups in turn, with my critical servers being the last to be patched. It ensures all goes as smoothly as possible and with the minimum amount of work, while keeping me aware of al that is happening. 

[WTargarean]

Screenshot of another product that shows if a patch needs a reboot and includes other information, I am not going to mention the product. This is to show that it is possible to show this information before deployment.

[Mike Grueber]

This information is available for some updates from some vendors, but is not available for all updates from all supported vendors.  Here is a screenshot from the Microsoft catalog:

[WTargarean]

Thanks Mike, possible to add a column in the Remediation page in Altiris in the future?