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.

Am 23.8.2021 um 21:36 schrieb Nobbyaushb:

Und das musst du mir zeigen..

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

Zitat

 

More Information
When Outlook is running in Cached Exchange Mode, it uses a local offline folder file (.ost). This file is periodically synchronized with the server. When you enable the Do not deliver before option to defer the delivery of a message, the message is deferred to the local Outbox, not to the server. Therefore, the message will not be delivered from the local .ost file unless Outlook is running when the message is scheduled to be delivered. This behavior does not occur in when Outlook is running in online mode.

 

Workaround
To work around this behavior, enable the Do not deliver before option to defer delivery of the message when Outlook is running in online mode.

 

- 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.

Zitat

This issue occurs because the message that originates from Office 365 or that is processed by EOP is added by having the following specific internal header:

 

X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent

 

This header identifies messages that have been processed by the Exchange Journaling agent. If the header is included in a message, Exchange Server recognizes that the message has already been processed by the Journaling Agent on a previous Hub Transport server. Therefore, it does not journal the message again.

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.

vor 1 Minute schrieb Navy:

@massaraksch Danke fürs virtuelle kramen, habs mir gelinkt da nicht mehr genügend User online sind kann ich noch nichts sagen.

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.