BroBias

Nope, da läuft grundsätzlich kein Virenscanner, nichts dergleichen installiert. MS Defender komplett abgeklemmt.

Noch offen, evtl. mag jemand teilen ? :) Zusätzlich bin ich momentan an der Arbeitshypothese, dass folgendes Error-Event ein Auslöser für den unmittelbaren Dismount nach switchover sein könnte: "Application - ESE - 489: "msexchangerepl. An attempt to open xxx\yyy.edb for read only access failed with system error 32. Cannot access because being used by another process" Diese DB ist leer, verstehe nicht woher der Fehler kommen soll. Virenscanner, backup agent oder ähnliches läuft auf diesen Servern entweder nicht, oder ist zum Zeitpunkt inaktiv (backup). Zugriffe auf das edb-file sind standard: system - full, orgamgmt - full, view-only orgamgmt - read/execute und admins - full. Ist mir schleierhaft woher der file-lock kommen soll und weshalb auf diesem Server aber nicht auf den anderen ... :/

In den Jahren warst du dann aber nicht in der IT unterwegs, oder? ;) Doch doch, recht intensiv, aber halt ausschließlich autodidaktisch und in kleinen Präsenz"stammtischen" ^^ Wieso, weshalb, warum ist dann wirklich offtopic und gehört eher an nen Stammtisch

Aye, das ist so. Kann mich hier nur anschließen. Rudimentäres Relaying weiterhin intern abbilden, bleibe dabei.

Aye, Verantwortungsbewusstsein fehlt da wohl gänzlich ... und wahrscheinlich auch ein ganzheitliches Verständnis des Themas überhaupt. Mit Fingerpointing auf generelle Hinweise zu Implementierungsfehlern zu reagieren ... leider immer öfter zu sehen, aber widert mich immernoch an.

Richtig, aber das war nun mal Thema dieses Threads. ;) Hrhr, wer hat nun das letzte Wort Hach, da kommen schöne Erinnerungen hoch. Zum Verständnis: Hab mich sicher seit 12-15 Jahren in keinen Foren mehr bewegt und beginne es grad dank euch wieder zu genießen

Aye, hab ich mehrfach erlebt und mich heftig mit MS Support in die Haare bekommen deswegen; zugegeben, ist schon etwa 3 Jahre her .

Zu S/MIME würde ich allerdings einiges differenzieren, was via BIMI nicht möglich ist m.E. Grundsätzlich wärs schon spannend das mal testweise zu implementieren und dann vor allem sehen was ich im Hintergrund für Möglichkeiten hab das VMC tatsächlich nach Maileingang zu verifizieren und wie zuverlässig das ist. Aber wie gesagt, .... und man muss ja auch ned jeden Mist mitmachen, eh ? xD

Das steht im VMC (das Logo). Ach komm xD Der Empfänger sieht ein Logo an der Mail, erinnert sich an seine IT die gesagt hat "wenn Logo da, dann gut" und das ist es. Wie würde ein Empfänger ernsthaft verifizieren, ob das cert zum Logo passt ? ^^

Eben genau das empfinde ich als trügerisch und gefährlich. Es suggiert eine Sicherheit die ganz schnell mal keine mehr ist bzw. senkt die Aufmerksamkeit über mögliche Betrugsversuche.

Das kommt sicherlich dazu, aber grundsätzlich wäre ja das Logo auch für die "normale" Mailkommunikation verfügbar und würde also euren Kunden generell angezeigt (so die einen Client verwenden der das unterstützt), oder überseh ich hier was? Aye, klaro, wo nun registriert ist weitestgehend unerheblich, war nur ein Beispiel. Ja, würde es dem Kunden generell angezeigt, ok. Sehe einfach den zusätzlichen Vorteil nicht, wenn sonst alle authentication Mechanismen entsprechend sauber sind. Die Aufmerksamkeit auf Kundenseite ... weiß ned ob wirklich relevant. Ist meinerseits eher ein Gefühl basierend auf Erfahrung wie Anwender mit Mails umgehen ^^ Ich würde sagen, hauptsächlich den, der dein Logo dann Fälschen wird um mit Phish-Stuff deine Kunden oder deren Kunden zu beglücken ;) Auch mit Blick auf die Kosten ist das wieder eher etwas für "größeren" Unternehmen (gemessen am Umsatz) / Konzerne, m.E. Wenn ich es korrekt verstehe, holt man sich für eine bestimmte Version des Logos ein VMC cert (1,5k / Jahr). In aller Regel gibt es aber versch. Varianten des Logs, was die Kosten schnell multipliziert. Woher soll jetzt auch der EMail-Empfänger wissen, welche Version des Logos das geschützte ist. Wenn ich also Fälschungen generell vermeiden will, muss ich alle Varianten zertifizieren lassen. Nice idea, aber für mich eher ein "nice2have" Thema wenn sonst gar nichts mehr anderes zu tun wäre

Nochmal back to topic: Habe hier schon mit versch. Integrationen gearbeitet; keine davon war abschließend zufriedenstellend, aus unterschiedl. Gründen ^^ Grundsätzlich kann ich Nils hier nur zustimmen: Kein Kalendersync ! bzw. folgendes: Hier verwenden wir aktuell "Linkpoint" als Outlook Plugin. Zwar könnte man damit auch nen full sync etablieren, funktioniert aber mehr schlecht als recht. Stattdessen sind wir in der Orga hingegangen, haben den fullsync abgeklemmt und erlauben nur noch den sync selektiver Events. So können die BAMs hingehen, spezifische Events mit ihren Cases/Opportunities nach Bedarf (!) syncen, mit ihren Teams aus SF teilen und laufen sehr viel weniger (wenn überhaupt) in Probleme rein, weil einfach nicht der komplette "Kalendermüll" jedesmal hin und her gesynced wird. Sorry für die hakelige Grammatik, redet grad ein Kollege nebenher auf mich ein

So ein Fehler ist mir vor vielen Jahren genau einmal passiert. Glaubt es oder nicht: Seither kopiere ich -immer- über editor-umweg, außer es kommt schon ausm plain editor Der zusätzliche Aufwand hat sich für mich jedenfalls schon mehrfach gelohnt ;)

-> https://www.wbs.legal/markenrecht/markenschutz/logo-schutz/#:~:text=Durch eine Wort-%2FBildmarke,beim Deutschen Patent- und Markenamt. Wesentlicher Satz hier : Die Anmeldung erfolgt beim Deutschen Patent- und Markenamt. Sonst ist es kein geschütztes Logo. Macht imo nur dann wirklich Sinn. Unseres ist zwar geschützt, aber hab momentan 0 Kappa das umzusetzen ^^ Davon abgesehen finde ich, ist es eher für Marketing bzw. MassMailing-Zwecke relevant und dadurch evtl. erhöhte Reputation bei empfangenden Mailsystemen. Das wird allerdings noch etwas dauern, bis sich das etabliert hat (oder bis dahin wieder durch was anderes ersetzt wird ^^).

Hm, das liest sich schon alles beinahe wie einstudiert zur Unterhaltung der Forenmitglieder ... Ich war bisher mit DMARCAnalyzer von mimecast unterwegs (auch schon bevor es an mimecast verkauft wurde) und heutzutage mit Dmarcian. Beides gute Tools, Unterschiede eigentlich nur im Bereich Compliance (also bspw. DSGVO-relevante Hosting/DatainTransit Themen) oder halt Vorlieben was Handling und Anwenderfunktionenen angeht. Je nach Größe und Komplexität der zu überwachenden Domains oder/und zum Senden legitimierter Systeme, wirst du auch lange nachdem die Policy auf Reject gesetzt wurde froh sein um deine Berichte. Auch um vernünftiges Anti-Phishing zuz betreiben sind diese wertvoll, weil du sonst Schwierigkeiten haben wirst phishing campaigns unter Verwendung deiner domains auszumachen. Leider gibt es immernoch viel zu viele Anbieter bzw. Endpoints, die keine DMARC-Validierung machen, oder könnten es aber ihren unversierten Kunden überlassen das zu aktivieren. Davon abgesehen kannst du so z.B. auch Fehler in zum Senden legitimierten Systemen leicht entdecken. Wenn ich Zeit hätte länger drüber nachzudenken würden mir sicherlich noch weitere Gründe einfallen. Tatsache ist aber auch, dass ich seit ich alles "DMARC - betreffende" hier beim neuen AG glatt gezogen hab, vllt einmal im Quartal reinschaue. Nichts desto trotz erübrigt das das DMARC Monitoring selbstverständlich nicht.

Tatsächlich finde ich es eine farce, mal wieder ! So nen Mega-Cloud-Service auf den Markt zu werden (M365 und alles was dazugehört) ohne inkludierte Exit-Strategieren und DR-extSite Backup Lösungen ist schon frech genug. Dann die MS Gold/Premium Partner strampeln lassen, aufgrund des Kundendrucks Lösungen hierfür zu entwickeln und nach Jahren endlich anbieten können. Sobald das dann einigermaßen etabliert ist (bspw. Hornet, aber auch andere Anbieter) wie die "alt' Fasnet" hinterher kommen und ne eigene Lösung promoten, die die Bemühungen der Partner diesbzgl. auf lange Sicht wieder gegenstandlos macht. Ganz großes Kino .... oder ein typischer Microsoft.

Hey ihr Lieben, nach wie vor ist mein Thema aktuell ^^. Ich habe schlicht auch noch einige andere Themen auf dem Tisch, kommende Woche Urlaub, Festival und Feuerkunst-Kurs .... Da der Hauptserver sauber läuft und Backups ebenfalls stabil bleiben ist die Lage relativ (!) entspannt Pläne sind gefasst weitere Server hochzuziehen, neue DBs zu erstellen, mbx zu migrieren usw. Das sind jedoch eher langfristige Prozesse (gibt auch noch ungeklärtes bzgl. der Wahl der besten Site hierfür, Hardware hierfür - neue Server will ich dann endlich nach BestPractice aufsetzen und nicht mehr mit Kompromissen arbeiten müssen hinsichtlich HW & Dedicated ressources). Eine Rückfrage lässt sich evtl. dennoch noch klären, bevor ich dann in den Urlaub gehe ^^: Im Rahmen der Fehlersuche bin ich auch vor allem an Berechtigungen auf Dateien und Ordneren auf den DB und Log Laufwerken hängen geblieben. Diese waren offensichtlich nicht konsistent und ich hab mich bemüht diese dem was ich auf dem Hauptserver auslesen kann anzupassen. Nun lässt sich auch die eine neue DB nicht mehr mounten, die auf dem Zweitserver erstellt wurde. Kurzum: Das bestätigt mich in meiner Vermutung, dass mit Datei/Ordner-Berechtigungen irgendetwas nicht stimmt, auch wenn ich es im System nicht (mehr) wirklich erkennen kann. In KBs usw. konnte ich dazu nicht wirklich was finden. Was habt ihr denn für Berechtigungen gesetzt auf DB und Log-Drive und zwar durch die Verzeichnisstruktur bis zu den einzelnen DB -bzw. Logfiles ? Welche Berechtigungen werden vererbt, welche nicht ? Das wäre denk noch sehr hilfreich, dieses Thema mal mit funktionierenden Umgebungen abgleichen zu können. :) Ganz lieben Dank vorab und nen wundervollen Tag alle miteinander.

Das hab ich natürlich in der Hinterhand, klar. Aber so ein Thema mit dem MS Support angehen ... no way ... da sind meine Erfahrungen mit MS Support über die letzten 8 Jahre einfach nur miserabel; freundlich ausgedrückt ;) -> Dienstleister ist erstmal die letzte Option. Theoretisch würde ich das auch so sehen, ja. Die Realität zeigt leider etwas anderes (siehe Beschreibungen hinsichtlich db maintenance die niemals abgeschlossen wird). Dabei weiß ich allerdings, dass weder vm storage/disks (dedicated luns) sauber konfiguriert sind, noch die volumes selbst (file allocation size nur 8 KB + ntfs statt refs). Gleichzeitig läuft auch noch das Netzwerk auf 1 statt 10 GB ... Diese Umstände werde ich jedoch erst beheben können mit einer Migration nach 2019 und neue Server (Metall) kommendes Jahr. Deshalb der versuchte workaround auf mehr aber kleinere dbs zu verteilen. Leider sieht es eben momentan so aus, dass der Server auf dem momentan alle Clientanfragen landen, alle dbs stabil laufen usw -> irgendwie korrupte kopien erstellt, selbst von neuen/leeren dbs. Der neue Server würde mir so nur Aufwände bringen, wenn ich im Anschluss nicht einfach hergehen kann und im Hintergrund neue Kopien ziehen lassen kann vom "main server". Dann scheint es mir sinnvoller auf dem aktuellen "Problemserver" den Storage zu erweitern, neue dbs zu erstellen, passive kopien auf den "main server" zu schieben und dann in diese dbs alle mbx verschieben (erfolgreiche switchover tests voraus gesetzt). Sobald das abgeschlossen ist, könnte ich dann die alten dbs wegschmeißen und so hoffentlich wieder in normal Modus übergehen. Jedenfalls würde so der Aufwand "Server neu aufsetzen und bestehende Konfigurationen angleichen" wegfallen. Grundsätzlich wäre jedoch schon interessant, wie das sein kann. Ein völlig normal operierender Server erstellt korrupte passive db Kopien auf DAG Mitgliedern ? Was kann dafür verantwortlich sein, will mir nicht einleuchten.

Aye, weine ihnen sehr vieles nach und bin da auch grundsätzlich und immer bereit für ne Diskussion Wollte allerdings das Faß in diesem Thread hier jetzt nicht noch weiter aufmachen xDD Ok, nächstes Update: Es wird immer spannender Im vorherigen Post hab ich ja noch mit einer neuen kopie einer existierenden DB gearbeitet ... jetzt mal mit was frischem: (1) Ich erstelle eine komplett neue, leere DB auf dem Problemserver (!) , migriere eine test-mbx rein, lege ne aktive kopie auf einen der anderen server..... mit dieser db kann ich problemlos switchover machen auf den anderen server und wieder zurück: 0 Probleme. (2) Ich erstelle eine komplett neue, leere DB auf dem main server (auf dem aktuell alle CAS Anfragen landen, generell der "main server", bisher stabil und ohne auffälligkeiten hinsichtlich dbs etc.). Dann lege ich eine neue aktive Kopie auf den Problemserver, manuelles seeding .... , keine mbx in dieser db ----> sobald ich diese passive kopie auf dem problem server mounten will geht das gleiche Fehlverhalten wieder los. Was macht denn das nun für einen Sinn ?

Ok, also ganz grundsätzlich: Ich hab die Umgebung vor ca. 1,5 Jahren von einem schon länger abwesenden übernommen. Nebst Einführung Teams Direct Routing, External Mail Security Anbieter ersetzen und vieler++++ anderer offener Baustellen, war da vergleichsweise wenig Zeit mich wirklich angemessen um die EXCH Umgebung zu kümmern ^^ Ich kenne die Empfehlungen hinsichtlich DB-sizes, ja. Alle Server sind bereits Enterprise-lizensiert (waren sie anfangs nicht), aber ich bemühe mich aktuell die db sizes wieder um die 2-400B zu bekommen; warum? -> server laufen auf vm infra, storage (disks) sind nicht vernünftig konfiguriert und die volumes auch 0 an EXCH best practices angelehnt. U.a. führt das dazu, dass die db maintenance auf keiner db jemals abgeschlossen wird. Das bekomme ich in den Griff, wenn die dbs so um die 200 - 400 GB sind, dann läuft die maintenance sauber durch. Die ganze Umgebung sukzessive auf neue, und dann sauber konfigurierte, Hardware zu migrieren ist in Planung, aber wird halt noch bis 2024 dauern bis ich damit loslegen kann; bis dahin muss ich improvisieren. Zu den Zahlen: Prinzipiell sind rund 550 mbx (user/shared) auf 4 dbs verteilt, wobei eine db rund 1++ TB groß war; insgesamt sprechen wir von ca. 5,7TB mbx-daten. Ich habe hier jedoch bereits begonnen eine der dbs zu splitten, weshalb sie aktuell nun auf 8 dbs verteilt sind. Das sollen noch mehr werden. Mindestens 2 weitere dbs hatte ich vor zu splitten, um die Größe pro db zu reduzieren. Was habt ihr denn da so für Erfahrungen aber welcher Anzahl dbs dieses "Verhältnis" zu ESE evtl. wieder kippt ? ^^ Zum vorliegenden Problem: Selbst ein vollständiges Löschen einer passiven Kopie im DAG, sicherstellen, dass auch das dazugehörige AD-Objekt weg ist, und anschließende Neuerstellung der db copy auf dem passive node, manuelles seeding .... keine Chance. Sobald diese db copy gemountet werden soll, beginnt wieder eingangs beschriebenes Fehlverhalten. Das leuchtet mir echt nicht ein (weil neue copy) und macht auch wenig Hoffnung, dass eseutil hier noch Abhilfe schaffen kann. Auch die Volume/Folder/File Berechtigungen für die neu erstellte Kopie entsprechend nun wieder exakt den Berechtigungen wie auch auf dem "main server"; keine Verbesserung ... Das ist echt seltsam. Was kann dazu führen, dass selbst eine neu gezogene Kopie von einer intakten db auf nem intakten Server im Anschluss in die gleichen Fehler reinläuft wie zuvor ? Da muss doch irgendwas im Argen sein, dass mit der db gar nichts zu tun hat .... ?

Hach, ich mag euch schon jetzt ;) Aye, stimme dir da prinzipiell vollkommen zu. Bin nur was MSEXCH betrifft noch nicht so fit und sattelfest, wie ich das zu meinen Domino-Zeiten quasi noch war. Deshalb der Anspruch hier tiefer zu graben; ist mein erstes mal mit so nachhaltigen db Problemen auf EXCH. Ein paar kleine Schritte weiter bin ich bereits: - Brandneue DB direkt auf "Problemserver" erstellt und eingehängt: Keine Probleme. Auch eine dorthin migrierte Testmailbox läuft einwandfrei. - Aktuell läuft ein fresh reseed einer der kleineren existierenden dbs, alle db -und logfiles zuvor gelöscht. Dauert noch ne Weile... --- Falls diese dann wieder sauber eingehängt bleibt, wäre das der erste Ansatz das Thema langfristig in den Griff zu bekommen. Allerdings dauert das Reseeding ne gefühlte Ewigkeit bei ca. 4 TB Daten :/ - Sobald ich mit dem Step zuvor fertig bin, werd ich die Kiste nochmal komplett in die maintenance schicken und offline nehmen. Alle betroffenen dbs dürften in nem "Dirty Shutdown" state sein, weshalb ich mal ein softrepair drüber laufen lassen will, um zu sehen ob das evtl. bereits hilft. Halte euch auf dem Laufenden. Alleine meine Gedanken hier reflektieren zu können hilft einfach schon ungemeint.

Hey grüßt euch alle miteinander :) Aye, ich war gestern etwas in Eile, frage sehr selten "extern" nach Unterstützung in beruflichen Belangen und hab deshalb sicher so einiges misachtet ^^ Ich bitte demütigst um Verzeihung - aufrichtig. Ich bin auch kein "MCSE" bzw. habe mich meistens geweigert zu den Lehrgängen die certs zu machen; halte nichts davon. Ich bin seit rund 20 Jahren im Infrastrukturbereich tätig, mit professionellem Fokus auf Netzwerk/Email-Security/Compliance und produktspezifischen Fokus auf IBM Notes/Domino (nostalgie-tränen kommen hoch ...) und eben seit etwa 8 Jahren dann auch wieder intensiv mit MSEXCH/M365/IDM/Telefonie Meint ihr ich soll den initialen Post nochmal ins Deutsche übersetzen (ausgenommen die Fehlermeldungen selbst usw., klar), oder genügt das fürs Erste ? Das müsste ich sicher in den Abend schieben. Bis dahin möchte ich kurz auf die bisherigen Vorschläge eingehen und auch noch aktualisieren aus meiner Perspektive: - Im Prinzip natürlich ein valider Ansatz (Server neu aufsetzen). Ich möchte jedoch zuvor noch einige andere Maßnahmen ergreifen :) - Nächste Schritte: komplett neue DB ins DAG + Kopie auf betroffenem Server, um zu sehen ob hier die gleichen Mount/Dismount (readfrompassive feature corruption) Events auftreten. Falls ja, würde ich z.B. auch nach Problemen am/"im" Volume/Storage selbst suchen. --- Server shutdown und db states mit eseutil überprüfen. Soft recovery wenn sinnvoll (dirty shutdown), hard recovery vermeiden. > dann erneut verifizieren. -----Alle passiven kopien weg, DAG auflösen, Volume auf betroffenem Server neu aufbauen (file allocation size ist eh nicht optimal) > DAG neu aufbauen und Kopien synchronisieren > dann erneut verifizieren. Mir geht es im wesentlichen darum herauszuzfinden was da eigentlich schief läuft. Also nicht "nur" alles wieder zum laufen bringen, sondern auch verstehen, zumindest näherungsweise, was die Probleme verursacht. Herzlichen Dank vorab für euer Mitdenken! Tobias

I have a 3 node DAG (EX2016, current patchlevel), 2 in "main" AD site and 1 in backup site. It's about 400 users homed in 9 mailbox databases currently. Since a few days on of the nodes in the main AD site doesn't keep db mounts anymore. So, when i e.g. do a manual switchover, the db is mounted properly for some seconds. Then a store transient error occurs, results in a disablement of "readfrompassive" feature, dismounts the db again and failing over to node 1 again or node 3 - depending the load. The "error structure" respectively the "process" happening when switching active copies to this server is always the same. I can reproduce it with every database on this server. Manual or automatic switchover to "node2" occurs, starting with Event 2090 informing about. Followed by 5 ESE informational events telling the log reply and db attaching. Then "MSExchangeIS" reports that the feature component "readfrompassive" (1061) has been re-enabled. Then the first error occurs "1001 - MSExchangeIS - MSEXCH info store encountered an internal logic error" Followed by an unhandled exception "1002 - processid perf counter (0) does not match actual process id.." Followed by a watson report error (4999) of the M.E.Store.Worker Only then the next error provides a bit (!) more information: "489 ESE - attempt to open edb-file for read only access failed with system error 32 (used by another process)" This is then followed by some Windows Error Reporting events (informational, 1001), some informational MSExchangeIS events (1021,40008,40036) ... Followed by another bunch of ESE events telling about log replays of the db about to be mounted ... ?? Funny enough ...: Only then "MSExchangeIS - 40008" reports that the db has been mounted successfully. Stopping worker process (1021) Starting MapiAddressBookAppPool (2000,2001) "MSExchange Mid-Tier Storage" informs about "PICW Core feature not enabled" (11000) Now another 4999 error is logged about "MSExchangeDelivery, M.ExchangeStoreProvider, M.E.M.S.DeliveryItem..." crashing > stacktrace result "MS.Mapi.CrossServerConnectionPolicy.Apply" Followed by 2 Windows Error Reporting informational events And finally followed by a ExchangeStoreDB event (126) informing about that a db copy on this server caused an error which resulted in dismounts. The reason should be looked up in previous events (see above ^^) Referring this it looks like that the server is trying to mount a db 3 times by default .... ? Every time it results in more or less same error events. What i have already tried: purge one of the passive copies on problematic node, delete related files and recreate the passive copy again newly Try to reproduce: Still failing as described above. Review file/folder permissions on db and log storage locations (separated disks/volumes). Actually there was an issue with partially incorrect permissions -> corrected all ownership back to administrators group and re-applied default permissions Unfortunately, this had also no effect at all - still same failing while activating db copy on this node Sending server to maintenance mode and shut down, check dbs with eseutil: all in dirty shutdown state (but still mounting even though only for a short time??) Read tons of kb articles and forum discussions related to such and similar behavior - no further insights unfortunately. Any help, ideas, tipps & tricks are highly appreciated. :)