ANSKAFFELSE AF FÆLLES MAIL- OG KALENDER- SYSTEM.

Transkript

1 ANSKAFFELSE AF FÆLLES MAIL- OG KALENDER- SYSTEM. Projektgruppe: Bjarne Poulsen (DJF), Peter Frost (ASB), Svend Aage Lund Mogensen (HUM), Søren Christensen (NAT), Søren Juhl (SUN), Søren Staunsager (SAM), Jens Hørlück (AU IT). 0. Ordforklaring Indstillinger Indstilling vedr. teknologivalg for nyt mail og kalendersystem Brugerstyring Indstilling vedr. organisering af drift af det fælles system Indstilling vedr. projektets organisering og selve migreringen Indstilling vedr. politikker for mail- og kalendersystemet Valg af teknologi Funktionskrav Økonomi vedr. anskaffelse Karakteristik af de 5 tekniske løsninger Idriftsættelse og migrering Plan ved sekventiel migrering Plan ved parallel migrering Migrering af FirstClass Økonomi i migrering Bilag A: krav til det kommende mail- og kalendersystem Mail- og kalender: Specifikation af krav til løsning Bilag B: Kortlægning af anvendelse af Mail og Kalender på AU Fordeling på brugere Specielle anvendelse og integrationer Bilag C Projektgruppens arbejde Nyt mail- og kalendersystem V 1.0 Side 1

2 0. Ordforklaring Notatet er fyldt med indforståede tekniske begreber og vendinger og derfor har vi valgt at give en kort forklaring på de væsentligste. Data Arbejdsstation Servere Valget står mellem forskellige leverandørers software på serveren. Gruppen har set og fået beskrevet 4 forskellige tekniske løsninger: Microsoft Exchange, VMWare med Zimbra, IBM Lotus Notes / Domino samt Oracle Beehive. FirstClass var inde i billedet; men kunne ikke leve op til et par væsentlige krav. I slutfasen blev udelukkende Exchange og Zimbra vurderet. I tilknytning hertil kan man vælge at lagre data på forskellige måder. Hver leverandør har sin anbefaling; men vi behøver ikke følge anbefalingen. Brugeren kan anvende mail og kalender via en browser eller via en klient på egen PC. Identitetsstyring, herunder rettigheder (login) på egen PC til mail og alle andre systemer, foretages i et specielt register. AU har implementeret et IDM, der skal bruges som grundlag for identitetsstyring. SAN: Disklager som selvstændig enhed, koblet til servere via netværk. SATA diske: billige diske som i PC er. Virtualisering: et logisk lag mellem disklager og server, så man kan organisere den fysiske datalagring uden at applikationen kender den. Alle 4 leverandører har deres egen klient. Desuden kan Microsoft Outlook bruges som klient hos de tre andre leverandører, d.v.s. uanset valget af serversoftware kan Outlook brugere fortsætte som hidtil. Den vedtagne standard protokol hedder LDAP. Microsofts variant af LDAP hedder AD. De tre andre bruger LDAP. AU s IDM kan snakke LDAP. Microsoft s Exchange kan ikke udveksle direkte med AU s IDM, men skal have et AD register som mellemled. Nyt mail- og kalendersystem V 1.0 Side 2

3 1. Indstillinger 1.1. Indstilling vedr. teknologivalg for nyt mail og kalendersystem. Der er enighed om, at AU kun skal etablere én sammenhængende mail- og kalenderløsning. Der er enighed om, at både Exchange og Zimbra kan løse opgaven som den fælles platform for mail- og kalender. Med en eksisterende kompetence og med udgangspunkt i AU s installerede systemer er der flertal for at etablere en Exchange 2010 løsning. Exchange er et velkendt produkt og der findes kompetencer på AU i Exchange. Der er ingen initiale licensomkostninger og de fleste standardprodukter har etableret integrationsmulighed til Exchange. Zimbra tilbyder en mere moderne arkitektur med åbne standarder, lettere at udvikle integration med andre systemer, klientsoftware kan afvikles på alle platforme, brugere, der ønsker det, kan anvende Outlook og Zimbra s webgrænseflade er en tro kopi af Zimbra s klientgrænseflade. Der foreslås etableret en løsning med spejling af applikation og data på to separate server rum for at sikre stabil drift. Udenfor selve mailsystemet etableres en pakkepost service, hvor store filer kan uploades og hentes. Endvidere lægges avancerede mail-lister i en separat applikation Brugerstyring Der oprettes et nyt AD, dækkende både ansatte og studerende ved AU. I første omgang skal det fælles AD udelukkende anvendes til identitetsstyring af Exchange. Dette projekt omfatter IKKE en migrering af andet til et nyt AD, idet det vil forlænge projektforløbet ganske væsentligt 1. Alle brugere på AU vil derfor i en længere periode være tilknyttet to AD / LDAP og det er derfor væsentligt, at der som minimum kan etableres same sign-on via IDM. Det nye fælles AD skal opdateres fra IDM og kun indeholde data, der også findes i eksisterende AD. Det kan ikke undgås, at denne løsning med to AD vil medføre gener for brugerne og der bør derfor arbejdes på at den fælles AD bliver autoritativ for alle. Denne proces forventes at tage adskillige år Indstilling vedr. organisering af drift af det fælles system. Projektgruppen har drøftet mulighederne for drift af et fælles system med hhv brugere og brugere. Support forudsættes at ligge i de lokale miljøer; medens en fælles driftsorganisation dels skal varetage selve driften af systemet, dels 2. niveau support. Gruppen er enige om, at ingen af de nuværende driftsmiljøer er i stand til at påtage sig driften af et så omfattende system med Microsoft Exchange. Der er enighed om, at der samlet set findes kompetence i de eksisterende driftsmiljøer; men at den er spredt og at de relevante personer alle udfører opgaver udover drift og support af Exchange. Det driftsmiljø, der skal varetage driften, skal således tilføres ressourcer fra andre miljøer. 1 Andet inkluderer både egen PC, printeradgang, adgang til alle andre systemer etc. Nyt mail- og kalendersystem V 1.0 Side 3

4 NFIT mener, at de ville kunne drifte en fælles løsning med Zimbra, idet komponenterne er velkendte for NFIT og skalering ikke er noget større problem. En kommende drifts- og supportorganisation skal etableres som noget af det første og organisationen skal være involveret i migreringen. Det forudsættes, at personer i denne driftsorganisation får den nødvendige uddannelse. Etablering af en driftsorganisation med tilstrækkelige samlede ressourcer er derfor afgørende for at der kan migreres med en acceptabel tidsplan Indstilling vedr. projektets organisering og selve migreringen. Det foreslås, at projektet bemandes med en projektleder fra AU IT, der har ansvaret for koordineringen indenfor projektgruppen, koordinering med eksterne leverandører og med de lokale AU driftsenheder. Det foreslås, at der oprettes en referencegruppe, hvor alle lokale AU driftsenheder er repræsenteret. Referencegruppen har to formål: dels at sikre, at der er tilstrækkeligt med ressourcer til rådighed lokalt til art gennemføre projektet og at de har den fornødne tid, når der er brug for det, dels at bidrage undervejs til opsamling af erfaring med selve migreringen. Når en enhed migreres er der to sæt af opgaver: - Teknisk migrering, der foretages af konsulentfirmaet. Herunder hører mapning af brugere fra eksisterende AD (LDAP) over i nyt AD (LDAP). - Information til brugere, planlægning af migrering, opsætning af PC er, støtte til brugere, samt støtte til konsulentfirmaet m.h.t. lokalkendskab. Det er projektgruppens vurdering at der ikke findes tilstrækkeligt med ressourcer på AU til at stå for hele migreringen, såfremt det skal foregå i et tilstrækkeligt højt tempo. Gruppen indstiller derfor, at der anvendes konsulentassistance i betragteligt omfang til at forestå den tekniske del af migreringen. Flere konsulentfirmaer har erfaring fra lignende projekter, som f.eks. konsolidering af mail i én installation for Region Midt, Region Hovedstaden og Københavns Kommune. Samtidigt skal der etableres en AU projektgruppe med tilstrækkelig bemanding til at projektet kan få den nødvendige fremdrift i opsætning af klienter og brugersupport til migreringen. Gruppen foreslår, at hver enheds migrering bemandes med mindst én person, der kender den lokale opsætning og de lokale brugere samt et rejsehold, der er involveret fra starten og som har / opnår erfaring med migrering. På denne måde kan der opretholdes et tilstrækkeligt højt tempo og et niveau af support, der giver mindst mulig spildtid blandt brugerne. Nyt mail- og kalendersystem V 1.0 Side 4

5 Samlet set foreslår projektgruppen, at planen, skitseret i 3.1 følges. Den indebærer at: - Det tager 15 mdr. fra projektet initieres til alle (ekskl. HUM) er flyttet over på en fælles løsning - HUM skal vurderes særskilt og først flyttes, når et nyt E-læringssystem er i drift. Alternativt skal HUM s brugere anvende to systemer parallelt. - Det skal accepteres, at der er en stram tidsplan. - Der skal frigives tilstrækkeligt med ressourcer på de nuværende driftsenheder, herunder mindst én person, der dels er med i planlægningen af migreringen, afsætter fuld tid på dette projekt i den periode, hvor flytningen af den lokale installation foregår og i en periode derefter. - Der etableres et rejsehold, der opbygger kompetence til migrering og som arbejder sammen med den lokale kontakt. - Der skrives kontrakt med et konsulentbureau om at varetage projektstart og migrering. Gruppen har vurderet parallel implementering; men har forkastet det af to grunde: dels fordi det vil være noget dyrere at hyre et konsulentfirma til at gøre det parallelt; men nok så meget fordi AU ikke har tilstrækkeligt med ressourcer til at migrere parallelt. Indhøstede erfaringer kan ikke overføres til efterfølgende installationer. Som alternativ foreslår gruppen, at man som en midlertidig løsning satser på relativt hurtigt at integrere kalenderdata på tværs af driftsinstallationer. Det vil ikke kunne gøres med fuld oplysning; men man vil kunne se, om en person er ledig eller optaget. Denne løsning kræver en nærmere analyse med henblik på at finde den bedste tekniske løsning, herunder hvordan personer identificeres på tværs af nuværende systemer. En sådan løsning vil forsinke den egentlige sammenlægning af mailsystemer Indstilling vedr. politikker for mail- og kalendersystemet. Mail Forslag: Alle enheder på AU skal anvende den fælles mail- og kalenderløsning. Forslaget begrundes dels i lavere totalomkostninger, dels i at alle ansatte får samme muligheder og kan bære deres mailboks med ved interne flytninger. Mail ansatte. Forslag: Alle ansatte skal have én personlig mailboks identificeret ved AU ID. Enhver ansats mailboks kan have et ubegrænset antal alias med domænenavn ejet af AU. Funktionspostkasser oprettes efter behov derudover. Det første forslag begrundes med simplificering af administration og sikring af at mailboksen flyttes med uanset organisatorisk tilhørsforhold. Det andet med at en ansat dels kan have flere stillinger og derfor behov for flere alias, dels kan forskeres publikationer gennem tiden medføre, at gamle alias skal kunne bevares. Forslag: Ansattes mailboks har ingen øvre grænse m.h.t. størrelse; men AU fastsætter arkiveringspolitikker for at styre lagerkapaciteten på forskellige former for medier. Dertil kommer at det fortsat skal være muligt at gribe ind overfor uhensigtsmæssig adfærd. Nyt mail- og kalendersystem V 1.0 Side 5

6 En analyse af størrelsesfordelingen viser, at langt de fleste har så lille et lagerbehov, at omkostningerne ved at styre kvoter er for høje i forhold til indkøb af ekstra lagerplads. Det medfører at mail (og vedhæftninger) ikke automatisk slettes. Derfor er der gode økonomiske grunde til at fordele arkiverne på medier efter tilgangsbehov. Den konkrete afgørelse om anvendelse af maildomæner ligger hos ledelsen. Det skal ikke være den enkelte medarbejders afgørelse. Mail studerende. Forslag: Alle studerende skal have én mailboks identificeret ved AU ID. For at forenkle kommunikationen med de studerende skal vi have vished for, at de har en mailboks, der fungerer og kan identificeres. I henhold til bekendtgørelsen af 4/ om elektronisk kommunikation med de studerende kan vi anvende denne mailboks til ikke-fortrolig information. For at øge brugen af systemet, skal det være attraktivt for de studerende at bruge det. Forslag: Der sættes ingen kvoter på studerendes mailbokse; men AU fastsætter arkiveringspolitikker for at styre lagerkapaciteten på forskellige former for medier. Dertil kommer at det fortsat skal være muligt at gribe ind overfor uhensigtsmæssig adfærd. Selvom samtlige studerende kunne få ubegrænset plads i den nye fælles løsning, så ville deres andel af den samlede datamængde kun udgøre ca. 8 %. Omkostningerne til administration af kvoter overstiger således omkostningerne til ekstra lager. (jf. bilag 2) Forslag: Ressourcestyring skal foretages i det fælles kalendersystem. Ved ressourcestyring forstås bestilling af mødelokaler, laboratorier, biler, udstyr etc. I takt med at de afleverende systemer bliver klar til at integrere med det fælles kalendersystem skal undervisningslokaler, undervisningsskemaer også kunne ses i den fælles kalender. Nyt mail- og kalendersystem V 1.0 Side 6

7 2. Valg af teknologi. Projektgruppen har set på følgende teknologier og blev præsenteret for de fire første: Microsoft med Exchange 2010 Oracle med Beehive IBM med Lotus Notes / Domino VMWare med Zimbra (Mikrograf/OpenText med FirstClass.) Alle fire præsenterede Unified Communications løsninger med integration af mail, voic , sms, RSS feeds og instant messaging (chat). Fælles for alle fire er, at klienten er anderledes end brugerne er vant til. Exchange 2010 har ny funktionalitet i forhold til 2003 og 2007, så brugerne skal ændre grænseflade, uanset hvilket system der skiftes til. Efter præsentationen gik projektgruppen videre med Microsoft Exchange og VMWare s Zimbra, fordi løsningerne teknisk set ligger indenfor de kompetencer, vi strategisk har valgt at fortsætte med i organisationen. Vi ønsker ikke at anmode leverandører om at bruge yderligere tid på arbejde, hvis sandsynligheden for at de bliver fravalgt af mere strategiske årsager, er meget store. Gruppen har vurderet anskaffelse i to forskellige scenarier: - Alle ansatte i en fælles løsning, der hostes af AU. Studerendes mail lægges i en gratis løsning i skyen. - Både ansatte og studerende lægges i en fælles løsning, hostet lokalt. Data fra Naturvidenskab viser, at studerende kun øger kapacitetsbehovet med 8 %. Det vurderes, at en del af supporten til studerende vil være uafhængig af, om de tilbydes en lokal eller en løsning i en sky. Styringen af identiteter er den sammen uanset løsning. Sammenlagt er det begrundelsen for, at gruppen indstiller én fælles løsning for ansatte og studerende Funktionskrav I bilag A er opstillet en række krav / ønsker til det kommende system. Vi fik svar fra alle fire inviterede (Microsoft, IBM, Oracle, VMWare) og projektgruppen var enige om, at alle fire i store træk kunne leve op til vore ønsker. Herunder at alle kan afvikles på en platform, der var kendt på AU. Exchange kan kun afvikles på en Windows server; men de øvrige kan afvikles på flere platforme, herunder Windows, Solaris og Linux. Klientadgang Alle fire leverer en specifik klient med fuld adgang til mail- og kalender, ligesom alle fire kan tilgås via Microsoft Outlook som klient med fuld funktionalitet. Ved alle fire kan man se mail med mere sædvanlige mail-klienter som Thunderbird etc. IBM, Oracle og VMWare har alle en specifik klient, der kan afvikles på både Windows, MacOS og Linux. Microsoft Exchange har ikke en specifik klient, der kan afvikles på Linux baseret arbejdsstation, så kalenderen kan kun tilgås via web-grænsefladen. Microsoft leverer Outlook til Windows og som en del af Office 2011 for Mac også Outlook for Mac. Mac klienten var forsinket med knap et år i forhold til Windows klienten. Nyt mail- og kalendersystem V 1.0 Side 7

8 Alle fire havde tillige en mulighed for webadgang, der altovervejende har samme layout og funktionalitet som den leverandørspecifikke klient. Ud fra præsentationen virkede det som om Zimbra s brugergrænseflade havde den største overensstemmelse. Mangler Der var stort set enslydende udfordringer, især til tre sæt af ønsker: alle kan levere tilgang til mobile enheder med activesync; men derudover reflekterer svarene, at mobilløsninger endnu ikke er et modent marked. at alle fire kan leve op til at kunne etablere log ind med NemID til webmail; men der skal udvikles mere konkret evt. via 3. part, når det gælder krypteret mail. at alle kan levere basale mail-lister; men at der skal specialudvikling til for at opfylde alle krav Økonomi vedr. anskaffelse. Vi har bedt leverandørerne af hhv. Exchange (Microsoft + ATEA) og Zimbra (VMWare + Trifork) give et overslag over de forventede omkostninger ved en ny installation fra bunden. Resultatet er vist nedenfor med kommentarer vedr. forskellen mellem de to løsninger efterfølgende. Tabellerne nedenfor viser de omkostninger, de to leverandører selv har specificeret. Vi har f.eks. bedt leverandøren anbefale en backup løsning og den ene anbefaler en hostet løsning, den anden investering i en lokal løsning (men medregner ikke efterfølgende internt tidsforbrug.). Se efterfølgende kommentarer. Økonomien i de to forskellige løsninger m. hhv og brugere viser, at Microsoft Exchange er den billigste løsning i anskaffelse, idet der er forskel i licensomkostningerne. Øvrige omkostninger i tabellerne er forskelle, der begrundes med leverandørernes teknologivalg til disklagring, backup mm. I øvrigt er det væsentligt, at en del af investeringen i hardware til Exchange løsningen er foretaget i Licens: VMWare kræver næsten en million i engangs licens 2, hvor Microsofts licens er inkluderet i den eksisterende aftale. Diskløsning: VMWare har valgt virtualisering ovenpå relativt dyre SAN diske. Microsoft har valgt billige SATA diske på serverne. Der er intet til hinder for, at Zimbra kan køre på de samme diske som Exchange og så vurderes det, at hardware omkostningerne til Zimbra ligger på linje med Exchange. SAN omkostninger til ZIMBRA løsningen er baseret på, at SAN etableres fra grunden til denne applikation. Hvis der kan bygges ovenpå eksisterende SAN i to driftscentre, ville omkostningerne være markant mindre. Hvor meget afhænger af en konkret analyse. Virtualisering: Projektgruppen mener, at det vil være en fordel at virtualisere storage. Det vil være dyrere i investering; men det opvejes af billigere drift. Gruppen har ikke regnet på virtualisering. 2 We decided to offer you a Perpetual License on Zimbra Collaboration Suite (one time license payment fee). The License is Perpetual; i.e. you own it in perpetuity. There is no license expiration, and there will be no new fees, other than the annual Support & Maintenance fee, which includes your Support Subscription, updates and upgrades. Nyt mail- og kalendersystem V 1.0 Side 8

9 Option 1: brugere Microsoft investering Microsoft årligt VMWare investering VMWare årligt Hardware - applikation og storage servere Hardware, server Hardware, disklager SAN switch Netværksomkostninger ( ) Backup Forebyggende vedligehold Energiomkostninger Strømforbrug licenser Option 2: brugere Microsoft investering Microsoft årligt VMWare investering VMWare årligt Hardware - applikation og storage servere Hardware, server Hardware, disklager SAN switch Netværksomkostninger ( ) Backup Forebyggende vedligehold Energiomkostninger Strømforbrug licenser Netværksomkostninger er afledte omkostninger til switche, porte mm., som konsulenterne fra Trifork har erfaring med følger i halen af et mail konsolideringsprojekt. Hvis vores netværk er tilstrækkeligt bestykket, falder de væk. Atea/Microsoft har ikke taget det med, idet de har antaget, at netværket er tilstrækkeligt bestykket. Der er således ingen forskel på dette punkt. Backup. Vi bad leverandørerne om at anbefale en backup strategi. Forskellen mellem de to løsninger ligger i denne anbefaling: - Microsoft/ATEA anbefaler en ren hostet cloud løsning, hvor data kun opbevares eksternt. En anden løsning, der involverer en hel/delvis lokal kopi af data til sikring af hurtig restore er ikke inkluderet i oplægget, da det konkrete design fordrer en nærmere dialog. - VMWare / Trifork baserer deres overslag på en lokal backup løsning, der etableres udelukkende for denne applikation. Såfremt applikationen kan kobles på en eksisterende backup løsning, falder omkostningerne. Hvor meget afhænger af en nærmere analyse. Nyt mail- og kalendersystem V 1.0 Side 9

10 Konklusion vedr. backup: der er ingen forskel mellem Exchange og Zimbra, når det drejer sig om backup omkostninger. Energiomkostninger. ATEA har udelukkende angivet strømforbruget for serverne. Trifork har inkluderet alle miljøomkostninger, herunder strømforbrug til server, køling, lan mv. Der er således heller ikke her nogen forskel mellem de to løsninger. Forebyggende vedligehold. Microsoft anbefaler kvartalsmæssig systemgennemgang mhbp. optimering af drift og identifikation af mulige forbedringer Karakteristik af de 5 tekniske løsninger. FirstClass OpenText (FirstClass) meldte fra, idet de ikke ønskede at gå ind på en række af vore krav, der krævede tilpasning. Især var der problemer med mulighed for login og mulighed for kryptering af mail med NemID. OpenText (Canada) ønskede ikke at lave lokale tilpasninger og det var ikke en mulighed, at 3. part kunne lave den type tilpasning. Oracle Behive Oracles Behive indeholder udover mail og kalender også en collaborativ løsning med fildeling mm. I forhold til Microsofts løsninger inkluderes der således noget af den funktionalitet, Sharepoint tilbyder. Tilgangen er ens for alle typer beskeder, idet alt lagres som filer i en Oracle database: mail, voic , vedhæftede filer etc. Det samme gælder kalenderelementer, adresser mm. Der lagres kun én instans af hvert element. Databasen kan tilgås via standard API og der er etableret integrationer til mange løsninger. Løsningen er teknisk set god, men Behive har stort set ingen markedsudbredelse i Norden. Oracle henviste til en referenceliste på oracle.com, hvor der er 14 referencer over hele verden fortrinsvist i USA. Der er ingen universiteter eller undervisningsinstitutioner. Oracle hentede en hollandsk specialist op for at præsentere Behive og diskutere vore krav. Gruppen vurderede, at løsningen kræver kompetencer, som AU p.t. ikke har. D.v.s. et valg af Oracle ville betyde en betydelig omkostning til kompetenceopbygning. Dertil kom, at vi foretrak implementeringspartnere, der dels er permanent tilstede i Danmark, dels har erfaringer fra tilsvarende implementeringsprojekter. Oracles løsning har en meget lav markedsandel i Danmark og som følge deraf er der stort set ingen, der kender produktet. Enhver udskiftning i driftspersonalet ville medføre omkostninger til kurser mm. IBM s Lotus Notes / Domino Lotus Notes / Domino er næststørst på det danske marked. Løsningen indeholder langt mere end mail og kalender og er i højere grad en platform for applikationsudvikling med mail, hhv. kalender som applikationer. Lotus Notes indeholder også en collaborativ løsning med fildeling mm. I forhold til Microsofts løsninger inkluderes der således noget af den funktionalitet, Sharepoint tilbyder. I denne platform kan der således også etableres Intranet og personlige portaler. Nyt mail- og kalendersystem V 1.0 Side 10

11 Lotus Notes er en åben platform og integrerer med alle større systemer. I modsætning til de øvrige systemer er opgradering til nye versioner enkelt og der er bagud kompatibilitet til de første versioner. IBM s referencer er fortrinsvist i de meget store organisationer. Herhjemme f.eks. Danske Bank. Der er ikke mange universiteter eller andre undervisningsinstitutioner i Norden. Projektgruppen vurderede, at applikationen eller rettere udviklingsplatformen kræver at AU s drifts- og supportpersonale skal håndtere et helt nyt univers, som vi p.t. ikke har kompetencer til. M.a.o. vil IBM s løsning kræve en betydelig kompetenceopbygning hos AU. Ovennævnte skepsis formidlede vi til IBM, der alligevel ønskede at deltage i det videre forløb. IBM sendte derefter et økonomisk overslag, der tog udgangspunkt i dels en initial investering i hardware, dels en totalomkostning til drift (inkl. alle omkostninger) på kr. pr. bruger pr. måned i scenariet med ansatte plus studerende i samme løsning. I scenariet med udelukkende ansatte ville prisen være højere; men blev ikke specificeret. M.a.o. foreslog IBM en løsning med en årlig totalomkostning på 15,3-18,4 mill. Kr./år. Uanset, at denne omkostning indeholder AU interne omkostninger som husleje, support og driftspersonale, vurderede gruppen, at IBM s løsning var alt for dyr. Microsofts Exchange Microsoft Exchange er markedsledende og et kendt produkt på AU, idet der er 8 Exchange installationer dækkende ca. 2/3 af de ansatte. Exchange 2010 er især ændret på den tekniske platform, idet der er lagt vægt på hurtig acces, billig datalagring og kontinuert spejling af data. Eks.: I modsætning til tidligere versioner gemmes vedhæftede filer både hos afsender og hos samtlige modtagere. Det medfører øget datalagring; men til gengæld hurtigere tilgang og simplere datastruktur. Data lagres på SATA diske, hvor nye diske kan tilføjes efter behov uden stop. Microsoft tilbyder to sæt løsninger: Exchange og cloud løsningen Exchange Online. I den sidste lagres data indenfor EU, så reglerne om dataeksport ikke overtrædes. De to løsninger er bygget, så konti kan flyttes mellem dem uden at brugeren mærker forskellen. Microsoft tilbyder Live@EDU (Exchange som cloud løsning) gratis for studerende. (Det anvendes p.t. af CBS). VMWare s Zimbra Zimbra blev udviklet som et open source projekt fra 2004 med virksomheden ZCS som hovedaktør. Fra begyndelsen har der været en open source del og en udbygning, der er licensbaseret. I 2007 købte Yahoo Zimbra og videre udviklede på platformen for at kunne konkurrere med Google. Det havde Yahoo ikke midler til og i januar 2010 blev Zimbra solgt videre til VMWare, hvor applikationssuiten indgår som en del af virksomhedens strategi om at tilbyde generelle applikationer ovenpå VMWare s virtuelle platform. (Der er ikke noget krav om at anvende VMWare for at bruge Zimbra.). VMWare ser ud til at have en klar strategi med Zimbra, herunder at VMWare er i fuld gang med at opbygge et netværk af partnere. Konsulentfirmaet Trifork deltog i præsentationen. Det er også helt klar, at Zimbra bærer præg af at have den nyeste arkitektur, sammenlignet med de tre andre. Det viser sig bl.a. i en meget åben arkitektur, således at man kan integrere direkte til de enkelte funktioner. Eksempelvist kan Zimbra uden problemer integrere med Exchange vedr. kalender og global adresseliste. Nyt mail- og kalendersystem V 1.0 Side 11

12 Zimbra anvender hele vejen igennem åbne standarder som f.eks. WebDav. Herunder CalDav for kalenderdata. Zimbra har et udviklingsmiljø, hvor man kan udvikle Zimlets d.v.s. små specialmoduler - til speciel funktionalitet. Der er mange Zimlets tilgængelige som Open Source. Samtidigt er Zimbra s arkitektur sammensat af komponenter, der er velkendte i en AU sammenhæng. Der er således ikke behov for en større kompetenceopbygning. University of Pennsylvania anvender både Exchange og Zimbra og integrerer på tværs af de to systemer. Hvis de skulle starte forfra, ville de kun have et system og ville vælge Zimbra, dels p.g.a. billigere driftsøkonomi, dels på grund af muligheden for Zimlets. Nyt mail- og kalendersystem V 1.0 Side 12

13 3. Idriftsættelse og migrering Projektgruppen har foretaget en grovanalyse af migreringen som en række selvstændige delprojekter. Analysen er suppleret med dialog med konsulenter fra TRIFORK, der har erfaring med migrering i Region Midt og Københavns Kommune. Sekventiel migrering Sammenlagt forventes migreringen at tage mindst 15 måneder, jf. nedenfor. Migrering af FirstClass er væsentligt mere komplekst end de øvrige. Se nedenfor i afsnit 3.3. Parallel migrering En migrering over 15 måneder kan muligvis afkortes, hvis vi f.eks. migrerer de fire nye hovedområder parallelt. Det vil betyde, at man pålægger de fire hovedområder at konsolidere deres mailsystemer hver for sig. Det vil medføre, at Erhverv & Samfundsvidenskab, hhv. Naturvidenskab og Teknologi noget hurtigere kan få et fakultetsinternt system til at fungere. For Kulturvidenskab vil problemet med FirstClass (se nedenfor) forhindre en hurtig løsning, uanset om processen kører parallelt eller sekventielt. Sundhedsvidenskab kører allerede i egen løsning. Når alle så er migreret over i lokale løsninger, foretages den endelige migrering. Parallel migrering er vurderet med kommentarer nedenfor. Projektgruppen kan ikke anbefale parallel migrering Plan ved sekventiel migrering Nedenstående plan er lavet med udgangspunkt i de diskussioner vi har haft med leverandørerne. En bedre og mere holdbar plan kan laves i løbet af fase 2. En afgørende forudsætning for at planen holder er, at AU lokalt og centralt stiller de nødvendige ressourcer til rådighed, når der er brug for dem. Fase 1: Analyse af eksisterende installationer For at kunne give et bindende tilbud på den tekniske migrering skal konsulentfirmaet bruge en uge med adgang til alle mail servere, hvor opsætning af hver eksisterende installation analyseres med afprøvede værktøjer og hvor netværk testes. Et led i denne analyse er analyse af ID strukturen i eksisterende AD (LDAP). Varighed: 2 uger. Fase 2: Planlægning, Arkitektur, design mm. I denne fase fastlægges systemets tekniske grundlag og alle designbeslutninger fastlægges. Hardwaren bestilles og driftsorganisationen etableres. Der laves en mere sikker migreringsplan. Forventet varighed: 8-12 uger. Nyt mail- og kalendersystem V 1.0 Side 13

14 Fase 3: Driftsimplementering I denne fase sættes mailsystemet op og der foretages test af drift og kobling til AD (LDAP). Der oprettes ét fælles AD med integration fra IDM. Denne fase afhænger meget af de ressourcer, der afsættes og den ekspertise, der hyres til projektet. Implementering af et fælles AD er p.t. den mest usikre del af planlægningen i hele projektet. Forventet varighed: 3-5 måneder. Fase 4: Opsætning af de studerendes mail. De studerendes mail skal sættes op og der skal etableres postkasser. Men ibrugtagning afhænger af planerne for de systemer, der skal føde dem: STADS E-læringssystemer: AULA, CAMPUS, Blackboard. Selvbetjening Tidsplanen for opsætning af de studerendes mail fastlægges senere og afhænger meget af studieadministrationens behov. Uden migrering af studerendes egne data kan denne fase udføres parallelt med migrering af ansattes mail- og kalender. Fase 5: Migrering af ansattes mail og kalender fra Exchange hhv. Cyrus mail Plan tager udgangspunkt i, at konsulentvirksomheden har de nødvendige værktøjer og har givet et tilbud på migrering. Desuden at de lokale miljøer stiller ressourcer til rådighed, når der er brug for dem. For hver af de nuværende 9 installationer er fremgangsmåden: a) Mapning af ID i de nuværende AD til AU ID og til det nye fælles AD. b) Der skal tages stilling til de mange ID i nuværende AD, der ikke umiddelbart kan mappes til AU ID. c) Sikring af at alle brugere har flyttet alle data over på server og ikke har mail liggende lokalt. Gruppen foreslår, at der kun konverteres fra server til server. Data, der kun ligger på PC konverteres ikke. d) Flytning af data fra server til server. Tidsforbruget afhænger af netværkskapaciteten. I praksis omkring 500 brugere pr. uge i starten af migreringen fra en eksisterende installation. En vis del af brugerne vil mangle data, f.eks. på grund af tidligere migreringer og skal gen-migreres. Erfaringen viser, at med store sites, hvor man har fundet problemerne i den første uge kan der fra ca. 3. uge migreres op til 1000 brugere pr. uge. e) Instruktion af brugere i ny mail anvendelse, login mm. Migreringen er arbejdskrævende og stiller krav til lokal ekspertise. Samtidigt kan AU formentlig ikke konvertere mere end ét driftsområde ad gangen. Tidsplanen, baseret på, at alt forløber som planlagt, giver et samlet forløb på mindst 7 måneder oven i de 5-6 måneder til analyse og driftsimplementering. Erfaringer fra andres mail migreringer og AU s erfaring med migrering af CMS indhold, viser at den altafgørende flaskehals er AU s egen organisation. Det gælder både lokalt og centralt. Nyt mail- og kalendersystem V 1.0 Side 14

15 ADM+TEO Exc uger ASB Exc uger SAM (jur,psy) Exc uge SAM (øk, stat) Cyrus mail+ Oracle kalender uge SUN Exc (2003) uger DMU Exc uger DJF Exc uger DPU Exc uger HIH Exc uge NAT Cyrus mail+ Oracle kalender 4000? 6 uger I alt Mindst 7 måneder. Ovenstående tidsplan er baseret på, at studerendes data ikke flyttes med over. I realiteten har kun DPU, HIH, SUN og NAT data liggende på studerendes mail. Såfremt studerendes mail skal flyttes med forlænges migreringsperioden. Hvor meget afhænger af en nærmere analyse. Rækkefølgen af migreringer foreslås som ovenfor. Dog således, at driftsmiljøet skal migreres først. Begrundelsen for rækkefølgen er, at installationer med flest integrationer fra andre systemer til eksisterende løsning vil få den nødvendige tid til at omlægge integrationerne til den nye løsning Plan ved parallel migrering. Som nævnt vil vi kunne køre migrering parallelt for Erhverv & Samfundsvidenskab, hhv. Naturvidenskab og Teknologi. Hvis det skal medvirke til en fælles løsning på lidt længere sigt, skal begge fakulteter migrere til en løsning, der relativt enkelt kan migreres over i en fælles løsning. En væsentlig del heraf er at koble op på en fælles AD. Da begge fakulteter skal migrere halvdelen af brugerne, vil det sammenlagt være for dyrt at mappe halvdelen over i et eksisterende AD / LDAP, for så senere at gentage processen for samtlige brugere, når man skal over i et fælles AD. Derfor er det på sigt billigst at migrere alle over i ét fælles AD. Det må forventes at fase 1 og fase 2 vil tage lige så lang tid som ved sekventiel migrering. E&S har ikke umiddelbart en løsning, der kan rumme hele det nye fakultet, så den eksisterende installation skal udvides. N&T kan rumme alle nye brugere i NAT s nuværende løsning; men det vil betyde, at alle brugere skal skifte to gange indenfor kort tid og i mellemperioden ikke har integreret kalender og mail. Alternativt skal der etableres en helt ny løsning for alle, hvilket vil medføre betydelige omkostninger til investering i nyt hardware. Fase 3 afhænger af den valgte løsning. Med ét fælles AD for hele AU vil det formentlig tage lige så lang tid at etablere de to løsninger som én fælles løsning. Fase 4 er uændret i forhold til sekventiel migrering. Fase 5 komprimeres. Men kun for de to nævnte fakulteter. Det vil medføre, at der ikke kan etableres et rejsehold til migrering. Både konsulentomkostninger, oplæring og problemløsning vil derfor være dyrere end ved en sekventiel løsning. Konklusion: det kan ikke anbefales at migrere parallelt. Nyt mail- og kalendersystem V 1.0 Side 15

16 3.3. Migrering af FirstClass FirstClass anvendes af Humaniora og har været i brug siden februar Der er ca ansatte brugere og ca studerende på systemet. FirstClass er et konferencesystem og alt er opdelt i konferencer, der anvendes på forskellig vis. Der er offentlige konferencer samt et ukendt antal private konferencer (konferencer oprettet på brugernes egne FC skriveborde) FC indeholder en række informationstyper: Mail (teknisk set er en brugers mailbox en konference). En mailbox indeholder mail til/fra eksterne brugere samt mail til/fra andre FC brugere (teknisk set et link til et FC dokument) Kalender personlige kalendere, delte kalendere og ressourcekalendere. Konferencer, der bruges på tværs til forskelligartet formål. Adresselister tilknyttet enkeltbrugere eller flere brugere via konferencer. Adresselister kan anvendes som distributionslister Instant messaging. Det centrale ved en konference er, at den kan anvendes af flere brugere i fællesskab og at en konference kan indeholde mange forskellige typer dokumenter. Det kan være uploadede filer af enhver art; men man kan også danne / skrive direkte i FC og således danne specielle FC dokumenttyper. Over årene er konferencerne blevet brugt til især tre funktioner: 1) Funktionspostkasser, hvor en funktion deles mellem flere (f.eks. studienævn) og hvor konferencen indeholder f.eks. sagsforløb med notater og breve. Mange sager har et fuldt sagsforløb i FC uden egentlig journalisering; men hvor sagsforløbet er veldokumenteret i konferencens mapper. 2) Intranet med dokumentdeling, møderækker med bilag, diskussioner etc. 3) E-læring: fagbeskrivelser, eksamensplaner, deltagerlister, dokumenter vedr. undervisning, præsentationer, wiki, afleveringspostkasser etc. Hver bruger har sin egen postkasse, der teknisk set er en konference. Den indeholder mail til/fra eksterne brugere, mail til/fra andre FC brugere (teknisk set et link til et FC dokument) samt adresselister. FC indeholder en web-server, hvorfor brugere kan gøre allehånde FC dokumenttyper og gængs HTML tilgængeligt på nettet. Det er ikke optalt hvor mange der gør brug af denne funktion, men enkelte forskere har lavet relativt omfattende personlige hjemmesider. Til alle konferencer (inkl. kalendere og adressedatabaser m.v.) er der tilknyttet en omfattende rettighedsstyring. Filer dubleres ikke i FC, hvorfor rettigheder til alle delte elementer skal reetableres for at gøre en eksport af data i konferencer meningsfuldt. Tekniske muligheder for eksport af data fra FirstClass Adresselister kan eksporteres dels til outlook, dels som VCF card. Mail til/fra eksterne mailadresser udenfor FC kan eksporteres med mailheader. Formentlig med en begrænset udviklingsindsats. Nyt mail- og kalendersystem V 1.0 Side 16

17 Mail mellem FC brugere har ingen mailheader; men de samme oplysninger findes i mailens historik. Der skal derfor laves en del udvikling / scripting for at eksportere FC interne mail til et format, der kan indlæses i et andet system. Kalendere kan eksporteres som ICAL format. Konferencer kan eksporteres over i en Windows mappestruktur med uændrede uploadede filer og hvor FC dokumenter eksporteres som både txt og XML dokumenter. Eksport af eksterne mail og kalender er relativt uproblematisk; men alt andet vil kræve en del udvikling af konverteringsprogrammel. Det største problem er p.t. at der ikke er nogen umiddelbar modtager af den del af dataene, der ligger i konferencerne: Funktionspostkassernes indhold og intranet delen burde eksporteres til et intranet; men der er p.t. ingen mulighed for det. E-læringsdelen i FC er struktureret markant anderledes end AULA og det kan ikke anbefales at migrere dertil. Endelig er det ikke muligt at eksportere de tilknyttede rettigheder til konferencerne. De skal derfor genskabes manuelt for samtlige konferencer. Hjemmesider kan kopieres manuelt, men AU tilbyder p.t. ikke personlige hjemmesider til ansatte i den fælles TYPO3 løsning. Der er ikke lavet estimat for eksport af data til et format, der kan indlæses i andre systemer og hverken IBM, TRIFORK eller ATEA ville give et overslag på eksport af data. Ingen af dem havde erfaring med FirstClass. Anbefalinger vedr. FirstClass Såfremt de ansatte og de studerende flyttes til et nyt mail system inden AU har et nyt E-læringssystem skal både studerende og lærere fortsat anvende FirstClass som E-læringssystem. Det vil være uhensigtsmæssigt og det vil være svært at undgå, at en stor del af begge parter anvender FC til mail. AU har heller ikke noget tilbud til afløsning af FC som intranet. Brugerne vil derfor opleve at en væsentlig funktion fjernes. Projektgruppen anbefaler derfor, at FirstClass brugere flyttes som de sidste til et kommende mailsystem og først efter at et nyt E-læringssystem er taget i brug. Projektgruppen anser det for urealistisk at konvertere de mange konferencer og foreslår derfor, at FC lever videre i en lang årrække som et arkiv over sager og forløb. Alle brugere skal således fortsat have adgang til FC. Vedr. konvertering er der tre muligheder opstillet efter skønnede omkostninger: 1) Kontakter / adresselister flyttes over i et nyt system. Mail og kalender konverteres ikke, men arkiveres på samme måde som konferencer. Efter en periode lukkes der for afsendelse af mail fra Nyt mail- og kalendersystem V 1.0 Side 17

18 FC. Denne løsning kræver kun begrænset udvikling for at placere kontakter hos de rette brugere. Til gengæld skal alle brugerne leve med to systemer parallelt i en periode. 2) Kontakter / adresselister samt eksterne mail og kalender flyttes over i et nyt system. FC interne mail konverteres ikke, men arkiveres på samme måde som konferencer. Efter en kort periode lukkes der for afsendelse af mail fra FC. Denne løsning bør estimeres, idet den hurtigere kan få brugerne effektivt i gang med det nye system. 3) Kontakter / adresselister samt eksterne og FC interne mail og kalender flyttes over i et nyt system. Der lukkes for afsendelse af mail omgående. Denne løsning bør også estimeres. Projektgruppen anbefaler at løsning 2 og 3 estimeres og der træffes beslutning derefter Økonomi i migrering Gruppen har fået overslag fra to konsulentvirksomheder: ATEA (Microsoft Exchange) og TRIFORK (Zimbra). Begge har erfaringer fra migreringer og konsolideringer af mail løsninger hovedsageligt Exchange til Exchange. ATEA har erfaringer fra Åbenrå Kommune og Region Midt. TRIFORK bl.a. fra Region Hovedstaden og Københavns Kommune. Begge anvender samme værktøj til migrering (Quest) og begge betinger sig en analysefase før der kan udarbejdes et tilbud på migrering og en plan. Omkostningerne til denne analyse vil beløbe sig til kr. Efter en dialog fremgår det, at ATEA ikke har inkluderet mapning af brugere til ny AD. Samtidigt fornemmes en holdningsforskel i overslagene, idet TRIFORK eksplicit siger, at risikoen er inkluderet. M.a.o. TRIFORK har i overslaget dækket sig ind. TRIFORK vurderer, at migreringsomkostningerne er uafhængige af hvilket system, der migreres til (Exchange eller Zimbra) Det er væsentligt at bemærke, at de studerendes mail ikke er inkluderet i migrering. Projektgruppen vil etablere en forretningsgang, så de studerende selv kan flytte deres mail, såfremt de ønsker det. ATEA Trifork Projektopstart Design af løsning Installation af SW Etablering forbindelse til nyt fælles AD Antivirus mm Migrering - ekskl. AD Projektstart, Migrering inkl. mapning til nyt LDAP LIVE@EDU integration Kurser, undervisning i alt Når man tager højde for ATEA s manglende mapning af brugere til nyt AD og LIVE@EDU integration, vil der ikke være grundlag for at vælge mellem de to konsulentvirksomheder ud fra de fremsendte overslag. Det er dog værd at bemærk, at ATEA er leverandør indenfor Statens Indkøbs aftale vedr. konsulentassistance vedr. Microsoft programmel. Ved en tilmelding inden 1/ kan Aarhus Universitet får betydelige rabatter på et tilbud som det fremsendte. Nyt mail- og kalendersystem V 1.0 Side 18

19 Bilag A: krav til det kommende mail- og kalendersystem Overordnet beskrivelse Hver studerende og hver ansat skal have en postkasse / mailkonto. Evt. med mulighed for selv at navngive mailadressen. Dog med den begrænsning, at allerede anvendte mailadresser ikke genbruges. Af hensyn til bagud kompatibilitet er det væsentligt at alle kan bevare hidtidige mailadresser, uanset navn og domænenavn. Mailadresser skal kunne benævnes via domænenavne, der signalerer organisatorisk tilhørsforhold. Mail- og kalender: Specifikation af krav til løsning. Både mail- og kalender. 1) Der bør være platforms-uafhængighed hvad angår klienternes operativsystem til stationære og bærbare arbejdsstationer. (Windows, Linux, Mac). Som minimum skal beskrives funktionalitetsforskelle ved forskellige klienttyper på forskellige operativsystemer. 2) Løsningen skal understøtte mobile enheder mobiltelefon og tablet PC - både til mail og kalender. 3) Der bør være platforms-uafhængighed hvad angår klienternes operativsystem til mobile enheder. De mest anvendte mobile klientplatforme bør understøttes (iphoneos, Android, Symbian, Windows Mobile). Som minimum skal beskrives funktionalitetsforskelle ved forskellige klienttyper på forskellige operativsystemer. 4) Identitetsstyring skal foretages via ét centralt directory, der opdateres af AU s IDM, hvori alle studerende og ansatte har et unikt AU ID, der skal identificere den enkelte persons postkasse. 5) Universitetets forskere anvender mange sprog og tegnsæt (kyrillisk, arabisk, kinesisk..). Derfor skal der være mulighed for at anvende UTF-8 som tegnsæt. Mail server. 6) Løsningen skal understøtte IMAP 7) Alle typer klienter skal kunne søge i et centralt directory. 8) Løsningen skal kunne rumme store mailbokse. (Den største mailbox på AU p.t. er på 25 GB.) 9) Løsningen skal inkludere arkivering både med mulighed for arkivering efter en standardpolitik og direkte initieret. 10) Brugeren skal på sin klient kunne initiere en effektiv søgning i sin mailkonto. Inklusive søgning i arkiv. 11) Ved lukning af en mailkonto skal kontoen kunne arkiveres, så administrator har adgang til data. 12) Serveren skal kunne implementere digital signatur (NemID), både til central kryptering og central signering. 13) Muligheder for brugerselvbetjening af administrative opgaver som gendannelse af slettede mails / aftaler, forward, etablering af alias, fraværssvar, sortering, opmærkning etc. 14) Beskrivelse af systemets anvendelse af DNS, muligheder for flere mailadresser / mailalias er pr. postkasse, delte postkasser, funktionspostkasser mm. Maillister 15) Der skal være mulighed for maillister, hvor ID vedligeholdes lokalt men hvor ID s øvrige attributter hentes fra det centrale directory. Alle former for maillister skal kunne rumme mailadresser for eksterne brugere. Maillister skal kunne etableres i flere former: a. Lister på den enkelte brugers adressebog. b. Fælles lister, der vedligeholdes manuelt Nyt mail- og kalendersystem V 1.0 Side 19

20 c. Lister der opbygges ud fra tilhørsforhold i andre systemer (f.eks. studieadministrationssystem, IDM, HR system etc.). d. Abbonnements-lister, hvor brugerne enten bliver tilmeldt eller selv melder sig til og fra og hvor listen kan etableres som lukket for listens medlemmer. Mailklient. 16) Der skal findes klienter på alle relevante platforme, der kan implementere sikker (lokal signering) med digital signatur (NemID). Helst således at én login kan danne rammen for en session med både læsning og afsendelse af mail. 17) Der skal være mulighed for at anvende Microsoft Outlook som klient, fordi Scanjour kun integrerer til Outlook m.h.t. direkte journalisering af mail. Kalenderserver. 18) Der skal kunne etableres ressourcekalendere, hvor ressourcer er klassificeret (lokaletyper, biler.). 19) Der skal være gode muligheder for søgning (herunder fritekst søgning) i ressourcer og til bookning af ressourcer 20) Ved lukning af en mailkonto skal personens historik bevares i kalenderen, herunder de møde indkaldelser på andre konti, der er foretaget fra kontoen. 21) Der skal være mulighed for at oprette gruppekalendere med overbliksvisning. 22) Når der i en åben kalender vedhæftes filer til mødedeltagerne, skal disse filer kun være tilgængelige for mødedeltagerne. 23) Der skal kunne integreres til administrative systemer ved at kalenderserveren stiller web-services til rådighed for hhv. rekvirerer services hos vores service bus. Som eksempler på integrationsbehov kan nævnes: Skemaplanlægningsværktøjer Learning management systemer Ressourcestyringsværktøjer Dokumentdelingssystemer / intranet ESDH systemer Unified communication systemer Integration med Nortel-baseret telefoniplatform / PC-omstillingsanlæg. 24) Muligheder for integration med sociale netværksservices (facebook, LinkedIn, twitter m.fl.) Drift og support 25) Beskrivelse af de administrative processer for IT-personale (hvad kræver det at oprette og vedligeholde løsningen) 26) Beskrivelse af identitetsstyring, herunder integration med AU s IDM. Evt. via et directory 27) Beskrivelse af skalering og performance for løsninger med brugere hhv brugere (det sidste inkl. de studerende). Hvad kræver det f.eks. af driftsinstallationen, at øge antallet med 25% eller 50%? 28) Hvordan håndteres SPAM og andre skadelige mails? 29) Beskrivelse procedurer for backup og restore: hvordan håndterer løsningen gendannelse af enkelt mail, én mailboks, hele systemet, herunder tidsforløb til backup. Markedsstilling 30) Markedsposition i Danmark: hvilke muligheder er der for flere leverandører til samme platform, tilkøb af konsulentydelser, rekruttering af personale med kompetence indenfor platformen etc. 31) Referencer på installationer i samme størrelse især i Danmark; herunder universiteter mm. Nyt mail- og kalendersystem V 1.0 Side 20

21 Bilag B: Kortlægning af anvendelse af Mail og Kalender på AU. I runde tal er 2/3 af universitetets ansatte klinter på en Exchange server, 1/4 er klienter på en Open Source løsning og knap 1/10 anvender FirstClass. AU s datamængder og konvertering. Initialt må der påregnes postkasser til ansatte, til studerende samt omkring ressourcer. Der forventes vækst både i antal postkonti, ressourcer og den lagrede mængde. P.t. lagres ca. 12 TB mail. Der er stor forskel på, hvordan studerende serviceres med mail. HUM har alle studerende på FirstClass, der også bruges som e-læringsplatform. HIH og DPU har alle studerende på den lokale løsning og har integreret med e-læringsplatformen. NAT og SUN har ligeledes alle studerende på deres lokale løsning. SAM giver studerende en AU postboks og ASB anvender VMS mail, hvor tilgangen er via web-mail. Exchange installationer. version Antal konti Kalender Datamængder studerende ASB GB Nej ADM+TEO 2003-> TB Nej DJF ,4TB Nej DMU ,8TB Nej DPU TB Ja HIH GB 1550 SAM (jur,psy) GB Nej SUN 2007 (2003) ,3TB 4270 NAT (inkl. dele af SAM) Mail - IMAP: Post-fix + CMU Cyrus ,9TB Ja Kalender Oracle Calendar GB HUM FirstClass kan ikke adskilles Andre På SUN findes to mindre lokalt baserede OSS mail-løsninger (uden kalender) med hhv. 175 og 75 konti. Disse er ved at blive flyttet til SUN s Exchange løsning. Mobile løsninger Alle installationer på nær HUM tilbyder mobile løsninger. Andelen af mobile enheder varierer. En del driftsområder kender ikke antallet af mobile enheder. Ressourcestyring Anvendes af alle. Politikker. Der er noget varierende politikker vedr. max postkasse størrelse. Fra 1GB (DPU), 2GB (ASB) over 6-8 GB til ubegrænset (DMU/SUN / NAT). De største postkasser på SUN er 11,6 GB, på NAT 25GB. Nyt mail- og kalendersystem V 1.0 Side 21