Managing an ARM64 Windows Tablet With ET Ducky

A child's Windows tablet needs to be locked to a short list of apps, kept current, and changed from time to time without anyone typing on the device. I manage a Surface Pro X learning tablet from the ET Ducky dashboard. The tablet has an ARM64 processor and runs Windows 11 Pro, and the ET Ducky agent runs on it natively. This post covers how the tablet is set up, how the scripts reach it, how an update runs, and what I learned along the way.

What the tablet runs

The Surface Pro X runs Windows 11 Pro on an ARM64 processor, and it is configured by a PowerShell module that lives in a public GitHub repository, Surface-Pro-X-KidSetup. The module creates the child's local account with a random password and automatic sign in, applies an Assigned Access multi-app kiosk profile, and sets Edge policies that block every URL except an allowlist of approved domains and the local apps folder. It also builds a custom home screen, KidHome.exe, which is compiled on the tablet from C# source embedded in the module.

Apps are tiles on that home screen. They can be offline HTML apps served from C:\KidTabletApps, where the child's account can read but not write, approved web apps, Store apps, or desktop apps under Program Files. The tile list and settings are in C:\ProgramData\KidTablet\config.json, which only SYSTEM and Administrators can change.

Enrolling the tablet and connecting the scripts

The tablet is a managed agent in my ET Ducky org, enrolled with a registration token from the dashboard. The agent runs as SYSTEM. My scripts repository is connected under Integrations and Script Repositories, and Browse and Import copies a script into the org's Imported Scripts. Each script has a settings block at the top and prints what it did.

An export script in the package repository generates those scripts and embeds the module into the ones that need it. It refuses to export when the embedded copies are stale, so the dashboard never holds an older module than the repository. I run the scripts from the agent's Live Session Shell tab with Run as logged in user unchecked, which runs them as SYSTEM.

The scripts I run

Six scripts cover day to day administration.

• Deploy-KidTablet is the first deployment. It is a single file with the module embedded, runs without prompts, and is safe to run again. It writes the module, creates the account, applies the kiosk and Edge policies, and registers a logon task that applies the account's per-user settings at every sign in.
• Update-KidTabletApps downloads the package from GitHub, backs up the previous package, and runs the package's own installer.
• Sync-KidTablet reapplies Edge policies, shortcuts, the kiosk profile, tile images, and the home screen from config.json.
• Set-KidTabletVoices changes the text to speech settings, which I describe below.
• Get-KidTabletStatus is a read-only report with the module hash, whether the home screen was built from that module, whether the child is signed in, the installed apps, and the tail of the launcher and kiosk logs.
• Reset-KidTablet returns the tablet to a clean slate.

How an update runs

I commit to the package repository and push main. In the dashboard I open the tablet, go to Live Session and Shell, and run Update-KidTabletApps. The script downloads the package zip from GitHub, checks an optional SHA256, carries pre-rendered voice packs over from the copy already on the tablet, and saves the previous package to a backup folder. The package installer then checks itself, installs the module, rebuilds the home screen if its source changed, reinstalls every app, and restarts the child's session. One run from the dashboard is a full update.

The first run of any new script text opens a security review in ET Ducky, because the script downloads a package. I approve it once as an org admin and the same text runs without another review. Imported scripts are snapshots, so after I change a script in the repository I remove it under Imported Scripts and import it again.

Changing a setting from the dashboard

The tablet has a read-aloud story app that I moved from cloud speech to a text to speech server on a PC at home, with the cloud service kept as the fallback when the PC is off. That change meant editing three values in the tablet's .env file and rewriting each app's config.js. Set-KidTabletVoices does both, probes the PC from the tablet, and names any voice profile that is missing from the server.

The script holds no secret. The PC trusts the tablet's subnet, so the tablet sends no credential, and the cloud speech key was placed in the .env file once.

Work that waits for the child

The home screen writes an idle counter every 30 seconds, and the tasks that run as SYSTEM read it before doing anything disruptive. A Store install that pauses the kiosk, or a session restart, only happens when the child is signed out or has been idle for ten minutes. Store apps are licensed per account, so the module queues them and installs them under the child's account at the next sign in, then restores the kiosk. A 30 minute watchdog restores it even if the install fails. New tiles need a fresh sign in, so when tiles are pending and the child has been idle on the home screen for two minutes, the launcher signs out and automatic sign in brings the account straight back, at most once every four hours.

What I learned running scripts through the agent

Secrets stay out of script text. When I pasted a key into an imported script, its text changed, which opened a new review each time and left the key visible in the dashboard. Keys now go into the .env file once. The agent also refuses to read credential files over the dashboard, which is the behavior I want, so my diagnostics use file sizes and dates instead.

A word in angle brackets in script text is read as a parameter prompt. Two of my scripts asked for parameters because of a comment and a regular expression, so I reworded the comments and built the expression from string pieces.

A SYSTEM token is not an admin token. A remote install updated the module and then stopped at the first app with an error that the process does not possess the SeSecurityPrivilege privilege, while the same installer run by an admin at the tablet succeeded. Set-Acl with a newly built ACL also writes the audit section, and the agent's SYSTEM token does not hold that privilege. The module now writes only the Access and Owner sections through .NET.

The Shell tab stops streaming after about two minutes on a long script and reports a polling timeout, while the agent keeps running the script. I confirm a run from the timestamp on the backup zip and from Get-KidTabletStatus.

Anything that lands in a chat or a log gets rotated. A hex dump of the settings file put a key into a transcript during this work, and I replaced it within the hour.

Where ET Ducky fits

I build ET Ducky, and this tablet is managed from the same dashboard as my test machines. ET Ducky agents support Windows and Linux on x64 and ARM64, which is why a tablet like this one can be managed the same way as a server. The pieces I use for it are the agent enrolled with a token, Script Repositories, Imported Scripts, the Live Session shell, and the security review on new script text. The Live Session shell works from the browser without the need for a VPN, which means the tablet can be changed from anywhere it has a network connection. The Live Sessions documentation covers the shell.