No. It is not supported to join Windows 2019 nodes into the 2012 R2 failover cluster. You can join there Windows 2016 but not the newer 2019.
Windows 2019 being added to an existing cluster expects the cluster to be running at the Windows 2016 functional level at least.
The newer 2019 version expects the cluster nodes to have self-signed certificates (ClusInfraCert) generated for their intra-cluster SChannel (TLS) communication on port TCP 3343. Which is not the case with the older 2012 R2 version nodes that only use Kerberos for node authentication and communication protection.
If you want to join the Windows 2019 into the 2012 R2 cluster you will get an error (after some timeout) stating simply that the 2019 cannot communicate with any node of the existing cluster.
This simple it is in fact:
NETSH ADVFIREWALL FIREWALL SET RULE all NEW enable=no
You may get the error 210 in the TerminalServices-Gateway Admin log on a Remote Desktop Gateway server (RD Gateway) saying that Http transport: IN channel could not find a corresponding OUT channel. This error may happen if you operate a load balanced RD Gateway farm and the load balancing mechanism does not use any affinity. RD Gateway requires at least the single affinity to be used.
The no affinity setting means that any TCP connection being established from a client may end up at any load balanced farm member. The RD Gateway on the other hand must establish two TCP connections, one for inbound and the other for outbound transport, while both connections must hit the same RD GW farm member. Thus we must configure the load balancing technology (usually the NLB) to connect all TCP connections from a single client to the same NLB farm member.
If you try to install a group managed service account (gMSA) on a server by using the Install-ADServiceAccount cmdlet you may receive an error message saying:
Cannot install service account. An unspecified error has occured
This may happen if you didn't create the group managed service account by using the parameter -KerberosEncryptionType with value of AES128 or AES256. The Kerberos etype parameter is not mandatory and need not to be specified if you do not restrict possible Kerberos etypes on the server. But if the server, which you plan to install the service account on, restricts Kerberos encryption types to AES only, you have to configure the encryption types on the gMSA as well.
If you want to check if your server restricts the available Kerberos etypes, you can check the following local security policy value:
Security settings - Local Policies - Security Options
Network Security: Configure encryption types allowed for Kerberos
If you see that only AES encryption types are allowed in the server's policy, you must use the -KerberosEncryptionType parameter and specify either the AES128 or the AES256.
You can install user interface language pack (MUI pack, UI pack) into any default language mutation of Windows 10 of any build. You can even install English (en-us) language pack into a non-English Windows 10.
First you naturally need to download the language pack. In my MVP/MCT case, I downloaded it from MSDN subscriber downloads portal. It comes in the form of ISO file containing all the available language packs in the form of individual CAB files both for x64 and x86 builds.
ISO can be opened within Windows Explorer so no problem mounting it from GUI and accessing its contents from command line later.
Then, you run the following command against your desired MUI CAB pack to be installed:
dism /online /add-package:"E:\x64\langpacks\Microsoft-Windows-Client-Language-Pack_x64_en-us.cab"
After DISM finishes you must restart the operation system and only then you should be able to open the Languages control panel and select the newly installed UI language as the primary choice.
I have just solved one interesting case. The customer has a great powerful RDP session-based application farm based on Windows 2012 R2. The farm runs several session collections with RemoteApps. The RDP RemoteApps are published through RDWeb and connected over RD Gateway when access from the internet. Everything is using trusted TLS/SSL certificates bought from a public CA such as GlobalSign or Symantec etc.
Everything worked smoothly and fast except for the application startup time when accessed from the internet. RDWeb itself was fast enough. But once you clicked an application it sometimes took even three minutes to start the application. After that, smooth play, no delays anymore. Apparently the RD Gateway was the problem because this didn't happen from LAN when you avoided the RD gateway, at least not that severely.
Digging deeper into the problem, both the RD Gateway and the RD Connection Broker were both had some of their own part in the problem.
The reason was certificate revocation checking which timed-out
The reason identified itself when I enabled auditing for windows firewall connections (the Filtering Platform Connection audit subcategory) and compared and correlated it with the events in the TerminalServices-Gateway/Operational event log. The Security event log showed repeated and frequent TCP connections to remote port 80 (HTTP apparently) started by system processes such as lsass.exe or svchost.exe. Weirdly the connections were going to public internet IP addresses.
And yes, when I checked the TLS/SSL certificate CRL paths and their URLs, these IP addresses showed to be the CRL distribution points of the public CAs which issued their RDP certificates.
Ok, it seemed like the system was trying to verify certificate revocation of its own server certificates (why the hell?) by downloading their respective CRL files. The problem was the farm servers didn't have internet access actually. So all the connections were only starting (SYN-SENT), then each was timing-out for 21 seconds (as is the standard TCP connection establishment timeout) and failed. And again and again with every client connection being established.
As it appears, the RDP gateway and sometimes even the RD connection broker servers are trying to verify its own server certificates revocation status by downloading CRLs.
The solution could be either to allow the servers download the public CRL files from internet over HTTP TCP 80 (if you need, you can configure them to use an HTTP proxy server with netsh winhttp commnad).
Or to make sure that they either cannot resolve their public DNS names at all.
Or if the servers must be able to resolve the public DNS names, then make sure that the following TCP connection fails immediatelly, instead of waiting for the 21 seconds timeout.
If you have a network firewall in place, you must change the blocked port setting from stealth or drop to reject. Or you can configure an explicit blocking Outbound Rule in the servers' Windows Firewall. The outbound blocking rules are good in this regard as they prevent the blocked TCP connection immediatelly and do not let the applications time-out.
You may want to use disk imaging tools such as my favourite WinHex for capturing forensically sound disk images from arbitratily attached USB/SATA/mSATA/M.2/SAS/etc. harddrives even if you do not have a hardware based write-blocker device. In order to prevent the operating system from switching the just attached disks to Online mode and mounting any file systems, you should configure the following registry values:
NoAutoMount = REG_DWORD = 1
SanPolicy = REG_DWORD = 3
Note that the NoAutoMount value goes really directly into the mountmgr registry key, while the SanPolicy value must be set in the Parameters subkey of the partmgr driver.
If you have the registry configured this way, the newly attached disk drives remain in the default Offline mode which means that thay are read/only.
If you want to switch the disks to the writable Online mode, you can always do so with diskpart's command online disk. Note although that making disk Online means immediate mounting any respective filesystem even if no disk letter may be assigned yet.
If you wanted to mount any file system while keeping the disk in read/only mode, you can achieve this with diskpart's command attributes disk set readonly prior to switching the disk into the online mode.
Thus having the disk in the offline mode means always read/only, while having the disk in the online mode may mean read/only or writable, depending on the disk's attribute setting which you can change yet before making the disk online.
A sample DISKPART transaction may look like this:
REM :the previous command listed your disks, the newly attached disk should be offline, note its number
select disk XX
REM :select the number of your offline attached disk instead of typing XX
REM :the previous command should have displayed some attributes, mainly the fact that the disk is in read/only state
attributes disk set readonly
REM :we make the read/only setting permanent for the selected disk by storing this information in the local computer registry
REM :note that this does not modify anything on the disk yet and note also that the setting stays in the local computer registry
REM :and does not roam with the disk if unplugged and moved to another computer
REM :makes the disk online allowing file systems to be mounted, although the disk remains in read/only mode and thus the file systems
REM :are read only as well. No disk letters assigned yet due to the NoAutoMount registry value
REM :only now disk letters assigned, the disk and its file systems still remain in read/only mode
I have already covered all the steps in a previous article about UEFI Secure Boot configuration and Windows 2016 installation from USB flash drive. Here I will just repeat what are the necessary steps to undertake in the UEFI BIOS in order to have the Secure Boot enabled in Windows 2016 or Windows 10. I have just experienced another motherboard which taught me it once again (it was Gigabyte H170-D3H motherboard with the original F4 and later with F20 and later with F21 BIOS update):
- CSM disabled - the compatibilitu support mode (CSM) must be disabled or it would allow nonUEFI boot media and boot loaders to be started which would effectively make the secure boot a nonsense
- require Administrator password to enter BIOS - this is another requirement as well. Without having the BIOS configuration password protected, secure boot is again without a logic
- Windows 8/10 Features setting enabled - you have to enable either the Windows 8/10 or the Windows 8/10 WHQL setting for the Windows 8/10 Features configuration option (you will find it on the BIOS tab). For me, both options worked to boot into the Secure Boot. I was not able to find any documentation about any differences in the two of them. So select whichever you like more :-)
- Secure Boot enabled - sure you have to change the setting to enabled :-) it is not enable by default
- Intel TXT - if the option is not present in the BIOS at all, it seems like it is supported automatically. I didn't need to do anything regarding this so called trusted execution technology.
The crucial thing to enable the Secure Boot
You must always Provision Factory Default keys! Even if you have just received your machine from manufacturing, you have to do it yourself. This cannot be done if the Secure Boot Mode is set to Standard. So the crucial technique is to first enable the Customized mode for secure boot, then provision the factory default keys manually and only then switch back to the Standard mode:
- switch the Attempt Secure Boot to Enabled
- switch the Secure Boot Mode to Customized - it enables the Key Management submenu
- go into the Key Management sub menu
- switch the Provision Factory Default keys to Enabled
- go back up
- switch the Secure Boot Mode to Standard
And you are all done.
We have the password reveal button (aka show password button) in most password entry GUIs since Windows 8. It is the small eye icon showing at the end of password entry edit boxes which, when you mouse-click onto it, reveals the currenlty typed password which would normally be hidden under the stars or dots. People like to lookup the value in order to prevent failed password attempts especially when the computer is configured with several national keyboards or just to be sure. Internet Explorer have had the button included since its version 8 regardless of Windows version.
Is there a keyboard shortcut that would allow you to display the password as you type instead of leaving the keyboard and scrabble around for the mouse? Moreover we server oriented geeks sometimes do not even have mouse available at all.
How to display the password using a keyboard shortcut
Yes there is. Only since Windows 10 and Windows Server 2016. But finally.
On the other hand, secure corporate environments may, according to some information security standards such as the ISO/IEC/EN/CSN 27001/27002, need to disable the password reveal button completelly. As people get accustomed to always showing their password for prior confirmation, they may forget about others watching. There are also survailence cameras etc.
How to disable the password reveal button
There is a Group Policy setting to disable this option available ever since the button exists (Windows 8 and latter). You will find it in a GPO (Group Policy Object) exactly here:
Credential User Interface
Do not display the password reveal button
Do not display the password reveal button
If you want to disable the show password button both in general user interface and in Internet Explorer you simply Enable both settings. It applies to the new Edge browser as well.
You may want to install Windows Server 2016 directly on a fully UEFI enabled system in order to be able to enforce the Secure Boot and make use of features such as Device Guard (Credential Guard) or the Hyper-V isolation and TPM virtual smart cards.
To have Secure Boot propagated the whole way up to a fully booted operating system, you have to clean install directly with all the UEFI support enabled (I have already covered some of it in a previous post about Secure Boot in Windows 10). On my current platform it does not work even if I only leave the CSM (compatibility support mode enabled) so what I need is a fully UEFI and Secure Boot enabled installation media which was not required on my previous trials with an older hardware and Windows 10. I plan installing from a pen flash drive. As it turns out, there some challenges though.
Requirements and challenges
Go into your BIOS (now called UEFI) and make sure you have:
- CSM (compatibility support mode) disabled - this prevents booting anything else than correctly digitally signed UEFI Secure Boot operating system, in our case the Windows 2016 setup from the installation media.
- all legacy OpROMs disabled
- Administrator password for entering the BIOS enforced - without admin password Secure Boot does not work
- Secure Boot enabled
The installation media based on USB pen flash drive must meet the following criteria:
- be GPT (GUID partition table) formated - we cannot use MBR style harddisk format, UEFI requires the newer format called GPT
- have a single partition formated with FAT32 - unless you are extremelly lucky, you cannot use NTFS. The UEFI BIOS needs to be able to read the contents of the partition and kind of logically they understand FAT32 only. You cannot create more partitions on the USB flash drive, because it is advertised as a removable media into operating system and thus it prevents you from creating more than a single partition. Some USB flash drives may have the option to flip the "removable bit" (also called RMB), but it is always kind of a hack for hours long fun during long winter nights.
And here comes the problem. Windows 2016 installation contains INSTALL.WIM file in the sources folder which is more than 4.3 GB long. Unfortunatelly FAT32 file system can accomodate files of size up to 4 GB only. So you cannot put such a big file on FAT32 while you cannot use NTFS for the source partition.
So we have to split the install.wim file into two .swm files with DISM command line utility and it will make do.
- Obtain the Windows 2016 installation ISO and extract the files from it.
- Split the sources\install.wim file to several .swm files using the now built-in DISM tool:
dism /Split-Image /ImageFile:sources/install.wim /SWMFile:sources/install.swm /FileSize:4000
- It will create at least two install.swm and install2.swm files, or even more of them, if you specified a smaller file size or have had a bigger original install.wim image.
- Delete the original sources\install.wim file from the sources folder and keep there or copy there the swm files that you just produced in the previous step
- Obtain a pen USB flash drive that you want to use for the installation media
- Start DISKPART command line as Administrator
- Identify your flash drive with the following command (in my case it showed as disk number 3):
- Select the disk, clean it, convert to GPT and create the empty partition:
select disk 3
create partition primary
format fs=fat32 quick
- Copy all the installation source files containing the split swm files which your prepared previously into the newly formated flash drive. You have to copy all the files from the ISO, including the sources, boot and efi folders as well
And go install, it should work :-) Note that such a drive should be displayed in the UEFI BIOS as a boot option. If it is not, the UEFI BIOS didn't recognize the drive or didn't recognize it can boot from it and it will not boot anyway.