Forum Discussion
Issues/Problems with Release 17733
Update on Docker and DISM - they work now.
On my original problems - #2 and #3, we have solved the issues.
Item #2 Docker failing was due to our not using the newest version of the Docker Engine and Client. Once we downloaded these, we were able to get a Server Core Docker image to run correctly in Server 2019. Also to note - the need for a separate Web Server image for Docker which we had used with Server 2016 isn't necessary - Web Services installed fine with the appropriate Powershell command (as my lab tech figured out) in Server Core, resulting in a working Web Server.
Item #3 The reason DISM wasn't working was that , as above, we were using an older version of DISM from Windows 10, which did work with Server 2016, but not with Server 2019. Once using the version directly from Server 2019, DISM worked fine.
We still have Problem #1 - With Server 2019, Link Local Multicast Name Resolution (LLMNR) does not work with IPv6 when IPv4 is disabled, in other words, single name resolution fails. It worked correctly with Server 2016. We noticed however, that the Computer Browser Service seems to have been eliminated with Server 2016. This should have no effect on the problem however, since it was used for Broadcast Based NetBIOS names with IPv4 only, however I am still very surprised that it has been removed as it provided backward compatibility for older versions of Windows such as XP, etc.
Computer Browser Service showed up once SMB 1.0 was enabled, so that problem is now solved!!!!!!!
However, we STILL have the LLMNR problem with IPv6. Single names flat out don't work with UNC paths, etc. if IPv4 is either disabled or the two computers are on different IPv4 networks forcing IPv6 to be used. Single names worked fine with Server 2016 using IPv6 only!!!!! If this is the intended result, is there some registry setting or something that we can do to bring back this resolution??????
- Brentfor
Microsoft
Bill, what build are you trying this with? 17733 or something newer?
Thanks for reading my information!!! I do appreciate it!!! we have upgraded to 17744 and the problem still persists. LLMNR will not resolve single names with IPv6 - again it works fine with Server 2016. Our scenario is that we put the machines on a private IPv4 network, while we still have other machines on our Public IPv4 network. In trying to reach the machines on the Public network IPv4 network from the ones on the Private Ipv4 network with single names using UNC paths (forcing the use of IPv6) it works fine with Server 2016 - does not resolve with Server 2019 .
Again I appreciate your reading my information in this blog!!!
Bill Reichert
Well, the last issue I was having with Server 2019 seems to have been solved or at least I have a work-around. That issue was that with Server 2019 having it's
IPv4 address on a Private network, and trying to reach our other Servers/Workstations, etc. on a Public IPv4 network, I could not use the single name of the server (LLMNR resolving to an IPv6 FE80 address) - it would not resolve as it always had with Server 2012 and Server 2016.) I want to emphasize that the Server 2019 has NO DNS Suffix configured!!!!!. To make the resolution work, I had to add the period after the single name, and it then resolved with the single name. Normally in the past the period only had to be used with the machine had a DNS suffix configured that was not resolvable by the DNS Server it was pointed to and we wanted to revert to only signal name lookup. What lead me to this "fix" was another person noting that when he pinged addresses by name the ".local" suffix was being added automatically (at times, not always) to the name, even when he had no suffix configured!!!!! At any rate, now my students can still do the lab projects by just adding the "period" after the LLMNR name!!!!
