Category Archives: sysadmin

sysadmin, Win10, Win11, Windows

How to Enable Remote Desktop Using PowerShell?

 by 

Recently, one IT team member asked about a PowerShell script to enable remote desktops. In this tutorial, I will explain how to enable Remote Desktop (RDP) using PowerShell with detailed steps.

Table of Contents

Enable Remote Desktop Using PowerShell

Remote Desktop is useful for administrators and users who need to access their computers remotely. Using PowerShell to enable RDP can save time and ensure consistency across multiple machines.

Note: You need administrative privileges on the target machine to enable RDP.

Now, follow the steps to enable remote desktop using PowerShell.

Step 1: Open PowerShell with Administrative Privileges

To enable Remote Desktop, you need to run PowerShell as an administrator. Right-click on the Start menu, select Windows PowerShell (Admin), and click Yes when prompted by User Account Control (UAC).

Step 2: Check the Current RDP Status

Before enabling RDP, it’s a good practice to check if it is already enabled. You can do this by querying the registry:

Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\' -Name "fDenyTSConnections"

If the output is 1, RDP is disabled. If it is 0, RDP is already enabled.

I executed the above PowerShell script on my local machine; you can see the exact output as 1, which means the RDP is disabled.

Enable Remote Desktop Using PowerShell

Step 3: Enable Remote Desktop

To enable Remote Desktop, modify the registry setting and configure the firewall to allow RDP connections. Here’s the PowerShell script to do this:

# Enable RDP
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\' -Name "fDenyTSConnections" -Value 0

# Enable RDP through the firewall
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

This script sets the fDenyTSConnections value to 0 (enabling RDP) and configures the firewall to allow RDP traffic.

Step 4: Verify RDP is Enabled

After running the script, verify that RDP is enabled by checking the registry value again:

Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\' -Name "fDenyTSConnections"

The output should now be 0.

Check out Rename a Computer Using PowerShell

Enable RDP on Multiple Machines using PowerShell

If you need to enable RDP on multiple machines, you can use PowerShell remoting. Here’s an example script to enable RDP on a list of remote computers:

$computers = @("PC1", "PC2", "PC3") # Replace with your computer names

foreach ($computer in $computers) {
    Invoke-Command -ComputerName $computer -ScriptBlock {
        Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\' -Name "fDenyTSConnections" -Value 0
        Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
    }
}

This script loops through a list of computer names and enables RDP on each one.

Check out Get the Windows Version Using PowerShell

Troubleshoot Common Issues

Now, let me tell you some common issues that you might face while enabling RDP using PowerShell.

Issue 1: PowerShell Remoting Not Enabled

If you encounter an error indicating that PowerShell remoting is not enabled, you can enable it using the following command:

Enable-PSRemoting -Force

This command configures the computer to receive remote commands.

Issue 2: Firewall Blocking RDP

If the firewall is blocking RDP, ensure that the necessary firewall rules are enabled. You can manually check the firewall settings or use the following command:

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

This command enables the firewall rules for the Remote Desktop.

Now, let me show you some advanced-level settings you can do using PowerShell.

Read Get a List of Installed Programs Using PowerShell

Configure Network Level Authentication (NLA)

Network Level Authentication (NLA) adds an extra layer of security to Remote Desktop connections. To enable NLA, use the following PowerShell script:

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\' -Name "UserAuthentication" -Value 1

This script sets the UserAuthentication value to 1, enabling NLA.

Set RDP Port

By default, RDP uses port 3389. If you need to change this port for security reasons, you can do so using PowerShell:

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\' -Name "PortNumber" -Value 3390

Replace 3390 with your desired port number. Ensure you update your firewall rules to allow traffic on the new port.

sysadmin, Win10, Win11, Windows

Ports that are used by Remote Desktop Services

  • 02/08/2025

This article introduces the ports that need to be open on firewalls to configure Remote Desktop Services (RDS) correctly.

The information and taxonomy are broken down by role, service, and component, and all inbound and outbound ports used are listed.

From client to RD resource

  • TCP 443 (HTTPS): Required if RDWeb is deployed.
  • TCP and UDP 3389: Standard Remote Desktop Protocol (RDP) port. It can be configured to a different port number on the host and client.

Remote Desktop Connection Broker (RDCB)

  • TCP 5504: Used for connections to RD Web Access.
  • TCP 3389: Used for connections to RD Session Host.
  • TCP 3389: Used for connections to non-managed VM pools. Managed machines use Virtual Machine Bus (VMBus) to open ports.
  • TCP 3389: Client port for clients not using RD Gateway.
  • TCP 445 and RPC: Used for connections to RD Virtualization Host.
  • TCP 445 and RPC: Used for connections to RD Session Host.
  • TCP 5985: Used by Windows Management Instrumentation (WMI) and PowerShell Remoting for administration.

Remote Desktop Gateway

Inbound external internet-based traffic from RD clients to the Gateway

  • TCP 443: Used for HTTP (including RPC over HTTP) over SSL. This port can be configured using the RD Gateway Management console.
  • UDP 3391: Used for RDP over UDP. This port can be configured using the RD Gateway Management console.

     Note

    Firewalls that have directional UDP analysis, such as TMG, require UDP “Send Receive” to be configured.

Internal traffic between the Gateway and the required user AD, resource AD, DNS, NPS, and so on

  • TCP 88: Used by Kerberos for user authentication.
  • TCP 135: Used by the RPC Endpoint Mapper.
  • TCP 135: Port that NTDS RPC services listens on AD.
  • TCP and UDP 389: Used by the Lightweight Directory Access Protocol (LDAP) for user authentication. It’s required when using LDAP for Certificate Revocation Lists (CRLs).
  • TCP and UDP 53: Used by the Domain Name System (DNS) for internal resource name resolution.
  • TCP 80: Required when using HTTP for CRLs.
  • TCP 21: Required when using FTP for CRLs.
  • UDP 1812 and 1813: Required when Network Policy Server (NPS) is used.
  • TCP 5985: Used by WMI and PowerShell Remoting for administration.

Internal traffic from the Gateway and the internal RD resources

  • TCP and UDP 3389: Used by RDP.

     Note

    Firewalls that have directional UDP analysis, such as TMG, require UDP “Send Receive” to be configured in the UDP protocol.

Remote Desktop Web Access

If RD Web Access is on a perimeter network, configure the following ports:

  • TCP: <WMI Fixed Port>
  • TCP 5504: Used for connections to RDCB for centralized publishing.
  • TCP 5985: Used by WMI and PowerShell Remoting for administration.

Remote Desktop Session Host

  • RD License Server: RPC ports.
  • TCP 389 and 636: Used for AD communication.
  • TCP 5985: Used by WMI and PowerShell Remoting for administration.

Remote Desktop Virtualization Host

  • RD License Server: RPC ports.
  • TCP 389 and 636: Used for AD communication.
  • TCP 5985: Used by WMI and PowerShell Remoting for administration.

Remote Desktop Licensing Server

For more information, see RDS Licensing (RDSL).

TCP

  • TCP 135: Used for RPC for License Server communication and Remote Desktop Session Host.
  • TCP 1024-65535 (randomly allocated): Used for RPC in Windows Server versions that are earlier than Windows Server 2008.
  • TCP 49152-65535 (randomly allocated): Used for RPC in Windows Server 2008 and later versions.
  • TCP 445: Used by the Server Message Block (SMB) protocol.
  • TCP 443: Used for communication over the internet to the Microsoft Clearing House.
  • TCP 5985: Used by WMI and PowerShell Remoting for administration.
  • TCP 139: Used by the NetBIOS session service.

For more information, see How to configure RPC dynamic port allocation to work with firewalls.

NetBIOS

  • UDP 137: Used for NetBIOS name resolution.
  • UDP 138: Used by the NetBIOS Datagram Service.
  • UDP and TCP 389: Used by LDAP with per-user Client Access Licenses (CALs) in AD.

From a proxy standpoint, the registry key HKLM\Software\Microsoft\TermServLicensing\lrwiz\Params shows the Microsoft service that the RD License Server communicates with.

Hardware, Linux, sysadmin

Ubuntu/Linux Mint – Brother QL-800 Label Printer

First thing first, leave the USB off. When you first plug in the power, if the “Editor Lite” light is on, then hold the button until it turns off. Editor Lite causes it to mount as a mass storage device and not as a printer.

Next up, download the drivers from Brother’s website: https://support.brother.com/g/b/producttop.aspx?c=ca&lang=en&prod=lpql800eus or via my local mirror (ql800pdrv-3.1.5-0.i386.deb).

Install the usual way:

sudo dpkg -i ql800pdrv-3.1.5-0.i386.deb

This will add the drivers and add a new printer. If you get any /var/spool/lpd errors, try making the right directory ahead of time and re-install the deb file.

sudo mkdir -p /var/spool/lpd/ql800

Plug in that USB. Check in Printers or via the CUPS interface (http://localhost:631/printers/). The device URI should look something like usb://Brother/QL-800?serial=000W0H924252.

If you run into problems (check via dmesg or jounalctl -f), it could be a udev rule that you’re missing. Try adding a new udev rule, changing the Serial number (find that out via “dmesg | grep Serial” when first plugging the USB in).

sudo vi /etc/udev/rules.d/10-brother-printer.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04f9", ATTRS{idProduct}=="209e", ATTRS{serial}=="000W0H924252", MODE="0664", GROUP="lp", SYMLINK+="usb/lp0"

Then restart udev and cups:

sudo udevadm control -R
sudo service cups restart

If you’re installing some other Brother, the vendor code should be good but you’ll need to replace the Product ID (209e) with your own. You can find this out by running “lsusb” (check the bold for the product ID).

Bus 003 Device 019: ID 04f9:209b Brother Industries, Ltd QL-800 P-touch Label Printer

Bonus! Using brother_ql – the Python package to control your Brother printer from the command line

Download and install from the website https://pypi.org/project/brother-ql/.

This should add it to the path (if not, the binaries should be in ~/.local/bin/brother_ql)

This next part you’ll need to figure out. I am using DK-1201 labels which are 29mmx90mm. I created a sample.png file which was exactly 306×991 pixels for testing. So my command line looks like this:

brother_ql --backend pyusb --model QL-800 --printer 'usb://0x04f9:0x209b/000W0H924252' print -l 29x90 sample.png

Note the change in the USB string — replace those with your product ID (if not QL-800) and serial number.

Source: Ubuntu/Linux Mint – Brother QL-800 Label Printer | 10pm.ca – Tidbits for the wandering Googler

proxmox, sysadmin

Recover From Grub Failure – Proxmox VE

General advice

During to the upgrade from 3.x to 4.x, I found myself without a working grub and unable to boot. Monitor shows:

  • grub rescue >

You can use Proxmox installation ISO in verison 5.4 or newer, and select debug mode. On the second prompt you’ll have the full Linux tools, including LVM, ZFS, …, available. If you exit that prompt you will come to the installation screens, simply hit abort there.

Alternatively, one can use a 64 bit version of Ubuntu or Debian Rescue CD.

Boot Proxmox VE in debug mode, or the Ubuntu/Debian off the ISO. We do not want to install Ubuntu/Debian, just run it live off the ISO/DVD.

First We need to activate LVM and mount the the root partition that is inside the LVM container.

  • sudo vgscan
  • sudo vgchange -ay

Mount all the filesystems that are already there so we can upgrade/install grub. Your paths may vary depending on your drive configuration.

  • sudo mkdir /media/RESCUE
  • sudo mount /dev/pve/root /media/RESCUE/
  • sudo mount /dev/sda1 /media/RESCUE/boot
  • sudo mount -t proc proc /media/RESCUE/proc
  • sudo mount -t sysfs sys /media/RESCUE/sys
  • sudo mount -o bind /dev /media/RESCUE/dev
  • sudo mount -o bind /run /media/RESCUE/run

Chroot into your proxmox install.

  • chroot /media/RESCUE

Then update grub and install it.

  • update-grub
  • grub-install /dev/sda

If there are no error messages, you should be able to reboot now.

Credit: https://www.nerdoncoffee.com/operating-systems/re-install-grub-on-proxmox/

Recovering from grub “disk not found” error when booting from LVM

This section applies to the following setups:

  • PVE 7.4 (or earlier) hosts with their boot disk on LVM
  • PVE 8 hosts that have their boot disk on LVM, boot in UEFI mode and were upgraded from PVE 7

In these setups, the host might end up in a state in which grub fails to boot and prints an error disk `lvmid/<vg uuid>/<lv uuid>` not found. An example (of course, the UUIDs vary):

Welcome to GRUB!

error: disk `lvmid/p3y5O2-jync-R2Ao-Gtlj-It3j-FZXE-ipEDYG/bApewq-qSRB-zYqT-mzvP-pGiV-VQaf-di4Rcz` not found.
grub rescue>

This error “disk `…` not found” error is originally caused by a grub bug. LVM metadata is stored on-disk in a ring buffer, so occasionally the current metadata will wrap around the end of the ring buffer. However, if there is a wraparound in the ring buffer, grub fails to parse the metadata and fails to boot with the above error.

The recommended steps differ between the PVE 7.4 and PVE 8.

PVE 7.x

This subsection applies to PVE 7.4 (or earlier) hosts with their boot disk on LVM.

PVE 7.4 ships grub 2.06-3~deb11u5 which is affected by the bug (though earlier versions may also be affected). This was also reported multiple times in the forum already, see here and here.

Temporary Workaround

In order to temporarily work around this bug and get the host to a bootable state again, it is sufficient to trigger an LVM metadata update. The updated metadata will reside in one contiguous section of the metadata ring buffer, so no wraparound occurs anymore. grub will then be able to parse the metadata correctly and boot again.

One simple way to trigger an LVM metadata update is to create a small logical volume:

  • Boot from a live USB/CD/DVD with LVM support, e.g. grml
  • Run vgscan
  • Create a 4MB logical volume named grubtemp in the pve volume group: lvcreate -L 4M pve -n grubtemp
  • Reboot. PVE should boot normally again.
  • You can now remove the grubtemp volume: lvremove pve/grubtemp

Note that there are many other options for triggering a metadata update, e.g. using lvchange to extend an existing logical volume or add a tag to an existing logical volume.

The workaround is only temporary: If the host is (re)booted at a time when there is again a wraparound in the metadata ring buffer, grub will fail to boot again.

On a running PVE system, you can check whether there is a wraparound in the metadata ring buffer using the following command:

vgscan -vvv 2>&1 | grep "Reading metadata"

If the output lines end with (+0), there is no wraparound. If they end with (+N) for any other number N, there is a wraparound and the grub will most likely fail to boot after a reboot.

Permanent Fix

The only permanent fix for PVE 7.x is:

  • Apply the temporary workaround to be able to boot PVE again
  • Upgrade to PVE 8 by following the upgrade guide.

PVE 8

This subsection applies to PVE 8 hosts that have their boot disk on LVM, boot in UEFI mode and were upgraded from PVE 7.

PVE 8 ships grub 2.06-13 in which the grub bug is fixed. However, on hosts that boot in UEFI mode and were upgraded from PVE 7, it can happen that the updated grub 2.06-13 EFI binary is not installed to the EFI system partition (ESP) at /boot/efi/EFI/proxmox/grubx64.efi. As a result, when booting in UEFI mode, the host still runs the older grub 2.06-3~deb11u5 binary that is affected by the grub bug. To find out whether this is the case, check its mtime using ls -l /boot/efi/EFI/proxmox/grubx64.efi. If it is older than the time of the upgrade from PVE 7 to 8, the host still runs the older grub binary when booting in UEFI mode.

Temporary Workaround

The temporary workaround for PVE 8 to get the host in a bootable state is the same as for PVE 7.x (see above).

Permanent Fix

The issue can be fixed permanently on PVE 8 by installing the correct grub metapackage for UEFI and choosing the correct UEFI boot entry.

First, apply the temporary workaround to be able to boot into PVE 8 again. When booted into PVE 8, run the following command. It checks if the host is indeed booted in UEFI mode, and if yes, installs the correct grub metapackage for UEFI:

[ -d /sys/firmware/efi ] && apt install grub-efi-amd64

This will remove the grub-pc package, and update the binary on the ESP. You can verify that the mtime of /boot/efi/EFI/proxmox/grubx64.efi was updated.

Note that this will not update the default EFI binary at /boot/efi/EFI/BOOT/BOOTx64.EFI, which might still be the grub binary that is affected by the bug. Consequently, make sure that you select the proxmox boot entry when booting in UEFI mode. If needed, you can adjust the boot order directly in the UEFI firmware or using the efibootmgr tool (see its manpage).

Source: Recover From Grub Failure – Proxmox VE