Issues/Problems with Release 17733

[Bill Reichert]

First, thanks for fixing the Windows Deployment Server problem.  Now for the still remaining problems.

1.  As with previous 2019 releases, with IPv4 disabled, and only using IPv6, when trying to reach other Windows machines by single name, LLMNR fails - it worked fine with Server 2019.

2.  Docker images such as the Web Server that we used with Server 2016, will not work with Server 2019 with message that Server version is incorrect. - it seems that there are only special Docker images for Server 2019, but we can't find one that works.

3.  When trying to restore an image with DISM, a message comes up that the Data is incorrect/corrupted and the restore halts.  This happened even though the creation of the image work perfectly with DISM.  The "Check Integrity" switch makes no difference.  (Note with version 17733 we have some more testing to do with this 3rd problem however).

[#2]

Thanks for the feedback, Bill! Please provide more context on #3 when you have it. We are not sure what your scenario is here that you are attempting.

[#3]

We have created an image from a fresh install saving to an external hard drive, cleaned and reformatted the original drive,  and are trying to apply the image using the command:

dism  /apply-image  /imagefile:F:\Images\fresh.wim  /index:1  /applydir:C:\   /checkintegrity

Upon running the command we get:

Error: 13 

Data Invalid

We have tried this several times with multiple builds of 2019. 

[#4]

Hello Bill,

  Thanks for reporting this. Could you please share additional steps \ command lines on how you captured the image?

  Could you also please share the dism log from c:\windows\logs\dism folder?

[#5]

I am sending you a copy of the lab project which gives ALL the steps we use.  Note again, everything works fine with Server 2016.  Note the lab project name is "Image X" but as you will see, we use DISM.

[#6]

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.

[#7]

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??????

[#8]

Bill, what build are you trying this with? 17733 or something newer?

[#9]

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

[#10]

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!!!!

[#11]

I don't think this is necessarily new. This one may be helpful in that regard.

https://serverfault.com/questions/74067/windows-appending-domain-suffix-to-all-lookups

[#12]

Well, the "Period" fix did not work after all for LLMNR not working with IPv6.  When doing the lab project in class it did not work for the students.  However, installing the January 18, 2018 cumulative update for Server 2019 seems to definitely have fixed the problem.  We ill be doing some further testing, however - I'm not believing anything until we try it on some 20 to 30 machines!!!!  That description of the update mentioned a fix for IPv4/IPv6 - not this problem however - but whatever they fixed seemed to take care of LLMNR working with only IPv6 enabled.