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

Hey folks!

Here is a quick way to find inactive AD Users in your environment. Get-ADUser ist the cmdlet we are going to use.

We are getting all users from the highest OU (domain.com) and using the Property LastLogonDate, which will not be returned if not specified in the -Properties parameter. After that a Where statement is going to show users that haven't logged in since 90 days or more.

Get-ADUser -Filter * -Properties lastlogondate | where { $_.lastlogondate -lt (Get-Date).AddDays(-90) }

We could also specify the OU where the command is going to search:

Get-ADUser -Filter * -Properties lastlogondate -SearchBase "OU=TerminatedEmployees,DC=Company,DC=com"| where { $_.lastlogondate -lt (Get-Date).AddDays(-90) }|select Name,Lastlogondate

There is also the -SearchScope Onelevel parameter to determine that we are not going to search recursively:

Get-ADUser -Filter * -Properties lastlogondate -SearchBase "OU=TerminatedEmployees,DC=Company, DC=com" -SearchScope OneLevel | where { $_.lastlogondate -lt (Get-Date).AddDays(-90) }|select Name,Lastlogondate

Have fun!

Hi Folks!

Here is a quick tip to install the VMware PowerCLI, which is - like the name says - for Windows PowerShell.

To initiate the installation process, type this command into the Powershell Console:

Install-Module -Name VMware.PowerCLI

Powershell will ask you if you wish to install "NuGet", which is required to automatically download and install VMware PowerCLI from PSGallery. You also have to trust the PSGallery repository in order to proceed with the installation.

Now you can list all of the VMware PowerCLI Modules:

Get-Module -ListAvailable | where { $_.Name -match "vmware" }

Or just check your currently installed VMware PowerCLI version:

Get-PowerCLIVersion

Enjoy!

With Windows Server 2008 R2, Active Directory has now a recycle bin. With this feature you do not have to use for example Windows Server Backup to initiate an authoritative AD restore, instead you can quickly recover deleted Users, OUs, Groups and other objects through Active Directory Administrative Center (Windows Server 2012 an upwards) or PowerShell

Enabling AD Recycle Bin (PowerShell commands

Enable-ADOptionalFeature 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target ajni.lab

Type A (=Yes to All) to enable the feature

(Optional) Check Deleted Object’s Lifetime

Get-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ajni,DC=lab" -Property msDS-DeletedObjectLifetime | fl

If you do not see the Property named "msDS-DeletedObjectLifetime", it means that it has the default value of 60 days.

You can change is with this command – do not forget to replace DC=ajni, DC=lab with your domain name:

Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=ajni,DC=lab" -Partition "CN=Configuration, DC=ajni,DC=lab" -Replace:@{"msDS-DeletedObjectLifetime" = 120}

Checking the property again, you‘ll see your new value:

You can also have a look at this property with ADSIedit:

Restoring an Object

In our example we deleted an OU called “ImportantOU”

Let’s list all Deleted Objects:

Get-ADObject -filter 'isdeleted -eq $true -and name -ne "Deleted Objects"' -includeDeletedObjects

And then restore our important OU. Before Restoring we can check if the Filter finds our OU:

Get-ADObject -Filter 'msDS-LastKnownRDN -eq "ImportantOU"' -IncludeDeletedObjects

Now restore:

Get-ADObject -Filter 'msDS-LastKnownRDN -eq "ImportantOU"' -IncludeDeletedObjects | Restore-ADObject

Our important OU is back from the dead:

We can also restore from Active Directory Administrative Center (ADAC)

Note that while AD Recycle Bin gives you the flexibility of quickly restoring deleted AD Objects, you should also have a functional Windows Server Backup and VM Backup with solutions like HPE Data Protector or VEEAM. Just in case something goes horribly wrong!