Nov 06 2018 06:19 AM - edited Nov 06 2018 06:53 AM
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-18...
Nov 12 2018 09:33 AM
How did you obtain this build? At the time you posted your feedback, this build had not been made available publicly.
Nov 12 2018 11:53 AM
This is likely coming from mDNS. Do you have an mDNS responder installed ( like Apple's Bonjour?)
Nov 12 2018 01:03 PM
Nov 13 2018 10:18 AM - edited Nov 13 2018 10:24 AM
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.
Nov 13 2018 10:33 AM
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?
Nov 14 2018 03:55 PM - edited Nov 14 2018 04:07 PM
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"
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-trial
And test it again, fresh clean install and report back.
Nov 15 2018 06:48 AM - edited Nov 15 2018 06:51 AM
This ".local" bug might also be a related problem for this:
https://support.microsoft.com/en-gb/help/4471218/mapped-network-drives-don-t-work-in-windows-10-vers...
Jan 08 2019 12:56 PM - edited Jan 08 2019 12:56 PM
.local bug still present in 17763.253, Windows 10 Pro 17763.253 does the same.
While pinging or trace routing a windows name in local network, ipv6 always returns .local
Example:
Pinging SEA.local [fe80::49ab:74ed:a10:32f7%3] with 32 bytes of data:
Reply from fe80::49ab:74ed:a10:32f7%3: time<1ms
If IPV6 is turned off and only IPV4 is used it always displays normal name "SEA" Example:
Pinging SEA [192.168.0.4] with 32 bytes of data:
Reply from 192.168.0.4: bytes=32 time<1ms TTL=128
.local name only appears if ipv6 is in use, because of this bug some network shares might not work correctly as SMB uses local ipv6 addresses to resolve Windows name.
*This does not happen in Windows Server 2016 (all latest updates). Windows Server 2016 always displays correct name via ipv6 local name in my example:
Pinging SEA [fe80::49ab:74ed:a10:32f7%3] with 32 bytes of data:
Reply from fe80::49ab:74ed:a10:32f7%3: time<1ms