WinPE Net Use Errors 53 & 1231

Hardware Hub Networking
1

At work I built a Linux based Windows deployment server. It runs on a PROXMOX hypervisor using Ubuntu LXC Containers.

  • isc-dhcp-server handles DHCP
  • tftp-hpa handles TFTP
  • apache handles HTTP
  • SAMBA handles SMB (only has one account)

This uses iPXE and I setup each service in it’s own LXC (no real reason).

I configured four 10Gig ports, two pairs bonded in fail-over then assigned the bonded interfaces to a Linux Bridge assigning this to each LXC container.

Each pair of fail-over NICs go to a pair of CISCO Meraki MS225’s. If one NIC fails it should fail-over to the other for both switches. (I disabled RSTP on the switch ports. Wondering if that could be the problem) This PROXMOX network configuration let’s me have 10Gig redundant to both switches while maintaining one network subnet.

I have a lightly modified version of WinPE where a very rudimentary script runs when WinPE finishes loading:

@echo off
wpeinit

echo Connecting to SMB Server.
:CONNECTING
net use n: \\10.0.0.4\windows password /user:\username
if %errorlevel% equ 0 (goto :IMAGE) else (goto :CONNECTING)

:IMAGE
n:\image.bat

This operation is performed 20+ times simultaneously 20~25 times a day.

What’s strange is the times when errors 53 and 1231 will appear. If it isn’t abundantly clear there’s a physical network disconnection 15 to 20 clients at a time will loop error 53 or 1231 for several minutes before connecting and DISM starts deployment. Meanwhile I have no problems during iPXE netboot into WinPE.

For some reason WinPE is having DHCP or SMB connection issues that only solve themselves after several minutes of waiting. I’m wondering if there’s a clear underlying cause.

Could it be because I only have a /24 subnet and I’m running out of IP’s? isc-dhcp-server not releasing the old ones?

Could it be a limited number of connections put in place by SAMBA? There’s only one account they all use so the server sees the same user connecting from 20+ different IP’s all at once again and again. Is it a artificial SAMBA limitation?

All input is appreciated. If I missed important details just ask.

2

I may have found a solution to my own problem but it may also only look like a solution.

Because my script has no delay it’s querying the server as fast as it can.
Now multiply this by 30+ computers and it’s possible I’m DDoS-ing the imaging server.

So, I stole timeout.exe from C:\Windows\System32\ on a Windows PC and dropped it inside WinPE’s boot.wim file. From here I was able to re-write the script to include a 5 second delay. Commited the changes to boot.wim. Dropped it back in WinPE’s sources folder and moved everything to an .ISO file I can boot from using a USB stick.

As it turns out it takes WinPE approx 6~8 seconds to acquire an IP from DHCP. By stopping the barrage of requests to connect to the SMB service when the client hasn’t even recieved an IP yet I’ve seen a noticeable improvement in the process.

For PC’s where Ethernet ports or USB-C ports aren’t connecting Ethernet properly that’s unavoidable and requires me to physically address them but that’s a whole different issue.

1 Like
3

I remember having this problem years ago when I was doing imaging for a previous company. I can’t remember how I fixed it but doing some searches, I feel like it was this though:

wpeutil WaitForNetwork

I think wpeutil should be in the boot.wim, but I’m not sure, you call this command before you attempt to connect to the network shares.

4

Wpeutil most definitely is. I use it to perform wpeutil shutdown and wpeutil reboot. I did not know it supported a WaitForNetwork argument. I can test this small scale and if it works just as well or better I can substitute timeout.exe since as you describe it will create that delay with the express intention of getting an IP.