Microsoft Office 365 E-Mail Alias Domain für alle Benutzer hinzufügen

Da es in Microsoft Office 365 leider keine „Generierungsrichtlinie“ gibt, oder zumindest keine auf die man schreibenden Zugriff hat, muss man für neue Alias-Domains jeden Benutzer einzeln anfassen. Jedem Postfach müssen die neuen E-Mailadressen einzeln hinzugefügt werden. Bei vielen Postfächern (oder Domains) ein sehr ermüdender Job.

Das ist auch erst einmal so, denn Microsoft scheint der Meinung, das eine E-Mail Domain für immer genug sei. Oder zumindest Änderungen daran selten.

Natürlich kommen Namens- oder Domainänderungen in der Realität aber ständig vor, auch für (neue) Alias-Domains. Der findige Admin macht das natürlich nicht mehr manuell im ECP, sondern an der PowerShell.

Neuen Domain E-Mail Alias mit der PowerShell hinzufügen

Ich nutze ein kleines „AddEMailAliasDomain“ Script. Die Domain example.com ist die „alte“ und richtige Absende-Adresse, beispiel.de ist die neue hinzuzufügende. Es wird nach der „alten“ Domain gefiltert, damit keine anderslautenden Postfächer verändert werden.

Get-Mailbox -ResultSize Unlimited -Filter { EmailAddresses -like '*@EXAMPLE.COM' } | Select-Object Identity,EmailAddresses | ForEach-Object {
    $proxyaddresses = $_.EmailAddresses | Where-Object { $_ -like 'smtp:*@EXAMPLEcom' }
    foreach ($proxyaddress in $proxyaddresses) {
        $newaddress = ($proxyaddress -split ':')[1] -replace '@EXAMPLE.COM','@beispiel.de'
        Set-Mailbox -Identity $_.Identity -EmailAddresses @{Add="smtp:$newaddress"}
    }
}

Die PowerShell Module für die Exchange Online Powershell muss man sich natürlich vorher importiert und verbunden haben:

PS C:\> Import-Module ExchangeOnlineManagement
PS C:\> Connect-ExchangeOnline

Alle deaktivierten Benutzer aus (bestimmten) ActiveDirectory Gruppen entfernen

Ich musste grade eine ganze Menge deaktivierter ActiveDirectory Benutzer aus allen Gruppen entfernen. Andernfalls hätten diese im AADConnect Synchronisationsfehler ausgelöst, da hier deaktivierte Benutzer-Objekte nicht synchronisiert werden.

Mein PowerShell Script das das sehr erfolgreich übernommen hat sieht so aus:

# Durch die OU laufen und deaktivierte User einsammeln ...
foreach ($username in (Get-ADUser -Filter {enabled -eq $false} -SearchBase "OU=<HIER SUCHEN>,DC=<DOMAIN>,DC=<TLD>")) {
 
# ... deren Group-Memberships holen ...
$groups = Get-ADPrincipalGroupMembership $username;
 
# ... durch die Gruppen laufen ...
foreach ($group in $groups) {
 
    # ... wenn Gruppenname stimmt (z.B. "VPN*") ...
    if ($group.name -Like "<NAME>") {
 
        # ... User entfernen
        Remove-ADGroupMember -Identity $group.name -Member $username.SamAccountName -Confirm:$false;
 
        # Ausgabe
        write-host "Habe" $username "von" $group.name "entfernt";
    }
}
}

Das funktioniert natürlich nicht nur mit Sicherheitsgruppen, sondern auch mit Verteilerlisten.

Die Suche nach dem/den Gruppennamen kann man in der Zeile $group.name -Like "Domänen-*" anpassen; hier tun es natürlich auch die anderen Operatoren wie -eq oder -neq.

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

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“

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“

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.