So here is a challenge I had to face today: I created a virtual machine (VM) in Azure from a custom image that was previously Sysprep'd by me. The image contained several applications intended to run on a RDSH (Remote Desktop Session Host) for Citrix Virtual Apps and Desktops (former XenApp), so the RDS role was also installed. The VM was not part of the domain, it was in a Workgroup and it could not reach the RDS license server. Which meant: I could not RDP into the machine to perform Domain Join. And if you already have some experience with Microsoft Azure, you will know that there is no Remote Console like in VMware or Hyper-V.

The VM was still reachable over the network. So here are four PowerShell commands that allowed me to remotely perform a Domain Join on that particular machine. Nothing fancy, but it might come in handy.

$Server="10.10.10.10"

Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value $Server -Confirm:$false -Force

This credential variable stores the local username and password of the computer. Something like computername\admin along with the password.

$Cred = Get-Credential

Add-Computer -DomainName "ajni.lab" -Restart

After executing the last command you will be prompted to insert domain credentials. The user obviously must have the right to create computers in the domain.

Here is a cool trick that not everyone might know (I didn't).

If you want to open Task Manager inside an RDP session, CTRL+ALT+DEL won't work, right? That key combination would trigger on your local computer.

For remote sessions, there is CTRL+SHIFT+ESC.

This shortcut directly opens Task Manager, no additional steps required!

I got tasked with installing a brand new Windows Server 2019 with the Remote Desktop Services (RDS) role. It was a pretty straightforward installation, but minor things might work differently compared to previous versions of Windows Server (I was migrating off Windows Server 2012 R2).

Start by adding the RDS role through Server Manager.

Select the RDS installation:

I went for the Quick Start because my deployment is fairly basic.

Session-based deployment enables multi-session support on the server.

The server should be automatically selected.

The three roles (RD Connection Broker, RD Web Access and RD Session Host) will be installed.

After the installation a license warning will be shown in the Notification Center.

Two things are needed in order for licensing to work properly: The license server and licensing mode.
In a production environment, usually there is a separate server hosting the RDS Licensing service.

Server Manager > Remote Desktop Services > Overview > Tasks > Edit Deployment properties

I had problems with the licensing mode not being applied properly. This registry key worked wonderfully though:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core
DWORD LicensingMode
4 = Per user
2 = Per Device

The license server can be also set through the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers
REG_MULTI_SZ SpecifiedLicenseServers = license.ajni.lab

With RD Licensing Diagnoser you can check for potential errors (can be opened through Server Manager > Tools > Remote Desktop Services).

Now on to the last step: Create a custom device collection.

Server Manager > Remote Desktop Services > Collections > Tasks > Create Session Collection

This is also pretty straight forward stuff.

Make sure you select the server by moving it to the right with the arrow.

In a production environment a custom group should be used to control the number of permitted users.

User profile disks were not needed in my environment.

After the creation, there are some things that should be changed in the Collection properties (Server Manager > Remote Desktop Services > Collections > Collection Name):

These are my specific settings, you should change the parameters based on your experience or leave them at their default values.

Older clients might have problems with these security settings (like Network Level Authentication - NLA)

Do not forget to apply the changes.

Bonus:

If you have specific AD user attributes, like the home folder or program auto-start, they will not work because of changes made to RDS 2016/2019. You can read this article from Microsoft's website: https://support.microsoft.com/en-us/help/3200967/changes-to-remote-connection-manager-in-windows-server

Following registry entries will tell the Remote Desktop Session Host (RDSH) to query AD DS for RDP profile settings:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
Name: fQueryUserConfigFromDC
Type: Reg_DWORD
Value: 1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp
Name: fQueryUserConfigFromDC
Type: Reg_DWORD

A quick post on how to change the Windows display language with Powershell. You might use these commands based on any logic that determines the user's location/language. For instance, I created a script that gets executed on logon and sets the language based on some criteria (maybe an Active-Directory group or attribute).

Set-Culture en-US
Set-WinSystemLocale -SystemLocale en-US
Set-WinUILanguageOverride -Language en-US
Set-WinUserLanguageList en-US -Force
Set-WinHomeLocation -GeoId 244

You can find the right GeoID on Microsoft's website

There is a built-in app in Windows that helps you record your screen and automatically creates steps with screenshots and a description. Just search "Steps Recorder" in the start menu.

Running the program as administrator allows you to record programs that run with highest privileges. Just start recording, go through the steps needed for the specific action, stop the recording and finally save the steps.

A compressed file will be created containing the report as a MHT file. It can be opened with a common browser.

A very handy tool both for documentations or end users.

Enjoy!