massaraksch

Hi, hat nichts mit dem Browser zu tun. Kurz auf Microsoft-Art gesagt: "It's by design". Vielleicht bauen sie das Feature *irgendwann* mal auch im Outlook Web ein.

Hi, mittels "Search-AdminAuditLog" sollte man das meiste finden. Allerdings nicht direkt die vollständige Shell-Befehlszeile, aber zumindest das Exchange-Cmdlet an sich und die verwendeten Parameter. Beispiel (zeigt die Aktionen der letzten 15 Minuten in einem GridView Fenster): Search-AdminAuditLog -StartDate (get-date).AddMinutes(-15) | Out-GridView Das hilft vielleicht weiter.

- entfernt -

Hi, mit ThrottlingPolicies hat das nichts zu tun. Ist sicher das alte Thema der "MaxObjsPerMapiSession" in den Reg-Einstellungen für den Store-Dienst (MSExchangeIS). Managed Store Limits in Exchange 2016 and Exchange 2019 | Microsoft Learn Müsste in diesem Fall der Wert für "objtMessage" (Default 250) sein. PS: Nicht gleich wahnsinnig hoch setzen, evtl. mit 500 anfangen und schauen, ob die Meldung weg ist. Leider muss nach Anderung der MSExchangeIS neu gestartet werden, also evtl. kurze Unterbrechung für Clients.

Hi, hier z.B. ein Kunde mit zwei Sites, wo der Schema-Master in Site A steht und dort keine Exchange-Server vorhanden sind. Diese stehen in Site B. Also: 1. auf einem DC in Site A die CU-ISO mounten und setup.exe /preparead /usw auf Kommandozeile 2. AD-sync abwarten 3. auf Exchange in Site B das eigentliche Setup durchführen Bisher kein Probleme gehabt.

Ja, da hab ich wohl was verwechselt. Danke für die Korrekturen.

Hi, nochmal eine Erläuterung: Wenn man -ErrorAction Stop verwendet (verwenden muss, wegen try-catch), dann fliegt man beim ersten Auftreten eines Fehlers aus der umgebenden foreach-Schleife raus. Ende Gelände. Das vermeidet man, indem man den catch-Block mit "continue" abschließt. Das führt zur Weiterverarbeitung der Schleife mit dem nächsten Item. Also ungefähr so: foreach ($Mailbox in $Mailboxes) { try {Set-MailboxFolderPermission ... -ea Stop} catch { Set-MailboxFolderPermission ... continue } }

Hi, mach mal Get-MailboxFolderPermission -Identity $element':\Kalender' oder Get-MailboxFolderPermission -Identity $element":\Kalender" Sollte beides gehen.

Hi, "get-reciepient" ? Erinnere dich an deinen Englischunterricht... PS: Ach, gerade erst die Antwort von Sunny61 registriert

Kurz erklärt: Diese angebliche "disruption", die Stellarinfo da beschreibt, ist ganz einfach Unsinn. Möchte wissen, wie der Autor auf sowas kommt.

Hi nochmal, hab mal etwas "gespielt"... In der Tat könntest du ein anderes Attribut dafür "mißbrauchen". "Position" (AD-Attribut: title) ist für Gruppen nicht verfügbar. Aber Abteilung (AD-Attribut: department) ist ein legitimes Gruppenattribut. Das Setzen des Attributs "department" geht in der AD-Benutzerverwaltung nur indirekt, über die Registerkarte "Attribute Editor" (vorher über View - Advanced Features aktivieren). Wäre natürlich etwas mühsam. In der Shell mit Set-ADGroup. Beispiel: Set-ADGroup EU-AT-V-S -Replace @{department='AT Salesteam Vienna'} Hinweis: Attribut löschen mit Set-ADGroup EU-AT-V-S -Clear department Falls es viele sind, könnte man das halt etwas scripten und über eine CSV-Liste und foreach in die Gruppen "reinblasen". Ist mir jetzt zu viel... Da hilft sicher das Scripting-Forum Dann wird deine Beschreibung bei Gruppen in der GAL in der Spalte "Abteilung" angezeigt. Im Offline Adressbuch dauert das natürlich wie üblich ca. 1 Tag (falls man das nicht manuell forciert). PS: Die im Outlook angezeigten Spalten kannst du IMHO nicht ändern.

Hi, du kannst den "Displayname" anpassen. Dieser wird in der GAL angezeigt (heißt in der Outlook-Anzeige zwar "Name", ist aber nicht der Gruppenname (Attribut "CN"), sondern "Displayname" und ist unabhängig davon. Der Displayname (Anzeigename) kann im Exchange Admin Center oder per Exchange Shell geändert werden: set-distributiongroup "EU-AT-V-S" -Displayname "AT Salesteam Vienna" In der AD-Benutzerverwaltung nur direkt über das entsprechende Attribut "Displayname". Oder auch per set-adgroup XXX -displayname "Mein Anzeigename" PS: Wie üblich dauert so eine Änderung etwas, bis sie im Outlook "ankommt". Besonders im Offline-Adressbuch. PPS: Naja, falls das nicht eurer "Konzernrichtlinie" widerspricht... Hab ich glatt überlesen.

Hi, das ist nicht unbedingt immer so. Berechtigungen mittels DistributionGroups (also Mail-enabled Universal Security Groups, die natürlich auch im AAD-Sync sein müssen) sollten übernommen werden. Wahrscheinlich sind es bei euch aber reine AD-Gruppen.

Das soll sicher bedeuten: auf einem Netzlaufwerk... Bitte nicht, das ist das Schlimmste wo gibt!

Evtl. noch die Junk-E-Mail Konfig? -> Junk-E-Mail endgültig löschen

Hi, ist jetzt etwas ins Blaue hinein geraten, aber hier habe ich einen Hinweis gefunden: Office 365 ProPlus Single Sign-On and Modern Authentication on RDS (spiceworks.com) Es geht da um einen Reg-Eintrag "DisableADALatopWAMOverride" beim User. Kann man ja mal probieren.

Nicht im Cache Mode. @teletubbieland Wirf doch mal die Cache-Datei (OST) auf dem Client weg. Dann werden die Inhalte neu synchronisiert und von der Windows-Suche neu indexiert. Oder nur die Offlineelemente des Posteingangs aus der OST-Datei entfernen (und neu synchronisieren lassen). Rechtsklick Posteingang - Eigenschaften - Offlineelemente löschen (etwas warten bzw. Outlook Neustart)

Wie hast du denn die Audit-Einstellungen bei dem Postfach konfiguriert? Standardmäßig wird da nicht alles protokolliert (speziell für den Owner nicht). Get-Mailbox POSTFACH | select *audit* SoftDelete, HardDelete, Move sind da IMHO erstmal gar nicht drin. Die zu überwachenden Vorgänge muß man dann erstmal selbst aktivieren, z.B. Set-Mailbox POSTFACH -AuditOwner Move,MoveToDeletedItems,SoftDelete,HardDelete usw. Die Konfig für Auditing ist halt nicht ganz trivial, deshalb hatte ich auch die Doku verlinkt. Also: https://docs.microsoft.com/de-de/exchange/policy-and-compliance/mailbox-audit-logging/enable-or-disable?view=exchserver-2019#configure-mailbox-audit-logging-settings-for-administrator-delegate-and-owner-access

Hi, Das mit dem LegacyDN ist relativ unwichtig. Exchange erzeugt die ziemlich "frei". IsMoveDestination = True scheint ja darauf hinzudeuten, daß da ein unvollständiger/abgebrochener Move-Request dahintersteckt. Der Wert sollte sonst immer False sein (wenn ein Postfach nicht aktuell verschoben wird). Beispiel: Während eines laufenden Move-Requests wird das Quellpostfach disabled oder der Account gelöscht. Bleibt also so ein verwaistes Ding übrig. Gibt es MoveRequests? Get-MoveRequest Bekommst du einen AD-Account, wenn du mit der angegebenen OwnerADGuid (ObjectGUID im AD) suchst? Also Get-ADUser -Filter "ObjectGUID -eq '66f06b43-a87c-488c-b60c-dfef465da963'" Ansonsten würde ich mich @NorbertFe anschließen: Wenn es kein wirkliches Problem gibt, dann ist das zwar eine interessante Forschungsaufgabe, aber man könnte das auch einfach lassen und sich wichtigeren Dingen zuwenden

Hi, laß dir doch mal alle Eigenschaften für dieses "verwaiste" Postfach mit Get-MailboxStatistics (also mit select *) ausgeben und poste die evtl. auch hier (vertrauliche Infos wie Namen ö.ä. unkenntlich machen). Vielleicht findet man da etwas Ungewöhnliches. Interessant könnten z.B. sein OwnerADGuid, LegacyDN, IsMoveDestination Scheint ja irgendein "Rest" zu sein, abgebrochener Mailbox-Move oder irgendwas. Evtl. könnte auch ein "Update-StoreMailboxState" was bewirken. https://docs.microsoft.com/en-us/powershell/module/exchange/update-storemailboxstate?view=exchange-ps

Laß bei deinem Search-Befehl die unnötigen Einschränkungen weg und verwende den (wichtigsten) Parameter -ShowDetails Mit -LogonTypes Admin,Delegate schließt du den angemeldeten User (Owner) selbst aus. Also laß den -logontypes am besten weg (bedeutet: alle). Also grundsätzlich sowas: Search-MailboxAuditLog mustermann -ShowDetails | ogv (mit | ogv wirfst du das in ein GridView, da hat man eine schöne Tabelle zum filtern/suchen) Mit | select kannst du die Masse der Details einschränken. Ich lasse mir immer folgende Details ausgeben (hab ich bei mir in einer Function verpackt, weil ich das ab und zu brauche). Search-MailboxAuditLog POSTFACH -ShowDetails -startdate XXX -enddate YYY | select LastAccessed,MailboxOwnerUPN,LogonUserDisplayName,LogonType,Operation,OperationResult,FolderPathName,SourceItemFolderPathNamesList,SourceFolderPathNamesList,SourceItemSubjectsList,ItemSubject,DestFolderPathName,FolderName,ClientInfoString,ClientIPAddress,ClientProcessName,ClientVersion,CrossMailboxOperation,DestMailboxOwnerUPN,DestMailboxOwnerSid,DestMailboxGuid,ObjectState | ogv

Hi, ja, da kann es wohl Probleme geben. Hab ich hier schon mal geschrieben: Aber bevor du dich mit den Language-Settings rumschlägst, solltest du erstmal prüfen, ob die nötigen Dienste laufen: Get-Service *compliance* Status Name DisplayName ------ ---- ----------- Running MSComplianceAudit Microsoft Exchange Compliance Audit Running MSExchangeCompl... Microsoft Exchange Compliance Service Die waren bei mir mal aus, obwohl die auf "automatisch" stehen.

Ich zitiere mich: Falls das alles nichts bringt, könnte man evtl. mal das Audit-Logging für diese Mailbox aktivieren (Erlaubnis einholen!) und nach dem nächsten "Verschwinden" einer Mail das Postfach-Log anschauen. Aktivieren oder Deaktivieren der Überwachungsprotokollierung für ein Postfach | Microsoft Docs Im Audit-Log kann man sehen, wer (Owner, Delegate) wann was gemacht hat (Move, SoftDelete, HardDelete usw.). User, Aktion, Zugriffsprotokoll, Client-Version, ClientIP usw. sind darin ersichtlich. Search-MailboxAuditLog (ExchangePowerShell) | Microsoft Docs Natürlich wird erst ab dem Aktivierungszeitpunkt protokolliert. Man muß also das nächste "Vorkommnis" abwarten. Manchmal sind es amoklaufende Smartphones (ActiveSync). Mein letzter ähnlicher "Fall" war der private Mac eines "Cheffe" (Apple Mail, also EWS).

Hi, wenn da das Ereignis DELIVER vom STOREDRIVER steht, dann ist die Mail auch im Postfach abgeliefert worden. Schon mal über die Outlook- oder OWA-Suchfunktion im gesamten Postfach suchen lassen? Evtl. im Junk-E-Mail Ordner gelandet? Kannst auch auf einem Exchange-Server eine ComplianceSearch in dem Postfach starten (z.B. nach Betreff, Empfangsdatum o.ä.). Falls das alles nichts bringt, könnte man evtl. mal das Audit-Logging für diese Mailbox aktivieren (Erlaubnis einholen!) und nach dem nächsten "Verschwinden" einer Mail das Postfach-Log anschauen. PS: Kannst auch mal "Get-Inboxrule -mailbox NAME -includehidden" machen (damit werden z.B. auch Regeln des Abwesenheitsassistenten angezeigt).

Hi, für das "Antriggern" hab ich keinen Vorschlag (außer eben selbst genügend Mails/Daten in die Mailbox zu kopieren/importieren). Hint: Man kann mittels Outlook einfach stinknormale Dateien in die Postfachordner ziehen, also 100 MP3 zu je 10 MB und schon hast du ein GB voll Einschub: Mit get-systemmessage erstellst du definitiv keine Systemnachricht, oder? Also eigene Systemnachrichten erstellen mit New-SystemMessage (ExchangePowerShell) | Microsoft Docs Eigene ändern mit Set-SystemMessage (ExchangePowerShell) | Microsoft Docs Eigene löschen mit Remove-SystemMessage (ExchangePowerShell) | Microsoft Docs (die Original Messages kannst du so nicht ändern, sollte man tunlichst auch nicht) Soweit so logisch. Gespeichert werden die IMHO direkt in der AD-Datenbank (daher der LDAP-Pfad), auffindbar sollten sie sein z.B. mit irgendeinem LDAP-Browser/Editor oder "adsiedit.msc" (hast du auf dem Exchange-Server). Aber Vorsicht, damit sollte man nicht "unbedarft" im AD herumeditieren! Entsprechende Befehle hast du ja oben. Hier noch was dazu: Exchange 2013 / 2016 NDR / Unzustellbarkeitsnachricht anpassen / customize DSN Messages - IT koehler blog (it-koehler.com) PS: Ob Ex2019 oder 2013/2016 sollte keinen grundsätzlichen Unterschied machen. PPS: Warum sollte die "Linux Welt" nichts mit LDAP zu tun haben? LDAP ist nichts Windows-Spezifisches.