Cumulative Update/s Break Windows Deployment Services

[thatley]

In case any of you come across this - this may save you some time.

 

Issue:

 

When building machines from WDS you get this error at the point the Boot.wim tries to load - "Windows failed to start. A recent hardware or software change might be the cause........" If you click past this screen you'll see the boot image and if you choose it, it loops back to this point every time.

 

This affects Server 2016 and Server 2012 (possibly 2008 R2 but I've not confirmed this yet.)

 

The problem is a cumulative update/s from Microsoft this week:

 

• KB4489882 for Server 2016 (tested removal on a number of servers and it fixes the issue)

• KB4489881 and KB4489883 for Server 2012

 

The 2008 R2 updates are:

 

• KB4489878

• KB4489885

 

The problem is one of the updates patches a security hole in TFTP, but unfortunately breaks WDS. Hopefully MS will fix this asap!

 

Advice is to decline the update/s in WSUS and then uninstall the relevant update/s. You will have to reboot after removal so bear this in mind.

 

Hope this helps anyone seeing this issue.

Edited March 15, 2019 by thatley

[thatley]

UPDATE:

 

Microsoft have now acknowledged this in their online update support pages. Message below:

 

"After installing this update, there may be issues using the Preboot Execution Environment (PXE) to start a device from a Windows Deployment Services (WDS) server configured to use Variable Window Extension. This may cause the connection to the WDS server to terminate prematurely while downloading the image. This issue does not affect clients or devices that are not using Variable Window Extension."

 

The fix is much easier than removing the updates:

“Use the Windows Deployment Services UI.

1. Open Windows Deployment Services from Windows Administrative Tools.

2. Expand Servers and right-click the server name.

3. Open its properties and clear the Enable Variable Window Extension box on the TFTP tab.

4. Restart the WDS Service.

5. If that doesn’t work, you may need to restart the server.

 

Microsoft is working on a resolution and will provide an update in an upcoming release."

 

Good luck!

Edited March 18, 2019 by thatley

[mbedford]

I experienced this problem this morning on WDS Server 2012. Can confirm the workaround provided allows the process to continue.

[thatley]

For information:

 

This "workaround" (sorry, I said "fix" in my previous post), does slow down the loading of the boot.wim file. I've only tested this on a single machine, so not sure how slow it will be when building a large number of machines.

[mbedford]

Yeah, I noticed a slow down in the transfer probably another 50% after the workaround.

 

In general, we routinely WDS 40+ machines at once and do notice a slight slow down with that volume but nothing that causes us to change what we are doing. I think the .WIM file takes about 10 - 15 seconds to transfer normally, add perhaps 10 more seconds when under load. So in the grand scheme of things, its barely noticeable. Compared to my previous solution of sticking a CD in the machines or at best, using Ghost on 3 or 4 at once, It will take a huge slowdown to make me worry :-)

Edited March 19, 2019 by mbedford

[thatley]

Yeah, I noticed a slow down in the transfer probably another 50% after the workaround.

 

In general, we routinely WDS 40+ machines at once and do notice a slight slow down with that volume but nothing that causes us to change what we are doing. I think the .WIM file takes about 10 - 15 seconds to transfer normally, add perhaps 10 more seconds when under load. So in the grand scheme of things, its barely noticeable. Compared to my previous solution of sticking a CD in the machines or at best, using Ghost on 3 or 4 at once, It will take a huge slowdown to make me worry :-)

 

 

Yes I always notice that after about 10 machines have started to build, then boot.wim slows right down anyway. And you are right, the old days of DVD's/Ghost etc are well and truly behind us

[gshaw]

This is why I'm such a big fan of this forum, thanks @thatley for posting this

 

Just had the same error appear on my WDS \ MDT after updating it to 8456 release \ 1809 ADK. Just remembered in the back of my mind this thread and looks like the workaround fixes it for me too. Saved chasing my tail blaming the MDT update for something caused by an OS patch!

Edited March 28, 2019 by gshaw

[thatley]

No worries GShaw, glad this post helped.

 

I too have had many issues fixed due to this forum - it's invaluable!

[MYK-IT]

Just to add, that this affects WDS on Server 2019 too.

[FragglePete]

This explains the issue I had getting stuff ready for Summer. Ended up building a new WDS/MDT VM with 2019 which then stopped working after a few of the updates (wanted to clear things out a bit anyways).

 

Check box cleared and things are working again, albeit a tad slower on the first boot.wim file being pulled from the server.

 

Pete