Office 365 Tenant löschen
Ein Tenant ist schnell angelegt aber auch die Löschung ist möglich. Manchmal ist dies sogar erforderlich wenn Sie z.B. den Tenant mit dem gleichen Namen in einem anderen Land neu anlegen wollen. Vielleicht wollten Sie aber auch einfach aufräumen und sicherstellen, dass die Daten nicht in falsche Hände komme.
Achtung: Der Löschprozess ist nicht umkehrbar und es gibt keine Backups, um die Daten seitens Microsoft wieder herzustellen. Prüfen Sie bei jedem Schritt genau, dass Sie der richtige Administrator im richtigen Tenant sind.
Die Reihenfolge der Checkliste kann variieren und neue Schritte könnten mittlerweile dazu gekommen sein. Ich lösche ja nicht täglich Tenants bei Kunden. Feedback und Korrekturen werden gerne genommen.
Aktion | Erledigt |
---|---|
Daten ExportMit dem Löschen geht der Zugriff auf alle Daten verloren. Kontrollieren Sie mehrfach, dass Sie alle noch erforderlichen Daten und Informationen außerhalb des Tenant gesichert haben. |
![]() |
Anmeldung als Global AdminUm einen Tenant zu entfernen, müssen sie "Globaler Administrator" des Tenants sein. Einige Dinge können per Browser im Office 365 Admin-Center oder im Azure AdminPortal erfolgen. Einige Aktionen gehen aber schnell per PowerShell. Laden und verbinden Sie sich daher mit der AzureAD-PowerShell und der MSOnline-PowerShell Install-Module -Name AzureAD Connect-AzureAD Install-Module -Name Connect-MsolService Connect-MsolService |
![]() |
MX-RecordSobald sie in den nächsten Schritten die Benutzer und damit die Postfächer entfernen, können eingehende Mails nicht mehr zugestellt werden. Sie sollten daher den MX-Record entweder auf 127.0.0.1 umstellen, damit Absender nichts mehr zustellen oder irgendwo anders ein temporäres Mailsystem aufbauen, welches die Mails während der Unterbrechung annimmt und für einen späteren Versand vorhält, bis das richtige Zielsystem samt der Empfänger wieder online ist. Tipp: Exportieren Sie mit "Get-Recipient" zur Sicherheit alle Empfänger für einen späteren Abgleich. get-recipient ` -resultsize unlimited ` | export-csv exorecipients.csv get-recipient ` -resultsize unlimited ` | export-clixml exorecipients.xml Sie wissen nie, wie diese Information später nicht doch noch mal erforderlich ist. |
![]() |
Benutzer entfernenAlle Benutzer mit Ausnahme des letzten globalen Administrators, mit dem sie arbeiten, müssen entfernt werden. "CloudOnly"-Anwender können Sie einfach so löschen. Objekte, die durch ADSync angelegt werden, sollten Sie über ADSync löschen lassen. Konfigurieren Sie den bestehenden ADSync einfach so um, dass Sie quasi alle OUs aus dem Filterkriterium entfernen. Beim nächsten Lauf wird ADSync dann all diese Objekte in den Papierkorb verschieben. Wenn Sie keinen ADSync mehr lokal haben, dann entfernt der nächste Schritt die Objekte, was aber etwas länger dauert. |
![]() |
DirSync abschaltenSolange ADSync im Tenant noch konfiguriert ist, kann der Tenant nicht deinstalliert werden. Folgende Zeile schalten die Konfiguration in Office 365 ab. # DirSync abschalten Set-MsolDirSyncEnabled -EnableDirSync $false # Status abfragen (Get-MSOLCompanyInformation).DirectorySynchronizationEnabled Es kann angeblich bis zu 72h dauern, bis die User dann von "DirSync" auf "CloudOnly" wechseln. Danach können Sie die Benutzer dann über das Azure Portal, das Office 365 Portal oder PowerShell entfernen. Manchmal kann es etwas dauern, bis die alle Benutzer entfernt sind. # Benutzer forciert loeschen Get-MsolUser | Remove-MsolUser -Force # Benutzer aus dem Papierkorb entfernen. Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin -Force Dieser Schritt entfernt aber nicht die ADSync-Installation und Einrichtungen in ihrem lokalen Active Directory. Wenn Sie später das lokale Active Directory erneut mit ADSync verbinden wollen, dann sollten Sie dort auch ADSync deinstallieren und bei den Objekten den SourceAnchor entfernen |
![]() |
MFA deaktivierenWenn Sie eigene MFA-Provider eingebunden haben, dann müssen diese vorab entfernt werden |
![]() |
LizenzenNun sind alle Benutzer zwar entfernt aber sie haben ja noch Lizenzen im Tenant, die gelöscht werden müssen. Damit verhindert Microsoft, dass Sie einen Tenant mit aktiven Lizenzen irrtümlich löschen. Ziel ist es, dass der Status auf "Deprovisioniert" steht. Office 36 kennt hier vier Stati.
Als Administrator müssen Sie im Bereich der Lizenzen daher zwei Schritte durchführen:
Für die Entfernung des Tenants müssen alle Lizenzen im Status "Deprovisioned" sein.
|
![]() |
Enterprise AppsWenn der Admin im Tenant zusätzliche Applikationen eingerichtet hat, müssen diese auch entfernt werden. Das geht per AzureAD Portal oder PowerShell: $ObjIds = (Get-AzureADServicePrincipal).ObjectId For ($i=0; $i -lt $ObjIds.Length; $i++){ Remove-AzureADServicePrincipal -objectid $ObjIds[$i] } |
![]() |
Azure Subscription umziehen/löschenManchmal nutzt eine Firma nicht nur "Office 365" sondern es gibt noch Azure Subscriptions, die mit dem Tenant verbunden sind. Wenn Sie weiterhin Zugriff auf die Subscriptions behalten möchten, müssen Sie diese an einen anderen Tenant binden.
Natürlich können Sie eine Subscription auch löschen:
|
|
Tenant im AzureAD LöschenDer finale Schritt erfolgt im Azure Portal auf dem Verzeichnis. Hier wird auch noch einmal geprüft, ob die Voraussetzungen erfüllt sind:
Vor dem finalen Löschen kommt noch einmal eine Überprüfung. In dem Beispiel wurden wohl ein paar Schritte übersprungen.
Der "Delete"-Button ist solange nicht aktiviert. |
![]() |
Expedited DeletionNormalerweise können gelöschte Daten bis zu 180 Tage (nicht garantiert!) wieder hergestellt werden. Über die Funktion "Expedited Deletion" können Sie erzwingen, dass die Daten nach spätestens drei Tagen gelöscht. |
![]() |
Tenant FreigabeMit der Löschung der Daten wird der Tenant selbst aber noch nicht gelöscht. Der Name "<tenantname>.onmicrosoft.com" wird erst dann freigegeben, wenn sich 180 Tage niemand mehr am Tenant anmeldet. Nach den oben beschrieben Schritten gibt es nur noch den einen "Global Administrator". Sobald sich dieser Administrator auch nur anmeldet, wird der Counter auf 0 zurück gestellt und die 180 Tage starten von Beginn an. Ich denke das ist ein Schutz, damit kein Tenantname nach zur kurzer Zeit wieder verwendet werden kann. Der Name kommt ja durchaus in URLs vor (z.B. SharePoint und OneDrive), so dass jemand beim Klick auf alte Links damit Missbrauch treiben könnte. |
![]() |
Retention Time
"Halt Halt", höre ich da rufen. Es gibt ja in Exchange, SharePoint und anderen Diensten entsprechende "Retention"-Regeln. Ein Administrator kann z.B. einstellen, dass auch durch den Benutzer gelöschte Mails dennoch wiederherstellbar sind. Es gibt ja auch noch die Compliance-Vorschriften, nach denen Informationen für eine gewisse Zeit aufbewahrt werden müssen. (Stichwort 10 Jahre für buchhaltungsrelevante Vorgänge.
Machen wie es kurz: Ohne Lizenz gibt es auch keine Retention/Compliance. Das dokumentiert Microsoft auch:
Q: Is data immutability maintained after service ends? (In other words, are
mailboxes placed on In-Place Hold or Litigation Hold retained after service ends?)
A: No. Microsoft’s responsibility as a service provider ends after your service
ends, which is when you stop being a customer/subscriber of the service. As
noted above, data is permanently deleted when your tenant account enters the
deprovisioning state, within a reasonable time after 120 days of end of
subscription, or within 3 days if you request expedited deprovisioning.
Mailboxes placed on In-Place Hold or Litigation Hold, including inactive
mailboxes, are also deleted as part of deprovisioning.
Quelle:
https://techcommunity.microsoft.com/t5/exchange-team-blog/data-immutability-and-office-365-tenant-lifecycle/ba-p/604610
Das bedeutet damit auch, dass eine erloschene oder insolvente Firma, die ihre monatlichen Office 365-Rechnungen nicht mehr bezahlt, sehr schnell ohne Daten da steht. Wobei das beim "Papierbüro" in der Regel auch nicht anders ist. Es dürfte regelmäßig ein Herausforderung sein ,wo die Ordner und Unterlagen mit den Rechnungen etc. einer erloschenen Firma deponiert sind, wenn niemand mehr dafür bezahlt.
Das Thema kennen Sie aber auch von verlassenen Kliniken, in denen Patientendaten ungesichert zurückbleiben.
- SZ: 3. Juni 2020, 18:46 Uhr Verlassenes
Krankenhaus in Büren: Hunderte
Patientenakten, frei zugänglich
https://www.sueddeutsche.de/panorama/bueren-krankenhaus-lost-place-patientenakten-youtuber-1.4926461 - Spiegel 30.6.2016 Promi-Krankenakten in
verlassener Klinik gefunden
https://www.spiegel.de/panorama/leute/klausjuergen-wussow-krankenakten-am-starnberger-see-gefunden-a-1100670.html
Microsoft lässt es da etwas gemächlicher angehen und hat verschiedene Zeiten veröffentlicht, die nach "aktiver Löschung" und "passive Löschung" unterscheidet. Passive Löschung tritt ein, wenn der Tenant gelöscht wurde. Die aktiven Löschungen betreffen Informationen, die ein Administrator oder der Benutzer selbst gelöscht hat oder der Benutzer, das Team, die SharedMailbox etc. gelöscht wurde.
Die genannten Zahlen sind "bis zu"-Intervalle, d.h. Microsoft stellt sicher, dass die Daten spätestens nach dieser Zeit gelöscht sind. Es könnte aber auch früher passieren.
Datenbestand | Aktiv | Passiv (Tenant gelöscht) | Subscription Ende | Expedited Deletion |
---|---|---|---|---|
Vom Anwender erzeugte Inhalte
|
30 Tage |
bis zu 180 Tage |
90 Tage 180 Tage |
3 Tage |
Metadaten z.B. des AzureADIrgendwo müssen ja die Identitäten und Anmeldeinformationen, MFA-Daten etc. liegen.
|
180 Tage |
180 Tage |
180 Tage |
3 Tage |
Interne DatenDaten, die Microsoft intern selbst verwaltet und verwendet.
|
30 Tage |
180 Tage |
180 Tage |
3 Tage |
Andere Werte kommen zum Tragen, wenn es um Lizenzen geht.
If a paid subscription ends or is
terminated, Microsoft retains customer data stored in
Microsoft 365 in a limited-function account for 90 days to
enable the subscriber to extract the data. After the 90-day
retention period ends, Microsoft disables the account and
deletes the customer data. No more than 180 days after
expiration or termination of a subscription to Microsoft
365, Microsoft disables the account and deletes all customer
data from the account. Once the maximum retention period for
any data has elapsed, the data is rendered commercially
unrecoverable.
Quelle:
https://docs.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-data-retention-deletion-and-destruction-overview?view=o365-worldwide
Sonderfall "Expedited Deletion"
"Bis zu 180 Tage" kann sehr lang sein, wenn es Gründe für eine aktive Löschung gibt. In dem Fall können Sie auf alle Optionen zum "Undelete" verzichten und eine "Expedited Deletion" anfordern. Über ein Microsoft Support-Ticket im Tenant können Sie einen "Lockout-Code" anfordern, der dann bei der Löschung einzugeben ist. In dem Fall wird Microsoft alle Daten des Tenant nach spätestens 3 Tagen gelöscht haben. Bedenken Sie aber, dass so eine Aktion natürlich Ermittlungsbehörden nicht verborgen bleiben dürfte und nicht immer ohne Folgen bleibt.
Aus meiner Sicht gibt es aber einen Grund, warum so eine "Expedited Deletion" aktiviert werden könnte. Stellen Sie sich vor, eine Tochter ihrer Firma in einem anderen Land hat bereits einen Tenant registriert, den sie als produktiven Tenant haben wollten. Damit ist aber nicht nur die Default Sprache vielleicht unpassend sondern die "Office 365 Region" dürfte sicher nicht passend sein. Dann könnte es wirklich eine Option sein, den Tenant leer zu räumen, zu löschen und dann neu einzurichten.
- Office 365 Tenant Region ändern
- Office 365 Region
- Data Retention, Deletion, and Destruction in Microsoft
365
https://docs.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-data-retention-deletion-and-destruction-overview?view=o365-worldwide - Change how long permanently deleted items are kept for an
Exchange Online mailbox
https://docs.microsoft.com/en-us/exchange/recipients-in-exchange-online/manage-user-mailboxes/change-deleted-item-retention - Learn about retention policies and retention labels
https://docs.microsoft.com/de-de/microsoft-365/compliance/retention?view=o365-worldwide - Data immutability and Office 365 tenant lifecycle
https://techcommunity.microsoft.com/t5/exchange-team-blog/data-immutability-and-office-365-tenant-lifecycle/ba-p/604610
Weitere Links
- Office 365 Region
- Office 365 Domain Umzug/Löschen
- Delete a tenant in Azure Active
Directory
https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-delete-howto#prepare-the-directory - Walkthrough of Deleting an Azure AD
Tenant
https://docs.microsoft.com/en-us/archive/blogs/ericgolpe/walkthrough-of-deleting-an-azure-ad-tenant - Can't delete a directory through the
Azure Management Portal
https://docs.microsoft.com/en-gb/troubleshoot/azure/active-directory/cannot-delete-directory-azure-portal - How to delete an Azure Active Directory
(ADD) Tenant
https://blog.nicholasrogoff.com/2017/01/20/how-to-delete-an-azure-active-directory-add-tenant/ - Removing an Office 365 Tenancy
https://www.tecfused.com/2018/10/removing-an-office-365-tenancy/ - Tenant deletion now available
https://techcommunity.microsoft.com/t5/azure-active-directory-identity/tenant-deletion-now-available/ba-p/243706 - In wich geographical region is my office
36 tenant hosted?
https://www.markwilson.co.uk/blog/2015/07/in-which-geographical-region-is-my-office-365-tenant-located.htm - Deleting an Azure AD Tenant
https://samcogan.com/deleting-an-azure-ad-tenant/ - Office 365 – You can not change the
country accociated with your tenant
https://www.hametbenoit.info/2013/04/27/office-365-you-can-not-change-the-country-associated-with-your-tenant/