The introduction of Active Directory Authentication Library (ADAL) support in Office 2013 and Office 265 ProPlus is great news. The Office suite of applications is now able to take advantage of advanced authentication options like federated SSO and MFA. Using ADAL with Office is referred to using Office with modern authentication. Modern authentication was recently made available to everyone and all you need to do to start using it is add three registry keys. You can find all the information you need here:

http://blogs.office.com/2015/03/23/office-2013-modern-authentication-public-preview-announced/

I recently ran into a problem with using ADAL in Office, which I think is a bug. When you try to connect to a new mailbox in Outlook using Autodiscover, and who doesn’t, Outlook is unable to successfully connect to the mailbox. From my testing, this problem is present in version 15.0.4693.1002 of Office 2013/365 ProPlus (a.k.a. March 2015 Update), which is the first version to include ADAL support.

You can look at the change log for Office here: https://support2.microsoft.com/gp/office-2013-365-update

Check your Office version by going to FileAccount and looking at Product Information:

The problem manifests itself when using the Account Setup Wizard.You enter your name, email address and password. Outlook queries Autodiscover DNS records for your domain. When your settings have been discovered you are asked to authenticate against the service. This authentication does not used ADAL in my experience, but displays an old fashioned authentication prompt. However, because of the bug, you will never get this far. Instead the wizard will inform you that it cannot find your settings.

To fix this, simply update to the latest version of Office. The most recent update, at the time of this writing, is version 15.0.4711.1003 (a.k.a. April 2015 update).

None of the fixes in this update specifically addresses this problem, as described in this post, but there is some mention about not being able to add a new account if your are using ADAL in Office and the account uses basic authentication in this KB article:

https://support.microsoft.com/en-us/kb/2965218

• When you enter incorrect credentials for an account that makes some mailbox connections use Active Directory Authentication Library (ADAL) authentication and some connections use basic authentication, you are not prompted to enter credentials again, and Outlook cannot connect to mailboxes by using basic authentication.
• When you enable the Active Directory Authentication Library (ADAL)-based authentication for Outlook 2013, you may be unable to add Office 365 accounts that use basic authentication. If you have enabled the ADAL-based authentication for Outlook 2013 that has an Office 365 account configured and the account uses basic authentication, you cannot connect to the account.

Anyway; updating resolves the problem.

make sure you DO NOT enable Direct Server Return on your endpoint Load Balanced Set:

In November of 2014 support was added for Source IP Affinity (also known as session affinity or client IP affinity) in the Azure Load Balancer. Before that it was not compatible with Remote Desktop Gateway. You could sort of load balance your RDGWs but it required you to put every RDGW server in its own cloud service and the use Azure Traffic Manager to load balance. With this approach you could not put your RDGW servers in the same availability set, so you had no guarantee that your gateways would be distributed across fault and update domains. Boldly, or foolishly, depending on your point of view, I decided to try anyway to use the Azure Load Balancer for RDGW, even though I knew it was not supported. Of course it did not work, but when eventually support was added I ran into problems.

After client IP affinity support was added to the load balancer I reconfigured my endpoints of my RDGW VMs:

Set-AzureLoadBalancedEndpoint –ServiceName <cloud service name> -LBSetName “RDGW HTTPS” -Protocol tcp –LocalPort 443 -ProbeProtocolTCP -ProbePort 443 -LoadBalancerDistribution “sourceIP”

Set-AzureLoadBalancedEndpoint –ServiceName <cloud service name> -LBSetName “RDGW UDP” -Protocol UDP -LocalPort 3391 –ProbeProtocolTCP -ProbePort 443 -LoadBalancerDistribution “sourceIP”

The sourceIP value in the LoadBalancerDistribution parameter is the critical one and it can only be set through PowerShell.

But still no connections… I tried all sorts of things. Since this had never worked I didn’t know if it was failing because of a misconfiguration or something in the Load Balancer. The only difference in setup I could find was that  my load balanced endpoints had Direct Server Return enabled. This was something I had decided to try back when I first set it up. There was not much documentation back then about what Direct Server Return actually did. But now there is a description in the portal:

DIRECT SERVER RETURN

Direct server return configures a virtual machine’s endpoint for the floating IP capability required to configure a SQL AlwaysOn Availability Group. This setting is required when using the SQL Always On Availability Groups in SQL Server. This setting can’t be changed after you create the endpoint.

So, not for RDGW at all…

Unfortunately you cannot disable DSR without deleting and recreating your endpoints. After removing and adding them again I was able to connect through the load balancer.

Since traffic to a particular instance behind the load balancer now is determined by the source IP, all traffic from the same IP goes to the same instance, you might experience an uneven distribution of load. Clients behind a proxy or NAT router will all end up on the same instance.

More information:

• Azure Load Balancer new distribution mode
• Microsoft Azure Desktop Hosting: RD Gateway Farm Deployment Guidance Updated To Support Azure Load Balancer Client IP Affinity
• Set-AzureLoadBalancedEndpoint cmdlet
• Microsoft Azure Desktop Hosting Reference Architecture Guide

BTW I wish the Remote Desktop PG would stop putting all their guides in Word docs, would be so much better on a web page…