Server returned an error: 5.7.3 Authentication unsuccessful eurprd04.prod.outlook.com code: 535

G Suite/Gmail gives an error when trying to authenticate your Office 365 email account.

Email used to be relatively simple in days of yore - configure POP3 or IMAP settings in pretty much any email client and you were good to go.

Things are a bit more complicated for many of us these days - there SPF and DKIM and DMARC to think about, two-factor authentication, encryption, SSL and TLS, different port numbers to configure etc.

Those of us who manage several domains and tenancies in Office 365 and G Suite and who have various email accounts bouncing around through forwards and collections from different email client can end up with a complex set of configurations that needs careful management not to fall apart!

Today's issue will be a relatively common scenario for many users.

Server returned an error: "334 VXNlcm5hbWU6 334 UGFzc3dvcmQ6 535 5.7.3 Authentication unsuccessful [AM6PR0402CA0015.eurprd04.prod.outlook.com] , code: 535"

The scenario is simply this: a G Suite Gmail account is configured to collect email and 'send as' from an Office 365 email account.

This was a working configuration and the password hasn't been changed recently. Logging on to Outlook online works ok.

First stop will be to check service health on the admin portal of the 365 account.

There is an Exchange Online advisory showing, but this appears to relate to accessing archive mailboxes rather than the email transport service or the Exchange Server as a whole. Since the online Outlook account tests ok sending and receiving, it looks like the 365 email service is working ok.

Next place to look will be Azure AD. I know some of the team had been testing some Multi Factor Authentication (MFA) configurations with Office 365 and Azure AD, so this is the most likely source of the problem.

To check if this was the source of the problem, we simply turned off MFA for the affected user. Since this change was being made online, the best thing now is to have a cuppa while you wait for it to take effect.

Ten minutes later, we checked the email configuration in G Suite and it validated ok. Problem solved.

Of course, you should be using two-factor authentication, but Microsoft does not recommend doing this for admin accounts (because of the difficulty of using MFA with PowerShell).

When using browser-based logons, two-factor authentication works well, but it becomes a bit trickier when using desktop applications like Outlook and Skype, where additional application passwords have to be generated.

It likely won't be long before biometric logons and other technologies replace our outdated and insecure passwords, but unfortunately, in the meantime, we'll have to live with them.

Windows 10 - Blue Screens haven't gone away...

It's been a while since we've seen the dreaded Windows 10 Blue Screen, but sadly these haven't gone away.

Often Windows blue screens would be associated with hardware changes or driver updates. This one happened a couple times this morning on a previously stable machine that hasn't had any hardware changes in some time, so we're presuming this one will down to a Windows update.

This is a Hewlett Packard machine running Windows 10 Pro 64-bit - it's a couple of years old with a reasonable spec (Intel Core i5 with 12GB RAM) and has been problem-free so far.

We're on first release for Office 365 updates and the semi-annual release for Windows 10. The HP Support Assistant runs in the background and is configured to install updates automatically.

So far this combination has worked pretty flawlessly.

Other than the odd reboot when Chrome or Edge exhausts memory with too many tabs open this machine hasn't had much in the way of problems.

Those who have worked around PCs for a while will know that current hardware and Windows 10 (in spite of well-publicised recent issues with updates) is much more reliable than even a few years ago.

So much so, in fact, that getting a Blue Screen of Death (BSOD) is something of a novelty these days.

That's not to say that it's not a real pain, but at least we get a bit more of an error message these days... Some of us can still remember having to use a flip camera to video the flash screen with an error on a machine with a terminal BSOD loop then freezing the frame to get the HEX error code to look up!

It would be difficult to get definitive stats on this, but my impression is certainly that much less time is devoted to poking around the registry, updating drivers and especially installing and configuring printers.

There are, of course, still plenty of user issues, security problems and malware/trojan/ransomware issues to deal with, but broken hardware and broken Windows is much less frequent than it used to be.