Windows Server 2016 Remotedesktop (RDS) mit RDWeb/Gateway Authentifizierungsfehler 0x607

Problem

In einer RDS Farm mit RDS Sessionhosts (RDSH), RDS Gateway und/oder RDS Broker Server(n) tritt „auf einmal“ ein Fehler bei der Verbindung mit einem RDS-Client ab Version  auf. Das fällt meistens bei der Anmeldung über das Web-Gateway auf – dort klappt die Authentifizierung, aber die RDP-Sitzung startet nicht. Der Fehler lautet:

„Ein Authentifizierungsfehler ist aufgetreten (Code: 0x607)“

RDS Authentifizierungsfehler 0x607Der Fehler tritt nicht auf, wenn man einen Windows 7 Client (RDP v7.x) verwendet.

Lösung (3 Möglichkeiten)

Schuld ist in der Regel eine Unstimmigkeit bei der Zertifikatsauswahl zwischen Client, Broker und Sitzungshost.

Möglichkeit 1: Sitzungssicherheit für die (in der Regel interne) Verbindung Gateway <-> Sitzungshost auf „niedgrig“ stellen. Dann wird der Fingerprint-Mismatch ignoriert und die Verbindung funktioniert sofort wieder.

Server-Manager > (Links) Remotedesktop-Dienste > Sammlungen/Sammlungsname > Aufgaben/Eigenschaften bearbeiten > Sicherheit > Verschlüsselungsstufe > „niedrig“

Nach einem Klick auf „ok“ klappt das sofort, das Gateway nutzt die Verbindungseinstellungen direkt.

Möglichkeit 2: Die „korrekte“ aber äußerst fummelige Lösung besteht darin, das korrekte RDS-Zertifikat das im RDS-Manager festgelegt wurde auf die RDSH zu verteilen, dort manuell (!) in das Computerkonto zu importieren und den zugehörigen Fingerprint in dem Registry-Schlüssel

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]
"SSLCertificateSHA1Hash"=hex:<fingerprint>

festzulegen. Nach einem Reboot der Hosts funktioniert die Verbindung meistens. Wie das allerdings klappen soll, wenn man auf einer LAN-Seite interne Zertifikate und auf der WAN-Seite externe nutzt konnte uns bishe rnoch niemand erklären …

Möglichkeit 3: Jemand(tm) hat auf dem Gateway die „Authentifizierung auf Netzwerkebene“ eingeschaltet. Das funktioniert sehr gut im internen Netzwerk, nicht aber wenn sich der Client außerhalb desselben befindet. Sprich: diese Sammlung funktioniert fehlerfrei für interne Nutzer, bei einer externen Anmeldung über RDWeb oder RDP am Gateway tritt der Fehler 0x607 auf.

RDS Fehler 0x607

 

Service Pack for ProLiant (SPP) Version 2018.06.0 Download Links

Wie in letzter Zeit leider üblich, verschanzt HPE das nun aktuelle SPP (2018.06.0) mal wieder hinter praktisch undurchdringlichen Support-Login-Portal-Request-Double-OptIn-Secure-Downloadbasket-PayToUpgdate-Überprüfungsklickereien. Ärgerlich wie unnötig vergrault diese Taktik leider nach und nach langjährige Kunden dieses ehemals ausgezeichneten Serverherstellers.

HPE Support-Portal – Download mit Servicevertrag oder gültiger Servergarantie: https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_465ae60442734bce83b19a5b5d

HTTP Direkter Download-Link (noch jedenfalls): http://h30537.www3.hpe.com/prdownloads/P09037_001_spp-2018.06.0-SPP2018060.2018_0618.6 …

Hir ist noch ein direkt mirror Link von einem coolen anderen Admn (thx LooP).

Torrent-Magnet Link magnet:?xt=urn:btih:E1C76DE3A0AD17A9C8822300F4A86752DD631AFC&dn=P09037_001_spp-2018.06.0-SPP2018060.2018_0618.64.iso

Original: magnet:?xt=urn:btih:0316adca126aac09eca8977bec21a65c7966c3a7&dn=HPE Service Pack for ProLiant (SPP) Version 2018.06.0

(Achtung, mgnet.me ist ein Klick-Forwarder für magnet-links, der blöde Spamseiten öffnet. Das ist da, weil WordPress leider immernoch keine „magnet:“ URNs unterstützt). Entschuldigt den Umstand.

 

 

vSphere storage motion „Fehler 195887250. Migration determined a failure by the VMX“

Problem

Eine VM möchte sich nicht via StorageMotion nicht auf ein VVOL verschieben lassen. Im Aktivitätsprotokoll sieht man den Fehler:

Fehler beim Warten auf Daten. Fehler 195887250. Migration determined a failure by the VMX.

und/oder

Migration determined a failure by the VMX. Storage vMotion konnte die Zielfestplatte /vmfs/volumes/vvol:0000000200004004-825d720126911b58/rfc4122.16630ae1-3756-4e47-b932-cdebf5862fd7/SERVERNAME.vmdk nicht erstellen.

und/oder

Erstellen einer oder mehrerer Zielfestplatten fehlgeschlagen. Es ist ein schwerwiegender interner Fehler aufgetreten. Weitere Details finden Sie im Protokoll der virtuellen Maschine.

Spannend zu suchen ist der Fehler 195887250. Der VMKernel meint damit „VMK_MIGRATE_VMX_FAILURE“, oder in ausgeschrieben „Migration determined a failure by the VMX“.

Lösung

Der weitaus häufigste Grund ist relativ einfach: Eine der Festplatten der betroffenen Maschine hat eine größe, die nicht durch 1Mbyte teilbar ist. VVOLs können nur vielfaches von 1Mbyte allokieren, daher schlägt das anlegen der Platte fehl.

Das sieht man auch im vmware.log der betroffenen Maschine:

2018-08-06T11:50:01.264Z| worker-2161938| I125: DISKLIB-LIB_CREATE : CREATE: Creating disk backed by 'vvol'
2018-08-06T11:50:01.265Z| worker-2161938| W115: OBJLIB-VVOLOBJ : VVolObjCheckSize: Requested size (32217052160) is not an MB multiple.
2018-08-06T11:50:01.265Z| worker-2161938| W115: OBJLIB-VVOLOBJ : VVolObjDetermineSizeInMB: Requested size (32217052160) is not a MB multiple.
2018-08-06T11:50:01.265Z| worker-2161938| W115: Mirror: scsi0:0: SVMotionLocalDiskCreate: Failed to create destination disk: The requested size is not a multiple of 1MB
2018-08-06T11:50:01.265Z| worker-2161938| W115: Mirror: scsi0:0: Failed to create disk from /vmfs/volumes/.../NAME.vmdk to /vmfs/volumes/.../NAME.vmdk.

Ärgerlicherweise behauptet die VCSA stattdessen: „No space left on device“

Der zweite Fall der ich einmal untersuchen durfte, war eine „kaputte“ Netzwerkkarte. Alles lief einwandfrei, nur storage motion auf dieser Karte nicht. NIC ausgetauscht, alles wieder fertig.

Bitlocker: „Kann die angegebene Datei nicht finden“

Problem

Der Bitlocker-Assistent läuft fehlerfrei durch, legt den Recovery-Key ab bricht im letzten Schritt mit dieser Meldung ab:

Das System kann die angegebene Datei nicht finden

Lösung

Es hat wahrscheinlich bereits einen fehlgeschlagenen Verschlüsselungsversuch mit angelegtem RecoveryAgentKey gegeben. Dieser muss entfernt (oder umbenannt) werden, bevor der Assistent einen neuen erfolgreich ablegen möchte. Die Datei nennt sich ReAgent.xml.

  • CMD „als Administrator“ starten
    C:\> pushd %windir%\system32\recovery

    C:\> ren ReAgent.xml ReAgent.old

Danach funktioniert der Assistent sofort wieder wie er soll.

Bitlocker: „Der Bitlocker-Verschlüsselungsschlüssel konnte nicht aus dem TPM abgerufen werden“

Problem

Bitlocker lässt sich auf neuen Geräten nicht aktivieren. Nachdem der Einrichtungsassistent den Recovery-Key (scheinbar) erfolgreich abgelegt hat, startet Windows 10 zur Überprüfung neu und meldet:

Der Bitlocker-Verschlüsselungsschlüssel konnte nicht aus dem TPM abgerufen werden

oder auch (noch irritierender):

Der Bitlocker-Verschlüsselungsschlüssel konnte nicht aus der PIN abgerufen werden

Lösung

Sofern die Ausgangsvoraussetzungen (BIOS aktuell, TPM2.0, Windows 10 1803+) gegeben sind, gibt es eine Ursache über die wir recht oft gestolpert sind. die Meldung „… konnte nicht abgerufen werden …“ ist eventuell etwas irreführend.

Die betroffene Maschine wird aller Warscheinlichkeit nach nicht auf einer GPT-Partition gestartet, sondern via BIOS im Legacy-Mode. Das ist praktisch immer bei Notebooks der Fall, die mit Windows 7 in einer windows 10 Upgrade-Version aufgeliefert werden.

Man kann die Bitlocker-Bereitschaft des TPM via Powershell (oder tpm.msc) ablesen:

PS C:\> Get-Tpm | Select-Object tpm* | fl
            TpmPresent : True
            TpmReady : False

Sollte das der Fall sein, hilft entweder die Umstellung im BIOS und eine Windows-Neuinstallation, oder die Umstellung des bestehenden Windows auf GPT-Boot.

Windows 10 ohne Datenverlust auf GPT boot umstellen:

  1. Windows 10 Legacy Mode booten
  2. CMD (als Amin):
    C:\WINDOWS> mbr2gpt /Convert /allowfullOS
  3. Reboot > BIOS > Das BIOS auf „UEFI“ (oder „UEFI only“ oder ähnlich) mit CSM umstellen
  4. Windows startet jetzt von der neuen GPT Partition, die Get-TPM zeigt nun TpmReady:true
  5. Bitlocker kann jetzt aktiviert werden

Das klappt auch in der Recovery-Console, also zum Beispiel wenn man das Bios schon auf UEFI umgestellt hat und Windows nicht mehr freiwillig starten will. Ein Windows-Setup vom USB-Stick und der beherzte Eingriff über die Widerherstellungskonsole helfen sofort weiter.