Loadingkk241

Known Issues

Resolved Issues

Release History

New Mobility Clients for Windows (January 17, 2018)

Versions of Mobility prior to v11.32 are fully compatible with recent Windows updates (released January 3 and 9, 2017) that address the Spectre and Meltdown vulnerabilities. However, we anticipate the release of a subsequent Windows update that will be incompatible with pre-v11.32 Mobility clients. NetMotion Software has released new Windows 10, Windows 8, and Windows 7 Mobility clients that address this future incompatibility.

You must upgrade to Mobility v11.32 before applying the expected Windows updates, otherwise Mobility will not work as expected. You must be proactive and install the v11.32 Mobility clients now to prevent incompatibility with the expected Microsoft updates. On January 17, we sent an email to Mobility administrators and posted an FAQ addressing this issue in more detail. There is no need to update the Mobility server.

Notes:

• For administrators who require a Mobility XE client, which uses an earlier client architecture, the release you must upgrade to is Mobility XE, v10.74.

• If you are running security software from Trend Micro, read the description of MOB-12067 before upgrading.

About Upgrading Mobility

Settings: When you upgrade Mobility, the settings that you have configured in the earlier release are used in the new installation. But sometimes NetMotion Software will change settings and you need to be aware of the consequences. See Things to Consider Before You Upgrade Mobility in the Mobility server help for details.

Mobility warehouse: Versions 10 and later of the Mobility server work only with version 7.0 and later of the Mobility warehouse.

• If you are upgrading to Mobility v11, your starting point must be Mobility servers running v9.2x or later, and version 7.0 of the Mobility warehouse.

• If you have version 7.0 of the warehouse from a previous release, upgrade the warehouse to v11.

See Upgrading the Mobility Warehouse in the Mobility server help for details.

FIPS 140-2 CNG Modules

When Mobility is configured to require FIPS 140-2 validated encryption, a Mobility server accepts connections from Mobility clients that use any of a list of cryptographic modules specified in the Mobility console. The default list of modules is as follows:

Before you install or upgrade the Mobility server, refer to FIPS Considerations During Setup in the help. It includes important tips for upgrading and information about Windows 7 clients.

Analytics Module

As of Mobility v9.50 the Analytics Module is a single component. For users who are upgrading and want to use the data they have collected, there are procedures and a utility (the Analytics Module Data Exporter) to migrate data from all supported configurations. Before installing version 11, look through the scenarios in Upgrading the Analytics Module in the Mobility server help and follow the instructions for the one that best fits your deployment.

Specifying an Internal Interface

If you have more than one network adapter on the computer that will host your Mobility server, you must specify (during Setup) the name of the network adapter that is to be used as the internal interface. To make sure that Mobility-related traffic is properly routed, refer to Configuring Network Interfaces and Routing for information about what you need to configure and take into account.

Customer Support and EOL Advisories

The Mobility server is supported only on Windows Server 2016 and Windows Server 2012 R2. For a list of advisories, with information about when support ends for operating systems or Mobility versions, see the Mobility server help.

Windows Server 2012 R2: Microsoft Support Advisory for NPS

On Tuesday August 8, 2017, Microsoft released a roll-up patch (KB4034681) for NPS running on Windows Server 2012 R2 that broke authentication based on RADIUS EAP-TLS and PEAP-TLS. You may no longer be able to authenticate after applying the roll-up.

Microsoft has published a work around that involves changing a registry setting on your NPS server. NPS administrators should evaluate whether to implement the work around, or to hold off installing the patch until Microsoft implements a fix.

Client issues are grouped by operating system and listed in descending order by issue number.

Cross-Platform Client Issues

iOS and Android: Skype session does not persist during roam [MOB-8599]

If you are on a Skype video call and you roam between cellular and Wi-Fi, your call is disconnected.

Client logon with UPN fails when authentication is NTLM [MOB-8578]

If you use a UPN to log on to a Mobility server (for example, user.name@your.company.com), and if the authentication protocol is NTLM, the logon fails. Call Technical Support for help if using a UPN is required in your deployment.

Windows Client

Upgrade fails unless Trend Micro has patch [MOB-12067]

If you are running security software from Trend Micro, and you plan to upgrade Mobility clients running on Windows, there are two options for ensuring a successful Mobility upgrade:

• Install the latest client software patch from Trend Micro before upgrading Mobility. The client hotfix that addresses this issue is 4440; you may need to request it from Trend Micro.

• Uninstall Trend Micro, upgrade the Mobility client, and then re-install your security software.

macOS Client

macOS: A quick disconnect/reconnect may cause Mobility to fail (Apple RADAR ID: 32073323) [MOB-11447]

If you disconnect your Mobility session, and then reconnect within 5 seconds, the operating system may spontaneously disconnect Mobility about 20 seconds later. In most cases Mobility will automatically reconnect when it detects this problem. This is an issue with the Apple operating system (Apple RADAR ID: 32073323).

macOS: AirWatch Per-App profile not displayed in Mobility client [MOB-8500]

If you create a VPN profile for Mobility in the AirWatch console, and you enable Per App VPN Rules in the connection info area, the profile does not appear in the list of configurations for the Mobility client for macOS.

macOS: Mobility extension stops unexpectedly (Apple RADAR ID: 25290018) [MOB-8172]

There is an issue with the Apple operating system (Apple RADAR ID: 25290018) that can cause the Mobility client to stop unexpectedly during roaming or startup, or when a policy is applied or removed. The Mobility app automatically reconnects if the Mobility extension crashes for any reason, so users may not be aware of this issue. When the problem occurs, an Info message is logged to appLog.txt ('Mobility extension stopped unexpectedly. Reconnecting.').

iPhone/iPad Client

iOS: Upgrading the Apple OS [MOB-11563]

If the Mobility VPN is installed when you upgrade your Apple operating system to version 11, you may see problems connecting with Mobility after the upgrade. To resolve this issue, restart the device, open Mobility, and establish a connection to the Mobility server.

Android Client

Android 8 and name resolution [MOB-11680]

When the Mobility client is running on Android 8, there are no issues getting names resolved by a DNS server that Mobility is configured to use. But the client may have issues with names that require a DNS server accessible via the local network (for example, a local printer).

Android 8: Mobility notifications not displayed [MOB-11679]

The Mobility client displays a number of connection-related notifications, indicating, for example, that the Mobility server is unreachable, the client is disconnected, or Mobility is connecting. These notifications are not working in Android 8; Mobility works as expected, but the user is not notified of connection issues.

Android: Application connections do not persist when roaming between networks [MOB-11233, MOB-3275]

Mobility supports two types of session persistence: application sessions and VPN tunnel sessions. Google made changes in Android 4.4, 7.x, and 8.x that may affect TCP application session persistence while roaming between networks. Session persistence when moving through coverage gaps, all UDP traffic, and VPN tunnel sessions are all unaffected, but when a network interface is reset (for example, roaming from cellular to Wi-Fi), TCP application sessions do not persist. Until Google fixes this issue, TCP session persistence on Android may be limited:

• Most Android applications reconnect automatically and users are not disrupted.

• Some Android applications may need to be restarted.

In all cases, Mobility automatically maintains the VPN tunnel session so that users do not need to re-authenticate. Even when there are interruptions, Mobility improves application behavior, performance, and stability.

After an upgrade, the user name field is blank [MOB-10900]

If you have a working VPN configuration when you upgrade your Mobility client, the configuration will continue to work. If you open the configuration and look at its settings, however, the User name field will be blank. The working credentials are saved in your configuration, just not visible.

Expected certificate is not listed as active [MOB-10703]

When you view or edit a VPN configuration for an Android device that includes a certificate in its credentials, the certificate is not always listed as expected. Here are situations in which that may occur:

• Manually created profile: If a certificate is selected during authentication, it is not listed as the active certificate.

• Android for Work: The certificate in the profile is not listed as active.

• nmcfg. file: You can create a configuration file and distribute it using email, as described here. If multiple certs are included with your .nmcfg profile, only the most recent certificate is selected and listed as active.

Changing or clearing certificates [MOB-10476]

On older Android devices (before version 6), changing or clearing certificates in Android Settings may also remove them from any Mobility configurations that use them (in the Mobility client, the certificate will be listed as Unknown). To use the certificate, you must import it again.

SOTI MobiControl and Android+ authentication [MOB-10414]

SOTI, the creators of the MDM MobiControl, collaborated with device hardware manufacturers to come up with a series of Android devices they call Android+. When you configure NetMotion Mobility VPN for an Android+ device using MobiControl, only password authentication is supported.

MobiControl profile may need to be pushed to clients again [MOB-10030]

When a profile is pushed down from the MobiControl console to devices running Mobility, the configuration should take place immediately. This is currently not working as designed; the workaround is to install Mobility first, then use the MobiControl console to push the profile down to devices.

Android: Mobility client is incompatible with IAS [MOB-9352]

The Mobility client for Android is incompatible with an authentication server running Internet Authentication Service (IAS), Microsoft's RADIUS implementation for Windows Server 2003. Mobility supports Network Policy Server (NPS), the current Microsoft implementation of a RADIUS server and proxy.

Android 5.x: Connecting Mobility on startup takes about a minute after device restart [MOB-7148]

When Connect on startup is selected, the Mobility client attempts to connect to a Mobility server at the same time as the Android device starts. On a device running Android 5.x that has been restarted, it can take up to a minute before Mobility begins connecting to the Mobility server.

Android 5.x: 'Connecting ... waiting for Mobility adapter' state persists [MOB-5739]

If a user is connected using Mobility and then uninstalls and re-installs the Mobility app (either the same version of the app, or during an upgrade), the Mobility client will remain in the 'Connecting ... waiting for Mobility adapter' state. Reboot the Android device to clear the message.

Android: Interface proxy settings are ignored when connected with Mobility [MOB-4190]

In the Android operating system you can modify the proxy settings for WiFi connectivity, but these settings are ignored when the device is connected over the Mobility VPN tunnel (without a VPN installed the proxy works as expected). This is due to Google issue 33935.

Android: Restricted profiles and multiple users [MOB-2914]

When an Android device has a restricted profile or is configured to support multiple users, the Mobility client for Android can only be started by the primary user. It cannot be started by any other user.

Mobility v11 browser settings for Internet Explorer 10

In Mobility v11 the console cannot be accessed using TLS 1.0; if you have only TLS 1.0 enabled, you will see the error This page can't be displayed. To change your Internet Explorer browser settings, go to Tools > Internet options > Advanced tab > Security and then select Use TLS 1.1.

This is a workaround for Internet Explorer 10; it is not an issue with Internet Explorer 11, Firefox, or Chrome.

For automated warehouse backup, warehouse port must be 389 [MOB-12139]

By default, Mobility servers communicate with the warehouse over port 389. If you specify a different port, automated backups of the warehouse will not work.

• The warehouse port is configured during Setup or in the Mobility Management Tool.

• Automated backups are configured during Setup or in the Warehouse Management Tool.

ActiveMQ event log error message [MOB-11443]

In the Mobility server event log you may see a Reporting error that looks like this right after you enable a log management server: TaskRunnerFactory - Error in thread 'ActiveMQ VMTransport: vm://Log4MobilityCollector#1-2'. This should be rare and the error can be ignored.

Standards-compliant RADIUS compatibility [MOB-10083]

Mobility supports standards-compliant RADIUS servers for authentication:

• If you are using a Dual Shield RADIUS server, make sure it is version 5.9.3.0215 or later, to ensure that it supports TLS 1.2.

• If you are using a Free RADIUS server, make sure it fully supports TLS 1.2.

Primary warehouse name cannot include Japanese characters [MOB-7821]

If you are running Mobility software that has been localized for the Japanese market, do not assign the primary warehouse a name that includes Japanese characters: a standby warehouse will not be able to create a replication agreement with the primary warehouse.

If a NIC is renamed, the new interface name must be selected in the Mobility Management Tool [MOB-6125]

If you change the name of the network adapter on the computer hosting a Mobility server, you must open the Mobility Management Tool and select the correct internal interface on the Mobility Server tab (even though there is only one interface displayed). If you do not perform this step, your Mobility deployment will continue to function, but only until the server is rebooted. If the server is rebooted and the correct interface has not been selected, Mobility clients will be able to connect, but will have invalid virtual addresses.

Analytics alerts using syslog do not send Japanese characters correctly [MOB-10135]

If your analytics server is hosted on a computer running a Japanese operating system, and you configure analytics to send alerts to a syslog server (Analytics > Settings > Send Alerts - Syslog), the characters are not sent correctly. To work around this issue, specify a syslog server using server settings instead (Configure > Server Settings > Syslog).