[Exchange 2010] Hoe om te gaan met pst bestanden

[Verwijderd]

Met Exchange 2010 wilt Microsoft eigenlijk dat PST bestanden steeds minder gebruikt gaan worden.
Er kan nu namelijk gebruik worden gemaakt van het archief...
Allemaal leuk en aardig maar ik zit met een principe kwestie nu.

Mijn omgeving:
2x Exchange 2010 (vm's) middels DAG + Casarray.
150 gebruikers, 1 database.


Wij hebben zo'n 100 gig aan losse pst bestanden van gebruikers rondzwerven.
Veelal oude archieven van voorgaande jaren waar soms nog in gekeken wordt

Nu kan ik middels powershell alle pst bestanden koppelen aan de mailboxen van de gebruikers,
en ze zo dus op laten nemen in de hoofd database van mijn exchange server.
En vervolgens een archief regel activeren


Nadeel:
De database groeit met 100gig aan onbenullige data,
en met misschien wel een grotere kans op corruptie van de DB

Voordeel:
Alle pst's kan ik verwijderen

Hoe denken jullie over het uitfaseren van de pst-bestanden ?

[Question Mark]

Ik begrijp je vraag niet zo goed. Even ervan uitgaan dat je gebruikers aangeven deze data te willen bewaren vanwege hun werkzaamheden, dan importeer je die pst's toch?

Die 100 GB extra storage is nu ook niet zo wereldschokkend...

Laat ik het omdraaien, waarom zou je het niet doen?

[Coach4All]

Verwijderd schreef op dinsdag 11 december 2012 @ 09:43:
Nadeel:
De database groeit met 100gig aan onbenullige data,
en met misschien wel een grotere kans op corruptie van de DB
Voordeel:
Alle pst's kan ik verwijderen

Hoe denken jullie over het uitfaseren van de pst-bestanden ?

De archieven zet je toch op tragere / goedkopere / etc.. storage?
Een eigen DB (of meerdere db's) dus.
Ennuh.... tegen corruptie heb je toch wel een backup van de (archive) DB?
(De kans op corruptie in pst's is vele malen groter...)

[CMD-Snake]

Verwijderd schreef op dinsdag 11 december 2012 @ 09:43:
Nadeel:
De database groeit met 100gig aan onbenullige data,
en met misschien wel een grotere kans op corruptie van de DB

Je zit nu met 100Gb aan onbenullige data op je fileserver. Dus op je totale storage maakt dat argument niets uit. Het is broekzak of vestzak of die 100Gb nu op een Exchange bak zit of op je fileserver.

Microsoft biedt mooie (gratis) tooling om .pst bestanden op te importeren in Exchange. Ik zou die handel opruimen.

Wellicht dat je de gebruikers ook kan gaan overtuigen om hun mail en archief op te ruimen.

[Jazzy]

Coach4All schreef op dinsdag 11 december 2012 @ 11:11:
[...]


De archieven zet je toch op tragere / goedkopere / etc.. storage?
Een eigen DB (of meerdere db's) dus.

Dat lijkt me een beetje zonde voor maar 100 GB, dat is nog niet eens één disk. Levert alleen maar extra overhead op.

[Jazzy]

CMD-Snake schreef op dinsdag 11 december 2012 @ 11:17:
[...]
Microsoft biedt mooie (gratis) tooling om .pst bestanden op te importeren in Exchange. Ik zou die handel opruimen.

Importeren is één, maar dan kan het PST bestand nog steeds aan het Outlook profiel gekoppeld zijn. Dat is dus iets om ook even goed naar te kijken.

De tool die je bedoelt trouwens is PST Capture.

[Verwijderd]

Jazzy schreef op dinsdag 11 december 2012 @ 12:11:
[...]
Importeren is één, maar dan kan het PST bestand nog steeds aan het Outlook profiel gekoppeld zijn. Dat is dus iets om ook even goed naar te kijken.

De tool die je bedoelt trouwens is PST Capture.

Of via dit commando ?

New-MailboxImportRequest -Mailbox user -FilePath \\localhost\d$\archive.pst -IsArchive


In ieder geval om op jullie vraag terug te komen, misschien is het ook een gevoelskwestie..
PST bestanden importeren.. terwijl ze nu lekker lokaal op pc's staan waar ik er verder geen last van heb..

[Jazzy]

Als je niet overtuigd bent van de nadelen van PST bestanden dan hoef je ze natuurlijk ook niet te importeren.

Paar redenen waarom andere mensen er vanf willen:
- Staan lokaal dus kwijt bij crash HD of verlies/diefstal laptop
- Staan op een share dus niet supported, meer kans op corruptie en veel handles naar je fileserver
- Niet beschikbaar via mobile, tablet of webinterface
- Niet centraal doorzoekbaar
- Afwijkende backup/restore procedure

Wat het cmdlet betreft, die doet alleen het importeren. De PST Capture tool kan PST bestanden localiseren en vervolgens centraal importeren, dus ook als het bestand op de C:-schijf van een laptop staat.

[ebia]

Je kunt het ook over een hele andere boeg gooien: waarom staat er zoveel belangrijke informatie in e-mailwisselingen, en hoe komt het dat dergelijke inhoud niet op een andere manier geborgd is?

Ik zou me daar wat meer voor inspannen dat te gaan regelen, dan dat je met allerlei kunstgrepen iets met je pst files gaat doen (broekzak/vestzak verhaal). (Alhoewel ik wel van mening ben dat je beter veel data op je Exchange server kunt laten staan, dan archief op te gaan bouwen in de vorm van PST bestanden).

[Verwijderd]

Wij zijn nu 'mail archive' aan het bekijken, dit moet PST bestanden overbodig maken. Alle mail die een bepaalde periode niet is gebruikt wordt weggeschreven naar een externe goedkope SAN. Exchange zelf is dan sneller te restoren in geval van nood, gebruikers hoeven geen mail weg te gooien (of PST BackUp te maken).

Google er zelf maar eens op, misschien is dit ook voor jou een oplossing.

[Jazzy]

Verwijderd schreef op dinsdag 11 december 2012 @ 13:44:
Wij zijn nu 'mail archive' aan het bekijken, dit moet PST bestanden overbodig maken. Alle mail die een bepaalde periode niet is gebruikt wordt weggeschreven naar een externe goedkope SAN. Exchange zelf is dan sneller te restoren in geval van nood, gebruikers hoeven geen mail weg te gooien (of PST BackUp te maken).

Denk je dat de investering te rechtvaardigen bij 100GB aan archief? Nog los van de vraag of de TS meerdere SANs tot zijn beschikking heeft.

[Killah_Priest]

Sinds sp1 voor Exchange 2010 kan je persoonlijke archieven ook in een aparte mail database opslaan dus de kans dat je Exchange omgeving hieronder te lijden heeft is klein.

[CMD-Snake]

Killah_Priest schreef op woensdag 12 december 2012 @ 23:20:
Sinds sp1 voor Exchange 2010 kan je persoonlijke archieven ook in een aparte mail database opslaan dus de kans dat je Exchange omgeving hieronder te lijden heeft is klein.

Als het VM's zijn heb je dikke kans dat hun storage een SAN is. Ik denk dat het dan weinig uitmaakt, het eindigd allemaal op die SAN. Het lijkt me dat een SAN wel snel genoeg is om geen merkbaar performance verlies te hebben als die DB groter is.

Een archief is wel een goed idee, zeker als er een maximale grootte is voor een mailbox. Maar ik weet niet of een aparte DB ervoor echt zal lonen.

[Jazzy]

CMD-Snake schreef op vrijdag 14 december 2012 @ 08:46:
Een archief is wel een goed idee, zeker als er een maximale grootte is voor een mailbox. Maar ik weet niet of een aparte DB ervoor echt zal lonen.

Als we het hier hebben over het Exchange Personal Archive hebben, waarom is dat dan een goed idee? Vraag het even omdat ik benieuwd ben hoe jullie hier tegenaan kijken.

[Paul]

CMD-Snake schreef op vrijdag 14 december 2012 @ 08:46:
Als het VM's zijn heb je dikke kans dat hun storage een SAN is. Ik denk dat het dan weinig uitmaakt, het eindigd allemaal op die SAN. Het lijkt me dat een SAN wel snel genoeg is om geen merkbaar performance verlies te hebben als die DB groter is.

Maar het SAN kan dan wel de pages van de productie-database op snellere storage zetten en die van de archief-DB op langzamere. Nu kan dat ook wel als alles in één database zit maar dan loop je kans dat al die mailtjes op storageniveau door elkaar staan en er dus veel meer pages 'hot' zijn.

Daarnaast hoef je zo'n archief misschien minder vaak of op een andere manier te backupen en is een kleinere store sneller te restoren als er iets is dan een grotere

[Killah_Priest]

CMD-Snake schreef op vrijdag 14 december 2012 @ 08:46:
[...]


Als het VM's zijn heb je dikke kans dat hun storage een SAN is. Ik denk dat het dan weinig uitmaakt, het eindigd allemaal op die SAN. Het lijkt me dat een SAN wel snel genoeg is om geen merkbaar performance verlies te hebben als die DB groter is.

Een archief is wel een goed idee, zeker als er een maximale grootte is voor een mailbox. Maar ik weet niet of een aparte DB ervoor echt zal lonen.

Ik doelde zelf vooral op het feit dat de ts bang was voor een corrupte mail database.

[Charlie932]

Je "gewone" maildatabase kan je qua performance het beste op een mirror volume zetten op het san. Zo'n archief kan ook prima op een raid5 volume op het san.

[Turdie]

Jazzy schreef op vrijdag 14 december 2012 @ 10:00:
[...]
Als we het hier hebben over het Exchange Personal Archive hebben, waarom is dat dan een goed idee? Vraag het even omdat ik benieuwd ben hoe jullie hier tegenaan kijken.

Omdat het archive dan overal beschikbaar is voor de gebruiker. PST's zijn niet beschikbaar via OWA en een personal archive volgens mij wel.

Wat ik wel een nadeel vindt is dat het Personal Archive van de gebruiker als de Mailbox database waar de mailbox van de gebruiker inzit, zou mooi zijn als alle personal archives binnen een andere aparte mailbox database opgeslagen kunnen worden.

[ Voor 3% gewijzigd door Turdie op 15-12-2012 23:28 ]

[Razwer]

Archive mailboxes zijn een leuk idee, however, er zijn wat caveats waar je rekening mee moet houden voordat je gaan implementeren.
Enterprise CALs zijn vereist.
Outlook (2010/2013) Pro Plus (VLK versie) is vereist.
Heb je geen Outlook Pro Plus, komt je archive mailbox niet naar voren (wel in OWA natuurlijk). Met een simpele google query zal je zien dat verkeerde outlook versie de meest voorkomende denkfout is met deze oplossing...

shadowman12 schreef op zaterdag 15 december 2012 @ 23:06:
[...]
Wat ik wel een nadeel vindt is dat het Personal Archive van de gebruiker als de Mailbox database waar de mailbox van de gebruiker inzit, zou mooi zijn als alle personal archives binnen een andere aparte mailbox database opgeslagen kunnen worden.

Je draait zeker nog geen SP1? Is in SP1 opgelost

[ Voor 32% gewijzigd door Razwer op 16-12-2012 12:26 ]

[Jazzy]

shadowman12 schreef op zaterdag 15 december 2012 @ 23:06:
[...]


Omdat het archive dan overal beschikbaar is voor de gebruiker. PST's zijn niet beschikbaar via OWA en een personal archive volgens mij wel.

Maar daar heb je geen Personal Archive voor nodig, dan is het veel goedkoper om de PST gewoon in de mailbox te importeren.

[CMD-Snake]

Jazzy schreef op vrijdag 14 december 2012 @ 10:00:
[...]
Als we het hier hebben over het Exchange Personal Archive hebben, waarom is dat dan een goed idee? Vraag het even omdat ik benieuwd ben hoe jullie hier tegenaan kijken.

Een archief functie is handig als je quota hebt gezet op hoe groot een mailbox kan worden. Anders heb je na import direct in de mailbox meteen users die niets meer kunnen tot ze eens opruimen.

Ik heb gebruikers meegemaakt die .pst's hadden die bijna 10Gb groot waren. Persoonlijk ben ik niet wild van alles in pst's bewaren. Gebruikers moeten gewoon van tijd tot tijd hun mailbox opruimen, al dan niet met wat dwang. Je fileservers vervuilen ook. Mensen slaan op de meest gekke locaties hun .pst's op.

[Jazzy]

CMD-Snake schreef op maandag 17 december 2012 @ 08:42:
[...]


Een archief functie is handig als je quota hebt gezet op hoe groot een mailbox kan worden. Anders heb je na import direct in de mailbox meteen users die niets meer kunnen tot ze eens opruimen.

Ik heb gebruikers meegemaakt die .pst's hadden die bijna 10Gb groot waren. Persoonlijk ben ik niet wild van alles in pst's bewaren. Gebruikers moeten gewoon van tijd tot tijd hun mailbox opruimen, al dan niet met wat dwang. Je fileservers vervuilen ook. Mensen slaan op de meest gekke locaties hun .pst's op.

Maar ook hier de vraag, waarom importeer je het dan niet gewoon in de aktieve mailbox? Dan bereik je het zelfde doel maar het kost je geen Enterprise CAL, geen extra beheerlast of overhead en de gebruiker kan gewoon met één zoekopdracht in zijn hele mailbox zoeken.

[wagenveld]

Mijn redenering achter personal archives is dat je het hele zooitje op langzame SATA storage kan plakken. Tweede argument is dat je ervoor zorgt dat de actieve mailbox niet te traag wordt. Ja, meer dan 10GB is geen probleem voor een mailbox maar >10000 items per folder wel. Outlook 2013 voegt daar trouwens nog aan toe dat niet de hele mailbox gedownload wordt maar (standaard) alleen de laatste 6 maanden.

[Jazzy]

Het aantal items in een mailfolder bij Exchange 2010 al 100.000 ipv. 10.000. En hebben we het met een trage mailbox dan over online of cached mode?

Als je ook trage SATA storage hebt, waarom zet je dan niet je hele database op die storage? Ik denk dat 90% van de omgevingen in de praktijk niet meer IOPs vraagt dan je met SATA kunt bieden. Tenminste, ik ontwerp en bouw tientallen servers per jaar en heb nog nooit een omgeving getroffen waar dit werkelijk hout snijdt. Zit me echt af te vragen of iederen elkaar napraat over de archieven of dat dit echt allemaal valide redenen zijn.

[CMD-Snake]

Jazzy schreef op maandag 17 december 2012 @ 13:35:
[...]
Maar ook hier de vraag, waarom importeer je het dan niet gewoon in de aktieve mailbox? Dan bereik je het zelfde doel maar het kost je geen Enterprise CAL, geen extra beheerlast of overhead en de gebruiker kan gewoon met één zoekopdracht in zijn hele mailbox zoeken.

An sich geen probleem om het in de actieve mailbox te stoppen.

wagenveld schreef op maandag 17 december 2012 @ 13:52:
Mijn redenering achter personal archives is dat je het hele zooitje op langzame SATA storage kan plakken. Tweede argument is dat je ervoor zorgt dat de actieve mailbox niet te traag wordt. Ja, meer dan 10GB is geen probleem voor een mailbox maar >10000 items per folder wel. Outlook 2013 voegt daar trouwens nog aan toe dat niet de hele mailbox gedownload wordt maar (standaard) alleen de laatste 6 maanden.

De meeste storage producten hebben standaard SAS schijven. En waarom zou je niet je gewone SAN ervoor gebruiken? In het geval van TS is 100Gb bijna niets voor een SAN.

[Razwer]

CMD-Snake schreef op maandag 17 december 2012 @ 14:16:
[...]
De meeste storage producten hebben standaard SAS schijven. En waarom zou je niet je gewone SAN ervoor gebruiken? In het geval van TS is 100Gb bijna niets voor een SAN.

Sommige SAN storage bied combinaties van SAS en SATA en soms ook nog SSD in de mix. Het ligt er helemaal aan hoe je (enterprise) omgeving er uit ziet en wat voor spul je hebt en wat je budget is.
Je eigen omgeving vergelijken met die van anderen is appels met peren vergelijken. Wat voor de ene organisatie een op oplossing is, is voor de andere misschien aso duur en andersom. Een beetje kort door de bocht van je dus...

[Jazzy]

Razwer schreef op maandag 17 december 2012 @ 23:35:
Een beetje kort door de bocht van je dus...

Maar dat geldt ook voor almaar zeggen dat je de archiefdatabase op goedkope storage kunt zetten. Ik heb in de afgelopen twee jaar nog nooit een praktijkcase gezien waarin dat de beste en voor de hand liggen optie was. Het blijkt zelfs moeilijk om uberhaubt houtsnijdende argumenten voor het personal archive boven tafel te krijgen.

[Razwer]

Jazzy schreef op dinsdag 18 december 2012 @ 08:14:
[...]
Maar dat geldt ook voor almaar zeggen dat je de archiefdatabase op goedkope storage kunt zetten.

eens, maar die uitspraken doe ik niet

Jazzy schreef op dinsdag 18 december 2012 @ 08:14:
[...]
Ik heb in de afgelopen twee jaar nog nooit een praktijkcase gezien waarin dat de beste en voor de hand liggen optie was. Het blijkt zelfs moeilijk om uberhaubt houtsnijdende argumenten voor het personal archive boven tafel te krijgen.

Ik kan je een praktijk case geven waar ik nu mee bezig ben
Het bedrijf waar ik werk is een cloud boer waarbij een klant zijn exchange bak hosted heeft staan. Klant betaald bedrag X voor SAN storage op SAS en bedrag Y voor SATA storage. Klant kiest er voor om 1tb op SATA te zetten voor online archives ivm kosten

[ Voor 48% gewijzigd door Razwer op 18-12-2012 08:43 ]

[Jazzy]

Dan vraag ik toch even door. Wat zijn de IOPs op zijn mailboxdatabases waardoor die ook niet op SATA kon maar op SAS moest?

[Razwer]

geen idee, server is nog niet live en is een project waar ik net pas ben in gedoken. Ik werk pas sinds deze maand bij deze boer. Volgens mij is het SOP om klanten op SAS te zetten (alles is virtueel, hyper-v 2012).

[Question Mark]

Dus de kans bestaat dat de klant betaald voor "dure" storage, terwijl dit qua requirements niet eens nodig is.

Benodigde IOPS zijn vooraf al vrij secuur te bepalen: Exchange 2010 Mailbox Server Role Requirements Calculator

[Razwer]

Zoals ik zei, SOP (standard operating procedure). Ik bepaal het business model niet.

[Jazzy]

Okay, maar we waren (ik ben, tenminste ) eigenlijk op zoek naar een valide usecase voor het personal archive op aparte storage. Nog steeds niet gevonden dus.

[Razwer]

tjah daar zijn de meningen over verdeeld. In het business model wat hier gehanteerd wordt is het dus wel valide
Je hebt een punt als je politiek niet een valide punt vind, maar helaas heb je toch vaak met politieke beslissingen te maken bij het toepassen van technische oplossingen wat het automatisch wel valide maakt

[wagenveld]

Wij hebben 1 klant (jawel) waar geen limieten zijn geimplementeerd. Top 10 gebruikers hebben dus meer dan 20GB aan maildata met een uitschieter aan de top naar 75GB (geen grapje). Dit is vanuit het bedrijf besloten. Ze hebben ook een SAS/SATA SAN met ~10TB aan SATA storage voor de backup en dus mail archief.
Twee punten hier, niemand wil een 75GB OST bestand maar mail moet wel centraal gebackupt kunnen worden. Tweede is een DR oplossing die van de gehele omgeving een backup draait welke binnen een bepaalde tijd voltooid moet zijn. Mail archief wordt hier niet bijgerekent. Logische beslissing dus om de personal archive store op SATA te plakken zodat het automatisch niet wordt meegenomen in de DR oplossing.

[Question Mark]

Razwer schreef op dinsdag 18 december 2012 @ 12:23:
In het business model wat hier gehanteerd wordt is het dus wel valide

Even een offtopic opmerking hoor, maar het is wel een beetje een vreemd businessmodel. Hanteer dan verschillende prijzen voor de diverse mailboxlimieten. Voordeel is dat er geen Enterprise call's nodig zijn, en dat men waarschijnlijk met goedkopere storage af kan...

Opmerking is overigens niet persoonlijk bedoeld hoor.

[ Voor 7% gewijzigd door Question Mark op 18-12-2012 12:46 ]

[CMD-Snake]

Razwer schreef op maandag 17 december 2012 @ 23:35:
[...]
Sommige SAN storage bied combinaties van SAS en SATA en soms ook nog SSD in de mix. Het ligt er helemaal aan hoe je (enterprise) omgeving er uit ziet en wat voor spul je hebt en wat je budget is.
Je eigen omgeving vergelijken met die van anderen is appels met peren vergelijken. Wat voor de ene organisatie een op oplossing is, is voor de andere misschien aso duur en andersom. Een beetje kort door de bocht van je dus...

Mijn punt voor de TS is meer, waarom als je al ruimte ergens hebt op een SAN (als die toevallig dan over SAS schijven beschikt) zou je een aparte storage oplossing maken met SATA schijven. Je moet daar weer apart voor investeren.

Ik zou nu zo zeggen, gewoon in je hoofd DB gooien die zooi.

[Paul]

CMD-Snake schreef op dinsdag 18 december 2012 @ 13:14:
Je moet daar weer apart voor investeren.

Als je het zo geïsoleerd bekijkt wel. Als je echter als lokale storage-guru bemerkt dat je storage tekort gaat komen en je budget is door het tegenvallende bedrijfsresultaat niet bijster groot (geen heel onwaarschijnlijk scenario ) dan moet je gaan beslissen _waarin_ je gaat investeren.

En als dan de keuze is 'SATA' of 'niks' dan ga je kijken wat je allemaal hebt dat het met de mindere performance van een SATA-array kan doen (Mits je al Enterprise CALs en Office Pro Plus hebt )

[ Voor 4% gewijzigd door Paul op 18-12-2012 13:43 ]

[Jazzy]

wagenveld schreef op dinsdag 18 december 2012 @ 12:28:
Twee punten hier, niemand wil een 75GB OST bestand maar mail moet wel centraal gebackupt kunnen worden. Tweede is een DR oplossing die van de gehele omgeving een backup draait welke binnen een bepaalde tijd voltooid moet zijn.

Bingo! Voor zover ik kan zien zijn dit de enige twee valide redenen om het Personal Archive te gebruiken, waarbij het verkleinen van de OST file degene is die ik dan nog wel eens vaker zie.

Verder blijf ik iedere keer als iemand personal archive zegt, vragen naar het waarom.

[wagenveld]

Jij was ons dus gewoon aan het testen

[CMD-Snake]

Paul schreef op dinsdag 18 december 2012 @ 13:37:
[...]
Als je het zo geïsoleerd bekijkt wel. Als je echter als lokale storage-guru bemerkt dat je storage tekort gaat komen en je budget is door het tegenvallende bedrijfsresultaat niet bijster groot (geen heel onwaarschijnlijk scenario ) dan moet je gaan beslissen _waarin_ je gaat investeren.

En als dan de keuze is 'SATA' of 'niks' dan ga je kijken wat je allemaal hebt dat het met de mindere performance van een SATA-array kan doen (Mits je al Enterprise CALs en Office Pro Plus hebt )

Mee eens. Maar dan zouden we ook elke keer moeten gokken wat iemand theoretisch kan spenderen.

SATA storage is natuurlijk beter dan geen. Overigens heb ik wel bij kleinere omgevingen met weinig gebruiker servers ingericht met alleen SATA schijven. Paste beter in het budget en performance was ruim voldoende.

[Jazzy]

wagenveld schreef op dinsdag 18 december 2012 @ 16:48:
Jij was ons dus gewoon aan het testen

Dat niet, maar ik hoor mezelf steeds zeggen dat het personal archive alleen nuttig is om je OST klein te houden en zie anderen toch personal archives adviseren met zelfs een aparte database op andere storage. Naast het sneller kunnen restoren van de jongste data heb ik geen steekhoudende argumenten gezien die de kosten van een personal archive rechtvaardigen.

[ Voor 24% gewijzigd door Jazzy op 19-12-2012 07:41 ]