Exchange online migration: Error: MigrationPermanentException: Target user ‎’User‎‘ already has a primary mailbox.

Veröffentlicht am von — Keine Kommentare ↓

Wenn man versucht ein Exchange OnPremises Postfache mithilfe von „Postfach verschieben – Zu Exchange Online“ via Migrationsbatch im Exchange Admin Center (EAC) in die Online-Organisation zu verschieben, schlägt der Versuch fehl. Es wird in den Details des Auftrages diese Fehlermeldung angezeigt:

'Error: MigrationPermanentException: Target user ‎'User‎' already has a primary mailbox.'.

Dieses Problem tritt auf, wenn die Attribute „HomeMDB“ und „HomeMTA“ für das Benutzerobjekt in lokalem Active Directory vorhanden sind (und der Inhalt nicht leer ist). Der Auftrag schlägt fehl.

Lösung

Man setzt die Attribute im lokalen AD einfach zurück …

Get-ADUser -Filter {userprincipalname -eq '<[email protected]>'} -properties homemdb,homemta | Set-ADObject -clear homemdb,homemta

… und startet den Auftrag einfach neu. Dann funktioniert das sofort ohne Fehler.

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.

Microsoft SQL Server 15128 „Die Optionen CHECK_POLICY und CHECK_EXPIRATION können nicht auf OFF festgelegt werden, wenn MUST_CHANGE auf ON festgelegt ist“

Veröffentlicht am von — Keine Kommentare ↓

Problem

Nach der Anlage eines neuen SQL-Benutzers möchte der Admin den Haken bei „Benutzer muss das Kennwort bei der nächsten Anmeldung ändern“ entfernen. Das SQL Management Sudio beschwert sich darauf hin aber, das „MUST_CHANGE auf ON“ festgelegt sei:

Die Optionen CHECK_POLICY und CHECK_EXPIRATION können nicht auf OFF festgelegt werden, wenn MUST_CHANGE auf ON festgelegt ist. (Microsoft SQL Server, Fehler: 15128)

Lösung

Das Kennwort muss geändert werden, erst dann kann man die Optionen wieder anpassen. Die „Änderung“ kann aber auch das selbe Kennwort wie vorher sein.

Kurzfassung in T-SQL:

USE master;
ALTER LOGIN <sqluser> WITH PASSWORD = '<kennwort>';
ALTER LOGIN <sqluser> WITH CHECK_EXPIRATION = OFF; // Kennwortablauf
ALTER LOGIN <sqluser> WITH CHECK_POLICY = OFF; // Kennwortrichtlinie

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