Diagnosing Outlook 2016 sign-in failures against Microsoft 365 on a legacy RDS host

The challenge

On a Windows Server 2012 R2 Remote Desktop Services host running Outlook 2016, new Outlook profiles could no longer be created against Microsoft 365, and an existing account couldn't re-authenticate after a password change. Existing profiles on the same server kept working, and the very same mailboxes connected fine from Windows 11 and from the browser. The result: onboarding new staff and recovering any account after a password reset was blocked, while the modern-auth sign-in window rendered blank and connections stalled at 'Authn: Error'.

What we did

We diagnosed by elimination, recording what each step ruled in or out. We cleared cached credentials and forced the embedded sign-in control into IE11 mode to fix the blank window, applied the WinHTTP and .NET TLS 1.2 keys, and set Autodiscover-exclusion keys to force the cloud endpoint — which narrowed the failure precisely to the modern-auth token stage rather than transport or certificates. The decisive test was reproducing the exact failure on our own Computer Mechanics Microsoft 365 tenant from the same server, which proved the client's tenant and Conditional Access were not at fault.

The outcome

The Entra sign-in logs gave the definitive answer: MFA succeeded, no Conditional Access policy was blocking, and the sign-in was interrupted by a device-authentication step the legacy client simply cannot satisfy. Outlook 2016 on Server 2012 R2 uses a deprecated embedded-IE/ADAL sign-in with no WAM broker and no Entra device registration, and both products are past end of support — so there is no tenant-side fix to apply. We restored mail access immediately via Outlook on the web, then scoped the permanent fix: migrate the RDS host to Windows Server 2022/2025 with Microsoft 365 Apps, where WAM and device registration handle that step natively, exactly as they already do on Windows 11.

Services involved