In this release:
The portal can now be accessed using Portal.aspx.
Existing users will be redirected to this page when they try to access the portal in ASM 10.2.3 using bookmarks, MMA URLs, etc.
A new Portal System named “ASM 10 Default” is added during the upgrade to 10.2.2.
This system is configured to use the new portal Skin and the new Home Page.
The existing “Default” and “Classic” Home Pages have been renamed to “vFire 9 Default” and “vFire 9 Classic”.
You are now able to opt-in to the new portal styling using the new Portal System.
This widget is hidden by default and can be enabled via the screen designer.
The grid will show calls logged by anyone in your organization (subject to portal security settings) and where the Awaiting Action indicator on the Call Status is checked.
This new widget uses the API for data access and uses server-side paging for optimal performance.
This widget is hidden by default and can be enabled via the screen designer.
The grid will show calls logged by anyone in your organization (subject to portal security settings) with newest calls at the top.
This new widget uses the API for data access and uses server-side paging for optimal performance.
This widget is hidden by default and can be enabled via the screen designer.
The grid will show the 10 most popular FAQs.
This new widget uses the API for data access and uses server-side paging for optimal performance.
We plan to make this section designable in future.
Opt-in via the setting in Preview Features.
Widgets can now be hidden and reordered via the designer.
You can also add any of the new widgets to the dashboard using the Dashboard Widget.
We’re planning further improvements to this in future.
A yellow warning indicator if there is another Request related to the same CI or Service.
A red indicator will be displayed if there is another Request with an overlapping implementation date.
Enable “Conflicting Change Indicators” in preview features to opt-in to this new feature.
We’ve added several new options for password complexity validation, including the ability to configure reCaptcha v2 on the portal change password screen.
The Portal and Nano no longer transmit Session ID’s in query strings or forms. Both use a cookie for authentication instead.
This solves one of the most important security problems reported during penetration testing.
This also means that the login restrictions in Nano and the Portal are brought into alignment with the restrictions in Core.
We’ve repurposed the old Reporting Role. It’s now called Dashboard Management.
The Dashboard Role can be used to grant access to Categories that have been created through the Dashboard Designer.
There is also a new Portal Role that is used for the same purpose.
The categories and related dashboards will appear in the navigation menu in Core and the Portal based on the current user’s role.
This enhanced functionality replaces the original static menus.
ASM Core now loads significantly faster and is significantly more reliable.
Dynamic Content Compression should be enabled in IIS for maximum performance.
A new web application (aka Virtual Directory) is created during the installation of ASM 10.2.3. The new web application is named Alemba.Web.Windows and is used during the windows authentication process when logging in to ASM Core.
This change should make windows authentication a little easier to configure and will resolve issues where the windows login prompt is occasionally displayed.
It is now possible to select extension fields from subtypes when using navigation properties via the API.
For example, extension fields added to the Desktop screen set were not accessible when selecting from the Call entity. Select statements such as $select=ConfigurationItem.Ext_DesktopType are now supported.
This change also means that searches of a base entity (i.e. Call, ConfigurationItem, Person) will now support selects of extension fields from sub types (e.g. Incident, Desktop, User). There are also a handful of fixes in the dashboard platform that will improve performance when using the API Data Source.
In addition, the Dashboard user will no longer consume a named license.
The selected portal system is sometimes lost when logging out or navigating to particular pages in the portal.
The selected portal system is now persisted using a cookie.
This means that the portal system selection will be maintained more reliably. It also means that you must explicitly select the default system (using portal.aspx?portal=DEFAULT) rather than selecting that system by omission.
ASM will now write more information related to SAML login, to the traces for ASM and Alemba.Web.
This includes the SAML Response XML.
The XML in this response contains sensitive information so is not written to the trace unless tracing is enabled. This is done via the server console for Portal and Nano and via the web.config for Alemba.Web for Core and API login.