What's New

• User experience with Proxy settings after registration

  The registration log contains messages about proxy settings that were used and if the proxy settings were saved. This allows users to confirm the proxy settings that were used during a registration, especially in the case of troubleshooting a failed registration. There are no behavioral changes with respect to proxies used during registration.

  One of the three following messages appears in the RegistrationLog.txt

  • "Using custom proxy settings with proxyServer='...', bypassList='...', and authentication=...."

  Custom proxy mode settings were given for registration. These are the settings used during registration. If a username was given for proxy then authentication is also used indicated by the value authentication=1.

  • "Using automatic proxy detection with authentication=..."

  Proxy mode is set to auto detect for registration. If a username was given for proxy then authentication is also used indicated by the value authentication=1.

  • "Not using a proxy for network communication."

  Proxy mode was set to none.

  All successful registrations indicate that proxy settings used during registration were saved as indicated by the line "Proxy settings used during registration were saved.".

  A failed registration will not retain any proxy settings as indicated by the line "Proxy settings used during registration were not saved."

• A new flag for Agent to opt-out of WinHTTP setting

  The Agent has a new flag to opt-out of setting WinHTTP during a Windows Agent Registration. Using this flag to opt-out of setting WinHTTP requires the customer to manage their Certificate Revocation Lists (CRL) on their own in order to prevent degraded performance over time. Customers who do not need to opt-out of this behavior, or are unprepared to manage their own CRL do not need to take any action.

  This "update WinHTTP Proxy" flag may be used to opt-out of the default behavior by adding the following line to the options file:

  updateWinHttpProxy=0

  where 0 means WinHttpProxy will not be overwritten during registration.

• Azure Blob Storage URLs: A list of Azure Blob storage URLs are now provided that must be part of the allow list in your firewall such that the IvantiNeurons Platform and its agents can communicate.
  Learn more about Azure Blob Storage URLs.

Agent Health allows administrators to ensure optimal performance of their Ivanti Neurons agents within their estate. By providing a centralized and actionable overview of agent health, it simplifies the process of identifying and resolving issues that can disrupt operations.

Proactive monitoring and diagnosis: Agent Health enables administrators to self-diagnose issues without relying on vendor support. This proactive approach minimizes downtime and enhances the reliability of your Ivanti Neurons implementation.

Comprehensive agent filtering: Administrators can quickly filter views to show agents that are overdue for check-in, missing entirely, or have been duplicated. This feature ensures that no endpoint issues go unnoticed, allowing for prompt corrective action. Learn more about health filtering.

Intuitive traffic light system: The health of each agent is visually categorized using a traffic light system:

• Green (Good): Agents operating as expected.
• Amber (Moderate): Agents with minor issues that may require attention.
• Red (Poor): Agents with critical problems that need immediate resolution.

This visual system makes it easy to prioritize troubleshooting efforts and focus on the most urgent issues. Learn more about the health indicators.

Detailed drill-down analysis: For agents marked as Moderate or Poor, administrators can drill-down into individual agent endpoints to access detailed insights into specific issues. This granular visibility accelerates root-cause analysis, ensuring faster time to resolution.

Integrated Help resources: Built-in links to Help content provide remediation assistance tailored to the identified issues. These resources empower administrators to resolve problems efficiently without extensive technical expertise.

Agent Health not only enhances operational efficiency but also boosts confidence in Ivanti Neurons implementations by providing the tools and information needed to resolve issues independently. It reduces the time and effort spent on troubleshooting, mitigates potential security risks, and ensures a seamless user experience.

Learn more about Agent Health.

Ivanti Neurons Power Management lets an administrator manage and optimize the power consumption of the devices in their environment. Administrators can now configure the power management settings and assign them to a policy. Power management does not affect the performance of the devices. You can manage settings such as Turn-off hard disk, Sleep after, Hibernate after, and Allow wake timers from Power Management settings page.

Learn more about Power Management Settings.

Power Management is available on Windows devices only.

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.