Keeping the Wireless On - Script the Reconnect

In our classroom fleet, almost all devices are wireless-only for their network access. This as a design is great for mobility and flexibility and the user experience but presents its own set of very unique challenges on the technical side. At various times and for a wide range of reasons, we encounter the situation where devices "lose" their wireless/Wi-Fi connection. Resolution usually involves dispatching a tech to the space or walking a user through, under most circumstances, simply "reconnecting" to the proper SSID.

I don't usually directly deal with these symptoms or their resolutions, but for some time I had "pinned" the idea of crafting a mechanism to at least try to reconnect the devices on a schedule or through some sort of automatic way. About a year ago, I stumbled across this post from 2012 in which this very problem was solved (although for Windows 7). It contains a lot of good information about use of the netsh command to do all of the things necessary! I just didn't have a good chance to implement it until quite recently (thanks, bookmarks).

The Test Case

Giving this a shot on one my test devices, I pretty much copied/pasted the example from the post mentioned above into a batch script:

ping -n 1 host.to.ping.com
if %errorlevel% EQU 0 goto end
netsh wlan disconnect interface=”Wi-Fi”
TIMEOUT 5
netsh wlan connect ssid=”[SSID]” Name=”[SSID]” Interface=”Wi-Fi”
:end

Manually disconnecting wireless and triggering this script (as any user due to how the credentials are cached) magically reconnected to the appropriate SSID! Perfect!

The Implementation

This was fine and dandy as a script, but the idea was to make this more or less seamless/transparent to the users of the spaces. This meant using a scheduled task to make this behave under our "expected" circumstances:

• Devices reconnect at boot;
• Devices reconnect at user login (assuming cached credentials are leveraged); and
• Devices check their connection and reconnect on a normal interval.

Scheduled task rollout via Powershell is pretty straightforward, and something I've written about in the past. But I'd not scripted out a multiple-trigger task before. This involved a basic modification to my "standard" scheduled task script for the $trigger:

$trigger = @(
    $(New-ScheduledTaskTrigger -AtLogOn),
    $(New-ScheduledTaskTrigger -AtStartup),
    $(New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionDuration (New-TimeSpan -Days 365) -RepetitionInterval (New-TimeSpan -Hours 2))
    )

After struggling a bit with the repetition bit, since it turns out to be very difficult to easily create a "hey run this thing every couple hours ... forever" task, I settled on a "run for one year ... every two hours ... starting on the date of installation" trigger. A year is sufficient in this case since the segment of the fleet to which this is deployed is refreshed/rebuilt annually.

An important note, though: This script cannot be run as SYSTEM, because it just won't work to handle the reconnect. It must be run as some sort of regular user (who is also a member of the "Log on as a batch job" pseudo-group). This user, fortunately, does not need to have administrator rights on the workstation, and if you're able to do so I'd recommend not using administrator rights for this process. For reasons well outside the scope of this post, I was able to work with an existing, restricted, non-administrator user account to accommodate.

Another important note: using a real user account as the principal of the task involved some fun business with ConvertTo-SecureString, BSTR, and [System.Runtime.InteropServices.Marshal] to adequately and securely address passing real credentials in plaintext (and distributed across a subset of the fleet). Perhaps that can be the subject of a future post.

The Rollout and Results

The rollout/deployment itself went exactly as expected, with no issues whatsoever. Due to the sporadic and unpredictable nature of the underlying problem, it is difficult to determine the efficacy of the rollout and implementation thus far. We'll have a better idea of things in a few months.

I'm really happy this turned out to be a relatively simple problem to help solve. It saves our techs time, and bolsters the end user experience.

Headline image courtesy of Electric Cyclery via Giphy