Switch day

Switch day moves every PC from the old emulators to WND Terminal in one go. You run a small discovery program across the estate, read one report, make a pack, and deploy. When people open WND Terminal for the first time, their own sessions, keyboard maps, macros and screen look are already there. Nobody re-enters a host name.

Three programs do it.

WND Terminal itself does the last part. On its first start it finds the person’s set-up file and adds it without asking.

The runbook

1. Make a share for discovery. For example \\fileserver\wnd-discover$. The computers write to it (give the Domain Computers group Modify, since wnd-discover runs as SYSTEM) and IT reads it. People don’t need to read it. It holds their files, so treat it like a home folder share.

2. Tell wnd-discover where it is. Set the registry value Share under HKLM\Software\WND Software\Discover to the share, with Group Policy Preferences or an Intune remediation script. You can also give it on the command line with --share.

3. Run wnd-discover on every PC. It’s one file with no installer (WND-Discover-Windows.exe, on the downloads page with the admin kit). Run it as SYSTEM so it can read every profile, from an Intune platform script, a Configuration Manager package or a Group Policy startup script:

   wnd-discover.exe --share \\fileserver\wnd-discover$
   

   It takes a few seconds, writes \\fileserver\wnd-discover$\<computer>\<user>.wnddisc for each person with emulator files and _computer.wnddisc for the computer, and changes nothing on the PC. Run as a sign-in script instead, add --me and it collects only that person’s profile. --list shows what it would collect without writing anything.

4. Make the report.

   wnd-automate readiness --estate \\fileserver\wnd-discover$ --out D:\Reports
   

   wnd-automate is installed with WND Terminal (C:\Program Files\WND Terminal\wnd-automate.exe). The report’s folder has the one-page summary for leadership (Switch day report.html and .pdf), the detail sheet with every file (Switch day details.xlsx), People.csv, Computers.csv and Needs a person.csv.

5. Close the gaps. A person is ready to switch when nothing of theirs needs a person. People.csv says who isn’t and why, and Needs a person.csv lists the files. Typical ones are Rumba profiles (Reflection Desktop converts them), encrypted Reflection documents (save a copy without encryption) and macros that use what WND Terminal doesn’t have. Fix them at the source, run wnd-discover again on those PCs, and make the report again. It takes about a minute.

6. Make the switch pack.

   wnd-automate switch-pack --estate \\fileserver\wnd-discover$ --out D:\SwitchPack ^
     --users-at \\fileserver\wnd$\users --license wnd1.your-key
   

   --users-at is where you’ll put the people’s files (a folder, or an https:// address on your intranet). --license puts your key in the policy files. Without it they say "Paste your wnd1. license key here", and the command reminds you. --look classic gives everyone the green-screen look of their old emulator (modern, light and auto work too). Without it, people get WND Terminal’s own.

7. Publish the people’s files. Copy the pack’s users folder to the place you gave in --users-at. Everyone needs to read it. Each file is named after a sign-in name (jsmith.wndconfig) and holds host names, keyboard maps and macros, never a password.

8. Set the policy. Import the admin kit’s ADMX into Group Policy and set the values in the pack’s WNDTerminal.reg, or deploy policy.json (Windows and Linux) or WNDTerminal.mobileconfig (Macs). They have your organization’s connections, FirstRunImport and the license. Add MaskPatterns and anything else you want from the policy settings reference.

9. Deploy WND Terminal. deploy\Install commands.txt has the install and uninstall command lines for Intune, Configuration Manager and Group Policy, and deploy\Detect-WNDTerminal.ps1 is the detection script for Intune and Configuration Manager.

10. Switch. People open WND Terminal and find their sessions, keyboard maps, macros and look already there. Each import is in the audit log as import.firstrun, with how many connections, keyboard maps and macros came over, so you can check it against People.csv. Uninstall the old emulators when you’re ready.

What wnd-discover collects

It looks at every user profile it can open (C:\Users\... from the computer’s profile list, /Users on a Mac, /home on Linux), walks it from the top, and takes the files WND Terminal’s importers know.

It also takes the same files from the folders every user of the computer shares (the emulator vendors' folders in C:\ProgramData, and C:\Users\Public). Those count for everyone who uses that computer.

It skips folders that never hold emulator files (browser data, caches, pictures, program package stores), doesn’t follow folder links, and doesn’t download files that are only in OneDrive. It finds the emulators installed from their entries in Programs and Features, or their install folders.

Passwords

Every file is scrubbed before it’s written, the way each format keeps a password.

• In INI-style session files (PCOMM, ACS, BlueZone, EXTRA!, PASSPORT, PowerTerm, HostExplorer, TN3270 Plus, QWS3270, Vista, tn5250), any setting whose name has password, pwd, passphrase, secret, credential or a token in it loses its value. The vendors don’t all publish their setting names, so the rule is wide on purpose.
• In Reflection settings (XML, and inside .rd3x, .rd5x and .rdox), password items and attributes lose their values. Reflection 11 .rsf commands such as .SetString rcPassword, "..." lose the quoted text.
• In PCOMM macros, encrypted inputs (a typed password) lose their value. In Basic, VBA and PSL macros, assignments such as Password = "..." lose the quoted text.
• A file that can’t be checked is left out and listed with the reason. That covers Rumba’s binary profiles, Reflection 12 .rsf files, encrypted Reflection documents and anything else that isn’t text. The report counts them as needing a person.

A macro can still type a password it doesn’t call one. Look at the macros that sign on (the report lists every macro) before you publish the pack. The SHA-256 in each file’s listing is of the scrubbed file, so the share never holds a hash of a password either.

What it doesn’t do

It connects to nothing but the share. It needs no policy and no WND Terminal, and it writes nothing on the PC. PuTTY keeps its sessions in the registry, which wnd-discover doesn’t read. People bring those over in WND Terminal from a .reg export.

The .wnddisc file

A zip with manifest.json and the files under files/. The manifest has the computer, the person, the system, when it was collected, the emulators installed (product, version, publisher, where), and each file with its path in the profile, emulator, size, SHA-256, the times it was changed, created and last opened, the settings that were scrubbed and, for a file left out, why. _computer.wnddisc also lists every profile looked at, with the ones that couldn’t be opened.

The .wndconfig file

A person’s set-up, as JSON (UTF-8). wnd-automate switch-pack writes one per person into users\. You can also write them yourself.

{
  "format": "wndconfig",
  "version": 1,
  "user": "jsmith",
  "made_by": "wnd-automate 1.0.290",
  "made": 1760700000,
  "computers": ["PC-0042"],
  "connections": [
    { "name": "Production", "host_type": "3270", "host": "mvsprod.example", "port": 992, "secure": true,
      "model": 2, "code_page": 37, "keymap": "Bank",
      "from": ["PC-0042/AppData/Roaming/IBM/Personal Communications/Production.ws"] },
    { "name": "Payroll", "host_type": "5250", "host": "ibmi.example", "port": 992, "secure": true,
      "model": 5, "lu": "PAYDSP01", "sign_on": "kerberos" }
  ],
  "keymaps": [ { "name": "Bank", "keys": { "ControlRight": "Enter", "Enter": "Newline", "Ctrl+KeyC": "Copy" } } ],
  "default_keymap": null,
  "display": { "theme": "classic", "font": "3270", "status": "classic" },
  "macros": [
    { "name": "Logon", "from": "PC-0042/Documents/Logon.mac", "result": "full",
      "script": "wait \"LOGON\"\ntype \"logon &USERID\"\npress Enter\n" },
    { "name": "Month end", "from": "PC-0042/Documents/Month end.ebm", "result": "runs",
      "legacy": { "kind": "extra", "source": "Sub Main\n  ...\nEnd Sub\n", "entry": "Main" },
      "kind_words": "EXTRA! Basic macro" }
  ],
  "notes": ["PC-0042/Documents/Old.rsdm: Rumba keeps session profiles in a binary format ..."]
}

Unknown fields are ignored, so files from newer packs still read.

On first start

With FirstRunImport set, WND Terminal looks for <FirstRunImport>\<sign-in name>.wndconfig when it starts. If the file is there it adds everything in it, through the same steps as importing files by hand. Connections your other settings don’t allow (AllowOtherHosts, LockHostType) are left out and counted in the audit event. It remembers the file’s SHA-256 in the person’s profile. With FirstRunImportOnce on (the default) it never reads the file again. Turn it off and it imports again whenever the file changes, which is how you send a new connection to people later. A person without a file sees nothing different.

The audit event is import.firstrun, "success" with where it came from and how many connections, keyboard maps and macros came over and how many connections were left out, or "failure" with why the file couldn’t be read.

In a browser

The gateway does the same for WND Terminal in a browser, keyed by the person who signed in. Set it in the gateway’s configuration:

[import]
first_run_url = "/srv/wnd/users"   # or https://intranet.example/wnd/users
first_run_once = true

The sign-in name is the one your identity provider gives the gateway, compared the same way (lower case, no domain). Each browser remembers what it imported.

Macs and Linux

wnd-discover builds and runs on Macs and Linux too. It reads /Users or /home, finds IBM i Access Client Solutions, tn5250 and PuTTY by their install paths, and takes /etc/tn5250rc. Run it with --share (there’s no registry there). The switch pack’s WNDTerminal.mobileconfig carries FirstRunImport for Macs.