Archiv des Autors: snacky

Update: Seit Windows 11 24H2 funktioniert der netsh befehlt leider nicht mehr, inzwischen haben wir aber die zugehörigen Registry-Settings gefunden.

Problem

Als Dienstleister bewegen wir uns ständig in Kunden-VPNs und nutzen sehr gern den Windows-Integrierten SSTP VPN-Client. Leider lässt dieser standardmäßig nur 2 gleichzeitige Verbindungen zu.

Versucht man eine weitere Verbindung herzustellen bekommt man direkt eine Fehlermeldung:

Verbindung mit VPN nicht möglich. Das Modem (oder ein anderes Gerät) wird bereits verwendet oder ist nicht richtig konfiguriert.

Lösung (bis Windows 11 23H2)

Die Anzahl der Miniports kann mittels netsh erhöht werden. Dazu an einer administrativen shell einfach folgendes netsh-Command ausführen:

netsh ras set wanports device="WAN Miniport (SSTP)" maxports=3

Eine Erhöhung auf mehr als 3 Ports ist mittels netsh aber leider auch nicht möglich. (Der Wert für den Parameter „maxports“ ist ungültig.)

Lösung (ab Windows 11 24H2)

Unter Windows 11 (24H2) und Windows Server 2025 funktioniert der netsh befehl leider nicht mehr.. Stattdessen bekommt man nur den wenig hilfreichen Fehler „Die Bindungsnummer ist unzulässig.“ (Englisch: „The binding handle is invalid.“)

Daher muss man das nun manuell hart in der Registry ändern.

Der Key (für SSTP) ist in der Regel:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0008

In den „nachfolgenden“ Keys (0009 usw.) finden sich die Einstellungen für die weiteren Miniports für die anderen VPN-Typen

Hier gibt es den Parameter WanEndpoints (DWORD), das ist der „effektive“ Wert, der bisher via netsh gesetzt werden konnte.

Damit die Änderungen aktiv werden muss der PC neu starten. Der Kerneltreiber lässt sich leider nicht im laufenden Betrieb neu laden.

Eine Erhöhung de Parameter WanEndpoints und MaxWanEndpoints auf mehr als 3 ist leider trotzdem nicht möglich. Beim Neustart werden diese automatisch wieder auf 3 reduziert.

Problem

Die aktuellen Windows Updates KB5034441 (Clients) und KB5034439 (Server) verursachen gerne mal den Fehler 0x80070643.

Der Fehlercode bedeutet im wesentlichen „zu wenig Speicherplatz“. Das bezieht sich in diesem Fall allerdings nicht auf die Platte bzw. Windows-Partition, sondern die Wiederherstellungspartition („WinRE“).

Auf Clients ist diese in der Regel zu klein wenn der Fehler auftritt, auf Servern kann es auch schonmal vorkommen, dass die Partition gar nicht existiert.

Sofern ganz sicher keine Recoveryumgebung benötigt wird, kann das Update im Prinzip einfach ignoriert werden (Zitat aus den MS KB-Artikeln: „HINWEIS: Wenn Ihr ausgeführter PC nicht über eine WinRE-Wiederherstellungspartition verfügt, benötigen Sie dieses Update nicht.“)

Sollte (sicherheitshalber) doch eine Recoverypartition erwünscht sein, hier die Kurzanleitung zum (Neu-)Erstellen und Vergrößern:

Lösung:

zunächst eine Konsole als Admin starten.

WinRE Status prüfen und ggfs. deaktivieren (wenn vorher „Enabled“):

C:\> reagentc /info
C:\> reagentc /disable

Ggfs. vorhandene Recoverypartition löschen und Windows-Partition verkleinern:

C:> diskpart
DISKPART> list disk
DISKPART> sel disk <OS Disk Nummer, i.d.R. 0>
DISKPART> list part
DISKPART> sel part <OS Partitionsnummer, i.d.R. 3>
DISKPART> shrink desired=250 minimum=250
DISKPART> sel part <WinRE Partitionsnummer, i.d.R. 4>
DISKPART> del part override

Neue Recoverypartition erstellen:

DISKPART> list disk
DISKPART> sel disk <OS Disk Nummer, i.d.R. 0>

# nur für GPT-Disks:
DISKPART> create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
DISKPART> gpt attributes =0x8000000000000001

# nur für MBR-Disks:
DISKPART> create partition primary id=27

# Partition formatieren:
DISKPART> format quick fs=ntfs label=”Windows RE tools”
DISKPART> exit

Sofern es vorher bereits eine Recoverypartition gab, kann diese nun einfach wieder aktiviert werden:

C:> reagentc /enable

Sofern es vorher keine aktive Recoverypartition gab, schlägt das fehl. Dann fehlt vermutlich auch das RE-Image in C:\Windows\System32\Recovery\WinRe.wim (reagentc /enable bzw. /disable verschiebt das Image zwischen der Partition und der Datei hin und her)

Dann muss man sich diese vom Installationsmedium (ISO) holen. Das geht am einfachsten per 7zip, das kann die ISO und die darin enthaltenen install.wim Files einfach öffnen. Aus dem Pfad \sources\install.wim\1\Windows\System32\Recovery\ im ISO kann die WinRe.wim dann nach C:\Windows\System32\Recovery\ kopiert werden.

Danach sollte sich das WinRE mittels reagentc /enable dann korrekt aktivieren lassen (WinRE.wim wird wieder aus System32\Recovery\ auf die Recoverypartition verschoben)

Danach sollte sich das Update dann problemlos installieren lassen.

Problem:

In einem Netz ist ein Windows Routing- und RAS-Server (RRAS) für den VPN-Zugriff konfiguriert, welcher für die IP-Adressvergabe an VPN-Clients den DHCP-Server im Netz nutzt.

Standardmäßig werden beim Start des RRAS-Dienstes dafür 10 Adressen im DHCP „reserviert“.

In kleineren Umgebungen sind das eventuell bereits zu viele und der DHCP-Bereich wird mit unnötigen Leases belastet.

Lösung:

Der RRAS holt sich DHCP-Adressen in Blöcken der „AddressPoolSize“ – Standardmäßig 10. Diese Blockgröße lässt sich mittels folgendem Registry-Eintrag auf dem RRAS-Server einfach Konfigurieren:

Pfad: HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ip
Wertname: InitialAddressPoolSize (REG_DWORD)

Danach muss der Routing und RAS Dienst („RemoteAccess“) einmal neu gestartet und bereits vorhandene Leases bei bedarf manuell aus dem DHCP entfernt werden.

Die Größe der Adress-Blöcke lässt sich somit beliebig verkleinern (oder vergrößern).