Attachments to Sharepoint

[schiesslt 10]

Hallo zusammen,

 

hoffe es passt vom Thema hier rein.

Bin mir nicht sicher, ob es ein Tool in dieser Variation gibt, Google fand auf jeden Fall nix befriedigendes.

 

Postfächer wachsen ja mittlerweile stetig.

Und das schlimmste sind die Attachments.

Deswegen bin ich auf der Suche nach einem PlugIn für Exchange, das bei Mail-Ankunft die Attachments aus den Mails in eine Sharepoint-Website lädt und in die Mail den Link zum File einfügt.

 

Prinzipell gibt es eine Lösung von MapiLab Attachment Save

Jedoch kann anscheinend dieses Tool nur in einen Folder speichern und nicht in SharePoint.

Alternativ wäre natürlich eine Möglichkeit mit Boardmittel bzw ein free Tool toll, aber für sowas zahlt man auch gerne Geld

 

Für Ideen und Anregungen bin ich sehr dankbar :)

[RobertWi 81]

Moin,

 

es gibt so Fragen, da habe ich mir in mehr als 10 Jahren Exchange noch nie Gedanke drüber gemacht - Mails inhaltlich auseinander reißen gehört dazu. :)

 

Im Ernst: Was bringt es Dir, wenn Du die Anlagen von einer Datenbank (Exchange), in eine andere Datenbank (Sharepoint) verschiebst, außer doppelte Arbeit, Mehraufwand bei Backup und Recovery, User-Verwirrung (wo ist meine Anlage?), usw.

[djmaker 95]

Das Stichwort ist HSM.

 

HSM :: hierarchical storage management :: Hierarchisches Speichermanagement :: ITWissen.info

 

Es gibt Produkte (u.a. von Symantec -> Enterprise Vault) die Email-Anlagen nach bestimmten Parametern aus dem Exchange entfernen und dort nur Links hinterlassen. Das Ganze geschieht transparent für den Anwender. Sofern das Backup sauber eingerichtet ist wird dieses auch erheblich entlastet. Es gibt dazu folgende Links:

 

Symantec Enterprise Vault | E-Mail- & Content-Archivierung

 

EMC SourceOne Email Management for Microsoft Exchange - Archiving

[RobertWi 81]

Danke für die Information.

 

Abgesehen von einem durchgängigen Archiv-System, wo die ganze Mail archiviert wird (und natürlich auch normale Dateien vom Fileserver, Daten von Sharepoint, usw.), sehe ich aber immer noch wenig Sinn darin, nur einen Teil aus der Mail herauszureißen.

[djmaker 95]

Du kannst für die Archivierung kostengünstigeren Speicher nehmen (z.B. SATA etc.), an den nicht so hohe Anforderungen bzgl. Performance gestellt werden.

 

Das Auslagern der Attachments wäre ggf. nur der Anfang. Der TO hat genau ein Problem adressiert und dafür eine Lösung bekommen. Ob das Geld dafür ausgegeben will muss er selber wissen. Zudem ist das ein wunderbarer Einstied die die revisionssichere Aufbewahrung.

[schiesslt 10]

Danke für die Links.

Bis zur Archivierung wollte ich eigentlich noch nicht gehen.

Aber HSM ist wirklich ein gutes Stichwort.

 

@Robert: der sinn ist eigentlich ganz einfach. wie djmarker schon sagte: günstiges Storage. Anlagen müssen nicht zwingend auf dem guten Storage (SAN) sein, sondern können ruhig auf iSCSI liegen.

Ausserdem gibt es eine Postfachbegrenzung und um diese einzuhalten gibt es nur ein paar Möglichkeiten:

1. löschen (was man rechtlichgesehen ja eigentlich nicht darf, da Firmenmails bis zu 30 Jahren (sind es 30??) aufgehoben werden müssen)

2. archivieren (eine "echte" revisionssichere Archivierungslösung ist teuer)

3. Attachments auslagern (Vorstufe zur Archivierung)

[RobertWi 81]

Moin,

 

@Robert: der sinn ist eigentlich ganz einfach. wie djmarker schon sagte: günstiges Storage. Anlagen müssen nicht zwingend auf dem guten Storage (SAN) sein, sondern können ruhig auf iSCSI liegen.

 

Die E-Mail stellt aber mit der Anlage eine Einheit dar. Entweder ist die ganze Mail "unwichtig", dann kann die ganze Exchange-DB auf billigen Store. Oder die Mail ist wichtig, dann gehört alles auf's SAN.

 

Wobei man einschränken muss, dass sich diese ganze Philosophie seit Exchange 2010 deutlich verändert hat und dank DAG-Technik die Verwendung billigem Storage deutlich einfacher ist.

 

Ausserdem gibt es eine Postfachbegrenzung und um diese einzuhalten gibt es nur ein paar Möglichkeiten:

1. löschen (was man rechtlichgesehen ja eigentlich nicht darf, da Firmenmails bis zu 30 Jahren (sind es 30??) aufgehoben werden müssen)

2. archivieren (eine "echte" revisionssichere Archivierungslösung ist teuer)

3. Attachments auslagern (Vorstufe zur Archivierung)

 

4. Größere Begrenzungen.

 

Deine Lösung 3 widerspricht Deinem Punkt 1. Denn billiger Store neigt zu höheren Ausfällen und damit zu Verlust. Oder Du machst den billigen Store aufwendig ausfallsicher, dass wiederum kostet Geld.

 

Das Problem dabei ist, und das erlebe ich jeden Tag in Diskussionen mit Kunden, dass sich Firmen nicht klar darüber sind, was sie wollen und wie wichtig die Verfügbarkeit für sie ist.

 

Im Endeffekt gibt es nur zwei Lösungen:

- wenn ich billigen Store nehme und Verlust in Kauf nehme, dann kann der Inhalt nicht so wichtig sein. Warum lösche ich den dann nicht gleich?

- wenn aber die Aufbewahrung wichtig ist (womöglich für 30 Jahre), bleibt mir nichts anderes, als ein professionelles System übrig; das kann ein Archivsystem sein oder DAG mit mind. drei Knoten, oder, oder.

 

Alles anders ist nur gebastelt und führt früher oder später zu mehr Problemen, als Lösungen.

 

Als Alternative: Hast Du schon mal die Exchange-Archivierung ins Auge gefasst? Ein zwei Knoten DAG nur für den Archiv-Teil mit "billigen" Storage ist auch nicht so schlecht.

[Dukel 454]

Auch im SAN gibt es unterschiedliche Storage. Schnelle und teure SAS / FC Disks und billigere SATA Disks.

 

Es spricht nichts dagegen Mails oder Anhänge, die x Jahre alt sind und auf die man kaum noch zugreift auf "günstigeren" Storage auszulagern. Noch ältere Daten kann man z.B. auch auf Band auslagern und wenn man dann eben solch eine Mail bekommt muss man ein klein wenig warten.

 

 

Btw. "Normale" gesetzliche Archivierung sind 10 Jahre. Im Medizinischen Bereich ist es länger (diese 30 Jahre z.B.).

[schiesslt 10]

@ Dukel: danke, dann sind es 10 Jahre :) (im Normalfall)

 

@ Robert:

also dass billiger Store zu erhöhtem Ausfall neigt, finde ich so jetzt nicht ganz richtig. iSCSI mit SATA Platten sind günstig, bieten meist Raid 6 und sind (für kleines Geld) mit redundantem Controller erhältlich.

 

Grössere Begrenzungen ist doch definitv keine Alternative? ich mach doch keine Restriktionen, damit ich sie später wieder aufhebe. Also ich würd mir dann irgendwie verars***t vorkommen ;)

Wir reden hier ja nicht von 200 MB Begrenzungen, sondern in der Regel von 2 GB.

 

Warum nicht wichtigen Inhalt löschen? weil du bzw der Anwender es im Grunde vom Gesetz her nicht darf! Wenn es geschäftliche Mails sind (und wir nehmen jetzt mal schön brav an, dass die Anwender Mails nicht für private Zwecke nutzen), müssen die eigentlich revisionssicher aufbewahrt werden. (okay, Revisionsicherheit erhalte ich hier ja auch nicht, das weiss ich.)

 

Wie willst du Exchange entscheiden lassen, welche mails "wichtig" oder "unwichtig" sind? den User lass ich sowas definitiv nicht entscheiden, also fällt schonmal die Alternative mit billigen Store für Exchange-DB aus.

 

wenn es eine solide Software ist (z.b. Mapilab), halte ich es nicht für Gebastel. man müsste natürlich das ganze mal ein wenig reuieren, wie es mit storageumzug, etc ist.

Open Source Software ist dagegen Gebastel.

 

Wo ich noch eine Möglichkeit sehe Speicherplatz zu sparen ist Storage mit DeDup. Hat da irgendwer Erfahrungen wie es mit der Exchange-DB ist? Stichwort eine Mail mit Anhang geht an z.B. 10 interne Empfänger. Wird die Mail in 10 Postfächern gespeichert, oder ist das immer nur ein Link auf eine Mail? (wenn die Mail 10x gespeichert wird, hätte ich einen weiteren Grund für das Auslagern ;) )

 

Archiv-Postfach von Exchange ist irgendwo vllt noch eine Möglichkeit, aber eine eigenständige 2-Knoten DAG für Archivierung hat natürlich auch was mit Kosten zu tun. (2x Server 2008 R2 Ent Lizenz und 2x Exchange 2010 Std Lizenz)

Aber ohne eigenständige DAG könnte man sich das ansehen.

[djmaker 95]

Nochmal als Klarstellung:

 

Bei "richtigen" HSM-Systemen wird nichts gelöscht. Es werden lediglich Speicherorte getrennt (oder die gesamte Email / Datei verschoben). Das Ganze geschieht aber transparent für den Endanwender und ändert ggf. nur etwas an der Zugriffsgeschwindigeit (Stichworte: Online-,Nearline-, Offline-Storage). Die Emails / Anlagen sind weiterhin direkt aus Outlook abrufbar.

 

Zur Archivierung in Exchange 2010:

 

Bei der Archivierungs-Funktion von Exchange 2010 sind folgende (kostenintesive) Punkte zu beachten:

 

Exchange 2010 Enterprise CALs

Office 2010 Pro / Enterprise wird benötigt

 

Für und Wider werden im folgenden bestens erläutert:

 

MSXFAQ.DE - PersonalArchiv

 

Ich sehe alle o.g. Lösungen ausschließlich im Enterprise-Bereich, nicht im 40 GB-DB-Umfeld.