Kategorie-Archiv: PowerShell

Löscht man in Microsoft 365 einen Benutzer mit persönlicher Sharepoint-Site, erhält man in Veeam Backup for Office 365 beim sichern diese Fehlermeldung:

Failed to process site: https://<TENANT>-my.sharepoint.com/personal/<USER>. Cannot contact site at the specified URL https://<TENANT>-my.sharepoint.com/personal/<USER>. Access to this Web site has been blocked. Please contact the administrator to resolve this problem.

Der „System Administrator“ kann den gelöschten Nutzer aber nicht mehr sehen, auch in der Veeam-Objektliste nicht.

Das liegt daran, das Microsoft die Site und deren Daten noch 90 Tage lang aufbewahrt, die Site aber den Status „locked“ bekommt. Die Fehlermeldung ist also technisch korrekt, aber wenig hilfreich.

Löschen der Sharepoint-Site

Man kann die Site, sofern nicht mehr benötigt (ist ja gesichert …), einfach „richtig“ löschen, dann verschwindet auch der Fehler sofort.

1. PowerShell „Als Administrator“ öffnen und das SharePoint Online (SPO) Module installieren: Install-Module -Name Microsoft.Online.SharePoint.PowerShell
2. Im Tenant als Global Admin bei SPO-Admin anmelden: Connect-SPOService -Url "https://TENANT-admin.sharepoint.com"
3. Prüfen ob der SPO Nutzer noch vorhanden ist: Get-SPOUser -site "https://TENANT-my.sharepoint.com"
4. Wenn der Benutzer noch da ist, diesen löschen Remove-SPOUser -Site "https://TENANT-my.sharepoint.com" -LoginName <UPN>
5. Jetzt kann man nachsehen, ob die persönliche SharePoint Site von diesem Nutzer noch da ist (was vermutlich der Fall ist). Die genaue URL zur Benutzer-Site kann man aus der Veeam-Fehlermeldung kopieren Get-SPOSite "https://TENANT-my.sharepoint.com/personal/USER" | select *
6. Wenn der Befehl einen Eintrag zurückgibt, auf den „LockState“ schauen. Dieser sollte „Unlock“ sein. Wenn das nicht der Fall ist, Lockstate zurücksetzen: Set-SPOSite "https://<TENANT>-my.sharepoint.com/personal/<USER>" -LockState Unlock
7. Dann kann man die verweiste Site einfach entfernen: Remove-SPOSite "https://TENANT-my.sharepoint.com/personal/USER"

Wir würden uns wünschen, das Veeam hier eingreift. v5.0.1.252 fixt den Fehler leider nicht nicht, Backup-Jobs aus vorhergehenden Versionen stoppen bei diesem Fehler einfach. Wenn der Standard „Ignore this Object“ wäre, wäre das alles halb so schlimm …

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