Release Notes Silverback 22.0

Windows 10/11

• Custom Terms & Conditions
• New Factory Wipe Options
• Require Network Connection in OOBE
• New Lockdown Policies

macOS

• Obliteration Behaviour and Bootstrap Tokens
• Notification Control
• Remote renaming
• Bypass Activation Lock
• New Device Information

iOS, iPadOS, tvOS

• WPA3 Support and additional Settings for iOS and iPadOS Wi-Fi
• Application Lock for tvOS

Android Enterprise

• Security Settings during Setup Wizard
• Control Factory Reset Protection 

Custom Terms & Conditions

During Autopilot enrollments or during the Join to Azure Active Directory, users are presented with Terms & Conditions. After entering the credentials, they are required to accept these Terms & Condition which were by default filled with a Matrix42 branded experience. With Silverback 22.0, we are providing now the possibility to customize the Terms & Conditions from the Azure Active Directory section in Silverback. You can now replace the default title, the default description and the Matrix42 logo to your customized one as shown in the following screenshot: 

By pressing the Preview buttons, you can take a sneak peak upfront from your Silverback Management Console to the new User Experience for your users during the enrollment. As of today, the white theme will be shown for Azure Active Directory Joins, when the device will be joined after the out-of-the-box experience and the dark theme during enrollments through the out-of-the-box-experience. Themes are currently not related to Windows 10 or Windows 11, but this might change in the future. For additional information please refer to Windows 10/11 All about Windows Autopilot. 

New Factory Wipe Options

Windows 10/11 offers multiple options to wipe, and re-provisioning devices and we want to let you participate from all these scenarios. As our previous versions did not support all of them, we are now even happier to share with you multiple new factory wipe options that will increase your flexibility. All of the new factory wipe options can be either executed via the Silverback Management Console or via API calls. By clicking the Factory Wipe button from the Devices section, the following types can now be selected from the additional options section: 

In addition to the above-described Factory Wipe options, we added also the possibility to use the Autopilot Reset from the Device Overview under Actions. Autopilot Reset works like a usual reset, except that the Autopilot reset keeps the device enrolled in Azure Active Directory and in Silverback. In addition, the Autopilot reset will perform the following:

• Removes personal files, apps, and settings.
• Reapplies a device's original settings.
• Sets the region, language, and keyboard to the original values.

The Windows Autopilot Reset process automatically keeps the following information from the existing device:

• Wi-Fi connection details.
• Provisioning packages previously applied to the device.
• A provisioning package present on a USB drive when the reset process is started.
• Azure Active Directory device membership and Silverback enrollment information.

By executing a Remote Reset, the current user will receive a notification that the Autopilot Reset is scheduled in 45 Minutes. 10 Minutes before the Autopilot reset will be initiated, users will receive a final notification.

First Notification	Final Notification

During the Autopilot Reset process, the device reports a status to the management system, which is shown between the Device Information and the Assigned Tags section in the Device Overview.  

Please refer to Windows 10/11 All about Windows Autopilot for additional information. 

Require Network Connection in OOBE

During the out-of-the-box-experience on Windows 10 and Windows 11 devices, users might circumvent the Autopilot enrollment by just simply providing no internet connection and creating a local account. To prevent this situation, you can now configure the Require Network in OOBE restriction, which correlates to a UEFI variable that is set to require a network connection. 

As compared in the following screenshots, the I don't have internet option will be shown or not during the out-of-the-box-experience, but the device must be one time enrolled to Silverback to apply this restriction. At the first out-of-the-box-experience, this option will be available and after the Autopilot setup, you can apply the restriction and during the next OOBE, this option will be hidden and kept active for all next OOBE scenarios. 

First OOBE, with the I don't have internet option.	After applying the restriction and a factory wipe, the option will be invisible.

New Lockdown Policies

Silverback 22.0 offers now new Lockdown policies for Windows 10 and Windows 11 devices. Lockdown policies allows you to configure your own device compliance and the option to define actions that should be automatically executed when a violation is detected. Enabling a lockdown policy ensures that the device is inspected regularly to ensure the compliance from the initial enrollment on due to the device lifecycle. Each policy can be enabled or disabled through their associated checkbox.

Obliteration Behaviour and Bootstrap Tokens

With Silverback 22.0, we are supporting from now on escrowing bootstrap tokens for newly enrolled supervised devices. Escrowing bootstrap tokens is an important piece for further investments in our macOS Management as these bootstrap tokens allows to bring several new features in our upcoming releases. The first feature where we use escrowed bootstrap tokens is to leverage the Erase all Content and Settings option in macOS 12+. This factory wipe method is similar to the experience that you have on iOS and iPadOS devices: a very fast wipe and re-provision process and we can say that we already really enjoyed it during our development phase! As an example, the time from a factory wipe to re-provision the device with the Device Enrollment Program is reduced from several hours (sometimes up to 4h) to only round about 6 minutes!

In general, bootstrap tokens are supported for the following devices:

• macOS Catalina 10.15, enrolled via Device Enrollment Program 
• macOS 11 (Big Sur) and later, enrolled as supervised device.

The option to factory wipe macOS devices with t​​​​he Erase all Content and Setting method requires additionally an Apple Silicon Processor or an T2 Security chip, as the Factory Wipe commands uses in this case the Erase All Content and Settings (EACS) instead of the usual Erase Device Command. With Silverback 22.0, the factory wipe action confirmation pop-up will show additional options for the obliteration behaviour. In combination with the Erase Device Command, the obliteration behaviour command acts as a fallback behavior for erasing a device from Silverback and the device will performs pre-flight checks to determine if the device is in a state that allows EACS. Depending on the selected obliteration behaviour, the device either starts or doesn't start to erase itself as highlighted below: 

To review if the bootstrap token is escrowed to Silverback during the enrollment, you can perform the following on your macOS device afterwards: 

• Open Terminal
• Enter the following command

sudo profiles status -type bootstrap token

• Enter your password and you will receive one of the following answers:

Notification Control

Already two years ago and with Silverback 20.0, we added the option of controlling notifications for applications on iOS and iPadOS devices. This control offered you since the capability to define specific per app notifications on the device for iOS and iPadOS devices and with Silverback 22.0, we are happy to have extended this profile to devices running on macOS 10.15+ and later. Same as for iOS and iPadOS, notifications can be disabled at all or can be permitted to options like Show in Notification Center or Show on Lock Screen. This profile helps you to ensure that your users don't accidentally disable notifications for important applications. To configure the new Notification Settings, navigate to macOS Profiles in a Tag and press New Notification Setting. Now select the App Store Country and start with a search for the app, but custom bundle IDs are also supported. After entering an app name, you receive the choice to select your application. After that, just configure the following notification controls to your needs:

Bypass Activation Lock

If you are managing supervised iOS and/or iPadOS devices, you may have recognized already the Activation Lock and Bypassing features in Silverback that we have now extended for macOS devices. The Activation Lock feature is in general designed to prevent anyone else from using a device that he does not own. When users add to their devices their personal Apple ID, (with enabling the Find my option) and the device gets lost or stolen and factory wiped, the next user will not be able to activate the device, as it is locked to the owner. With Silverback 22.0, we added the Allow Activation Lock option to the Restriction profile. With this option, you can control the Activation Lock for your managed devices. If you don't want to disable the Activation Lock and users are logging into their Apple ID and enabling the Find My feature, you can now unlock devices with a bypass code that can be exported Admin section > Logs > Activation Lock Bypass Codes.

From the Activation Lock screen in the macOS Recovery, select Recovery Assistant and click on Activate with MDM Key, to enter your exported bypass code for unlocking the device as demonstrated in the video below.

Please review additional information about how to enable, disable Activation Lock and the System Requirements from the official Apple documentation: Activation Lock for Mac. From the system requirements, the Activation Lock is not supported on every device. To prevent of showing errors in the Pending Commands, Silverback will send the Allow Activation Lock setting with escrowing the Bypass codes only under the following conditions:

• macOS Version must be higher than 10.15 
• Devices must be supervised
• Security Information must report that the Activation Lock Manageable

In addition, the Disallow Activation Lock setting will only take affect if the Activation Lock is not already activated on the device. From the device overview of each device, you will find the following useful information about the Activation Lock: 

• Device Information: Activation Lock Supported
• Security Information: Activation Lock Enabled
• Security Information: Activation Lock Manageable

For Allow or Disallow Activation Lock, the configuration is sent to your devices via the Settings command type and the escrowing Bypass Codes is executed within the Activation Lock Bypass Code type, which can be reviewed from the Pending Commands overview. 

Remote Renaming

As we offered you already the remotely rename option for iOS, iPadOS, Android, and Windows 10/11 devices, we wanted to bring this feature as well to macOS to close the gap. With Silverback 22.0, you will now gain the ability to remotely rename macOS devices by opening the device overview and executing the rename option under actions. Additionally, you can upload a *.csv file or add single devices into the Hardware Authentication to pre-define device names. When the Hardware Authentication is used, Silverback will automatically rename the devices according to the configuration. After renaming a device, Silverback will now additionally and automatically query the device information from the device to get the newest device name as soon as possible. This is one improvement that we also added within this release for iOS and iPadOS devices.

For macOS, please note that we extended the device information overview also which brings now three different attributes according to the device name:

• Device Name (Device Information)
• Hostname (Network Information)
• Local Hostname (Network Information)

After renaming the device, the Device Name and the Local Hostname will change and reported immediately and the Hostname requires a reboot. This is especially good to know if you use the Unified User Experience, as there the hostname is displayed as the device name.

New Device Information

At the beginning of this release cycle, we simply wanted to find out the way how we can show the Enable Remote Desktop and Disable Remote Desktop button status accordingly to the device status. During our successful investigation we found several additional device information where we think that they will be interesting for you as an Administrator, too. As a result, we added overall 25 new values in three different sections: 

• Device Information
• Security Information
• Network 

WPA3 Support and additional Settings for iOS and iPadOS Wi-Fi

At the starting point of this feature, we wanted to bring the WPA3 support for Wi-Fi Profiles. As WPA3 represents the latest generation in mainstream security for wireless networks, it is an important upgrade that we wanted to deliver. During the development it turned out that we can improve several areas of the Wi-Fi Profile at all and at the end we decided to provide you a 100% set of Wi-Fi features that iOS and iPadOS devices supports nowadays. This includes the following improvements and new features for Wi-Fi Profiles: 

In general, we expect now that the configuration of Wi-Fi profiles is more comfortable and more straight forward for you. For additional information, please refer to our Knowledge Base article about WPA Enterprise Settings for all WPA Enterprise related settings.

Application Lock for tvOS

In this release, we extended another existing profile to another applicable platform, the Application Lock for tvOS devices. With the application lock profile, you can turn the device into a device that runs only one application. This feature is very useful in demonstration areas like promotion shops or roadshows to let users only use one specific application. Within the Application Lock profile, you can setup your desired App Identifier (Bundle ID) with additional options to Disable Touch (touch surface on the Apple TV Remote), Disable Auto Lock and Enable Voice Over. Upon receiving the profile, the home button is in a disabled state, and the device returns to the app automatically upon wake or restart. The feature is supported on supervised tvOS devices running version 10.2+.

Security Settings during Setup Wizard

For Android and Samsung Knox Device Owner enrollments, we made a slight change in the enrollment process. After the authentication process is performed in the Companion application, Silverback will send directly the restriction profile to the devices, before processing the enrollment within the Setup Wizard. The idea behind this change is to limit the potential vectors of attacks on devices that are not yet fully protected during the enrollment. With this change, devices will now be configured with important policy compliance settings during the Setup Wizard of Android and will be protected as soon as possible with a configured and applied restrictions profile. If as an example, screenshots are disabled within the restrictions profile, screenshots are already prevented at the All Set! screen, which part of the Setup Wizard that is available for newer devices. For older devices, the restriction profile will be applied independent from the Setup Wizard capabilities of the device. 

First, users are presented with the Activating Device and the Register to cloud messaging indicator	At the Applying security settings point, restrictions will be applied on the device	At the All Set! screen, the device is already secured and users can finish the enrollment with opening the Companion

Control Factory Reset Protection

In general, the Factory Reset Protection is a security feature on Android and Samsung Knox devices running on Android 5 and newer. It was designed to make sure that someone is not able wipe and factory reset a phone that is lost or stolen. 

If a user adds to their devices one or multiple Google Accounts, the Factory Reset Protection is active and when the devices go though an untrusted factory reset, the next user for the device needs either to enter one of the previously added Google Account or use the last known Passcode or PIN on the device to unlock the device. As this scenario is very useful for private used devices, it might lead to a scenario where a user in your organization is using a managed device with a personal Google Account and will leave your company for any reason. In this scenario, you will probably wipe the device from the Management Console and hand the device over to the next user. As the remote wipe from the Management Console is a method, that is considered as untrusted, the next user would need (one of) the previous Google Account credentials to unlock the device. Without having this account or at least the last used Passcode/PIN, the device can't be used anymore as it is locked.

With the Factory Reset Protection configuration in Silverback, we are offering two ways to prevent this scenario in the future. You can choose if you want to disable the Factory Reset protection on managed devices or to determine which account can unlock the device, like a master account that is capable to unlock the device after an untrusted factory reset has been performed. Please refer to Factory Reset Protection and Bypassing for Android and Samsung Knox for additional information.