I recently updated an old Win2008R2-based domain to a new Win2019-based one (with the common promote / demote / decommission dance). This was for a very small office (3 peoples), so this is a single-DC setup where both the old and the new DCs doubled down as fileserver.
For this reason, I created a DNS alias to point the old name (ie: olddc.example.com
) to the new one (ie: newdc.example.com
). So far, so good: all client could reach the new DC/fileserver both with the old and the new names. However, I forget to formally add to the new DC the old DC's name (as an alias). In other words, I did not issue something similar to:
netdom computername newdc.example.com /add:olddc.example.com
Today I was on the new DC and, out of muscle memory, I tried to reach its own shares via the old names (opening Explorer and writing \\olddc.example.com
). Explorer immediately complained about "wrong credendials" and, indeed, a Wireshark dump shown STATUS_LOGON_FAILURE
. I issued the netdom
command above (adding olddc.example.com
as an alias) and the problem went away: the server is now able to see its own shares via the old name.
I know and understand why the alternate/alias name should be added via netdom
(or through a separate setspn
command). However, what surprises me is that all the Win10 clients shown no complains at all even when such alternate name was not provided.
So, why do the Win10 clients worked with not issues at all while the server immediately walked back from accessing its own shares with a "unknown" DNS alias? Is it due to some different settings between Server and Client OSes? Or is it related to accessing a loopback share?