Skip to main content
Matrix42 Self-Service Help Center

Release Notes Silverback 23.0

About This Release

Matrix42 Silverback 23.0 provides new and improved features that have been implemented. During the development of this version, we have been focusing on valued feedback from our customers and partners to provide an ideal feature selection.

Important Announcements

.NET Core Hosting Bundle Update

With Silverback 20.0 Update 3, we introduced for the HTTP/2-based Apple Push Notification Service a new in-place backend technology based on .NET Core Runtime and the ASP.NET Core Module that will be installed with the .NET Core Hosting bundle as part of our system requirements. This bundle allows ASP.NET Core apps to run with IIS and ensures the communication between Silverback and the Apple Push Notification Service on your Windows Server. Since the official support for the bundle in version 3.1 has expired, we have updated to the new version .NET 6.0 with a Long Time Support in this Silverback release. After the Silverback update, please download and install the newest available ASP.NET Core Runtime 6.0 Hosting Bundle and restart your Internet Information Service once to ensure the communication of your Apple devices. It is not mandatory to uninstall the old bundle in version 3.1.

clipboard_e130f9f8317bceb9d69a602e09827696e.png

Overview

New Improvements

New Changes

New Features

Direct Boot Support

Android runs in a secure, Direct Boot mode when the device has been powered on but the user hasn't unlocked the device. In general, the system provides a credential encrypted storage, which is the default storage location and only available after the user has unlocked the device and a device encrypted storage, which is a storage location available both during Direct Boot mode and after the user has unlocked the device. By default, apps don't run during Direct Boot mode and you may have recognized this already when you are awaiting a message from an Instant Messaging system in the Direct Boot state of the device. In this state, you won't receive a notification and even several system apps are working only partially in this state.

This situation in combination with the Matrix42 Companion application is influencing one common use-case for Administrators to clear unknown passcodes for devices and with additional configurations like preventing users to Perform Factory Reset or with a not set Maximum Failed Attempts passcode option, it might be very difficult to get the device usable again. To address and improve this scenario, we implemented in Companion Version 23.0 the direct boot support and added the ability to execute the Clear Passcode, Restart, and Factory Wipe actions while the device is in direct boot mode. Please note that devices in this state needs to be connected to a known network. Without having an internet connection, the executed commands remain in a pending status as the devices aren't connected to the internet. 

In addition, the Direct Boot Support has a positive effect on the start of the Single and Multi App Mode when the devices are equipped with a passcode. In this constellation, the Single and Multi App mode now starts faster because the Companion application can listen to the system events Locked Boot Completed and Action User Unlocked to launch the application(s) faster. In case of a missing passcode, the Boot Completed system event will be still used to start the Single and Multi App Mode, that occurs ~15-30 seconds after entering the system. 

New Improvements

Please find all new Improvements in Silverback 23.0 below.

Management Console

  • Fixed an issue with not working grid controls under Associated Devices view
  • Per specific application version distribution inside the App Portal shows now only installations on managed and blocked devices instead of all historical devices
  • For devices that have been assigned a policy for Hardware Authentication but do not transmit an identifier, a violation is now displayed in the device overview
  • Added safe resolving for XML Entities of user controlled inputs
  • Mixed notations for Wi-Fi settings have been adjusted
  • Changed Tab Name for Logs to Silverback - Logs

Apple Management

  • Updated to Microsoft .NET 6 version for Apple Push Notification Service Sender
  • Added additional push notification for macOS devices after installing Privileges Profile that contains a Wi-Fi with enabled Automatically Join option
  • Removed the unsupported Get Restriction commands on iOS and iPadOS for User Enrollments to prevent Errors displayed in Pending Commands
  • Added abandoned mechanism with information in Pending Commands for not supported profiles on User Enrollments on iOS and iPadOS
  • Renamed iOS7+ App Config to App Config in the App Portal

Android Enterprise

  • Platform in Associated Devices in Tags shows now Samsung Knox instead of SamsungSafe
  • Bird's eye view for Application Feedback shows now also not expanded Applications Feedback from the device overview
  • Installed application list command now forces an Application Feedback report and logs the duration
  • Extended the security layer for the checkin endpoint
  • Added nlscan.settingrouter application (Newland Handscanners) to the enabled system apps list
  • Enterprise applications on Samsung Knox can now installed and uninstalled even if restrictions are set to prevent the action

Windows 10/11

  • Renamed Allow Convenience Login to Allow Simple Password in Passcode Profile
  • Added missing values for Passcode Profile settings in Resultant Tags and aligned label names

API

  • Added favicon and static Tab Name for API Help
  • Descriptions for Full Device Wipe Action in API Help shows now correct information
  • Fixed an issue that Require Network Tethering is a mandatory option while executing Full Device Wipe
  • Fixed an issue for additional body parameters for Full Device Wipe action

Enterprise Service Bus

Changes

  • Changed Digital Signatures for the Cloud Connector to new Matrix42 GmbH certificate

Known Issues

  • The issue belongs to PRB37220: If Android or Samsung Knox devices are assigned a label via the hardware authorization and a tag is distributed via this label, then it may be that not all settings from the tag are applied unless it is modified after the assignment.
  • Was this article helpful?