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…

Here is a quick rundown of how to add the base VM agent to existing Azure VMs:

1. Find all your VMs that currently do not have the agent installed:
   Get-AzureVM  | where { $_.GuestAgentStatus -eq $null }
   or this variation if you only want to get the VMs that are actually running:
   Get-AzureVM  | where { $_.GuestAgentStatus -eq $null -and $_.Status -eq “ReadyRole”}
2. Install the agent bits on the VM
   Azure does not provide a way to inject the agent into an existing VM, AFAIK, but you can use any number of ways to push it out. You can download the agent here http://aka.ms/vmagentwin. I use the following command line to silently install the agent:
   msiexec.exe /package WindowsAzureVmAgent.2.3.1198.670.rd_art_stable.140328-0941.fre.msi /passive
   Pro Tip: Use Azure Files to store the files and scripts you use. That makes them readily accessible to you VMs, with the added benefit of not having to maintain a file server.
3. Update your VMs to reflect that they are now running the agent:
   Get-AzureVM  | where { $_.GuestAgentStatus -eq $null } | ForEach { $_.VM.ProvisionGuestAgent = $true;Update-AzureVM -VM $_.VM -Name $_.Name -ServiceName $_.ServiceName}
4. Check the status of the guest agent for all VMs:
   Get-AzureVM  | select -Property ServiceName,Name,@{Name=”GuestAgentStatus”; Expression={$_.GuestAgentStatus.Status}}
   Every VM with the agent installed should report a value for Ready in the GuestAgentStatus column.
5. We can now add other extension agents; like BGInfo:
   Get-AzureVM | where { $_.ResourceExtensionStatusList.Count -eq 0} | Set-AzureVMBGInfoExtension -ReferenceName BGInfo -Version 1.* | Update-AzureVM
6. Another example would be the Azure Operational Insights extension:
   Get-AzureVM  | where {$_.GuestAgentStatus.Status -eq “Ready” } | Set-AzureVMExtension –ExtensionName MicrosoftMonitoringAgent -PublicConfiguration ‘{“WorkspaceId”:”<OpsInsights Workspace ID”}’ -PrivateConfiguration ‘{“workspaceKey”:”<OpsInsights Primary Access Key>” -Publisher Microsoft.EnterpriseCloud.Monitoring -Version 1.0 | Update-AzureVM
   Find your workspace key and ID in the Azure portal. More info here: https://morgansimonsen.wordpress.com/2015/02/16/how-to-install-the-azure-operational-insights-agent-on-an-azure-vm-using-powershell/

Most of the Azure VM extensions have their own specialized PowerShell cmdlets to configure them, e.g. Set-AzureAccessExtension, Set-AzureVMBGInfoExtension, Set-AzureVMMicrosoftAntimalwareExtension etc. But you can also, to some extent, use the generic Set-AzureVMExtension. The example below show how to use it to install and configure the Operational Insights agent/extension in your Azure VM:

Get-AzureVM -ServiceName <cloud service name> -Name <VM name> | Set-AzureVMExtension –ExtensionName MicrosoftMonitoringAgent -PublicConfiguration ‘{“WorkspaceId”:”<OpsInsights Workspace ID”}’ -PrivateConfiguration ‘{“workspaceKey”:”<OpsInsights Primary Access Key>”}’ -Publisher Microsoft.EnterpriseCloud.Monitoring -Version 1.0 | Update-AzureVM

You can find your OpsInsights workspace ID in your Operational Insights portal.

1. Select Servers and Usage
2. Press Configure
3. Your Workspace ID and access keys are displayed on the right. Use the primary key.

For servers outside Azure you can onboard them directly following these instructions:

Connecting agents directly to Operational Insights

Happy monitoring!