Microsoft SQL Server (MSSQL) Msg 15150 Cannot Alter The User ‘dbo’

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.

Lösung

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'
GO

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.

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.