Kategorie-Archiv: Microsoft 365

Exchange MaiboxMoveRequest schlägt fehl MapiExceptionFolderHierarchyChildrenCountQuotaExceeded: Unable to create folder. ‎0x80004005

Veröffentlicht am von — Keine Kommentare ↓

Bei der Migration einer Mailbox nach Exchange Online schlägt die Sychronistion mit diesem Fehler fehl:

MigrationMRSPermanentException: Error: Could not create folder 2288. –> MapiExceptionFolderHierarchyChildrenCountQuotaExceeded: Unable to create folder. ‎(hr=0x80004005, ec=1253)‎

Exchange Online hat mehrere Limits. Zum Beispiel eine Verschachtelungstiefe von 300 Ordnern und 1000 Ordner pro IPM_SUBTREE Ordner. Aber so viele Ordner gibt es doch gar nicht?

Ordner in Exchange Online (richtig) zählen

Die Anzahl der Ordner pro Postfach lassen sich ganz einfach zählen:

Get-MailboxFolderStatistics | Measure

Aber das ist nicht sie ganze Warheit; via MAPI lassen sich Ordner auch außerhalb der in Outlook sichtbaren Postfachstruktur anlegen. Beispielweise erstellt jedes ActiveSync-Gerät einene eigenen Ordner für seine Konfiguration und Synchronisationsdaten. Wirklich alle Ordner zählt:

Get-MailboxFolderStatistics -FolderScope NonIpmRoot | Measure

Möglicherweise sehen die Zahlen hier auf einmal völlig anders aus. Vor allem iPhone-Geräte scheinen relativ anfällig für die (unbewusste) Erzeugung übermäßig große Ordnerzahlen zu sein. Wir haben hier Wert zwischen 50.000 und 120.000 gesehen – was auch beim zählen wahnsinnig lange dauert. „Get-MailboxFolderStatistics“ läuft hier auch mal drei Stunden lang.

Nicht-Sichtbare Exchange Ordner entfernen

In unsere Fällen war es am einfachsten, die mobilen Geräte einfach alle von dem betroffenen Account zu entfernen (dabei werden alle automatisch erstellten Ordner entfernt) und nach der Migration neu zu verbinden.

Get-MobileDevice -Mailbox <NAME> | Remove-MobileDevice

Exchange OnPremises Ressourcen (Ressourcen-Postfächer wie Räume) nach Exchange Online migrieren

Veröffentlicht am von — Keine Kommentare ↓

Benutzer-Postfächer kann man im Exchange Control Panel (ECP) durch einen schnellen Klick auf „Postfach verschieben > Zu Exchange Online“ recht einfach verschieben.

Leider hat Microsoft noch keine solche Funktion für Ressourcenmailboxen eingebaut. Also muss man Räume und Geräte manuell an der PowerShell verschieben. Das geht allerdings relativ problemlos.

Raum- oder Gerätepostfächer zu Exchange online verschieben

Zuerst eine Verbindung zur Exchange Online PowerShell herstellen:

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

Dann ein Credential-Objekt für die lokale Domäne erstellen:

PS C:\> $OnPremCred = Get-Credential

Und schliesslich die Migrationsaufträge (MoveRequests) erstellen:

PS C:\> New-MoveRequest -Identity "<Name der Ressource>" -Remote -RemoteHostName <Name Exchange> -TargetDeliveryDomain <Tenant Name>.onmicrosoft.com -RemoteCredential $OnPremCred

Mit den üblichen Tools wie Get-MoveRequest lässt sich der Auftrag dann verfolgen. Im GUI sieht man diese allerdings leider nicht – dafür freifen Parameter wie das BadItemLimit und so weiter.

Ein im lokalen ActiveDirectory gelöschter Benutzer wird nicht von AADConnect in Microsoft 365 gelöscht

Veröffentlicht am von — Keine Kommentare ↓

Es tritt manchmal das Problem auf, das ein gelöschtes AD-Objekt (Benutzer) aus dem lokalen („OnPremises“) ActiveDirectory (EXAMPLE.LOCAL) nicht in das AzureAD synchronisiert wird, also dort nicht ebenfalls entfernt wird. „Normalerweise“ sollte das aber der Fall sein.

Das Objekt ist in diesem Fall weiterhin in Microsoft 365 sichtbar, kann aber auch im Portal (https://portal.office.com) nicht entfernt werde. Das passiert dann, wenn die Verzeichnissynchronisierung ein bestimmtes Cloud-Objekt „unerwartet“ nicht löschen kann und führt zu einem verwaisten Azure AD-Objekt, das von einem Administrator direkt entfernt werden muss.

Lösung (Windows 10+)

  • Wenn nicht vorhanden, AzureAD/MSOnline PowerShell Modul installieren
    Install-Module -Name MSOnline
  • Mit dem AzureAD (Microsoft 365 Tenant) als „Globaler Administrator“ verbinden
    Connect-MsolService
  • Objekt suchen mit
    Get-MsolUser -UserPrincipalName [email protected]
    … oder mit
    Get-MsolUser -SearchString "nam"
  • Wenn gefunden, Objekt(e) entfernen
    Get-MsolUser -UserPrincipalName [email protected] | Remove-MsolUser

Office 365 auf Windows (RDS) Server ist plötzlich „nicht lizenziert“ und das Office Anmeldefenster verschwindet einfach

Veröffentlicht am von — 5 Kommentare ↓

Problem

Office 365 wurde korrekt und mit aktiviertem „Shared Computer Activation“ installiert. Nach einer Weile berichten Benutzer von „unlizenziertem Office“ und das man seine Lizenz nicht mehr aktivieren könne.

Das Anmelde-Feld erscheint zwar, man kann hier seine E-Mail Adresse auch eingebene, aber dann verschwindet es wieder und Office wird nicht aktiviert. Es gibt keine Fehler und sogar die Ereignisanzeige bleibt leer.

Lösung

Standardmäßig verwendet Microsoft Office 365 ProPlus (seit Version 2016) die Frameworkbasierte Authentifizierung der Azure Active Directory-Authentifizierungsbibliothek („ADAL“). Nach der Umstellung auf die neue „modern Authentication“ via „WAM“ passieren aber leider häufiger mal Fehler.

Es hilft zuverlässig, WAM und ADAL einfach zu überspringen:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
"DisableADALatopWAMOverride"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
"DisableAADWAM"=dword:00000001

Das geht natürlich auch per Gruppenrichtlinie (GPO) im Benutzerkontext (Benutzerkonfiguration) und benötigt nicht mal einen reboot.

Erlärung

Ab Build 16.0.7967 verwendet Office nun den „moderneren“ Web Account Manager („WAM“) für Office-Anmelde-Workflows. Es war auch mal wieder Zeit für neue TLAs. Selbiger bringt, wie immer, einige spannende neue „Eigenheiten“ mit.

WAM sucht beim Start nach den neuen Voraussetzungen für den Identity Providers (IdP), die beim Zusammenführen von Office 365 Konten verwendet werden (IdP IDReg_Match). Für synchronisierte Domänen an sich ein segen – es funktioniert nun auch der lokale UPN. Theoretisch.

Wenn Windows 10 oder Windows Server 2019 mit einem lokalen Active Directory verbunden ist, muss der IdP für WAM/O365 nun aber das sogenannte „WS-Trust-Protokoll“ (respektive Flag) unterstützen. Dies geschieht aber nicht automatisch in allen Konfigurationen; warum das oft nicht der Fall ist, haben wir noch nicht herausgefunden. Wenn beispielsweise das Authentifizierungstoken eines Benutzers ungültig wurde, zum Beispiel beim Kennwort-Zurücksetzen oder deaktivieren eines Nutzers, versucht das WAM den Benutzer erneut zu authentifizieren. Soweit idst das ja auch richtig – aber man erwartet hier nun das altbekannte Popup-Fenster des IdP, das bei einem fehlgeschlagenen Zugriff aber nur kurz geöffnet und dann sofort wider geschlossen wird wenn das Flag nicht korrekt/lesbar/vorhanden ist.

AADConnect Kennwort eines Benutzers neu in das Azure AD synchronisieren

Veröffentlicht am von — Keine Kommentare ↓

Problem

Nach der „Kennwort zurücksetzen“ Aktion der Administrators einer lokalen Domäne wird das neue Kennwort eines Benutzes nicht automatisch in das Azure AD (Office 365) synchronisiert.

Der Benutzer kann sich zwar in dem lokalen AD mit seinem neuen Kennwort anmelden, in Office 365 aber weiterhin nur mit dem alten.

Ändert ein Benutzer selbser sein Kennwort (STRG+ALT+ENTF), wird das neue Kennwort sofort (max 120 Sekunden) synchronisiert.

Lösung

Von manuellen Datenbank-Änderungen an der Client-API „vorbei“ bekommt AADConnect (ADsync) nichts mit. Da es (ohne weiteres) nicht möglich ist, Kennworthashes aus dem AzureAD für einen Vergleich zu exportieren, bleiben die Kennwörter bis zur nächsten Änderung unterschiedlich.

Das Kennwort kann aber einfach manuell (nachträglich) neu synchronisiert werden.

  • PowerShell auf der AADConnect Maschine öffnen („Als Administrator“, mit ExecutionPolicy auf mindestens „RemoteSigned“)
  • Distinguished Name (DN) des Benutzers besorgen:
    • Get-ADUser NAME | select D*
  • Assistenten zur Synchronisation des Kennworthashes des DNs starten:
    • Invoke-ADSyncDiagnostics
  • Dem Assistenten folgen (2 > 3 …)

Schon fertig 🙂