Auto-Determine Primary IP Address

One of the things I've baked into our production task sequence for "multi-user devices" is a secondary way to automatically determine a device's use case while in the WinPE stage. The primary, preferred way to determine use case is by the use of SCCM collection variables, but those require a known object (in the proper collection) to function as designed. Thus, for all rebuilds of known devices, the use case is figured out by collection variable.

For new (unknown) machines, if we're doing a build-in-place we must determine the source IP of the workstation to automatically "assign" the proper subset of task sequence actions. Some basic IP address examinations function as an acceptable way to make that determination. Our network architecture is configured in such a way that we have clear enough distinctions between spaces to make this behave as expected, meaning that "lab" machines are in a certain subnet, "classroom" machines in another, etc.

I've spun up a quick and simple GitHub repo for the example below. It's more or less exactly what is used in production (though without the determining logic and setting of task sequence variables). The additional bits (examples) to set task sequence variables are in my repo for auto-generating OSD computer name.

The Setup

It's pretty simple Powershell. Since we only expect one network adapter to be available and ready in WinPE, we just get its address, and Split it into its components:

$defaultIP = (Get-NetIPConfiguration | Where-Object { $_.IPv4DefaultGateway -ne $null -and $_.NetAdapter.Status -ne "Disconnected" } ).IPv4Address.IPAddress
$IPcomponents = $defaultIP.Split(".")

It's important to note this will identify the "first" adapter, so as always one should test in their own environment to determine if any logic additions are required in the Where-Object block.

The Examination

Once we have the split address, we can do some variable assignments for other/later bits in the code, or we could assign those values as task sequence variables.

$subnet = $IPcomponents[2]
$address = $IPcomponents[3]

In our production environment, the above captures the third and fourth octets of the IPv4 address, since those are what we use to match subnets and ranges for our various locations.

The subsequent five-to-ten lines of code (not shown here for identity reasons) basically match ranges and address/assign the proper text value to the task sequence variable.

That's All?

Pretty much. In our production environment there's a tertiary option to display an input dialog with radio button choices, but this is only displayed if neither a collection variable was assigned or an IP address range match applied.

By addressing some auto-matching of use case by IP or other variable, I've further reduced the need for our techs to sit and babysit the early stages of a task sequence, and also cut down user (tech) input errors dramatically. This saves time, effort, and heartache for everyone. I don't recall how many times I've personally "fat-fingered" one of these assignments in the past, which often requires starting the whole process over... No fun.

Of course, while this example illustrates how to use this data in a task sequence case, it could be used (with testing) for most any type of basic use case. Ideally it works with N==small network adapters.

Headline image via Wikipedia