As most of you may be aware, Micro Focus released ZENworks 2017 Update 4 in late January. I’m hoping that by now you may already have deployed it in your ZENworks zone. If you haven’t, I’m sure that this article will provide you with sufficient reasons to do so. Even if your ZENworks zone is already on Update 4 this article may highlight some features you missed.
ZENworks 2017 Update 4 is different from other ZENworks 2017 updates in that it doesn’t have a central theme, but instead has enhancements across the whole ZENworks suite. So I’m sure that every ZENworks customer will find something of interest in this release. Given that we have made over 30 enhancements, in this article I’ll restrict myself to some new key features across the ZENworks Suite.
Locate & Wipe a Windows 10 Device
In Update 3, we introduced the capability to geo-locate a mobile device. Subsequent to this, we received lots of requests to implement it for other platforms. With ZENworks 2017 Update 4, it is now possible to locate lost or stolen Windows 10 devices, provided they are online. In a manner identical to mobile devices, there is now a “Geo-Location” tab available for Windows 10 devices, from which an administrator with necessary rights can locate a Windows 10 device.
In Update 4, it is also possible to Wipe a Win 10 device using a quick task. This can be particularly helpful in scenarios where a Win 10 device is either lost or stolen. When such a device is Wiped all user data (across all disks) and installed applications are removed, leaving behind just Windows on the device.
Both of these new capabilities (Locate & Wipe) make use of the updated quicktask architecture available in ZENworks 2017 Update 4, ensuring that they work across NAT environments. On the device, these capabilities are implemented through the use of Win 10 MDM APIs by the ZENworks Agent. This is an initial step towards our goal of supporting the full suite of Win 10 MDM capabilities in forthcoming releases.
Service / Process Check in Bundles
As most of us are painfully aware, installation of certain software doesn’t go well if certain services, such as anti-virus are running on the device.
On the other hand, successful installation of certain software may require a certain service or process to be running on the device.
In ZENworks 2017 Update 4, as part of bundle creation it is now possible to check if a specific service or process is running or not on the device and then define an appropriate action to be taken (see Figure 2).
This check is available as part of Action System Requirements, Bundle System Requirements and Policy System Requirements across Windows, MacOS and Linux bundles.
Releasing Quarantined Patches
ZENworks Patch Management comes with an in-built protection feature where a patch which fails to install 3 times will be skipped and will be Quarantined. This can be pretty useful in scenarios where a vendor has released a bad patch or if there is software on the device which is preventing the patch installation. Until now, in order to re-deploy such a quarantined patch, the administrator would have to delete an xml file on the device either manually (which can be challenging in a zone with many sites) or by deploying another bundle.
With Update 4 it is now possible to release such patches from quarantine through a quicktask from the ZENworks Control Center itself. This quicktask decrements the patch installation count to 2 (from 3) and thus allows the patch to be deployed again. Once released, the patch can again be deployed via Patch Policy or through remediation deployment.
Support for Wildcard in Application Control Policy
Administrators using ZENworks Endpoint Security have the ability to block execution of any application on the device through an Application Control Policy. To take an example, this can be helpful in schools where a calculator is banned during an examination. Prior to Update 4 the administrator would need to define the full application name to do this e.g. calc.exe. This would block the classic calculator (launched from c:\windows\system32) but not Windows 10 calculator (calculator.exe).
Update 4 provides support for wildcard characters as part of an application name. Thus, *calc*.exe blocks all applications containing ‘calc’ in their name. This also makes it possible to block all files of a type from being executed; for example, ability to block all *.bat files. (Fig. 3).
Since it is easy to specify *.* and block execution of everything on the device, wildcard filenames are not enforced in the Windows directory and ZENworks home directory. To block an application in these directories, an explicit filename would still need to be used.
Factory Reset Protection for Android Devices
In Update 3, we started supporting the Android Enterprise Work Managed profile, which enabled organisations to have full control over devices being issued to end users.
In Update 4, we have introduced a setting through which organisations can enforce that an Android device can’t be factory reset from Settings menu on the device. This ensures that the end user is unable to unenroll the device by resetting it. With the addition of this capability, an administrator now has complete control over the device managed using Android Enterprise Work Managed Profile.
In case a device is stolen, it is typically reset by performing a Hard Reset which resets the device through device boot loader menu. However, with newly introduced Factory Reset Protection, it is now possible to make such a lost/stolen device useless for any further use. Enabling Factory Reset Protection ensures that a factory reset device can only be activated by keying in specific corporate account details defined upfront in ZENworks.
This is something akin to Activation Lock functionality on iOS devices. In cases where an administrator needs to reset the device for maintenance purpose, it is possible to disable Factory Reset Protection at the time of wiping the device through a quick task.
Enforcing Restrictions on Android Devices & Delaying OS Updates
Since the time we introduced mobile management capabilities in ZENworks 2017, it has been possible to enforce many more restrictions on iOS devices as compared to Android devices. Over the last couple of years, this gap has even increased a bit. So I’m really pleased to say that with Update 4, we are introducing almost 50+ restrictions which can be enforced on an Android device. (Fig. 4).
As an example, it is now possible to enforce that an App can’t be un-installed, block all outgoing calls or even block text messaging. Depending upon the type of restriction, it may be applicable only across Work Managed mode, only across Work Profile Mode or both.
With Update 4, it is now also possible to delay installation of OS updates on a managed mobile device (across both iOS and Android). This delay can be particularly helpful, if there are applications which need to be tested for the newer OS version. This can also be useful in scenarios where an administrator may want to wait to ensure that an OS update is stable enough. Given that in recent past, there have been some iOS updates which have caused a multitude of issues on devices, delaying an OS update can significantly improve the end user experience.
The delay can be enforced by setting the restrictions available under the OS Update tab in the device control policy. Once enforced, a newer OS update won’t show up on the device for the duration of delay. It should be noted that this setting can only be enforced on an iOS Supervised device and Android Work Managed device.
Deploying Wi-Fi Configuration on Mobile Devices
The ability to distribute Wi-Fi configurations is one of the most requested mobile management features. This allows administrators to silently provision Wi-Fi configurations to end user devices ensuring that whenever the end user is near a configured network, the device gets connected without the user needing to type in their credentials, trying to figure out how to connect or in some cases trying to figure out how to install a certificate on their device.
So I’m really excited that with Update 4 it is now possible to deploy Wi-Fi configurations on managed iOS and Android devices.
In Update 4, we have introduced a new bundle type – ‘Corporate Bundle’ to house bundles for corporate resources like Wi-Fi, VPN etc. As a start, within this bundle type we have added a Wi-Fi Profile bundle through which Wi-Fi configurations can be distributed to devices.
In Update 4, we are supporting all the widely used Encryption Protocols – WEP, WPA1 & WPA2. We are not yet supporting WPA3, as it was finalised only couple of months back and routers supporting WPA3 are yet to hit the market. As, and when, this happens, we will go ahead and add support for WPA3. Along with Encryption Protocols, we are also supporting the most widely used Extensible Authentication Protocols (EAP) such as PEAP, LEAP, TTLS etc. (Figure 5).
The only notable EAP exception which we are not supporting is TLS where authentication between a device and Wi-F server is through a user/device identity certificate. This is on our list of things to do and we plan to support it in future releases.
Since it is not necessary for devices to trust the certificate used by a Wi-Fi point, using the Wi-Fi Profile bundle, an admin can also provision certificates to the device in case, thus ensuring that trust is established beforehand.
Distributing Enterprise Applications on iOS Devices
Typically, mobile application stores (App Store & Google Play) have their own set of guidelines which an app must comply with. As an example, if on the Android platform an App requires access to phone logs or text messages, it is required to demonstrate to Google that the underlying use case is one amongst the Google approved use cases or else it won’t get published. Stores can also mandate apps to support specific hardware as Apple did recently by mandating that all Apps need to support the latest set of iPhones.
For many organisations requiring custom applications for their internal use, adhering to store guidelines may not be feasible due to the application use case being in violation of store guidelines. Also, in some scenarios the need to be in compliance of store guidelines can manifest itself in the form of increased development cost.
Lastly, some organisations may have company confidential data as part of app and may want to limit and control its distribution. Thus, many organisations choose to distribute their enterprise applications privately to a selected set of mobile devices.
However, distributing apps outside application stores can be quite challenging and may involve users being asked to disable settings, accept certificates etc. before an app can be installed. Even once installed, updating such an app would typically require end users to do all the steps as required at the time of installation. It is here a UEM solution like ZENworks can be of great help in distributing these applications directly to devices and in the process bypassing the application stores.
With Update 2, we added the capability to deploy enterprise applications to Android Devices. With ZENworks 2017 Update 4, we have now added the capability to distribute enterprise applications to iOS devices.
There is a new Bundle type using which enterprise developed iOS Apps can be uploaded into ZENworks. Thereafter, the enterprise app would be installed on the device just like an app from App Store. Apart from savings in distribution costs, it ensures that future updates can be deployed on devices just like any other app update and without need for user interaction.
To summarise, ZENworks 2017 Update 4 has more than 30 enhancements along with defect fixes spread across the ZENworks Suite. I’m sure that with such an expansive feature set, every ZENworks administrator has something to cheer about.
This article was first published in OHM43, 2019.1, p12-15