What's New

When a patch deployment fails on the device, the agent makes a certain number of attempts to deploy before giving up. The counter for the deployment retry attempts can be reset manually and the events are captured with the intent of reporting the number exhausted attempts in Deployment History.

A new report has been added for Patch Management: Deployment History - Summary. This report offers a summary view of devices and overall patch status represented as percentage succeeded, failed reboot, and pending reboot.

Learn more about Reporting.

For Windows, you can now set a Reboot criticality. This specifies the priority of the reboot request that is sent to the agent, so that the agent can schedule the reboot according to settings in the agent policy. The reboot request is honored only if the value set in the patch configuration matches or exceeds the Minimum reboot criticality set in the agent policy.

Learn more about Reboot Behavior.

Patch for Intune now supports the publishing of multiple languages. Language options are available when managing products from vendors that supply language-specific installers, which enables you to publish different language versions to different groups.

Learn more about configuring the management of a product.

App Control's success hinges on Trusted Ownership, which ensures that no executable can run unless it is owned by a trusted account, such as an Administrator or the Trusted Installer. This means that anything installed or modified by a user cannot run. In mature organizations, this could lead to legitimate user-installed applications being blocked. To prevent this, App Control allows users to identify potential blocked apps and create exceptions for them, known as allow rules, ensuring that productivity remains unaffected while maintaining security. These rules can be configured to apply to specific software versions, locations, people, devices, or IP ranges.

To identify software that might be affected by Trusted Ownership, it is recommended to start with a configuration in Audit only mode. This allows App Control to collect information on what is being executed without imposing any restrictions. The gathered data is presented graphically, enabling administrators to determine which allow rules to create.

Additionally, you can create deny rules—preventing an application, even if owned by a trusted owner, from executing under certain circumstances. This is useful for sensitive applications automatically installed on all devices but intended to be accessed only by specific people.

Watch a related video on trusted ownership (4:39)

The second key feature of App Control is the ability to reduce the number of administrators in your environment by enabling privilege elevation only for necessary tasks and specific users. Similar to app blocking, App Control can collect data on who and what currently require administrator privileges. This information helps administrators create rules that allow users needing elevated privileges for specific activities to perform those tasks without having permanent administrator access.

Watch a related video on elevated privileges (2:00)

Users have access to 10GB of free storage. Uploading and deleting files from that space is managed through the cloud storage explorer, which is accessed from the Download action in an app package.

App Distribution will now work correctly when the Neurons agent is configured to use a proxy server.

Users can deploy the App Portal to Windows devices. It will contain apps assigned to the end user, allowing them to install them, as needed. This will be a phased rollout, available to a limited number of customers. We expect the full rollout to occur in late November.

These new queries show an overview of all Ivanti Application Control (AC) and Environment Manager (EM) configurations that are configured on devices. The query will return data only if AC/EM configurations are deployed through Neurons AC/EM (Hybrid) Deployment.

New sensors have been added that can query Ivanti Environment Manager (EM) events on your devices. These include the Ivanti Environment Manager Events Summary, Event Overview, Details, Action Performance and Action Performance Details sensors. As a prerequisite for these sensors to work, the EM agent needs to be installed on the devices.

The location setting under Edge Intelligence Settings is now supported on Mac devices. This means that the complete configuration for the location setting can now be done under Edge Intelligence Settings. The old setting in the Edge Intelligence UI has been removed as this one is no longer needed.

Learn more about Edge Intelligence Settings.

Various queries worked with a "From date" and a "To date" parameter to define a time range. This has now been changed into one parameter called "Date range" that supports some built-in options to specify a "last x days" date/time range. It is still possible to define a custom range.

Various queries have been enhanced. An additional property called “Operating System” has been added to the landing page: Agent Overview. The Device Dashboard query now shows the local device time. The BIOS information query has been restructured to make the properties clearer.

When using bot inputs a new ‘list of text/strings’ type has been added which allows a list of values to be passed into a bot at runtime. In addition if the Web Request stage is pointed to an API which returns multiple field-level arrays as part of its response, bots can now be leveraged to work with the response.

The web request stage now by default will attempt to automatically map a JSON response to a get command into checkboxes, automatically determining the data type (date, number, boolean etc) so all the admin has to do is to select the data types they want to use in the bot and these will be made available as outputs.

A new query stage has been added to return details of recently used removable storage devices as retrieved from the Windows Event log via the Edge Intelligence sensor. This contains a historic view of devices which can be filtered to specific dates as required.

A number of new list stages have been added to accompany the field-level array support to add flexibility when working with list data. There are new stages for Average list, Filter list, Find in List, Flatten list containing list, list length, pick first in list, sort list and sum list. The For-Each stage has also been performance optimized and moved to the list section of stages. Further stage detail can be found in the stage information descriptions.

Learn more about List function stages.

A new feature has been added to allow the generation of a human-readable date on applicable stages. This can be found in the ‘advanced settings’ area of compatible stages and can be used in text box inserts (tokens) or email bodies.

The ability to target private groups when building a bot and using the ‘run now’ functionality has been added to streamline the build process and avoid the requirement to pollute public groups with test devices.

A new experience has been added to the bots home screen. This allows the view of executed bots over time which includes details on the number of endpoint interactions performed broken down by bot. This also provides visibility on high impact scheduled bots which have their execution spread over a slightly longer duration, to optimize load and reduce surge demand on the network. A high-impact bot is one which performs several thousand interactions in a 5 minute window, and is a function of the number of stages processed times the number of endpoints targeted. Human triggered bots bypass this mechanism.

The reporting UI can filter by trigger so is also useful to view the usage over time of custom actions from the device or people views.

Learn more about Endpoint Interactions.

A new Settings area has been added to the bots home page. This allows an admin to select users or roles whose members should receive email notifications based on the options of scheduled bots running, succeeding and/or failing.

New Device and People inventory stages have been created. This allows the enrichment of data for devices or people passing through the bot, and leverage that data in filters for branching or inserting into other stages such as email reports, web requests or ITSM tickets. These are available for early access and will be getting rolled out more broadly based on feedback.

For users leveraging ServiceNow, it is now possible to create or update tickets using bots. This supports the option of linking the asset to the ticket and avoiding duplication of creating tickets if one already exists for the device/use-case. It can also be used for managing the full lifecycle of a ticket within a bot, e.g. detect an issue, open a ticket, perform diagnostics and record them in the ticket. Take an action, recording the outcome in the ticket and move the ticket to a closed state if problem resolved. Alternatively re-allocate the ticket in the workflow as required or modify other metadata such as priority.

A new stage has been added to allow an admin to disable an Entra ID account using bots (people mode). This is the first of a number of new people action stages to allow more powerful remediation possibilities for a number of scenarios.

Introduction of new reporting capabilities for Patch Management, including two out-of-the-box report templates: Patches by Device - Summary and Devices by Patch - Summary.

Users can apply a range of filters to customize the reports and export them in PDF, Excel, or CSV formats. These features provide an easy way to track compliance and efficiently address security-related questions.

Learn more about Reporting.

Addition of two Patch Management datasets to Dashboard Designer. One dataset focuses on deployment history, while the other provides data on device-patch scans. With these new datasets, users can create interactive and comprehensive dashboards that cover key aspects of patching, including devices, patches, vulnerabilities, and deployment history.

Previously, the Connector report that was most recently run determined the patch install status. The patch install status is now taken from the most recent scan from the Neurons patch engine if one is available. A scan from an Ivanti Endpoint Manager connector will be used if it is newer than the Neurons scan, and scans from other connectors are used only if the previous Neurons scan was more than 7 days ago.

As the risk from vulnerabilities and exploits keep getting worse over time and patching the fleet of devices across the organization on a continuous basis becomes a challenge, Information Technology and Information Security teams have to ensure that the most critical patches, followed by most important ones are deployed.

Ivanti Neurons for Patch Management now allows you to set deployment criteria based on a variety of risk models:

• VRR (Vulnerability Risk Rating) – This scoring model takes into account the risk of exploitation or the possibility of an active exploit, in addition to Common Vulnerability Scoring System (CVSS), Common Weakness Enumeration (CWE) data, OWASP (Open Web Application Security Project), open-source threat intelligence, subject matter expertise, trending information, and more. You can enter custom VRR score as the selection criteria during patch configuration.
• CVSS (Common Vulnerability Scoring System) – This scoring system is widely accepted as a standard for rating vulnerabilities and uses a variety of factors to determine the score. However, the score largely static and doesn’t account for the evolved attack and exploit scenarios over time. You can enter custom CVSS score as the selection criteria during patch configuration.
• Exploited Vulnerabilities – This criteria allows for patches to be primarily targeted for known vulnerabilities that are being actively exploited, based on gathered intelligence.

Note, all the three criteria can be applied simultaneously, if desired.

Learn more about Configuration Behavior.

You can now set deployment criteria, within a Patch Configuration, based on Linux Severity levels: critical, important, moderate etc, for both security and non-security patches.

Learn more about Configuration Behavior.

Several versions of Windows 10 and Windows 11 share the same core operating system and system files. A number of features exposed in newer versions also exist in the previous versions in a dormant state. Hence, an enablement package can be deployed to activate these features, requiring only a single reboot.

You can now deploy an enablement package for a Windows device directly through the console via Routine Maintenance. Multiple packages can be selected on the basis of OS versions of the devices, with the option to view and choose superseded patches.

Example: Using enablement package MSNS20-12-W10-4562830, newer features released in Win 10, ver 20H2 can be activated on Win 10, ver 2004.

Learn more about Configuration Behavior.

Deployment History has been enriched with interactive filters and status cards related to deployment success, failure and progress. The time period for both Patch View and Device View can be changed using drop-down with a host of options: Last hour, 4 hours, 24 hours, 7 days, and custom range. Deployment history data displayed in the grid changes dynamically based on the selected time period.

The top 10 deployment failures, along with the reason, can been seen in an interactive bar chart while the impacted devices are displayed on the grid below.

Learn more about Deployment History.

This feature is currently only available for Patch Management, all other capabilities will use the Mandatory criticality level by default.

Reboots are a shared resource in the Ivanti Neurons Agent. The Agent platform provides each engine with the ability to ask reboots to be deferred or to reboot an endpoint immediately.

The net effect of this is that multiple reboot requests can stack up while reboots are being prevented. In this scenario, the agent will kick-off just a single reboot to satisfy all those individual requests.

With different engines requesting different reboot schedules, this can lead to hidden failures in engines that require reboots as part of their operation.

So, we have introduced criticality levels to decide when a reboot takes precedence.

Each product capability or configuration will notify the centralized reboot mechanism of its own criticality level.

These levels consist of:

• Critical: for items that require an immediate reboot to resolve critical dependencies (for example, a zero-day patch).
• Mandatory: for when a reboot is required for new/updated functionality to function properly (for example, a new engine update).
• Advised: for when something might request a reboot, however, it's not urgent.

From within an agent policy, customers can then decide how each criticality level is handled in terms of configuring deferrals, messaging and reboot timings.

It is possible to configure a minimum criticality level for each policy, to limit reboots to just the level of urgency desired, or to set a ‘Do not reboot’ preference.

This provides users with a central, standardized reboot mechanism that addresses existing, known reboot limitations including:

• Patch Management users need to configure both pre and post deployment reboots, from the same area of User Interface, preferably with different reboot options.
• Zero-day patch settings require an immediate reboot and need to override any already pending reboot postponements.
• Many users require critical servers, such as domain controllers or SQL clusters, to remain online and therefore need the option to prevent reboots completely for these devices.

Learn more Agent Policy Reboot experience.

To help identify actionable content, the Help topics Required URLs, IP addresses and ports and Operating System Compatibility Matrix now contain a revision history.

Our previous version of Device grouping only allowed for one level of grouping. Now we support ‘condition grouping’ or grouping within a group. This makes our grouping more powerful and allows you to better filter on your desired devices.

Previous versions of our group filtering only allowed for a date to be entered into the filter. We now have a new filter option that allows you to enter a number of days. This allows the filter to be more dynamic.

We now have a permission that will hide the delete button. This will enhance your security and restrict who can and cannot delete devices from the Device view.

There is now a permission that can be assigned to a member to Create/Modify a public group. This will allow you to restrict who can or cannot create and modify a public group in your organization.

You can now create a power management setting and deploy that setting to your devices via a policy. The settings include:

• Turn off hard disk
• Sleep after
• Hibernate after
• Allow wake timers

Addition of three DEX Score datasets to Dashboard Designer: Devices DEX Score, People DEX Score, and Organization DEX Score. For all three datasets, scores from surveys conducted via Neurons Bots are also available. Additionally, for the Organization DEX Score, we are now tracking the score on a daily basis, enabling trend analysis over time.