Die Outlook-Suche verhält sich ja häufiger etwas ungewöhnlich, das man aber sei einer Weile praktisch nicht mehr freigegebene Ordnern (Nicht freigegebene Postfächer) von anderen Nutzern suchen kann, ist merh als ärgerlich. Grade in Zeiten von Exchange Online ist das sehr ärgerlich.
Schuld ist Outlook in Verbindunge mit dem Windows Indexdienst. Freigegebene Ordner werden standartmäßig wie freigegebene Postfächer heruntergeladen; diese landen somit im Index. Leider beauftragt Outllook bei der Sucher nur noch „Eigenes Postfach“ und liefer somit bei freigegebenen Ordnern nur leere Ergebnismengen zurück.
Woraround
Man kann Exchange dazu zwingen, die Serverseitige Suche zu verwenden. Der Zugriff auf Microsoft 365 Exchange Online-Postfächer ist dann zwar etwas langsamer, dafür liefert die Outlook-Suche plötzliche wieder korrekte Ergebnisse. Bonus: Neu vergebene Berechtigungen greifen nun ebenfalls sofort.
Das geht unter den E-Mail Konten > E-Mail > Postfach auswähen und oben „Ändern“ > Weitere Einstellungen > Erweitert > Freigegebene Ordner herunterladen AUS schalten.
Nicht schnell eingerichtet, aber sehr hilfreich: App Kennwörter als Ergänzung zur Multi-Faktor Authentifizierung – als Teil von Microsoft 365 ist ein fundamentaler und sehr gut umgesetzer Schutzfaktor für den Zugang.
Der geneigte Microsoft 365 Administrator kann Multi-Faktor Authentifizierung mit wenigen Klicks (oder via PowerShell) für einzelne oder alle Anwender aktivieren. Wie steht es aber um statische App Kennwörter – Wie erstellt man nun für ältere Programme oder SMTP-Clients (Kopierer, Scanner, CNC-Maschinen …) App-Kennwörter?
Limitierungen bei App Kennwörtern
Pro Benutzer maximal 40 App-Kennwörter
App-Kennwörter funktionieren nur in Microsoft 365, auch bei Hybrid-Szenarien nicht im lokalen Server
Funktioniert nicht bei „bedingtem Zugriff“ mit MFA (und modernern Auth)
App Kennwörter werden generiert (z.B. xmnfgsaofn3DSk) vorgegeben und können nicht geändert werden. Muss ein Kennwort „getauscht“ werden, geht das nur über löschen > Neu
Bei den „Hohen Sicherheitsstandarts“ muss MFA pri User erzwungen sein
Schritt 1 – App-Kennwörter für Benutzer erlauben
Man kann App Kennwörter nur erlauben, wenn die Azure AD Multi-Factor Authentication für den betreffenden Nutzer aktiviert ist.
Ganz Oben (!) unter „diensteinstellungen“ den „Benutzern das Erstellen von App-Kennwörtern zum Anmelden bei nicht browserbasierten Apps gestatten“
Schritt 2 – MFA erzwingen
Ganz oben unter „benutzer“ muss die Verwendung von MFA erzwungen werden, wenn die „Hohen Sicherheitsstandarts“ für das AzureAD eingeschaltet sind (Standard seit 2020).
Die Einstellung wird in aller Regel nicht sofort aktiv, aber man kann die Übernahme erzwingen, indem man als Administrator alle Sitzungen des Nutzers abmeldet und der Nutzer sich neu (in einem Browser) anmeldet
Und schon wieder so ein Fall von Selbst-Notiz. JEDESMAL muss ich googeln wie man die Version oder Edition des grade genutzten MS SQL-Servers anzeigt
Version anzeigen
SELECT @@version
Edition und Version anzeigen
SELECT
CASE
WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '8%' THEN 'SQL2000'
WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '9%' THEN 'SQL2005'
WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '10.0%' THEN 'SQL2008'
WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '10.5%' THEN 'SQL2008 R2'
WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '11%' THEN 'SQL2012'
WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '12%' THEN 'SQL2014'
WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '13%' THEN 'SQL2016'
WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '14%' THEN 'SQL2017'
WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '15%' THEN 'SQL2019'
ELSE 'unknown'
END AS Produktversion,
SERVERPROPERTY('ProductLevel') AS Patchlevel,
SERVERPROPERTY('Edition') AS Edition,
SERVERPROPERTY('ProductVersion') AS Build
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:
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.
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:
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.
„Zugriff verweigert“ bekommen (lokale) Administratoren für den Zugriff auf \\server\c$ Admin-Freigaben. Die Freigabe ist aktiv, in der Freigabenverwaltung sichtbar, das Kennwort stimmt, aber Windows verweigert den Zugriff.
Schuld ist, mal wieder, die Benutzerkontensteuerung, genauer die Remote User Account Control (Teil der UAC) in Windows. Abhängig davon mit welcher Art von Konto man sich anmeldet, also Domänenkonto oder Lokal, schlägt die Filterung des UAC-Zugriffstokens zu. Diese wirkt sich in der Standardeinstellung nicht auf Domänenkonten in der Gruppe der lokalen Administratoren aus, sondern nur auf lokale Konten.
Lösung
Um die Filterung des Tokens zu deaktivieren:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"LocalAccountTokenFilterPolicy"=dword:00000001
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.Alles klarMehr Informationen
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
