I am sure this is not the only bug in Windows 2016, but one you might stumble upon especially in mixed Windows version environments with roaming profiles. However I am not sure whether or not it is a bug or a "by design" decision made - but not well enough documented.
According to TechNet: Deploy Roaming User Profiles separating profiles for each version of Windows can be done via GPO by adding HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ProfSvc\Parameters\UseProfilePathExtensionVersion with 1.
As the article states, this is working for Windows 10, 2012, 2012R2, 8.x and 7, 2008, 2008R2 and Vista... on might - as I did - expect that due to its code-share Windows 10 == Windows 2016 in its behavior and Microsoft just 'forgot' to add Windows 2016 to the recently updated document; more about this in a moment.
We installed Windows 2016 in a production ready domain with Windows 2012 R2 domain functional level and deployed a Windows 2016 functional level domain as well. Lazy admins do lazy things, I am (in an Admin role) often lazy which is why I shouldn't 'play' the Admin... but more important for this bug, I did create a GPO rule and did attach it to the root of the domain. It works like a charm for all Windows 8.x / 10 / 2012R2 clients but with Windows 2016 the result is strange. Which user ever using a roaming profile and wants to login locally, can't do that.
There is NO helpful error message in the event log, the only message that explains why you are logged in with a temporary profile is that there wasn't enough disk space ... which in our case wasn't true at all.
After trying around a bit, I found that disabling the GPO creating the Roaming Profile Version did do the trick. This is domain functional level independent!
In our case, the work around to this is quite easy since we already organize servers, workstation and mobile devices in different organizational units, servers are even 'classified' - so much for the lazy admin. For now we placed the GPO just in the organization unit(s) for workstations and mobile devices and not on a global domain level neither on server organizational units in which Windows 2016 servers (will) appear.
However, it is unclear for me whether this is a 'by design' issue or a bug... I'll update this note as soon as I have more information.
IntroductionYou might come across the above issue when you setup a new system that should use your Exchange server as mail-relay. You may wonder how this (the error) could happen, invest several hours in research and funny or not, you'll find only Office 365 'solutions' - and some programming related.
All in all - you might not find a solution that is the one for you.
A potential solution...... might be as simple and stupid - and make you maybe banging your head against the wall, as I considered afterwards - just to cross-check whether the FROM-Email is the same Email-address - or in the pool of Email addresses, which have been configured for the account you are using to send your Emails.
At least if all your attempt to solve the issue failed, it might be right the moment to double check what you - and I - should have checked first ;-)