Exchange 2010 - Mailboxfreigabe Auditierung und Logging

[wernbert 10]

Hallo Leute!

Wir haben hier einen User bei dem andauernd Mails verschwinden (IT intern wissen wir dass dieser ein Koffer ist und mit ziemlicher Sicherheit dafür selbst verwantwortlich ist.)

 

Der User ist nun zum Betriebsrat gegangen - vom Betriebsrat ist der Auftrag gekommen eine Liste aller User auszuwerten die auf ein anderes Userpostfach Zugriff haben.

Am besten noch - wenn möglich - von wann bis wann der Zugriff erteilt wurde (Urlaubsvertretung z.b).

 

Gibt es hier eine Möglichkeit dies auszuwerten?

bzw. wenn unter 2010 nicht, ev. durch ein Upgrade auf 2013? (dann hätten wir noch ein Argument mehr auf 2013 umzusteigen)

[NorbertFe 1.812]

Habt ihr keine Retention Time definiert? Meist findet sich da doch einiges, ohne riesigen Aufwand. Nur so als zusätzlicher Gedanke.

 

Bye

Norbert

[RobertWi 81]

Moin,

 

ergänzend zu Norbert:

 

Aktuelle "Freigaben" kann man mit Get-Mailboxpermission (administrativ), bzw. Get-Mailboxfolderpermission auslesen. Letzteres ist allerdings mühselig, da es keine Rekursion gibt.

 

Wann welche Berechtigung aktiv war wird ohne vorheriges Einschalten höchsten für den Admin protokolliert. Und ob diese Änderung in Outlook überhaupt protokolliert wird, glaube ich eher nicht.

 

Das hat sich auch mit Ex 2013 nicht geändert. Und man braucht auch keine Argumente, endlich umzusteigen - es gibt aber sehr viele, bloß nicht zu wechseln.

[wernbert 10]

Und man braucht auch keine Argumente, endlich umzusteigen - es gibt aber sehr viele, bloß nicht zu wechseln.

 

Könntest du mir diese ev. vl. mitteilen?

Vl. hast du schon Erfahrungen was uns auch betreffen würde...

 

@Norbert: User A hat die Mailbox von user B eingebunden - User A löscht in der Mailbox von User b etwas? Wo finde ich das gelöschte Mail dann in den Deleted Items bzw. im Outlook-Wiederherstellungs-Assistenten?

[NorbertFe 1.812]

In einer der beiden Mailboxen würde ich erstmal vermuten. Hab ich aber nicht getestet. Aber was spricht gegen einen schnellen Test an deinem System? ;)

[RobertWi 81]

Könntest du mir diese ev. vl. mitteilen?

Vl. hast du schon Erfahrungen was uns auch betreffen würde...

 

Da gibt es einige:

 - Neue Bedienoberfläche, der Features aus 2010 fehlen (muss dann via EMS gemacht werden)

 - schlechte bis keine Drittanbieterunterstützung (laufen Deine Virenscanner, Backup, Archiv, etc. mit Ex 2013?)

 - unsinnige Featureänderungen bei Dingen, die vorher problemlos funktioniert haben (z. B. hat das Einrichten einer DAG einen früher nicht notwendigen Schritt bekommen, ohne den die Einrichtung komplett scheitert)

 - Designänderungen im Rollenkonzept, die für erfahrene Admins mal wieder ein komplettes Neulernen erfordern und daraus entstandene andere Hardware-Anforderungen

 - veränderte und für Kunden aufwendige und fehlerträchtige Updates Strategie (= jedes Update ist quasi ein Servicepack und kann Schema-Änderungen enthalten und die Zusammenarbeit mit Dritt-Produkten brechen - es muss also intensiv getestet werden, kann aber gleichzeitig der einzige Weg sein, ein sicherheitskritisches Updates zu bekommen)

 

Der für mich aber schlimmste Punkt: Extrem schlechte Produktqualität. Bugs ohne Ende und oft die Frage, ist das ein neues Feature oder ein Bug ist. CU 2 musste zurückgezogen werden (der Fehler wurde nicht gefunden, weil das Ding intern gar nicht getestet wurde!) und das CU2v2 MUSSTE installiert werden, da man Exchange sonst nicht mehr updaten konnte (btw: Eine Deinstallation eines CU gibt es nicht mehr, die Kunden hatten das fehlerhafte CU2 an der Backe, bis zu Korrektur oder sie haben den Server neuinstalliert). Das CU 3 ist schon mindestens vier Wochen überfällig und wird einen Bug beinhalten, der intern schon bekannt ist, aber nicht mehr behoben werden kann - weil die Prozesse zu aufwendig sind. Einen weiteren Bug (wenig Auswirkung, aber fatale Außenwirkung) konnten die MVPs eventuell noch verhindern. Na ja, wobei erst der Release des CU3 zeigen wird, ob Microsoft diesen Bug (die Korrektur ist Peanuts, der Starttyp eines Dienstes ist verkehrt) beheben konnte oder in den Release Notes nur darauf hin weist.

 

Schau Dich einfach mal in den Foren um, wie viele Probleme mit Ex 2013 auftauchen, die es mit 2010 nicht gibt/gab. Sicher, ist das Ding neu und die Admins haben noch wenig Erfahrungen. Aber an so viele Installations-Probleme, die zum Totalverlust führten, kann ich mich bei 2010 nicht erinnern. Eines dieser Installationsprobleme hatte ich selbst in meiner Mini-Testumgebung (1x DC, 1x Ex 2013 - nichts los darin). Offensichtlich war es ein Fehler, die Windows Updates vor dem CU2v2 zu installieren. Das beschwerte sich danach, dass ein "Interims Update" auf der Kiste sei, das erst deinstalliert werden müsste. Es sagte mir aber nicht, welches. Und: Das fiel erst während der Installation auf. Ergebnis: Exchange komplett unbrauchbar, halb aktualisiert, Dienste deaktiviert und Null Informationen darüber. In der Testumgebung war die Reparatur einfach - Snapshot zurücksetzen und erst CU2v2, dann Windows Updates. In einer Produktivumgebung hätte das mehrere Stunden gedauert.

 

Jedes einzelne Problem ist oft nur ein "Problemchen", aber es zeigt, wie MSFT mit dem On-Prem-Produkt "Exchange 2013" umgeht und welche Bedeutung es hat. Es gehört schon einiges dazu, Kunden in Bugs laufen zu lassen, weil man selbst das Update nicht getestet hat und in der eigenen Cloud eine komplett anderen Updates-Weg fährt (eigentlich gar keinen, die Dinger werden im Rotationsprinzip immer wieder neuinstalliert).

[NorbertFe 1.812]

 

 

 - Neue Bedienoberfläche, der Features aus 2010 fehlen (muss dann via EMS gemacht werden)

Spontan fällt mir die Konfiguration der Antispam-Agents ein, wobei die wahrscheinlich nur überhaupt noch drin sind, weils sonst einen noch größeren Aufschrei gegeben hätte. ;)

 - schlechte bis keine Drittanbieterunterstützung (laufen Deine Virenscanner, Backup, Archiv, etc. mit Ex 2013?)

Gibt's überhaupt schon 3rd Party Virenscanner die Exchange 2013 sinnvoll Supporten? Nach Ausbau der vsapi würde mich das auch wundern. Wurde eigentlich irgendwo erklärt, warum die vsapi "schlecht" ist? ;)

 - Designänderungen im Rollenkonzept, die für erfahrene Admins mal wieder ein komplettes Neulernen erfordern und daraus entstandene andere Hardware-Anforderungen

Damit könnte ich als Dienstleister grad noch leben. ;)

 - veränderte und für Kunden aufwendige und fehlerträchtige Updates Strategie (= jedes Update ist quasi ein Servicepack und kann Schema-Änderungen enthalten und die Zusammenarbeit mit Dritt-Produkten brechen - es muss also intensiv getestet werden, kann aber gleichzeitig der einzige Weg sein, ein sicherheitskritisches Updates zu bekommen)

Das war grundsätzlich vorher auch schon so, nur war es dort eher Zufall und selten. Aber hier:

http://www.exchangeinbox.com/article.aspx?i=209 liest sich das wie beabsichtigte Strategie seitens MS. :(

 

 

Jedes einzelne Problem ist oft nur ein "Problemchen", aber es zeigt, wie MSFT mit dem On-Prem-Produkt "Exchange 2013" umgeht und welche Bedeutung es hat. Es gehört schon einiges dazu, Kunden in Bugs laufen zu lassen, weil man selbst das Update nicht getestet hat und in der eigenen Cloud eine komplett anderen Updates-Weg fährt (eigentlich gar keinen, die Dinger werden im Rotationsprinzip immer wieder neuinstalliert).

Kann ja gar nicht sein, da ja "cloud first" und "datacenter scale" getestet wird, kann das alles gar nicht sein. ;) Ich spar mir hier mal meine Meinung zu der derzeitigen Produkt-Service-Ausrichtung, da du meine Meinung oben grundsätzlich triffst.

[verschwörungstheorie=on]Wenn Exchange 2013 so schlecht als on-premise ankommt, ist die Schlußfolgerung dann wahrscheinlich, dass die nächste Version nur noch als Cloud Service angeboten wird, weil ja niemand zu Exchange 2013 wechseln wollte.[verschwörungstheorie=off]

 

 

Bye

Norbert

 

 

[RobertWi 81]

(Dein Zitat ist irgendwie falsch)

 

 

Das war grundsätzlich vorher auch schon so, nur war es dort eher Zufall und selten. Aber hier:

http://www.exchangei...icle.aspx?i=209 liest sich das wie beabsichtigte Strategie seitens MS. :(

 

 

Ich kann mich nicht erinnern, das ein RU unter 2007 oder 2010 Schema-Änderungen mitbrachte, bzw. Schnittstellen brach. Ein SP ja, aber kein RU.

 

Bei den CUs kann das aber mit jedem Update passieren. Und ich bekomme das CU im Notfall nicht mehr runter, ich muss neuinstallieren. In er Praxis führt daher jedes CU zu einem deutlich erhöhten Prüfaufwand.

 

Ach, eines fällt mir noch ein: Bei Ex 2013 ist es nicht mehr möglich, Rollen nachzuinstallieren oder wieder wegzunehmen. OK, das passt in das Rollenkonzept des Multi-Role-Servers, das MSFT vorsieht.

 

Und bei den Connectoren erinnere ich mich an einen Spruch eines anderes MVPs letzte Woche: "wo kann ich diesen mist mit den unterschiedlichen empfangsconnectoren (frontend usw.) nachlesen. sind die bei MS voll bekloppt?".... :)

 

Das meine ich mit: Bewährte Konzepte werden geändert (mir ist der technische Hintergrund klar, aber einen praktischen Nutzen hat das irgendwie noch nicht gebracht).

[NorbertFe 1.812]

 

Ich kann mich nicht erinnern, das ein RU unter 2007 oder 2010 Schema-Änderungen mitbrachte, bzw. Schnittstellen brach. Ein SP ja, aber kein RU.

Damit könnte die Mehrheit wahrscheinlich leben, wenn es eben nicht nur die Api's brechen würde, weils grad mal jemandem einfällt. Ich bin kein Entwickler, aber ich habe viele Kunden mit installierter Software für Disclaimer, Antispam und Backup draussen, wo solche Änderungen zu extrem hohem Planungsaufwand führen. Das war natürlich bei SPs ein wenig entspannter, da sehe ich klar auch so.

 

Bei den CUs kann das aber mit jedem Update passieren. Und ich bekomme das CU im Notfall nicht mehr runter, ich muss neuinstallieren. In er Praxis führt daher jedes CU zu einem deutlich erhöhten Prüfaufwand.

 

 

Wie mein Link zeigt, kann es nicht nur passieren, sondern es ist bisher immer passiert. Was 1. unschön ist für jeglichen ISV und 2. eigentlich zeigt, dass Exchange 2013 auch heute nach über einem Jahr nicht wirklich fertig ist. Und ganz ehrlich, da war sogar Exchange 2007 OHNE SP weiter und funktionaler. ;)

Und bei den Connectoren erinnere ich mich an einen Spruch eines anderes MVPs letzte Woche: "wo kann ich diesen mist mit den unterschiedlichen empfangsconnectoren (frontend usw.) nachlesen. sind die bei MS voll bekloppt?".... :)

Wer sagt denn sowas? ;) Und ja, recht hat er/ich. :D

 

 

Das meine ich mit: Bewährte Konzepte werden geändert (mir ist der technische Hintergrund klar, aber einen praktischen Nutzen hat das irgendwie noch nicht gebracht).

Sehe ich genauso.

 

Bye

Norbert

[wernbert 10]

@RobertWi:

Prinzipiell geb ich dir Recht - die WebGUI des 2013 kann nicht diesen Funktionsumfang wie 2010 - spricht aber nichts dagegen die Shell zu verwenden...

 

Drittherstellerunterstützung ist wirklich schlecht - da geb ich dir recht.

 

DAG-Einrichtung: aso? welcher Schritt wäre das? hab den 2013 aktuell nur in einer Single-Instanz laufen

 

Ok, die Veränderung des Rollenkonzeptes find ich persönlich nicht so schlecht...

 

Die updatestrategie ist leider wirklich kompletter Mist - nur das schlimme ist dass diese Strategie wahrscheinlich nicht mehr geändert wird.

 

Und zu Verschwörungstheorie von Norbert:

Na dann wird wohl hoffentlich ein Hersteller das fehlende Loch schließen wollen mit einem anderem Produkt in dieser Mächtigkeit wenn MS nur mehr ein Cloud-Provider werden will.. 

[NorbertFe 1.812]

Ok, die Veränderung des Rollenkonzeptes find ich persönlich nicht so schlecht...

Sie bringt dir aber (zumindest bei Single Server) auch genau keinen Vorteil, oder? ;)

Und zu Verschwörungstheorie von Norbert:

Na dann wird wohl hoffentlich ein Hersteller das fehlende Loch schließen wollen mit einem anderem Produkt in dieser Mächtigkeit wenn MS nur mehr ein Cloud-Provider werden will.. 

Wie gut das funktioniert sieht man ja bei TMG. ;) Das wurde abgekündigt und keiner der anderen Hersteller ist bisher in der Lage das TMG lückenlos zu ersetzen. Entweder fehlen viele Features oder das ganze ist so "komplex" in der Konfiguration, dass man das nicht machen will. ;)

 

Bye

Norbert