Moin,
spätestens seit Erscheinen von Exchange 2013 konnte man sich drauf verlassen: alle 3 Monate gibts einen neuen kumulativen Update (CU).
Komischerweise ist der CU11 bisher nicht aufgetaucht. Im Netz findet man nur Leute die ebenfalls den CU11 suchen 
Weiß jemand aus dem Forum dazu etwas Neues? Will Microsoft diesmal vielleicht einen CU herausbringen der keine neuen Probleme verursacht?
Viele Grüße
Rolf
Moin!
Ich glaube ich habe das was merkwürdiges ausgegraben.
Auf unserem Exchange-System werden die Mailboxen mehrerer Unternehmen gehostet. Ein Teil dieser Unternehmen administriert teilweise selber, d.h. legen Mailboxen, Kontakte und Verteilerlisten selber an und pflegen diese. Damit das sauber getrennt von anderen Unternehmen funktioniert, sind diese untereinander in verschiedenen Organisationseinheiten (OU) untergebracht, für die "Konter-Admins" spezielle Rollen definiert (wobei alles weggelassen wurde was diese nicht für ihre Aufgaben benötigen bzw. verwenden sollen) und diese Rollen mit Managementscopes auf die OU des jeweiligen Unternehmens begrenzt.
Das funktioniert auch ganz gut (mit der Einschränkung daß es keine Read-Scopes gibt und daher alle Unternehmen alle Mailboxen sehen können (via get-mailbox)).
Jetzt möchte eine Firma Mailboxen mit new-mailboximportrequest/new-mailboxexportrequest bearbeiten. Ich habe daher dafür auch wieder eine Rolle definiert, diese mit einem Scope auf die OU des Unternehmens begrenzt und ... muß staunen:
Trotz Scope kann diese Firma systemweit (!) Mailboxen exportieren und importieren! Es ist problemlos möglich auch für Mailboxen außerhalb des definierten Scopes Export oder Import anzustoßen. Man kann zwar nicht danach schauen (z.B. get-mailboximportrequeststatistics) oder diese entfernen (remove-mailboximportrequest) - aber die Imports/Exports laufen korrekt durch.
Meine bescheidene Meinung: da es keine Read-Scopes gibt kann man grundsätzlich erst mal alle Mailboxen sehen bzw. anzeigen (get-mailbox). Auf dieser Basis schiebt new-mailboximportrequest bzw. new-exportrequest den MRS an der dann die eigentliche Arbeit macht - und der sich natürlich nicht um irgendwelche Scopes kümmert. Die cmdlets (new-mailbox....request) scheinen die Scopes zu ignorieren.
Ich habe das mal bei Microsoft eingetütet. Mal schauen was dabei rauskommt.
Grüße
Rolf
Kommt mir bekannt vor: das hatten wir als unsere Exchange-Umgebung "überlastet" war. Schau doch mal auf den Maschinen nach wie es da aussieht (Performance Monitor, Eventlog): ist da was zu finden?
Sind die User eventuell übermäßig aktiv oder haben Mailboxen mit extrem vielen Items?
Erfolgt der Zugriff über einen Proxy und ist dieser in Ordnung? Gibt es evtl. Netzwerkprobleme bei den Client-PC (schau mal im Eventlog der PC nach ob da was von unerbrochenen Netzwerkverbindungen zu finden ist)? Nicht wundern, es kann sein daß auf den Rechnern ...zig andere Anwendungen problemlos laufen. Outlook ist (was Netzwerkstabilität betrifft) extrem pingelig.
Moin,
ich muß für einen Kunden eine spezielle Retention Policy bauen die leider nicht funktioniert. Daher wollte ich das Logging des Managed Folder Assistant (MFA) auswerten- nur: der Server schreibt kein Log ...
Mit get-mailboxserver|ft *man* wird mir ein Verzeichnis angezeigt, dieses existiert jedoch nicht und daher gibts auch keine Logs:
LogPathForManagedFolders
------------------------
C:\Program Files\Microsoft\Exchange Server\V15\Logging\Managed Folder Assistant
Kann man das Logging für den MFA irgendwo einschalten?
Grüße
Rolf
EDIT:
Ich habe nun anscheinend herausgefunden wir man den MFA dazu bringt das entsprechende Verzeichnis anzulegen:
set-mailboxserver -FolderLogForManagedFoldersEnabled $true
Allerdings hinterläßt die Abarbeitung der RetentionPolicies dort keine Spuren - ich vermute das ist nur eine "Kompatibilitätssache" bzgl. Exchange 2010.
Grüße
Rolf
Hallo!
Auf meinem Exchange 2016 gibt es einige hundert User die mit einer "hausinternen" IOS-App unterwegs sind. Diese App verursacht auf dem Exchange sehr hohe Last (TimeInServer: teilweise 100facher Wert "normaler" User).
Die Belastung kann man auch in der CPU-Belastung der betroffenen Server sehen.
Da die Entwickler bisher nicht rausfinden konnten was sie da treiben (ich für meinen Teil vermute die App liest zyklisch den Kalender durch) würde ich gerne die betroffenen User etwas ausbremsen um die Systemlast zu reduzieren.
Exchange stellt dafür die Throttling Policies bereit. Ich könnnte also für diese User eine angepaßte Policy erstellen und zuweisen und damit das Problem erst mal lösen (natürlich mit dem Risiko daß dann die App nicht mehr richtig läuft).
Unsere bisher verwendeten Throttling Policies verwenden für EAS noch die Default-Werte:
EasMaxConcurrency: 10
EasMaxBurst: 480000
EasRechargeRate: 1800000
EasCutoffBalance: 600000
Meine Frage: an welchem Parameter könnte ich da mal drehen - und wie groß sollte die Änderung sein? Bisher habe ich keiner Gefühl für die notwendigen Werte.
Ich vermute, EasRechargeRate und EasMaxBurst sind meine "Kandidaten" für eine Änderung. Nur: was kann man da angeben ohne die betroffenen User gleich komplett abzuklemmen?
Viele Grüße
Rolf
Schon klar. "Bad Copy Count" ist 1, auf der rechten Seite wird angezeigt daß die Kopie unbrauchbar ist. Am besten ich mache nach dem nächsten Maintenance Mode mal einen Snapshot und poste das hier rein.
In der EAC wird die Kopie als "defekt" angezeigt. Eventlog liefere ich nach sobald das Problem wieder auftritt!
Moin!
Vier unserer Exchange-2016-Server zeigen seit einiger Zeit ein seltsames Verhalten: wenn wir die Maschinen in den Maintenance Mode versetzen und irgendwas daran gemacht wird (patchen etc.) und man nimmt sie wieder in Betrieb, sind danach einige Datenbankkopien auf dem jeweiligen Server defekt und müssen neu gemacht werden. Nach dem reseeden der Kopien ist wieder alles im Lot - bis zum nächsten Mal "Maintenance Mode".
Komischerweise ist das nur bei den 4 Servern so die wir als allererste Server auf Exchange 2016 umgestellt hatten. Die anderen Server zeigen dieses Verhalten nicht.
8 dieser Server sind technisch 1:1 identisch. Davon haben 4 das Problem, 4 jedoch nicht. Patchlevel aller Server ist identisch.
Ich habe den Eindruck daß das Problem mit irgendeinem CU oder Patch reingekommen ist.
Ist sowas schon einem von euch passiert - und hat er eventuell dazu einen Workaround?
Viele Grüße
Rolf
Das geht auch anders.
Beide Firmen haben ja Mailboxen mit einer gemeinsamen Domain (Beispiel: @firma.com).
Firma 1 und 2 haben jeweils ja noch eigene Domains (Beispiel: @firma1.com und @firma2.com).
Der MX-Record der gemeinsamen Domain zeigt auf eines der beiden Mailsysteme, also @firma.com --> Firma 1.
Dieses leitet Mails für User die sich nicht auf diesem System befinden an die Postfächer auf dem anderen Exchange weiter
indem es mittels Mail-Kontakt die Adresse ummappt (Beispiel: annehmendes System ist das Exchange der Firma 1, es mappt
daher "@firma.com" auf "@firma2.com" um wenn die Mailboxen auf dem anderen System liegen).
Die Argumente (kein Online-Mode, maximal 1500 User pro Server) haben die mir auch erzählt. Hingegen hat der Microsoft-Consultant ein (nicht funktionierendes) Sizing gemacht bei dem ca. 2500 Mailboxen pro Server laufen sollen. Man merkt aber daß sie mit aller Macht versuchen die Leute in die Cloud zu holen.
Bei Messungen stellte sich heraus daß die Datenbankzugriffe (IOPS) eigentlich ganz gut sind - es gibt aber einige User die dramatisch über die Stränge schlagen (Faktor 100 und mehr als normal). Diese Leute sind vermutlich
für unsere Performanceprobleme verantwortlich. Wir kriegen im Peak bis zu 2000 IOPS zustande, das ist jenseits von gut und böse.
Wir werden nun 4 Server mit SSD aufsetzen die vom Sizing her im oberen Leistungsbereich liegen (192GB RAM, 24 Cores ...). Auf diese Maschinen werden wir zunächst die "Problemkandidaten" verschieben und beobachten ob damit eine Besserung der Gesamtsituation eintritt. Zumindest haben wir damit erst mal die "Brunnenvergifter" isoliert und zusammengesperrt, im Idealfall fackeln die neuen Maschinen das Problem elegant ab.
