How to deploy Microsoft Lync 2010 Mobility Service (for mobile devices like the iPad and iPhone)

Deploying Microsoft Lync 2010 mobility services for iPad and iPhone

After much struggle to get my iPad to work with Lync server (I tried everything from certificates to configuring the edge server, etc.) I found out Microsoft lets those mobile devices connect via web services but you need to install them. The installation surprisingly seems like a hack more than a simple wizard the way Microsoft does it. All the answers can be easily found on the link mobility documentation from Microsoft but I found a great guide online I´m going to share below. I recommend you visit the link for up to date content I´m just copying it here so if for some reason the link changes or the content goes down the information is not lost. Good luck with your deployment!

 

The original content may be found here: http://blog.schertz.name/2011/12/deploying-the-lync-2010-mobility-service/

Now that the Lync 2010 Mobility Service has been out for a week there has been ample time, relatively speaking, to dissect the documentation, run through multiple installation attempts, and perform some initial discovery work on exactly what this new service is and how it appears to function.  Understanding these concepts can greatly increase the odds of a successful deployment, and this article addresses some of the more complicated or potentially confusing aspects of the overall solution.

(A special thanks goes out to Dave Howe at Microsoft for yet again fielding numerous questions related to how the new Mobility service operates in the undocumented areas.)

Prerequisites

Before beginning the configuration and deployment steps in this article first make sure that each of the following packages has been downloaded; it is also recommended to review the official deployment guide.

• Microsoft Lync Server 2010 Mobility Guide
• Lync Server 2010 Hotfix KB 2493736 (Cumulative Update 4)
• Microsoft Lync Server 2010 Mobility Service and Microsoft Lync Server 2010 Autodiscover Service

An important requirement is that the Mobility service is not supported on a Front End server with a collocated Mediation Server role that has two separate network interfaces which are configured separately as a primary interface for Lync server/client communications and a PSTN interface.  A traditional single-homed collocated Front End server is supported and works fine, it is only the multiple NIC scenario that is not.

Environment Preparation

The example environment used in this article include a single Enterprise Edition Front End Server, Director Server, Edge Server, and Forefront TMG server for a reverse proxy.  All servers are running Windows Server 2008 R2 and Lync 2010 Server CU3 version software.  Steps which are different when a Director role is or is not deployed are specifically identified and explained in detail.

Configure Internal DNS

The first step is to define a new DNS record in the same internal forward lookup zone for each defined SIP domain in the Lync topology.  As the example environment has a single primary SIP domain defined as mslync.net then the internal and external Autodiscover records are created in this same namespace.

Both Alias (CNAME) or Host (A) records are supported, but the simpler approach of using CNAME records will be used for the internal record as this approach works better with a pool since additional server nodes would require additional autodiscover A records.  By using an alias record then the single pool FQDN will always be used as the resolution target.

• Create a new internal DNS Alias (CNAME) record with an Alias Name of lyncdiscoverinternal for the new internal autodiscover FQDN and set the target host as the Director FQDN (e.g. lyncdir.schertz.local) or Front End pool/server FQDN if no Director is deployed.

Install Cumulative Update 4

Before installation of the Mobility service each Lync Server must first be upgraded to Cumulative Update 4.

• Download the LyncServerUpdateInstaller.exe package from the Microsoft Download Center and save locally on the Lync Server.

• Using the Lync Server Management Shell stop all Lync services with the Stop-CsWindowsService cmdlet.

Stop-CsWindowsService

• Then stop IIS World Wide Web Publishing Service using the command net stop w3svc in the same shell window.

net stop w3svc

• Launch the LyncServerUpdateInstaller.exe hotfix package on the server and select Install Updates to automatically deploy on line the required update packages on the server.  Verify that the latest installed version is checked in green before exiting the installer.

• Restart the server if prompted, otherwise re-issue the Stop-CsWindowsService cmdlet to once again stop the Lync services. 
• If the server was not rebooted then restart IIS using the net start w3svc command.

Perform the installation steps above for each Lync server to insure that the entire environment is running the same version of software on all like components.

This next step is only performed once per pool and should be run from only one Front End server per pool for each instance of Back End databases.

• Using the Lync Server Management Shell use re-issue the Stop-CsWindowsService cmdlet to once again stop the Lync services on the Front end server.
• The Install-CsDatabase cmdlet is used to update the Back End SQL databases.  Specify the FQDN of the SQL Server hosting the pool’s databases.  If there are no collocated databases in the same instance for any other Lync Server roles (e.g. Monitoring or Archiving) then omit the -ExcludeCollocatedStores parameter from the command.

Install-CsDatabase –Update –ConfiguredDatabases –SqlServerFqdn sql.schertz.local –ExcludeCollocatedStores

• Restart all Lync services by using the Start-CsWindowsService cmdlet.

Configure Listening Ports

Prior to installing the Mobility service on a Front End server the Lync Topology must have the specific Web service internal and external listening ports defined.  These steps should be performed on each Front End server in the environment.

• Using the Lync Server Management Shell issue the following two cmdlets to define both the internal and external listening ports.

Set-CsWebServer -Identity lync.schertz.local -McxSipPrimaryListeningPort 5086

Set-CsWebServer -Identity lync.schertz.local -McxSipExternalListeningPort 5087

• Publish the changes to the Lync Topology by issuing the Enable-CsTopology cmdlet.

Enable-CsTopology

Server Installation

Although the same installation package must be deployed on all Front End and Director servers it will only install the services which are appropriate to that role.  Each Front End server will have both the Autodiscover and Mobility services installed whereas a Director will only receive the Autodiscover components.

Install IIS Prerequisites

The Mobility service utilizes the Dynamic Content Compression component of IIS which was previously not a prerequisite component for Lync Server, so it must be installed only on Front End Servers (not on Directors).

• For Windows Server 2008 R2 use the Lync Server Management Shell to execute the following cmdlets. A reboot should not be required after installation of the additional IIS component. (For Windows Server 2008 consult the official documentation for an alternative cmdlet, or just use the Add Features wizard in Windows.)

Import-Module ServerManager
Add-WindowsFeature Web-Server, Web-Dyn-Compression

Note: Although the official documentation states that the additional web component is not required on a Director server, it appears that the McxStandalone.msi installation process does not correctly ignore this prerequisite check when it is run on a Director Server.  Currently any attempt to install the package on a Director without this component fails with an error status code of 1603 which states that the “Mobility Service installation requires that IIS Dynamic Content Compression is already installed.”

Until either the documentation is updated or the installation package is fixed then this step will need to be performed on Director Servers as well.

Install Mobility and Autodiscover Services

The new services are not installed by simply running an installation package like the hotfixes.  Instead the MSI file must be saved into a particular directory on the Lync Server and then the Lync Bootstrapper application is manually kicked-off.  This app will notice the existence of the new installation package and automatically perform the installation of the required services based on the specific server role it detects.

• Download the McxStandalone.msi installation package and save it into the following existing directory on each Lync server where it will be installed.

C:ProgramDataMicrosoftLync ServerDeploymentcache4.0.7577.0setup

• Using the Lync Server Management Shell change to the Deployment directory and run the Bootstrapper application using the following commands.

cd “C:Program FilesMicrosoft Lync Server 2010Deployment”
.Bootstrapper.exe

Notice that once the process completes the prerequisite check on a Front End Server then it will install both theFeature_WebComponent_Autodiscover and Feature_WebComponent_Mcx components.

Alternatively the deployment on a Director server will only report the installation of the Autodiscover component.

If the mobility services are to be restricted to internal mobile clients only (e.g. phones connected to internal WiFi access points which have direct access to the internal Lync servers) then use Set-CsMcxConfiguration cmdlet to disable external mobile client access.  (Do not run this cmdlet if external mobile client access is desired and the reverse proxy configuration will be implemented.)

Set-CsMcxConfiguration –ExposedWebUrl Internal

What this cmdlet actually does is enforce which Mcx URL is passed to the connecting mobile client via the autodiscover process.  By default the External Mcx URL is always passed to all clients, regardless of whether they are directed to the internal or external Autodiscover site.  By running the cmdlet above and setting the parameter to Internal then all clients will receive only the internal Mcx URL back.  Thus in an internal-only test environment the clients will always connect to the internal Mcx web site, but in a full deployment with external access then all clients will be passed to the External Mcx URL regardless of the mobile client’s network location.  This concept is discussed in more detail later in the article.

To validate the component installation launch Internet Information Services (IIS) Manager and expand the Internal and External web sites to look for the new Autodiscover and/or Mcx services.  Again, a Front End server should contains both applications in both sites, while a Director will only have the Autodiscover application.

Also notice that two new Application Pools have ben created on the Front End server: CSExtMcxAppPool andCSIntMcxAppPool.  These will not exist on Director Servers since the Mobility service is not installed on them.

Update Internal Certificates

Starting with the Front End Server(s) and then moving to any Director servers each Lync certificate must be updated to include the new autodiscover FQDN.  Note that in this scenario each Lync server uses a single certificate per server which is assigned to all installed roles and the certificates were all issued by an internal Windows Enterprise Certificate Authority.  In environments were public certificates are used or multiple certificates are assigned to servers for different roles (SIP, internal, or external web services) then additional or different steps may be required, so consult the official deployment documentation in those cases.

Note: This is a section that is very confusing in the official Mobility Guide and required about 10 re-reads to understand what it was trying to convey. Assuming that probably 100% of deployments will not already have a “lyncdiscover” FQDN on the existing certificate then the first steps in the document seem out of place, which are just a convoluted way of identifying that the existing certificate does not already have the new name assigned to it. Additionally the instructions in step 6 are poor as following those steps would produce two separate certificate requests for ‘WebServicesInternal’ and ‘WebServicesExternal’ usages leaving the original certificate assigned to the ‘Default.  This would result in converting a server previously using a single certificate to using three separate certificates.

That being said it is recommended to ignore that section of the official documentation for the most part and simply use the Lync Certificate Wizard to issue a new certificate request to a CA of choice.  If multiple SIP domains are defined in the Lync environment then still read through that section of the official documentation as a reference since there are additional steps outlined for making sure that each SIP domain will include its associated autodiscover FQDN in the certificate request. 

The completed installation of the mobility package and the previous listening port configuration has provided Lync server with the components required to know that the WebServicesInternal and WebServicesExternal usages now require thelyncdiscover.<sipdomain> FQDN to be defined in the certificate FQDN.  Thus simply requesting a new certificate will automatically add that new FQDN to the Subject Alternative Name field in the new request.

Note: This does not actually work correctly for a Director server (a pattern is starting to emerge here).  The certificate request on a Director fails to automatically include the autodiscover FQDNs so they must be manually added in to the request which is covered in a later step in this section.

• Launch the Lync Server Deployment Wizard on the desired Lync Front End or Director Server and browse to Install or Update Lync Server System > Request, Install, or Assign Certificates and click Run Again. 
• Expand the Default Certificate and verify if the same certificate is applied to all three server usages or if different certificates are assigned to different ones.  In this example a single certificate is assigned to all usages.

• Make sure that all three usages are checked and then click Request to launch the Certificate Request wizard. 
• Verify that the first window states that it will “Request a certificate for the Default certificate (Server default, web service internal, web services external) Lync server usages.”
• Choose to either send the request immediately to an internal Certificate Authority, or if this is a public certificate or a private certificate assigned by an offline or locked-down CA, then select the option to prepare the request now but send it later.  This will save the request to a text file which can be manually sent or submitted to the offline CA.  Since this example environment utilizes an online Enterprise Windows CA then the Send immediately to an online certification authority option is selected.

• Select the desired online Certificate Authority to submit the request to.  Any Windows Enterprise CAs will automatically be listed, but Standalone CAs can be targeted by specifying the actual path to the CA in the second option.

• Specify alternative credentials to submit the online request if the current user account does not already have those level of rights on the CA. 
• Do not specify an alternative certificate template unless for some reason the internal CA does not have the default Web Server template enabled.  In that case make sure that the custom template used is compatible with the Lync Server certificate requirements.
• Enter a Friendly Name and then enable the Mark the certificate’s private key as exportable setting.  The Friendly Name has no bearing on the certificate functionality and can even been changed after the assigned certificate is received, it is purely a descriptive label and can be anything.  Do not change the bit length from the default 2048 value unless there is some company requirement to do so, although lowering the value is not recommended due to reduced protection offered by a weaker encryption level.

• Populate the Organization and Geographical Information with the pertinent data for the environment.

When requesting a new Front End certificate the Subject Name / Subject Alternate Names window should show the newlyncdiscover.<sipdomain> and lyncdiscoverinternal.<sipdomain> FQDNs.  (The certificate wizard on a Director server will not correctly add these entries and thus they must manually be defined in a later step.)

• Include any additional SIP domains in the current certificate in this request as well to insure that Automatic Configuration or any other client capability is not adversely impacted.  In this environment the sip.mslync.net FQDN is actually pointed to the Director server so that FQDN is not included on the Front End server certificate but instead on the Director certificate request (not pictured). 
• On the Configure Additional Subject Alternative Names window if the request is for a Director server then manually enter the missing lyncdiscover.<sipdomain> and lyncdiscoverinternal<sipdomain> FQDNs for each SIP domain defined in the Lync topology.  This step is not currently documented in the official deployment guide but it is required that these names are also located in Director certificates in addition to Front End certificates.

• Verify the selected values and execute the new Request process.  In a single process this action will submit the request to the CA, which should accept the request and immediately return an issued certificate which the Lync server will automatically import into the Computer store and then attach the associated private key to it.

> Request Certificate

Request-CSCertificate -New -Type Default,WebServicesInternal,WebServicesExternal -CA “DC.schertz.localRootCA” -Country US -State “IL” -City “Chicago” -FriendlyName “Lync Front End Certificate” -KeySize 2048 -PrivateKeyExportable $True -Organization “Home Lab” -OU “Home” -AllSipDomain -Verbose -Report “C:UsersadministratorAppDataLocalTempRequest-CSCertificate-[2011_12_10][10_18_21].html”
Creating new log file “C:UsersadministratorAppDataLocalTempRequest-CSCertificate-68e83735-805d-49c5-a277-8d6b087941a9.xml”.
Create a certificate request based on Lync Server configuration for this computer.
Issued thumbprint “E46942E812746BF3146D78B14257C325547E6167” for use “Default,WebServicesInternal,WebServicesExternal” by “DC.schertz.localSchertz-RootCA”.
No changes were made to the Central Management Store.
Creating new log file “C:UsersadministratorAppDataLocalTempRequest-CSCertificate-[2011_12_10][10_18_21].html”.
“Request-CSCertificate” processing has completed successfully.

• Once that step has completed successfully then select Assign this certificate to Lync Server certificate usages to immediately assign and enable the new certificate to the Lync services.

View the new certificate to validate that the Subject Alternative Name field correctly displays the new internal autodiscover FQDN in additional to all of the previous web service and Simple URL FQDNs.

• Complete the Assign Certificate task to finish the process and close the wizard.

> Assign Certificate

Set-CSCertificate -Type Default,WebServicesInternal,WebServicesExternal -Thumbprint E46942E812746BF4136D78B14257C325547E6167 -Verbose -Confirm:$false -Report “C:UsersadministratorAppDataLocalTempSet-CSCertificate-[2011_12_10][10_25_49].html”
Creating new log file “C:UsersadministratorAppDataLocalTempSet-CSCertificate-453d98f9-da39-45ab-b3be-00204d1b2d95.xml”.
Assign the certificate to the Central Management Store.
The following certificate was assigned for the type “Default”:
Default: E46942E812746BF3146D78B14257C325547E6167 lync.schertz.local 12/09/2013 CN=Schertz-RootCA, DC=schertz, DC=local 702419ED00000000001E
The following certificate was assigned for the type “WebServicesInternal”:
WebServicesInternal: E46942E812746BF4136D78B14257C325547E6167 lync.schertz.local 12/09/2013 CN=Schertz-RootCA, DC=schertz, DC=local 702419ED00000000001E
The following certificate was assigned for the type “WebServicesExternal”:
WebServicesExternal: E46942E812746BF4136D78B14257C325547E6167 lync.schertz.local 12/09/2013 CN=Schertz-RootCA, DC=schertz, DC=local 702419ED00000000001E
Creating new log file “C:UsersadministratorAppDataLocalTempSet-CSCertificate-[2011_12_10][10_25_49].html”.
“Set-CSCertificate” processing has completed successfully.

At this point the internal server deployment is completed and it is recommended to issue a server reboot as is general practice anytime a server certificate is replaced.  Repeat the steps in this section for any other Front End servers and then move on to any Director Servers.  The steps are basically the same for Directors except for where specifically called-out.

External Access Configuration

To complete the infrastructure configuration it is important to understand from the official mobility deployment guide that when external access is deployed then all mobile client connections are routed through to the published external Mcx web site.  Even internally connected mobile client will be redirected out the firewall and back into the same reverse proxy rule that external clients are directed to.  This method of ‘hairpinning’ client communications insures that all mobile client web server requests to the Mobility service follow the same path to the same published external web service.  This approach prevents different clients, or sometimes the same client after moving between networks (e.g. WiFi to 3G) from connecting to both the external or internal Mcx web sites.  For proper operation all clients must be directed to either one or the other.  So in a full deployment with external access the internal Mcx web site is never reachable and is not used to handle any client traffic.

HTTP vs. HTTPS

An important concept to cover is that the Lync Autodiscover process has the capability to be initiated over either HTTP (80) or HTTPS (443).  Either approach offers an inherent advantage and disadvantage.  Primarily most deployments will utilize HTTPS as this is more secure and matches the rest of the current Lync published web service configuration, but requires that the certificate on the reverse proxy web listener is updated to include the new lyncdiscover.<sipdomain> FQDN.

Alternatively the initial autodiscover step can be performed over HTTP instead and as soon as the client receives a redirection to the external web service FQDN for connection to the mobility service then the communications will switch to secure HTTPS.  So the advantage here is that no certificate change is required since the client connection to the new autodiscover FQDN is not over HTTPs, but  mostly likely port 80 will need to be opened from the firewall as this was not previously a requirement for Lync.  So depending on change control process and security policies one approach may be easier than the other, or the less-secure HTTP route may not be allowed at all.  (The data that actually is passed in clear text is minor and will be highlighted later in the article).

Reverse Proxy Configuration

Here is another section were the official documentation seems to be over-complicated, as it suggests creating an entirely new Web Publishing rule, yet it uses the same exact settings as the existing rule for that internal Lync Server. Thus the following simplified directions will leverage the current TMG configuration so that only a certificate update and a single parameter change is required to support Lync Autodiscover over HTTPS.

The following steps will cover only the more secure HTTPS approach and are specific to Forefront Threat Management Gateway (TMG) but are nearly identical in ISA Server as well.  The same concepts apply to any other reverse proxy solution which might currently be in use to publish Lync web services.

Current Environment

As stated this environment contains both a Front End pool and a Director.  In this scenario the Lync Autodiscover service is published in the same manner that the SimpleURLs are published.  There are currently two separate web publishing rules, one for the Front end Server and one for the Director.

The Director rule is configured to listen on the (bogus) public IP of 11.22.33.44 and contains both the external web services FQDN and the SimpleURL FQDNs.

   

Configure External DNS

• Create a new public DNS Host (A) record with a Name of lyncdiscover and set the IP address to the external IP address which is already assigned to the Reverse Proxy listener of the published Lync external web services FQDN.

Update Public Certificate

This step can vary greatly depending on which third party certificate authority is used for the existing certificate, so for simplicity’s sake the directions are basically to request a new certificate from the CA which includes a new SAN entry forlyncdiscover.<sipdomain> and then import the new certificate into the reverse proxy server.

Update Reverse Proxy Configuration

Now that the new certificate is imported into the reverse proxy server there are only two simple steps to

• Edit the Director’s web listener (or the Front End Server’s web listener if no there is no Director Server) and assign the new certificate using the Select Certificate button on the Certificates tab.

• Edit the Director’s web publishing rule (or Front End if no Director) and add the new autodiscover FQDN (e.g.lyncdiscover.mslync.net) to the list on the Public Name tab.

• Apply the changes to TMG to complete the configuration.

Supporting Push Notification

The new Push Notification Clearing House (PNCH) solution is used for Windows and iOS mobile clients which do not support traditional application backgrounding like the Android client does.  Federation services between an on-premises Lync deployment and Office 365’s Lync Online are used as the conduit between Lync and the online Push Notification services for Microsoft.

Configuration

The first step is to define a new Hosting Provider relationship between Lync and Lync Online, if one does not already exist.  (Some environments may already have been configured with this to support federated communications with other companies currently using Office 365 Lync Online.)

• Using the Lync Server Management Shell enter the following New-CsHostingProvider cmdlet to create the new identity in the Lync topology.

New-CsHostingProvider –Identity “LyncOnline” –Enabled $true –ProxyFqdn “sipfed.online.lync.com” –VerificationLevel UseSourceVerification

• Even if the previous step was already completed the push.lync.com domain is new and will need to be defined using theNew-CsAllowedDomain cmdlet; the comment parameter is optional.

New-CsAllowedDomain –Identity push.lync.com –Comment “Mobile Push Notifications”

By default the push notification are not enabled after deploying the mobility services so both service types must be manually enabled if either devices are to be supported in the environment.

• Using the Set-CsPushNotificationConfiguration cmdlet enable either one or both of the two services.

Set-CsPushNotificationConfiguration –EnableApplePushNotificationService $true –EnableMicrosoftPushNotificationService $true

It is assumed that federation services are already enabled in the Lync environment, but if for some reason it has not been then the following cmdlet can be used to turn on the capability (which requires a properly deployed and configured Edge Server).

Set-CsAccessEdgeConfiguration -AllowFederatedUsers $true

• To verify that federation is working correctly between the two Lync organizations use the Test-CsFederatedPartnercmdlet with the internal Edge FQDN of the on-premises Lync deployment.  In order for this cmdlet to work properly theLync Server Management Shell must be launched with the Run As Administrator option.

Test-CsFederatedPartner –TargetFqdn edge.schertz.local –Domain push.lync.com –ProxyFqdn sipfed.online.lync.com

Firewall Considerations

The Mobility documentation discusses a requirement to allow traffic over TCP 5223 for push notifications, but depending on the which document, section, or diagram is referenced then it may be a bit difficult to understand exactly what traffic this impacts.

Traffic over TCP 5233 is identified on Apple’s Well Known TCP and UDP Ports document as “XMPP over SSL, Apple Push Notification Service’” and also discussed in the troubleshooting section of this article.

Apple mobile device which are connected to an internal corporate network need to be able to initiate outbound TCP connections through any corporate firewalls to the Apple Push Notification Service (APNS) over port 5223.  The device initiates this connection to the APNS so that it can receive any pending push notifications.  It is common for internal corporate WiFi networks to be configured with more restrictive policies then wired networks and may not allow outbound traffic across all ports.  In these scenarios any network where a mobile device could be internally connected will need to be allowed to send outbound traffic to the Internet over TCP 5223, otherwise push notifications will not work with those iOS devices.

Mobility Policies

Initially all Lync users will be allowed to sign-in to a mobile client as a new global Mobility Policy was created during the installation that is enabled by default.

• To verify the new policy execute the Get-CsMobilityPolicy to view the parameter settings.

PS C:> Get-CsMobilityPolicy

Identity           : Global
Description        :
EnableOutsideVoice : True
EnableMobility     : True

Additionally Site and User level mobility policies can be defined for a more granular level of control of which accounts can use mobile clients and/or Outside Voice features.

Client Connectivity

To verify that an external client can successfully reach the published autodiscover web site and retrieve the redirection information a web browser from an external PC can be used.

• From any web browser go to the autodiscover FQDN over HTTPS and accept the request to download the file.

https://lyncdiscover.mslync.net

• Open the file with Notepad to see the contents of the redirection file.

{“AccessLocation”:”External”,”Root”:{“Links”:[{“href”:”https://lyncdirweb.mslync.net/Autodiscover/AutodiscoverService.svc/root
/domain”,”token”:”Domain”},{“href”:”https://lyncdirweb.mslync.net/Autodiscover/AutodiscoverService.svc/root
/user”,”token”:”User”}]}}

This information is used to redirect the client to the autodiscover web site but using the existing external Web service FQDN for the Lync server itself (e.g. lyncdirweb.mslync.net).  In the event that HTTP is used for Autodiscover this is the only information that is passed across the wire in clear text, as the follow-up connection to the provided URL will utilize HTTPS from then on.

To test an actual mobile client the recently released Android Lync Mobile application was installed on a Samsung Galaxy Tab and using only the Sign-In Address and Password the new autodiscover name was resolved based on the supplied SIP URI’s domain to locate the correct Lync server automatically and sign-in to Lync.

       

Additionally if the SIP URI and User Principal Name are not identical (as is the case in this example environment) then the initial sign-in will fail.  Unlike the Windows Lync client the mobile clients will not automatically prompt for credentials when this fails, it simply says to check the credentials and try again.

For Android clients open the Options menu from the Sign-In screen and populate the User Name field with the proper AD username in either UPN format (e.g. [email protected]) or NetBIOS format (e.g. SCHERTZjeff).  Meanwhile iOS users simply need to tap the More Details button to display the username field.