Technology Solutions for Everyday Folks

Basic Dialog to Manually Name OSD Task Sequence Device

Many years ago I wrote about the way I automatically generate the OSDComputerName value for most devices in my fleet. Much of that process remains as it did back then, but I've never written about how I handle the one-offs (such as my testing VMs or other nonstandard hardware).

There's not a lot truly "special" about manually naming a device during a task sequence but as I recently made the major annual improvements in my core task sequence (requiring modifications to the Powershell that handles the input dialog), it seemed timely to share.

The Old Way

To be honest, I actually stole ("with pride"—IYKYK) the little dialog I've been using from our central IT folks. It worked, was lightweight, and did what I needed when the auto-naming script didn't. There were always some things and nuance I didn't really care for, but hey...I didn't need to write or maintain it!

Unfortunately, even the central team was no longer using this particular dialog and deploying it required me to use package content. I needed (and wanted) to use embedded Powershell directly in the task sequence step, so it was time to roll my own. I figure ten+ years of solid use of something I didn't ever need to touch was enough!

The New Form

First off was building out the basic dialog. Since I'm lazy and have it, I use an IDE to handle all the form components and placements. It adds a bit of bloat to the script, but I didn't have to try tweaking it beyond doing some basic testing for different resolutions, which is still a thing for some of our laptop models in WinPE. Ultimately, the name dialog presents like this:

Screen snip of a Powershell-generated Windows forms dialog to collect Computer name information.

Form Validation and Output

One of the things I added when rebuilding the form was basic validation to catch empty strings, extra-lengthy strings, or special characters. There's nothing especially unique, but it's a nice touch and can help track down devices that went sideways.

In particular, I have three conditions to check:

  1. If the name is blank, use a default name. This is unlikely as the dialog will pre-populate with the MININT name, but good to catch anyway.
  2. If the name is longer than 15 characters, truncate to those first 15. This is kinda archaic, but since my auto-names will wind up at the NetBIOS maximum length of 15 characters, might as well enforce it for any manuals.
  3. Any special characters in that name? Use a default name. There are more graceful ways to handle this without going nuclear and using a default but the odds of this in my environment are astronomically low—why fix for a problem that may never exist?

At invocation, my form adds some FormClosed code which is where all of this (and the setting of the task sequence variable) happens:

$OSDComputerName = $ComputerNameBox.Text.ToUpper()
Write-Host "RAW NAME: " $OSDComputerName
if ($OSDComputerName.Length -eq 0) {
	$OSDComputerName = 'MZO-UNKNOWN-BOX'
} elseif ($OSDComputerName.Length -gt 15) {
	$OSDComputerName = $OSDComputerName[0..14] -join ""
} elseif ($OSDComputerName -match "^[-_]|[^a-zA-Z0-9-_]") {
	$OSDComputerName = 'MZO-UNKNOWN-BOX'
}
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment
$tsenv.Value("OSDComputerName") = "$($OSDComputerName)"

This little bit of code grabs the text box value, does that bit of validation and sanity checking as necessary, and drops the resulting name in/as the OSDComputerName TS variable for action later on. Pretty straightforward.

Et Voila!

What's nice about this little solution is it is neatly encapsulated in one simple Powershell script, which I have embedded in the TS step at its new location. I've got a gist of the full script if you're interested to Steal With Pride (or modify) for your own purposes. Simple. Effective. Cleaner than what I used before.

Good luck!