Packet Radio Build Part 1 – Windows Server Configuration for a Packet Node
Now that I’ve concluded the base packet radio series, where we went from an introduction to packet, BPQ32, all the way up to an TCP/IP Stack in Linux, it’s time to build my dream packet node. The is the first post in a new series made to take you from A-Z of building a stable, robust, and secure packet radio node with real world use cases in the form of an RMS Winlink Gateway, while still hosting the BPQ32 node for Message forwarding, Chat, and APRS. I will host all of these services on a single VHF radio, and a single HF radio with AX25, as well as VARA working on both. Further more, all of the Operating systems used in the nodes will be virtualized within Proxmox, with passed through USB devices. This will give us lots of extra flexibility and backup solutions. This is a big task, and those of you that follow me know I like to do things to a high standard, so strap in, and follow along if you’d like.
Why use VMs?
By running all of the packet node software in VM’s we open up lots of opportunity to increase redundancy, security, and have a well managed backup plan. The server will be running Proxmox, a great (and free) hypervisor, packed with many features. By having Windows Server in a VM, we can take daily or even hourly snapshots of the Virtual Machine, store them anywhere we like, and restore them at any point something goes wrong. On top of this, we can run other operating systems alongside windows if we want, like linux running software for our node, but have Windows handle windows native applications like VARA. We get more security because if the virtual environment is compromised, it can easily be contained, and we get an extra firewall on the hypervisor level to manage it. If we wanted to get really crazy, we could have have another server replicated with VM migration if one fails, to get high availability fail over. It’s truly the best way to host services like this.
Why Windows Server?
Given all of the other content here is mostly written for Debian, it may seem strange I’ve chosen windows to host my packet radio/winlink rms node. I’ll be upfront there. I’ve made RMS and VARA work in wine. It’s not a fun process, and any update to the operating system feels like the tape and glue will rip off at any time. Winlinks RMS/Relay and trimode applications also do not have official support for Linux or wine. Given how finicky things are in that environment, I’ve opted to go with something functional here. There’s a time to experiment and tinker, but this isn’t one of them. Windows Server will work well for this case, as it’s made to run 24/7, 365. Many people opt in for Windows 10/11. While this is the easy route, it’s often met with update blockers, de-bloating scripts, and other workarounds to make things more stable within windows. Windows server ships with the purpose of eliminating all of these weird fixes and tweaks to allow a stable server environment. We can chose when to update, restrict network usage and make it the perfect OS wile still having native support for Winlink applications and VARA with group policies. It stands on much more solid ground than running a specific wine version, with a very old version of .net, or hacking together a client to stop all updates.
That isn’t to say we can’t start a Linux VM, and link LinBPQ or other services that run well on Linux over the network back to the windows server via network KISS. But as for now, it’s apparent that running the Modems/TNC and Winlink program stack on windows.
Configuring Windows Server to be an Optimal Packet Radio Node
I’m starting with a brand new installation of Windows Server 2022, having just finished the setup process and logged into the Administrator account for the first time. If prompted to allow our PC to be discoverable to other devices on the network on first login, lets go with yes if you trust the network your servers connected to.
Creating a User
We’ll start with creating an administrator user (Other than the Default) that will be used to actually run our applications. If the “Server Manager” screen isn’t open yet, search for it within the start menu, and open it up. Click “Tools” on the top right and click “Computer Management”
Now we’ll open “Local Users and Groups” -> “Users” on the left side, then right click into the white space and click “New User…” Check the box for the password to never expire, and uncheck the box to force the user to change the password at next login.
Next double click your newly created user, open the “Member Of” tab, click “Add”, then “Advanced” and then “Find Now”. Double click the “Remote Desktop Users” Group. Repeat the process and double click the “Administrators” Group. It should look something like the following:
Once that’s done, just click “Apply” and then “OK”
Enable Auto Log-In
This isn’t advised if random people may have physical access to your server. But this is a great option to deal with restarts and power outages, so that BPQ32, Dire wolf, RMS Packet and other applications can get started back up on their own.
Back on the Server Manager Page, we will once again click “Tools” at the top right, and this time click “Local Security Policy” Once the window opens, expand “Local Policies” on the left side, and then click “Security Options”. On the lift on the right, find “Interactive Login Do not require Ctrl + Alt+ Delete”, doubble click it, set it to enabled, and then press Apply/Okay.
Back on the Server Manager window, click the tools button once more, and this time click “Registry Editor”. Within the Registry editor, navigate and expand the following path: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\.
On the right side, find and double click the key “AutoAdminLogon”, and set the value to “1”.
Find “DefaultUserName”, and set that to the username you just created.
Next, right click into the white space on the right and Go to New -> String Value”. Name it “DefaultPassword”. Double click it, and set the value to the password you created for your account.
Name your Server and Assign it a Static IP address.
We will now name our windows server to something that is more straight forward, as well as set a static IP address. That way we know what is it if we see it on out network, and know what IP to remote desktop/ forward ports for later.
Press the start button and type “name”, and click “View your PC name” In the window that opens, click the “Rename this PC” button, and change it to something you will recognize. Choose to restart later, as we have one more thing to do.
Click the start button once more, and this time type “Network Connections” and click “View Network Connections”. Right click your Ethernet Adapter, and select “Properties”. Highlight “Internet Protocol Version 4”, and click properties once more. Check the option to “Use the following IP Address”, and set the IP to a static one within your network that you will remember, use 255.255.255.0 as the sub-net mask, and enter your routers IP for the default gateway. Make sure to also put in at least one valid DNS server. You can use your router if it provides DNS, or just use googles at 8.8.8.8.
Allow Remote Connections
Press the start button once more, and search “Allow Remote Connections”, and click the option that comes up. Under the “Remote Desktop” Tab, click “Show Settings” next to “Change settings to allow remote connections to this computer”. On the window that pops up, select the option to “Allow remote connections to this Computer” Click Apply and then Ok.
Test what we have done so far
At this point I restarted the server to make sure my auto login worked as planned, and it did. I also tried to “RDP” (Remote Desktop) into the server from my main computer to make sure I was able to access it remotely. You can do this from your own computer by searching “Remote Desktop” on your start menu, putting in your windows server IP address, and connecting with the account you have created on it. If you have all of this working, you’re about half way there for the preparations, next we will dig into group policies.
Group Policy Changes
Now that we have our new user logged in, it’s time to dig into group policies. These options are where we “make our money” when using windows server as our operating system for RMS gateways or Packet Radio BBS nodes.
Open the Group Policy Editor by clicking the start button, searching “Edit group policy” and clicking the “Edit group policy” option. Use the following table below to expand the referenced path on the left hand side, and then double click the keys on the right to change the value to the one indicated.
\Computer Configuration\Administrative Templates\Windows Components\Windows Update\No Auto-restart with logged on Users for scheduled Update Installations\ -> Enabled
\Computer Configuration\Administrative Templates\Windows Components\Windows Update\Configure auto-restart required notification for updates - > Enabled (User Action)
\Computer Configuration\Administrative Templates\Windows Components\Windows Update\Configure Automatic Updates -> Enabled (2) Apply
\Computer Configuration\Administrative Templates\Windows Components\Windows Update\Display Options for Update Notifications -> Enabled (2)
\Computer Configuration\Administrative Templates\Network\Network Connections\Domain Profile\Allow ICMP exceptions -> Enabled (Allow All)
\Computer Configuration\Administrative Templates\Network\Network Connections\Domain Profile\Allow inbound Remote Desktop Exceptions (Enter your IP)
\Computer Configuration\Administrative Templates\Network\Network Connections\Standard Profile\Allow ICMP exceptions -> Enabled (Allow All)
\Computer Configuration\Administrative Templates\Network\Network Connections\Standard Profile\Allow inbound Remote Desktop Exceptions (Enter your IP)
\Computer Configuration\Administrative Templates\System\Internet Communication Management\Internet Communication Settings\
TURN OFF EVERYTHING EXCEPT:
"Turn off access to all Windows Update Features", "Turn off Automatic Root Certificates Update", "Turn off Registration if URL connection is referring to Microsoft", "Turn off Windows Update device driver searching".
\Computer Configuration\Administrative Templates\System\User Profiles\Disable detection of slow Network Connections -> Enabled
\Computer Configuration\Administrative Templates\Windows Components\Store\Turn off Automatic Download and Install of Updates -> Enabled
\Computer Configuration\Administrative Templates\Windows Components\Store\Turn off Store Application -> Enabled
\Computer Configuration\Administrative Templates\System\Power Management\Select an Active Power Plan -> Enabled High Performance
\Computer Configuration\Administrative Templates\System\Power Management\Sleep Settings\Turn on the ability for applications to prevent Sleep (Plugged In) -> Enabled
\Computer Configuration\Administrative Templates\System\Power Management\Sleep Settings\Allow applications to prevent automatic Sleep (Plugged In) -> Enabled
\Computer Configuration\Administrative Templates\System\Power Management\Video and Sleep Settings\Turn off the Display (plugged in) -> Enabled (500)
\Computer Configuration\Administrative Templates\System\Server Manager\Do not display Initial Configuration Tasks Window at Login -> Enabled
\Computer Configuration\Administrative Templates\System\Server Manager\Do not display the Server Manager automatically at Login -> Enabled
\Computer Configuration\Administrative Templates\System\Shutdown Options\Turn off automatic termination of applications that block or cancel shutdown -> Enabled
\Computer Configuration\Administrative Templates\Windows Components\App Privacy\ -> Enable - > Set Default for all apps to "Force Deny" EXCEPT for access to the microphone.
\Computer Configuration\Administrative Templates\Windows Components\Data Collection and Preview Builds\Allow Diagnostic Data -> Enabled (Diagnostic Data Off)
\Computer Configuration\Administrative Templates\System\User Profiles\Turn off Advertising ID -> Enabled
After the above changes has been made give the server another restart.
Debloat Tweaks
This section further trims down some of the fat that even may exist on windows server. Keep in mind, the portion is not officially supported by Microsoft. We will use two third party tools to further reduce network usage from windows, including eliminating all telemetry.
Go ahead and open up an admin power-shell by searching “powershell” on your start menu. Hold in shift, and right click “Windows PowerShell”, and then click “Run as Administrator” to open an Admin Powershell. Once it’s open, copy and paste the following line of code below and hit your enter key. When prompted for which option to use, enter “1” and press enter.
& ([scriptblock]::Create((irm "https://win11debloat.raphi.re/")))
We will now download, and use the second tool “ShutUp10”, which helps us further eliminate unnecessary resource usage and tracking. First download the tool from here: Free Download O&O ShutUp10++ – O&O Software GmbH. Once downloaded, right click the file and press “Run as Administrator”.
Once it’s open, click “Actions” on the top menu, and choose “Apply all Settings”. You may get a warning, but really we don’t need any of the options enabled on this server for it’s use EXCEPT ALLOW APP ACCESS TO MICROPHONE. Make sure to go down manually and turn that option back off (red) as we need it for our TNCs.
Once that is done give your server a restart, and take a break. You’ve earned it.
The Results
We now have a fully functional windows server environment that will auto login after power outages or restarts. It will still allow updates when the user starts them, and still has it’s security features like virus scanning enabled. After all of this, we now idle at 0% CPU usage, and only take up 1.3G chunk of ram (mostly Windows Defender), which isn’t bad considering it’s windows server.
Whats Next
We now have a slimmed down windows server, that will restart on our own time. The bloat is mostly removed, and we should be able to access it remotely. It will also automatically log into the admin account in case power is lost or it’s restarted. This will be important later when we configure our applications to auto-start. Next we will lay the foundation of our Packet Radio Node by getting the TNC/Modem applications configured and installed, along with getting our Sound Card and CAT interfaces connected and tested.
Check out Part Two:
[…] Packet radio build: Windows Server configuration for BPQ32 and Winlink It stands on much more solid ground than running a specific wine version, with a very old version of .net, or hacking together a client to stop all updates. The Modern Ham […]
What version of Windows Server are you using? And how are you dealing with the license? The cost for a single license is more than most radios.
[…] Click here for Part 1 […]