Forum Discussion
Windows Server 2019 - 1809 - Build 17763.107 - LAN names return .local
In Windows Server 2019 - 1809 - Build 17763.107 when user pings or tracert ( trace routes ) a LAN name, name has 50% chance to return .local at the end.
Example:
How to reproduce:
1. Install Windows Server 2019 on PC1 and name it PC1 in "computer name with default workgroup"
2. Install Windows Server 2019 on PC2 and name it PC2 in "computer name with default workgroup"
3. Connect 2 PC's via ethernet switch / or via virtual network / VirtualBox
4. Ping PC2 from PC1 or tracert PC2 from PC1
5. PC2 will have 50% chance to report as PC2.local ( .local at the end of the name )
6. If you ping or tracert PC2 from Windows Server 2016 ( version 1607 ) it will always return as PC2 (no .local at the end)
7. This only happens if both PCs run version 1809 of Windows Server 2019 or Windows 10
8. Because of .local in the end some programs don't work correctly and report that PC2.local does not exist but PC2 does
9. SMB shares sometimes also don't work correctly because of this 50% bug
This happens out of the box with default installation of windows server 2019 / windows 10.
Version 1607 does not have this problem.
I already reported Windows 10 1809 problem here:
https://techcommunity.microsoft.com/t5/Windows-10/local-LAN-name-problems-a-new-bug-in-Windows-10-1809-17763-55/m-p/282728#M1884
8 Replies
This is insiders build.
Only out of the box windows server was installed, nothing was added, drivers are out of the box, basically full clean install of windows.
Do you have an mDNS responder installed ( like Apple's Bonjour?)No, nothing was installed, only windows.
Nothing is in drivers/etc.
Two computers are connected with a layer 2 switch.
Only 2 computers exist in this network, nothing was changed or added, clean windows install only.
Same happens with build 17763.55 (public).
I will try again today with public .107 release, also original .107 public ISO files and report back.
17763 in any form was never made available to Server Insiders. The last build that was offered to Insiders was Build 17744. 17763.1 was live very briefly on some external channels on 10/2 but almost immediately removed from all external channels. 17763.107 was not made available externally until today, 11/13. How did you obtain the .107 build in time to provide feedback on 11/6?
Before MS took down all the links, Windows Server 2019 evaluation was available for download, this was 17763.1 "trial", same as full version but trial version.
17763.107 was available for Windows 10 insiders as "windows10.0-kb4464455-x64.cab"
http://download.windowsupdate.com/c/msdownload/update/software/updt/2018/11/windows10.0-kb4464455-x64_de985f6d38215b316470dbecabb453c762a217af.cab
Anyone can use DISM in powershell to install and upgrade 17763.1 (ws2019 trial) to .107, this also applies to windows server as both windows 10 and server share almost the same code.
So Windows server 2019 17763.1 (trial) + kb4464455 = 17763.107 (trial)
If you do this you get Windows Server 2019 17763.107, which is for "insiders" to test things out.
So this was the method i used to test new patches.
I will again download the new updated trial version when links show up:
https://www.microsoft.com/en-us/cloud-platform/windows-server-trialAnd test it again, fresh clean install and report back.
Dusty HarperMicrosoft
This is likely coming from mDNS. Do you have an mDNS responder installed ( like Apple's Bonjour?)
- Dusty HarperSince WinXP Name Resolution occurs in the following order
1) Is the name referring to the localhost? [Local Cache lookup]
2) Is the name in %WinIdr%\System32\Drivers\etc\Hosts? [Hosts lookup]
3) Is the name in the local DNS cache? [DNS cache]
4) Can a DNS server resolve the name? [DNS Query]All of these are configurable via the Services\TCPIP\ServiceProvider regkeyAfter this it gets a bit more convoluted and you need to see how your device is configured
Perform Ipconfig /all and at the top look for Node TypeYou are most likely using H(ybrid) Node Name Resolution
5) Is the name in the NetBIOS cache? [NetBIOS cache]
6) try P(eer)-Node Resolution
a) Can a WINS server (if configured) resolve the name? [WINS Query]
b) Is there an answer to the name using mDNS (multicast DNS)?
c) Is there an answer to the name using LLMNR (Link Local Multicast name Resolution)?
7) Try B(roadcast)-Node Resolution
a) Is there an answer to the name using NetBIOS broadcast?This behavior is configurable via the Services\NetBT\Parameters\NodeType & Services\NetBT\Parameters\DHCPNodeTypeWhat I suspect is happening is that you are using a short name (no DNS suffix specified, and the DNS query is taking too long to return, so other methosds are tried, and either mDNS or LLMNR is able to answer (hence the .local suffix)Something you should check is in your TCPIP properties, what DNS suffix are you appending to your short names? (you can find this using Ipconfig /all)
How did you obtain this build? At the time you posted your feedback, this build had not been made available publicly.
