ugg.li Schnelle Hilfe für schnelle Admins
Nicht immer schön, aber effektiv. Schnelle Hilfe für schnelle Admins.
Wenn man einen SQL Benutzer nicht vom SQL-Server entfernen kann, weil dieser Fehler auftritt („Error: 15150“), hat der Benutzer vermutlich noch ein Datenbankschema im Besitz.
Der Besitz der Datenbank (des Schemas) muss einfach wieder „mit Gewalt“ übergeben werden. Wir machen das in aller Regel für den SA und vergeben dann als dieser neue Berechtigungen.
Use <DATENBANK>
GO
sp_changedbowner 'sa'
GODa 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.
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-ExchangeOnlineWenn ein Benutzer in einer Hybrid-Umgebung erstellt wird und ihm dann eine Exchange Online-Lizenz zugeordnet wird, wird für diesen Benutzer ein Cloud-Postfach erstellt.
Der OnPremises Exchange Server erfährt davon aber nichts, daher ist der Benutzer im lokalen ECP nicht aufzufinden und das Mailrouting („Nachrichtenfluss“) von intern nach extern schlägt fehl.
Wenn man Office 365 zum ersten Mal im Hybridmodus verwendet, erstellt man oft neue Benutzer, indem man einfach ein AD-Konto erstellt und dieses via ADConnect synchronisiert. Danach wird der neue User lizenziert und bekommt ein Postfach. Das erzeugt genau das oben genannte Problem – die OnPremises Exchange Adressliste weiss nichts von dem neuen Objekt und routet keine E-Mails in die Cloud.
Beim Verschieben einer solchen Mailbox zurück nach On Premises tritt dieser Fehler auf:
Error: MigrationPermanentException: Cannot find a recipient that has mailbox GUID ''. --> Cannot find a recipient that has mailbox GUID '<GUID>'
Die „richtige“ Methode zum Bereitstellen neuer Benutzer in Office 365 besteht darin, neue Remotepostfächer zu erstellen.
Man kann einen OnPremises-Benutzer auch nachträglich mit seiner „echten“ Exchange-Online Mailbox verbinden.
Man schaltet einfach die Remote-Mailx im Exchgange ein und trägt die Online-GUID des Postfaches ein.
1. In der OnPremises Exchange PowerShell (EMS) die Remote-Mailbox einschalten:
Enable-RemoteMailbox <USER> –RemoteRoutingAddress <[email protected]>Die RemoteRoutingAddress via AADConnect und dem Hybrid-Agenten sieht immer gleich aus „[email protected]“.
2. Die GUID der Exchange Online Mailbox in der Exchange Online PowerShell abfragen:
Get-Mailbox –Identity <UPN> | fl Identity,ExchangeGUID3. In der OnPremises Exchange PowerShell (EMS) genau diese GUID wieder eintragen:
Set-RemoteMailbox <USER> –ExchangeGUID <GUID>Das funktioniert natürlich in beide Richtungen, also auch für Benutzer-Objekte die in der Exchange Online EMC nicht mehr angezeigt werden. Interessanterweise beschreibt Microsoft in diesem Artikel nur den Weg in die Cloud 😇
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.
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.
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.