Using `Edit-OSDCloudWinPE -StartURL` breaks installation if the network is slow

[n4kama]

The startnet script starts immediately after the WinPE boot, without waiting for proper IP configuration.

On slow networks like mine, and when using Edit-OSDCloudWinPE -StartURL to build the ISO, the script just stops because it still has the self-configured IP address in the 169.254.x.x range and cannot reach the remote script.

The script stops because of line 26 of Invoke-WebPSScript.ps1 :

function Invoke-WebPSScript
{
    [CmdletBinding()]
    param
    (
        [Parameter(Mandatory, ValueFromPipeline)]
        [Alias('WebPSScript')]
        [System.Uri]
        # The URL of the PowerShell Script to execute.  Redirects are not allowed
        $Uri
    )

    $Uri = $Uri -replace '%20',' '
    Write-Verbose $Uri -Verbose

    if (-NOT (Test-WebConnection $Uri))
    {
        Return
    }
    #[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
    [Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls1
    $WebClient = New-Object System.Net.WebClient
    $WebPSCommand = $WebClient.DownloadString("$Uri")
    Invoke-Expression -Command $WebPSCommand
    $WebClient.Dispose()
}

It just returns when the connection to the URL failed which is understandable except when the fault lies with ourselves.

---

I believe that either:

• The Test-WebConnection should call a new function that ensures the workstation has a valid IP (i.e., not starting with 169.254).
• The function Initialize-OSDCloudStartnet, which is called first in the startnet script, should be modified to add the same check as above.

I believe the last option to be preferable.

Let me know what you think. I am happy to make the modification and request a PR.

[rvdwegen]

I was looking at going the StartURL route too because I wanted to do some custom stuff before and after installation but I've found that OSDClouds StartNet/Shutdown/etc script options fill that gap just fine. Might be worth looking into.

[n4kama]

As indicated in my previous message, the Initialize-OSDCloudStartnet function is the one to be changed in order to correct this faulty behavior. It even seems that the function was originally intended to handle the initialization of network configurations, but the code is commented out and not implemented (like a TODO).

So I took the initiative of writing the missing code. It has now passed all the tests in production in my environment.

I'll publish a PR in a few hours to make the patch available.

[n4kama]

So it looks like this:

Standard case

Slow network or slow hardware

---

Note: I improved the log messages a bit in my PR.