Outlook not starting and unable to configure new accounts (Office 365)

TL;DR: If Outlook refuses to open and you cannot set up new accounts, check your Internet Explorer policies and make sure TLS 1.2 is not inadvertently being turned off.

I ran into a problem where Outlook (Office 365) would not start anymore on a Windows Server 2016 RDS. Users would receive the following error message:

If I tried to configure a new account, Outlook would attempt to retrieve account info for a while, and then claim that “something went wrong”. The login prompt would sometimes enter a loop, repeatedly requesting credentials.

Azure AD was logging the following error message, which also appeared in the Azure Active Directory Event Log on the RDS server:

You are using TLS version 1.0, 1.1 and/or 3DES cipher which are deprecated to improve the security posture of Azure AD. Your TenantID is: {tenantId}. Please refer to https://go.microsoft.com/fwlink/?linkid=2161187 and conduct needed actions to remediate the issue. For further questions, please contact your administrator.

I double-checked all of the settings mentioned in the Microsoft article, but TLS 1.2 was already enabled on this server (as it should be by default on Server 2016).

Strangely, Outlook would work fine while logged on as the domain administrator, even with mailboxes that were previously failing when the user was logged on onto their own account. This made me think it might be related to policies somehow, as the domain administrator is excluded from most of them. However, all of the security protocol settings are machine-wide, not per user, so that left me quite puzzled for a while.

After some more searching, I tried different options in the Outlook account setup dialog to see if I could get anything else out of it. When I chose the option to create a new account, yet another dialog came up, showing error 0x80190001. This is HTTP_E_STATUS_UNEXPECTED, or “Unexpected HTTP status code.” (you can use the handy site errorco.de to quickly look up these error codes). Since the login dialog uses Internet Explorer to render the login page, I tried launching IE the normal way and was immediately hit with a certificate validation error.

I checked the IE security settings and indeed TLS 1.2 was turned off there! After turning it on, Outlook immediately started to work:

Finally, I tracked down the policy that was responsible for incorrectly setting the IE preferences. It seems likely that this policy was created before the TLS 1.2 checkbox existed, causing the setting to default to off when the environment was migrated to Server 2016. Although this issue had not caused any problems in the past, Microsoft’s recent security updates to Office 365 now require TLS 1.2, making it necessary to update the policy. Once I made this change, everything worked smoothly again.