Autoren-Archiv: weed

vCenter 6.7/7 Host hinzufügen schlägt fehl „Unable to push CA certificates and CRLs to host“

Veröffentlicht am von — Keine Kommentare ↓

Das Hinzufügen eines neuen Hosts (ab vSphere ESX 6.7 U3) ins vCenter schlägt mit der Meldung fehl:

Ein allgemeiner Systemfehler ist aufgetreten: Unable to push CA certificates and CRLs to host <HOSTNAME>

Oder auch auf English:

Unable to push CA certificates and CRLs to host <HOST>

Lösung

Mit vSphere 6.7U3 wurde die Zertifikatssicherheit verschärft. Die Fehlermeldung ist (indirekt) darauf zurückzuführen, dass selbstsignierte Zertifikate (oder Zertifikate ohne vertraute CA) aus dem TRUSTED_ROOTS Speicher des vCenters Server beim Hinzufügen (oder Verbinden) den ESXi-Host übertragen werden sollen. Ab U3 lässt der Host das aber nicht mehr zu.

Man kann diese Verhalten aber zum Glück ändern:

  1. vSphere Host-Client des neuen hosts öffnen
  2. Verwalten -> System -> Erweiterte Einstellungen
  3. Config.HostAgent.ssl.keyStore.allowSelfSigned auf „true“ setzen

SSTP Fehler 0×80092013 „Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war“

Veröffentlicht am von — Keine Kommentare ↓

Manche Windows 10 VPN-Clients mit SSTP-Verbindungen scheinen nach langem problemlosem arbeiten plötzlich ihre Zertifikatsanbieterlistensperrfunktion zu „verlieren“. Die Ursache kennen wir noch nicht.

Die VPN-Einwahl via SSTP Endet mit der Meldung „Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war“.

Lösung

Eine wirkliche Lösung ist das hier nicht, aber wenn man die Verbindung dringend benötigt, kann man Windows 10 dazu überreden, die CRL nicht abzufragen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters]
"NoCertRevocationCheck"=dword:00000001

Dann funktioniert die Verbindung in aller Regel sofort wieder.

Install-Module fehlt: Die Benennung „Install-Module“ wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei …

Veröffentlicht am von — 2 Kommentare ↓

Als Admin ist man es gewohnt, mit dem PowerShell Cmdlet Install-Module erforderliche Module nachzuinstallieren. Doch das schlägt auf älteren Systemene mit PowerShell 4 mit fehl:

install-module : Die Benennung "install-module" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdateio der eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.
 install-module
CategoryInfo : ObjectNotFound: (install-module:String) [], CommandNotFoundException: FullyQualifiedErrorId : CommandNotFoundException

Die PowerShell Version lässt sich schnell prüfen:

PS C:\> $PSVersionTable.PSVersion
PS C:\Users\.admin> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      -1     -1

Lösung

Unter Server 2012R2 gibt es die PowerShell 5, die NuGet als Paketprovider mitbringt, noch nicht automatisch. Also muss man beides manuell installieren.

  1. Download und Installation „Windows Management Framework 5.1“: https://www.microsoft.com/en-us/download/details.aspx?id=54616 (Für „meinen“ Server 2012R2 war das das Paket Win8.1AndW2K12R2-KB3191564-x64.msu)
  2. TLS 1.2 als „Strong Crypto“ aktivieren (nein, 2012R2 kannte das noch nicht, das sprach noch SSL3). Reboot nicht vergessen!
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

… und am besten auch direkt für 64bit:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
  1. NuGet Paketprovider installieren:
[PS] C:\>Install-Module PowershellGet -Force

Mailbox von Exchange Online zurück nach Exchange Server on Premises verschieben („Offboarding“)

Veröffentlicht am von — Keine Kommentare ↓

Es gibtr zwar einen schicken Assistenten der beim Cloud-OnBoarding hilft, aber natürlich kein GUI das beim zurückverschieben von Mailboxen hilft.

Lösung

Auf an die Admin-PowerShell und einen Offboarding-Auftrag erstellen:

# Exchange Online PowerShell Modul importieren
PS C:\> Import-Module ExchangeOnlineManagement

# Exchange Online Credentials in eine Variable legen
PS C:\> $onlinecred = Get-Credential

# Exchange Online PowerShell Verbindug herstellen
PS C:\> Connect-ExchangeOnline -Credential $onlinecred

# On Premises (lokaler Exchange Server) Credentials angeben
PS C:\> $opcred = Get-Credential

# Neuen Move-Request erstellen
PS C:\> Get-Mailbox -Identity <MAILBOXNAME>| New-MoveRequest -Outbound -RemoteTargetDatabase "<LOKALE DATENBANK NAME>" -RemoteHostName <EXCHANGE SERVER FQDN> -RemoteCredential $opcred -TargetDeliveryDomain <DOMAIN>

Outlook Suche in Freigegeben Ordnern liefert keine Ergebnisse (Suche funktioniert nicht in „fremden“ Ordnern)

Veröffentlicht am von — 2 Kommentare ↓

Die Outlook-Suche verhält sich ja häufiger etwas ungewöhnlich, das man aber sei einer Weile praktisch nicht mehr freigegebene Ordnern (Nicht freigegebene Postfächer) von anderen Nutzern suchen kann, ist merh als ärgerlich. Grade in Zeiten von Exchange Online ist das sehr ärgerlich.

Schuld ist Outlook in Verbindunge mit dem Windows Indexdienst. Freigegebene Ordner werden standartmäßig wie freigegebene Postfächer heruntergeladen; diese landen somit im Index. Leider beauftragt Outllook bei der Sucher nur noch „Eigenes Postfach“ und liefer somit bei freigegebenen Ordnern nur leere Ergebnismengen zurück.

Woraround

Man kann Exchange dazu zwingen, die Serverseitige Suche zu verwenden. Der Zugriff auf Microsoft 365 Exchange Online-Postfächer ist dann zwar etwas langsamer, dafür liefert die Outlook-Suche plötzliche wieder korrekte Ergebnisse. Bonus: Neu vergebene Berechtigungen greifen nun ebenfalls sofort.

Das geht unter den E-Mail Konten > E-Mail > Postfach auswähen und oben „Ändern“ > Weitere Einstellungen > Erweitert > Freigegebene Ordner herunterladen AUS schalten.