massaraksch

Hi, da war mal was mit den Language Settings: Search-AdminAuditLog and Search-MailboxAuditLog with parameter return empty results - Exchange | Microsoft Docs Sieht etwas frickelig aus, also genau durchlesen.

Hi, hast du auch die nötigen Eigenschaften gesetzt, z.B. "AllRequestInPolicy"? Siehe auch hier, Example 4: Set-CalendarProcessing (ExchangePowerShell) | Microsoft Docs

Hi, hast du "Senden als" und "Senden im Auftrag von" beide gesetzt? Wenn ja, dann nimm "Senden im Auftrag von" wieder weg.

Hi, wegen Erinnerungen mal Outlook mit speziellem Parameter starten (vorher natürlich schließen): Start - Ausführen... outlook.exe /cleanreminders Siehe auch: Command-line switches for Microsoft Office products

Hi, haben deine lokalen PublicFolder-Mailboxes PF1,PF2,PF3 eine ordentliche SMTP-Adresse, die per Autodiscover auflösbar ist?

Hi, man kann auch ohne Verschieben den Suchindex eines Postfachs neu erstellen: Start-MailboxAssistant -Identity mailbox@contoso.com -AssistantName BigFunnelRetryFeederTimeBasedAssistant Wenn das Problem allerdings nach einiger Zeit wieder auftaucht... PS: Ich glaube, das ist erst seit CU11 verfügbar.

Hi, mach doch mal ein Outlook-Profil ohne Cache-Modus. Passiert das dann auch?

Hi, was meinst du mit "Sobald ich das Kennwort manuell in Exchange Online anpasse ist der Vorgang wieder erfolgreich durchführbar."? Änderst du das Kennwort des eingetragenen Migrationsaccounts wieder in das "alte" Kennwort? Denn Assistenten hab ich dafür noch nicht verwendet. Wenn, dann mache ich das direkt in der Exchange Online Shell (Connect-ExchangeOnline) mit "Set-MigrationEndpoint". Set-MigrationEndpoint "Name_des_Migrationsendpunktes" -Credentials (Get-Credential) Er fragt dich dann in einem Anmelde-Dialogfeld nach den Anmeldedaten.

Hi, kleiner Hinweis: Seit CU22 lautet der Lizenzparameter nicht mehr /IAcceptExchangeServerLicenseTerms sondern /IAcceptExchangeServerLicenseTerms_DiagnosticDataON oder /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF

Hi, vielleicht mal die Website im IIS-Admin prüfen. Irgendwelche HTTP-Redirects auf den virtuellen Unterverzeichnissen (OWA usw.) eingestellt? Da gibt es z.B. eine Falle, wenn man einen HTTP-zu-HTTPS Redirect nach OWA auf der Default Web Site einstellt und die (hier unerwünschte) Vererbung auf Unterseiten nicht beachtet. Wäre allerdings seltsam, daß der Fehler dann nicht im IE und mobilen Clients auftritt.

Unsere Abteilungssekretärin macht das seit Jahren. Erklärung hier: https://support.microsoft.com/en-us/topic/an-e-mail-message-may-not-be-delivered-at-the-scheduled-time-when-you-enable-the-do-not-deliver-before-option-in-an-outlook-message-2cc9c435-7162-2c56-d680-d2bd6f99e1dd

- Probleme bei langsamen/instabilen Verbindungen (unterwegs, Wechsel zwischen Netzen z.B. WLAN etc.) - große Postfächer - überhaupt kein Zugriff, wenn keine Verbindung

Bei Outlook geht das verzögerte Senden, ohne daß Outlook geöffnet ist, nur im Online-Modus (also Cache Modus ausschalten). Das macht das Feature aber relativ nutzlos, denn der Online Modus hat ja diverse Nachteile, die man meist nicht haben will.

Microsoft ist konsequent: Schon bei Exchange 2010 gab es dieses Verhalten. Habe das hier im "Lab" gerade mal getestet

Nur mal so: "Remove-Mailbox" ist genau das, was du mit "entfernt den AD-Account" meinst. Deaktivieren ist "Disable-Mailbox" (das was NorbertFe mit "exchange Attribute entfernen" meint). PS: Ups, geht ja durcheinander hier Die wichtigsten Attribute könnte man sich vorher ja noch rausziehen (in eine schöne CSV oder so).

Hi, Ursache ist, daß EOP einen speziellen Header hinzufügt, der dem OnPrem-Server anzeigt, daß die Mail schon vom EOP Journal-Agent bearbeitet wurde. Damit meint der lokale Agent, er müsse nichts mehr tun. Siehe: Email received via EOP not journaled - Exchange | Microsoft Docs Lösung ist, im Office 365 über das Exchange Admin Center > Compliance Management > Journal Rules eine entsprechende Journal-Regel einzurichten (Ziel ist dann ebenfalls das OnPrem-Journal Postfach). Tipp: Suchmaschine -> exchange eop journaling -> erster Treffer PS: Ist aber echt interessant. Muß ich mir direkt "abspeichern".

Hi, zum möglichen Zugriff auf Netzwerkressourcen in der Domäne mit dem lokalen Systemaccount wurde der Hinweis ja schon gegeben (den Computerkonten die nötigen Schreibrechte auf der Freigabe erteilen). Unabhängig davon mal eine gut gemeinte Anmerkung: Was du bisher versucht hast, ist sicherheitstechnisch ein No-go. Du willst die Credentials eines (oder sogar des built-in Administrators der Domäne) auf unsicheren Clients speichern? Niemals! Sich mit dem Domain-Admin auf unsicheren Clients anmelden? Nein! Scripte auf Clients mit dem Domain-Admin laufen lassen? Nein!

Hi, "AutomateProcessing" muß schon auf "AutoAccept" (Besprechungsanfragen und Absagen automatisch verarbeiten) stehen, sonst funktioniert die Buchungsautomatik überhaupt nicht, auch nicht die Genehmigung. Und dann: "Diese Benutzer können die Terminplanung automatisch durchführen, wenn die Ressource verfügbar ist" -> Keiner (das müßte -AllBookInPolicy $false entsprechen) "Diese Benutzer können eine Anfrage zur Genehmigung durch den Besitzer übermitteln, wenn die Ressource verfügbar ist" -> Jeder (müßte -AllRequestInPolicy $true entsprechen) Oder wie auch immer gewünscht... die einen dies, die anderen das (Gruppen, User). Die Automatik mit ihren vielen Möglichkeiten ist anfangs durchaus etwas schwierig zu durchdenken. Kannst du auch hier noch weiter nachlesen: https://docs.microsoft.com/de-de/exchange/recipients/room-mailboxes?view=exchserver-2019#change-how-a-room-mailbox-handles-meeting-requests

Hi, das "Warum" hat er ja erklärt ("Ich brauch das zur Prüfung ob der Nutzer eine MAilbox hat oder noch nicht."). Aber ja, das Mailsystem ist natürlich nur Spekulation.

Hi, siehe: Attributes synchronized by Azure AD Connect | Microsoft Docs msExchExtensionCustomAttribute1..5 -> This attribute is currently not consumed by Exchange Online Scheint also nicht supportet in EXO.

Hi, nur mal als Anmerkung: Die AD/LDAP-Property "mail" ist kein hinreichendes Kriterium, daß der User eine Mailbox hat. Das kann auch ein Mailenabled-User sein. Oder ein reiner AD-User, wo nur jemand was ins Mail-Feld reingeschrieben hat. Um es eindeutiger zu machen könnte man nach msExchMailboxGUID schauen. Die sollten wirklich nur User mit Postfach haben.

Hi, ein paar Ideen: Wenn dein Task über den "Default Frontend" Connector mit einem Exchange-Konto authentifiziert senden will, dann müssen "Exchange Users" dort bei "Permission Groups" auch erlaubt sein. Dies sind sie standardmäßig nicht (deshalb ist die "Authentication unsuccessful"). Und wenn dann bei "Security Settings" die "Integrated Windows Authentication" aktiviert ist, dann sollten keine Anmeldedaten im Script nötig sein (die kommen ja über den Task-Prozess, der mit dem Konto läuft).

Hi, Der Server braucht max. 2 Stunden: https://www.frankysweb.de/exchange-server-quota-cache-limits-werden-erst-nach-lngerer-zeit-bernommen/ Mit dem Client hat das weniger zu tun.

Wenn du den Wert änderst musst du eh mal den Information Store neu starten.

Hi nochmal, In Erinnerung kram... evtl. das MAPI-Session Limit auf dem Server? Jetzt wohl: "MAPI on the Middle Tier" -> Sessions per Database. Siehe: https://docs.microsoft.com/en-us/exchange/architecture/mailbox-servers/managed-store/managed-store-limits?view=exchserver-2019 \\HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Maximum Allowed Sessions Per User = XX War vielleicht auf dem alten Server entsprechend gesetzt. Wobei das eigentlich schon bei 32 Sessions (Standard) abwürgen müsste.