HPE Alletra 5000/6000 (ehem. NimbleStorage) in GreenLake hinzufügen

Möchte man heute ein HPE Alletra Array der 5 oder 6000er Serie in Betrieb nehmen, muss man es zunächst in HPE GreenLake hinzufügen und mit der Data Services Cloud Console (DSCC) verbinden. Das geht leider nicht (mehr) ganz wie in sämtlichen Dokumentationen beschrieben, daher hier einmal kurz zusammengefasst:

  1. HPE Account erstellen (sofern noch nicht erfolgt) und die Subscription aktivieren (Aktivierungslink und Details sollten bei Array-Bestellung per Mail kommen)
  2. GreenLake Workspace erstellen
  3. Storage -> Data Services in dem GreenLake Workspace „provisionieren“
  4. Oben links im Menü neben dem GreenLake Logo unter Manage Users dem Benutzer via …-Menü Assign Role die Administrator Rolle für Data Services zuweisen
  5. Dann oben unter Devices im Inventory Add Device klicken, Storage Devices als Device Type auswählen, Purchase or Lease auswählen, die AF-XXXXXX Seriennummer als Serial Number und die Modellbezeichnung (z.B. 5010 für eine Alletra 5010) als Product Number verwenden und den Assistenten zuende Klicken.
  6. Unter Device Subscriptions kann man dann in gleicher Art mit dem Subscription Key die Subscription hinzufügen.
  7. Jetzt kann man den Setup-Assistenten des Arrays (aus dem Nimble Setup Manager) zu ende klicken und via Data Services -> Setup Service das Array konfigurieren.

Windows Update Fehler 0x80070643 bei KB5034441 oder KB5034439

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.

Windows Client mehr als 2 SSTP-VPN-Verbindungen

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

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.)

RRAS weniger DHCP-Leases für VPN-Clients verbrauchen

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).

VMware ESXi CDP/LLDP mit standard vSwitch

Da ich ständig vergesse, wie man auf einem VMware standard vSwitch CDP bzw. LLDP konfiguriert um Uplinks von/zu physischen Switches schnell und einfach nachvollziehen zu können:

Per SSH auf den ESXi verbinden und folgenden esxcli Befehl ausführen:

esxcli network vswitch standard set --cdp-status=both -v vSwitch0

--cdp-status=both konfiguriert den vSwitch sowohl für’s empfangen, als auch senden von CDP/LLDP Paketen.

Mit dem Parameter -v <vSwitch> wird der Name des zu konfigurierenden vSwitch angegeben.

Alternativ geht das auch per esxcfg:

esxcfg-vswitch -B both vSwitch0

Das war schon alles, nun kann man ganz einfach auf den physischen Switches die CDP/LLDP Infos abrufen.

Z.B. auf HPE (Aruba) Switches:

show cdp neighbors
show lldp info remote-device

Häufig liest man online, dass es nicht möglich ist (oder zumindest nicht supported) auf standard vSwitches CDP/LLDP zu aktivieren. Über den vSphere Client oder den ESXi Host client geht das auch (soweit ich weiß) tatsächlich nicht. Dort heißt es dann bei den vmnics auch „CDP/LLDP steht auf diesem physischen Netzwerkadapter nicht zur Verfügung.“

Dieser KB-Artikel beschreibt das vorgehen aber auch ganz offiziell.