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
Manchmal scheint eine Domain nach DNS-Änderungen noch gefühlte Ewigkeiten auf die „alten“ Einträge zu bestehen. In vielen Fällen ist das auf das gutgemeinte aber lästige Caching der Google-DNS Server zurückzuführen. Das jeder DNS-Server einen Cache betriebt ist ja auch sinnvoll. Wenn man aber „schnell2 etwas ändern will, steht einem die TTL der Einträge aber manchmal im Weg. Vor allem die auf (sehr) vielgenutzten Nameservern.
Die öffentlichen DNS-Server von Google sind (ipv4/ipv6)