Skype for Business mobility

Before we go into the Skype for Business mobility world in depth, let’s look at the high level functionality the mobile app provides. At this point it is also prudent to declare that functionality differs depending on what OS your mobile device supports. For instance, Android devices don’t have the ability to use push notifications, while iOS and Windows devices do. In this article I am going to discuss the mobile application in general terms. The mobile app provides users with extended reach of their enterprise collaboration toolset beyond the boundaries of a corporate network or device. Traditionally, collaboration tools have been bound strictly within the corporate world, network and device and only extended outside with the use of VPN technology. As we know, VPN connectivity is not recommended for any real-time media data packets. So back in the days of Lync 2010, Microsoft designed a mobile app that could leverage the external access methods Lync provided natively. This meant that users could be mobile and consume their Lync services from anywhere with a data connection (Wifi or carrier 3G) without the need for VPNs or other proprietary solutions. Great move. As the mobile application and the core of Lync improved, so did the functionality provided to users. Today’s Skype for Business mobile application now delivers the most advanced toolset yet to users regardless of location and device, including:

• Instant Messaging and Presence
• Push Notifications
• IP Audio and Video Calling
• Call Management
• Conference Join
• Content Viewing
• Dial Pad and Voicemail playback

There are some environmental variables that hamper the success and reliability of the mobile application. The mobile app, relies on the devices having a sufficient and stable connection to the internet i.e. Wifi, 3G, 4G etc. However, all these methods of connectivity have their own unique problems. These problems usually surround bandwidth and throughput. Wifi connection is the best form of connectivity for a mobile device, but the nature of how Wifi works, channel interference, obstacles, distance from the access point, number of devices connected to the access point etc., all have a profound effect on the mobile app’s capability to provide a good experience. 3G and 4G connections are less desirable, carriers can limit bandwidth and throughput which has an effect on the app’s ability to participate in a video call or content sharing viewing. Sometimes, even when you have full signal strength Video and content sharing may not be possible due to the carrier’s policing of their data network. Not only this, but the same crutches Wifi has, is also true to mobile data networks but they are magnified. Taking this into consideration, means that the mobile app is flawed by the underlying technology it relies on to operate. So all we can expect from this app, is to perform as best as it can in the circumstances it finds itself in. So next time you are screaming at your mobile client because it cannot perform the task you’ve asked, spare a thought to the constraints before blaming Microsoft J.

So with this in mind, how can the application be used effectively by users? The app itself, is a good instant messaging tool and performs reasonably well when engaged in an instant message conversation. Server side conversation history now improves this experience with users being able to continue conversations between devices (subject to Exchange 2013+), a feature long wished for amongst regular Lync users. Being able to join Skype for Business meetings using one click join from your mobile is a welcome addition to the mobile app recently, combined with viewing content and PowerPoints rather than just being able to listen to the audio portion of the meeting makes the mobile app a powerful mobile collaboration tool. Participation in meetings whilst on the move is crucial to modern working, however, please avoid the use case of “you can now join meetings, view powerpoints and content using your mobile app, whilst in the car” This is an oft-used scenario pitched even by Microsoft themselves as a USP of the mobile app. But beware, in the UK of the driving laws. You could get points on your licence for dangerous / careless driving which could lead to a ban, for instance:

• Driving while in an audio conference using a hands-free Bluetooth solution is akin to taking a mobile phone call and therefore, conceivably legal under current driving law
• Driving while in a conference and viewing a PowerPoint or Desktop is akin to watching a DVD on your in car entertainment system. This is illegal, and you will be prosecuted if caught. It’s dangerous, so don’t do it!

Another massive benefit of the mobile application is the ability to update your call forwarding settings on the move. Perhaps you have just checked in to a hotel that has poor wifi, but has a room telephone. Update your forwarding settings to the room phone and in 2 minutes, you have all your incoming enterprise voice calls received on that phone.

As mentioned and before we move on to dependencies, the mobile application is supported on almost every mobile device on the market today, iOS 9+, Android 4+, Windows Phone’s are all supported. There are some exceptions. The main one being no support or application for Blackberry devices running Blackberry developed OS and a handful of Android devices that have the Tegra 2 Chipset installed. A list of all Tegra 2 chipset devices:

• Acer Iconia Tab A100 and A500,
• Asus Eee Pad Transformer,
• Asus Slider,
• Exper EasyPad,
• LG Optimus 2X,
• LG Optimus Pad,
• Motorola Atrix 4G,
• Motorola Droid Bionic,
• Notion Ink Adam tablet,
• Olivetti OliPad 100,
• Point of View Mobii 10.1,
• Samsung Galaxy S II (in some regions),
• Samsung Galaxy Tab 10.1,
• T-Mobile G-Slate,
• Tesla Model S,
• Toshiba AC100,
• Toshiba Folio 100,
• Velocity Micro Cruz Tablet L510,
• ViewSonic G Tablet,
• Motorola Xoom

Dependencies

As with any Skype for Business role, feature and modality, there are dependencies and mobile applications are not immune to these. Each dependency will be discussed in a little detail shortly, but for a BOM, you need the following:

• Skype for Business Front End Server
• Reverse Proxy
• Skype for Business Edge Server
• Public SSL Certificates
• Publically routable IP addresses and a firewall that supports NAT
• Public Domain Name with DNS zone control

Skype for Business Front End Server

As with any Skype for Business modality, you need a Front end server. Without one, Skype for Business simply does not exist. Specific configuration of the Front End services is required in order to deploy mobility successfully. First and foremost, the mobile application is a web service dependent application. This means it doesn’t connect directly to Skype for Business services at program level. Instead it uses a web service and SDK to interface with the Front End services. These web services can be viewed in IIS Management Console on the front end server under the external website. Three virtual directories are required to exist for mobile app support:

1. Autodiscover
2. Mcx
3. Ucwa

You may also notice that the external web services site on the front end listens on TCP ports 8080 for HTTP and 4443 for HTTPS traffic. While the internal web services site listen on native TCP ports 80 and 443 respectively.

This is an important consideration for mobility services. The nature of the mobile application authentication process demands that sign-in be handled differently to that of internal services. Furthermore, key internal management applications are not exposed to the public domain, such as, Control Panel (CSCP), Web based PowerShell (OCSPowershell) and response group configuration page (RGSConfig). These directories are available on the internal website, but not the external.

The front end server also is responsible for mobile app user policies to set some application restrictions. These policies are handled by PowerShell commandlets using the Skype for Business management shell.

As the external website listens on non-standard ports, a solution is required that can transform incoming requests on standardized ports into the correct back-end ports needed to expose the external website to the public domain. This is achieved using a reverse proxy.

Reverse Proxy

A reverse proxy is simply a server that accepts incoming web requests from one source and passes through that request to the “real” web server that sits on the inside network, not published directly to the internet. As traffic passes through the reverse proxy, it can determine which internal web service to send the request to and more importantly for Skype for Business, which port. For Skype for Business there are a few supported reverse proxies, but the main ones are IIS ARR, WAP, Kemp, Netscaler.

The reverse proxy will handle all external and internal web requests made by the mobile application for the web service url e.g. sws.domain.com. Therefore, DNS records must exist both in the public and private domain DNS zones i.e. split DNS.

The requirements for the reverse proxy are relatively simple. The main 4 requirements are:

1. SSL decryption and re-encryption – Ability to install a public trusted certificate to the reverse proxy virtual IP service for the required URLs for decryption of packets on the public side, read and interpret the packet HTTP header to determine the correct back end service to send the request on to, and then re-encrypt the packet on the private side and send to the front end server.
2. Symmetric routing must be configured. That means that the outgoing packet from the front end must traverse the same route the incoming packet arrived on, i.e. in through the reverse proxy and back out of the reverse proxy. This is more of a networking requirement than a reverse proxy requirement per-say. The use of web proxy servers is not supported as it can cause asymmetric routing. If a web proxy server is in use, then all external urls for the Skype for Business deployment from all machines must bypass the web proxy server.
3. Any form of content caching on the reverse proxy must be disabled. Caching is not supported.
4. The reverse proxy must support COOKIE based persistence rather than SOURCE based persistence. This is because the source address of the mobile device can change as it traverses 3G hotspots and Wifi networks. Using COOKIE based persistence means the device can be identified regardless of network membership and will be trusted so authentication does not need to reoccur.

Skype for Business Edge Server

The Edge server we have come to know as a dependency of things like federation and external access. However, as the mobile application uses web service requests, the edge server is not required if you just want users to be able to use the mobile application for IM, Presence and address book search. You DO need an Edge server, if you plan to deploy P2P, and multi-party voice, video and want mobile users to be able to view content such as desktop sharing. The edge server acts as a STUN and TURN server that allows the mobile app to be suggested as an eligible peer for media establishment. The same as a standard desktop client.

SSL Certificates

As the mobile application is treated as external peer, regardless of its location (internal corporate wifi, or 4G), all signaling and web service requests will use the external URLs of the reverse proxy and Edge server for connectivity. The deployment of internal root certificates to mobile devices can be problematic, especially on unmanaged devices. Therefore, it is highly recommended, and in fact the only supported solution to use trusted SSL certificates from the likes of GoDaddy for your external reverse proxy and Edge services.

Reverse Proxy Certificate Requirements

In a single SIP domain deployment, the use of a wildcard certificate e.g. *.domain.com is supported and is the cheapest option for many. However, this certificate can be reused for other services, and if in the wrong hands can lead to security breaches. Therefore, a Unified Communications Certificate (or UCC) with Subject Alternative Names (SANs) using the SHA-2 256 bit encryption algorithm and key length of 2048 are recommended.

The certificate’s common name (the one you see the certificated issued to) should be the web services external URL e.g. sws.domain.com. This does not matter for the Reverse Proxy server so much as the Edge. However, the SAN names must include

• Lyncdiscover.domain.com
• Meet.domain.com – required if you want external or mobile meeting join.
• Dialin.domain.com – not specifically required for mobility, but needed if you are using dial-in PSTN conferencing

This certificate needs to be installed on the reverse proxy server for your Skype for Business web services. Ensure you have the complete trust chain installed on the reverse proxy server and also the private key of the certificate issued is installed.

In a multiple SIP domain deployment, you cannot use a wildcard certificate. Instead a UCC certificate is the only form of secure connectivity available to you. An additional SAN entry will be required for the Lyncdisover URL for each SIP domain added, e.g. lyncdiscover.domain.com and lyncdiscover.domain2.com. You can present your meeting join and web services url out as a shared service for all SIP domains, therefore, these are not required for additional SIP domains.

Alternatively, if you cannot afford a UCC certificate to cover all your SIP domains, you can force unencrypted autodiscovery using lyncdiscover.domain.com over HTTP port 80 only. In this case the discovery service would not be encrypted, but signaling and web services would. In this instance a wildcard certificate or UCC without lyncdiscover added as a SAN would be acceptable.

Edge Server Certificate Requirements

There are a couple of edge deployment topologies available. However, in either case, a trusted SSL certificate covering the external access edge service and conferencing service is required. The common name (or subject name) of the certificate must match your external access edge FQDN e.g. sip.domain.com, with the conferencing FQDN as a SAN entry. The AV FQDN is not required as an entry on the certificate. One point to note is that if you are not using sip.domain.com as your access edge FQDN, and using something like accessedge.domain.com, then it is recommended (although not essential) to include sip.domain.com as a SAN entry also.

Networking Requirements

A dedicated public IP address is required for your reverse proxy server. For your edge you will need another public IP address, or 3, depending if you are using a single consolidated edge server or scaled edge server. Either way, these must be dedicated IPs, i.e. not shared with any other service. The firewall must support 1:1 NAT. Port Address Translation (PAT) is not supported.

The firewall should also support hair-pinning on the public untrusted network interface. This is needed for when mobiles are on corporate wifi networks. Mobiles will attempt to connect to the external web service URL only. This will be pointing at your firewall and therefore, it needs to turn that request back on itself and NAT it to the reverse proxy. Many security administrators do not like this, therefore an alternative is to point the web service URL, and your AV FQDN to your reverse proxy, and Edge AV private external DMZ IP respectively, using your internal DNS Zone to effectively achieve the same result.

Mobility Inside Your Network

Many users wish to use their mobile device when at work. When we talk about Mobility inside your network, I mean mobile devices connected to your corporate Wifi. Not a mobile inside your building connected to the carrier data network for instance. As I have eluded to in the dependencies, the mobile app is treated as an external source, even when connected to your internal Wifi. This means all signaling and web service requests for things like address book search, presence etc will be handled by your reverse proxy and using your external web services FQDN. Therefore, assuming the mobile device has been provided internal DNS servers by DHCP over Wifi, you need a Zone creating on your DNS server for each public SIP domain you offer.

You may notice I have not referenced Lyncdiscover here. This is because of the way the mobile app discovers the service. It begins with trying to resolve lyncdiscoverinternal.domain.com before reverting to lyncdiscover.domain.com. As the mobile device is connected to your internal DNS servers, it will be able to resolve lyncdiscoverinternal.domain.com which will be pointing directly to your front end server pool. It will attempt to connect to this service using HTTPS first, but will fail as the certificate will be internally signed. However, it will attempt HTTP discovery which will succeed before trying the lyncdiscover.domain.com name resolution. Therefore, when mobile clients are internal, they will always perform discovery locally to the corporate network, rather than attempt to break out to the reverse proxy server.

When it comes to media establishment, there are two ways in which media will be established. Which, depends on whether the mobile client can establish media directly with the peer internal IP address, or if it cannot.

Mobile Client to Desktop Client when both endpoints are Internal

When both endpoints are on the same network, SDP will discover both peer candidates as having a routable private IP e.g. 192.168.1.10 and 192.168.1.11. Therefore, media will be established directly, while signaling will always go via the reverse proxy to the front end as in this diagram

(dashed arrow to show alternative solution if firewall hairpin disallowed)

Mobile Client to Desktop Client when both endpoints are Internal BUT there is no direct path between them

In this scenario, perhaps the mobile client is on a guest Wifi Subnet which is heavily firewalled and the desktop client is on the corporate LAN. Here it would not be possible to directly establish media between the two endpoints. To get around this problem, media would be established using the Edge server as an ICE, TURN server for media relay between the two endpoints.

(dashed arrow to show alternative solution if firewall hairpin disallowed)

Mobile Client to Desktop Client when the Desktop Client is External and Mobile Client is Internal

This scenario is similar to the previous example in that direct media establishment is not possible between the two endpoints and therefore, media will us the Edge server as the media relay server (MRAS).

(dashed arrow to show alternative solution if firewall hairpin disallowed)

Mobility Outside Your Network

When the mobile device is outside your network on 3G or home Wifi etc, all discovery, web services and media paths will use the external URLs. Media will be established using the Edge ICE, STUN and TURN server as the relay for media between the two endpoints, unless of course both external endpoints are on the same LAN (doubtful).

Discovery Service

So we have talked about the discovery service, mentioned the DNS records Lyncdiscover.domain.com etc. But what is it and why is it important for mobility? Well, the discovery service is an XML based web service that provides the fundamental connection settings to the mobile client for the purpose of automatic discovery and connectivity. Without the discovery service the mobile app would not be able to determine the Web Service URL, MCX URL, UCWA URL or the AV FQDN. This means that you will not be able to sign into the client or consume any features. Instead, the user would be required to manually enter these connection settings into the application. Not user friendly at all.

The discovery service for Skype for Business differs a little from the Exchange counterpart, in that the discovery service does not perform any authentication on the discovery request, it is deferred to the web service instead. Therefore, you are able to determine anyone’s discovery settings without having an account on their system. Just browse tohttps://lyncdiscover.theskypeshow.com/Autodiscover/Autodiscover.svc/root and find out yourself!

Here is an example of an autodiscover request from a mobile device

The response from the discovery service will be an XML response and it will contain all the connection service URLs, both internally and externally. It will also determine whether the client is internal to the Skype for Business deployment or external

From the above capture, you will be able to determine that the discovery service has identified the mobile client as external by looking at the AccessLocation=External attribute at the beginning of the XML response. The mobile client will interpret that information and perform DNS lookup and resolution to all its required External services. These are notably

• External/Authbroker
• External/CertProvisioning
• External/Mcx
• External/Ucwa
• External/WebScheduler

These Service locations are then used to connect and authenticate with your Skype for Business solution.

Authentication

Authentication for the mobile application is performed initially using NTLM. This means that your username and password are used to determine your authenticity against the Skype for Business solution and ultimately your Active Directory. There are several problems with NTLM from security to performance and therefore NTLM is somewhat discouraged in some businesses. The main concern with NTLM authentication is that it requires authentication against your AD increasing the dependency on this service being available.

So to combat this, the mobile app, like it’s desktop counterpart performs a second level of authentication after NTLM has succeeded. This comes in the flavor of a Certificate. This certificate is issued to you and the device from the Certificate Provisioning Service on the Skype for Business Front End server pool. This certificate is used to encrypt the SAML security token used to encrypt SOAP requests (Mobile app uses SOAP). The token carries the sip address of the user as well as an actor token that contains the FQDN of the authorizing server (front end pool) and the realm (domain name). This token is then validated by the Web Ticket Service (OAUTH) which means that as long as the Certificate used to sign the token is valid (i.e. not expired), subsequent NTLM authentication is not required.

The result of this type of authentication means that users are able to sign in to the mobile app repeatedly with better performance and experience than if they were relying on NTLM, while protecting them from a weak form of authentication. The downside for administrators is that the certificate provisioning service issues certificates to users and devices for a period of 180 days out of the box. This means that a user who has left the business could potentially continue to sign into the mobile application for up to 6 months if you simply disable the AD account. Therefore, proper processes need to be in place to first disable the user from Skype for Business before disabling the AD account. Admittedly, there are ways to reduce the lifetime of certificates issued by the certificate provisioning service, but this is out of scope of this article.

Multi Factor Authentication

Briefly touching on MFA for Skype for Business, MFA is supported for the mobile application. MFA is not supported however, on Skype for Business Online (at the moment). This is down to the fact that you cannot turn on passive authentication for SfB Online. Passive authentication is required for the mobile app to work with MFA providers. Therefore, if you have SfB Online, then you have to use App Passwords with Azure MFA subscription to effectively bypass the MFA process for the mobile client. For on-premises, MFA is supported for providers such as ADFS with Certificate MFA, however, you must configure your Skype for Business deployment for Passive Authentication.

What is passive authentication? In a nutshell, this means Skype for Business will offload its authentication challenge to another authentication provider. The user will be redirected in the client to perform authentication on another system, e.g. ADFS and that system will be responsible for allowing / disallowing authentication requests.

This change is an architecture changes and can have profound effects on the functionality of your deployment if not fully considered. To enable Passive Authentication you need to turn OFF all other forms of authentication, this includes Kerberos and NTLM. If you are not ready and you don’t fully understand ADFS at this point, then things can break, fast. Please read this topic https://technet.microsoft.com/en-us/library/dn308567(v=ocs.15).aspx

Configuring Mobility

Configuring the mobile client remotely is basic. You can create a mobility policy and assign this policy to a user to set things like:

• Require Wifi for Audio, Video and Content Sharing – to protect against carrier data plan charges
• Enable / Disable mobility for a user, all users within a particular site, or globally
• Enable / Disable Outside Voice (Call via Work)

If you do not plan on using mobility, I suggest not exposing your external web URL to the outside world for security. This can be done by running the following command

Set-McxCsConfiguration –Identity Global –ExposedWebURL Internal

You can also set the maximum time the mobile application can be inactive for before, requiring it to re-establish its connection by running the following commands

• Set-CsMcxConfiguration –Identity Global –SessionExpirationInterval <seconds> – For Apple and Windows Phone Users
• Set-CsMcxConfiguration –Identity Global –SessionShortExpirationInterval <seconds> – For Android and Nokia device users

Testing Mobility

There are some remote testing facilities for mobility. The most commonly used service iswww.testconnectivity.microsoft.com However, this will test only that discovery service is functional in respect to the mobile application. If you want a solid test of the mobility service, use the Lync Connectivity Analyzer which can be downloaded here:www.theskypeshow.com/aka/analyzer

You can also run PowerShell synthetic transaction command to test the mobility service. However, you need to first pass each user’s password in the test into a PS credential

$cred1 = Get-Credential

$cred2 = Get-Credential

Test-CsUcwaConference -TargetFqdn fepool01.domain.com -OrganizerSipAddress “sip:user1@domain.com” -OrganizerCredential $cred1 -ParticipantSipAddress “sip:user2@domain.com” -ParticipantCredential $cred2

Push Notifications

Push notifications are alerts that can be sent to a mobile device when the mobile application is inactive, minimized in the background services. In order for push notifications to work, you need an Edge server deployed and they are not enabled by default. There are two push notification services:

• Microsoft Push Notification Service (MPNS)
• Apple Push Notification Server (APNS)

Push notifications are not sent directly to the mobile client from the Edge server, instead, notifications are sent to APNS and MPNS in the cloud, which in turn relays these notifications to the user’s device. Push Notifications are not a reliable form of information delivery. There are no guarantees that the notification will reach the intended device. As far as Skype for Business is concerned, a push notification is a “fire and forget” service with no way of determining the status of the request. There are some allowances for the inevitable drop in mobile service, for instance APNS will attempt to redeliver notifications for a limited amount of time. If this time has elapsed, the notification is lost forever.

With modern iOS devices and the latest mobile application update for iOS, you no longer need to enable APNS for push notifications, but you still need an Edge server. For Windows devices, in order to use the MPNS, you need to federate your on-premises Skype for Business deployment with Office 365. Please note Android devices do not support push notifications.

If your users use iOS mobile devices inside your network connected to corporate Wifi, you must allow TCP port 5223 outbound to the internet for the APNS to reach the mobile client.

You are able to test the push notification service using a synthetic transaction powershell command Test-CsMcxPushNotification –AccessEdgeFqdn sip.domain.com

SHARE

Milan Tomic

Hi. I’m Designer of Blog Magic. I’m CEO/Founder of ThemeXpose. I’m Creative Art Director, Web Designer, UI/UX Designer, Interaction Designer, Industrial Designer, Web Developer, Business Enthusiast, StartUp Enthusiast, Speaker, Writer and Photographer. Inspired to make things looks better.

• 
• 
• 
• 
•