anskaffelse af fÆlles mail og kalender system
Post on 03-Apr-2022
14 Views
Preview:
TRANSCRIPT
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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 ............................................................................................................................................. 2 1. Indstillinger ................................................................................................................................................ 3
1.1. Indstilling vedr. teknologivalg for nyt mail og kalendersystem. ........................................................ 3
1.2. Brugerstyring ..................................................................................................................................... 3
1.3. Indstilling vedr. organisering af drift af det fælles system. ............................................................... 3
1.4. Indstilling vedr. projektets organisering og selve migreringen. ........................................................ 4
1.5. Indstilling vedr. politikker for mail- og kalendersystemet. ................................................................ 5
2. Valg af teknologi. ....................................................................................................................................... 7 2.1. Funktionskrav .................................................................................................................................... 7
2.2. Økonomi vedr. anskaffelse. ............................................................................................................... 8
2.3. Karakteristik af de 5 tekniske løsninger........................................................................................... 10
3. Idriftsættelse og migrering ...................................................................................................................... 13 3.1. Plan ved sekventiel migrering ......................................................................................................... 13
3.2. Plan ved parallel migrering. ............................................................................................................. 15
3.3. Migrering af FirstClass ..................................................................................................................... 16
3.4. Økonomi i migrering ........................................................................................................................ 18
Bilag A: krav til det kommende mail- og kalendersystem ............................................................................... 19 Mail- og kalender: Specifikation af krav til løsning...................................................................................... 19
Bilag B: Kortlægning af anvendelse af Mail og Kalender på AU. ..................................................................... 21 Fordeling på brugere. .................................................................................................................................. 22
Specielle anvendelse og integrationer. ....................................................................................................... 22
Bilag C – Projektgruppens arbejde .................................................................................................................. 23
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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.
Servere
Arbejdsstation
Data
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.
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.
Brugeren kan anvende mail og kalender via en browser eller via en klient på egen PC.
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.
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.
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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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.
1.2. 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æsentligt1. 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.
1.3. Indstilling vedr. organisering af drift af det fælles system. Projektgruppen har drøftet mulighederne for drift af et fælles system med hhv. 11.000 brugere og 51.000
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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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.
1.4. 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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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 e-mail 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.
1.5. Indstilling vedr. politikker for mail- og kalendersystemet.
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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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/11 2010 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 40.000 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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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, voice-mail, 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 40.000 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.
2.1. 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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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.
2.2. Ø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. 11.000 og 51.000 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 2010.
Licens: VMWare kræver næsten en million i engangs licens2, 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.”
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 9
Option 1: 11.000 brugere Microsoft
investering Microsoft
årligt VMWare
investering VMWare
årligt
Hardware - applikation og storage servere 609.250 38.200
Hardware, server
480.000 45.540
Hardware, disklager
1.446.542
SAN switch
240.000
Netværksomkostninger (206.640)
206.640
Backup 28.560 463.000 420.000
Forebyggende vedligehold
43.120
Energiomkostninger
180.308
Strømforbrug
65.992
licenser
7.820 990.000
Option 2: 51.000 brugere Microsoft
investering Microsoft
årligt VMWare
investering VMWare
årligt
Hardware - applikation og storage servere 873.250 38.200
Hardware, server
480.000 45.540
Hardware, disklager
1.653.190
SAN switch
240.000
Netværksomkostninger (206.640)
206.640
Backup 28.560 463.000 480.000
Forebyggende vedligehold
43.120
Energiomkostninger
180.308
Strømforbrug
93.191
licenser
7.820 990.000
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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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.
2.3. 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, voice-mail,
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 implementerings-
partnere, der dels er permanent tilstede i Danmark, dels har erfaringer fra tilsvarende implementerings-
projekter. 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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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å 25-30 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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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.
3.1. 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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 15
ADM+TEO Exc. 2003 1.114 3 uger
ASB Exc. 2007 1.100 3 uger
SAM (jur,psy) Exc. 2003 450 1 uge
SAM (øk, stat) Cyrus mail+ Oracle kalender 350 1 uge
SUN Exc. 2007 (2003) 4.600 6 uger
DMU Exc. 2007 1.240 3 uger
DJF Exc. 2007 2.900 5 uger
DPU Exc. 2007 1.226 3 uger
HIH Exc. 2007 200 1 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.
3.2. 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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 16
3.3. Migrering af FirstClass FirstClass anvendes af Humaniora og har været i brug siden februar 2000. Der er ca. 1000 ansatte brugere
og ca. 10.000 studerende på systemet.
FirstClass er et konferencesystem og alt er opdelt i konferencer, der anvendes på forskellig vis. Der er
10.634 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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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.
3.4. Ø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 38.500 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 44.506 Design af løsning 127.500 Installation af SW 141.372 Etablering forbindelse til nyt fælles AD 82.467 Antivirus mm. 27.489 Migrering - ekskl. AD 981.750 Projektstart, Migrering inkl. mapning til nyt LDAP
1.787.995
LIVE@EDU integration 54.978 Kurser, undervisning 78.625 90.085
i alt 1.538.687 1.878.080
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. konsulent-
assistance vedr. Microsoft programmel. Ved en tilmelding inden 1/3 2011 kan Aarhus Universitet får
betydelige rabatter på et tilbud som det fremsendte.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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 e-mail (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 10.000 brugere hhv. 40.000 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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 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 11.000 postkasser til ansatte, 40.000 til studerende samt omkring 3.000
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 2007 1.100 1.100 450GB Nej ADM+TEO 2003->2010 1.114 1.114 1.1TB Nej DJF 2007 2.900 2,4TB Nej DMU 2007 1.240 1.240 0,8TB Nej DPU 2007.2 1.226 600 1TB Ja HIH 2007 1.750 1750 350GB 1550 SAM (jur,psy) 2003 450 80 230GB Nej SUN 2007 (2003) 8.823 1,3TB 4270
NAT (inkl. dele af SAM)
Mail - IMAP: Post-fix + CMU Cyrus 12.000 3,9TB Ja
Kalender Oracle Calendar 10.1 3225 3 GB
HUM
FirstClass 10.700 kan ikke adskilles 9.879
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.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 22
Identitetsstyring
Alle Exchange løsninger samt HUM løsninger anvender AD. NAT (inkl. dele af SAM) bruger LDAP.
Exchange installationer.
ASB AD - medarbejdere og studerende
ADM+TEO AD - medarbejdere
DJF AD
DMU AD
DPU AD - - medarbejdere
HIH AD
SAM 2 stk. AD
SUN AD - medarbejdere og studerende
NAT LDAP - medarbejdere og studerende
HUM LDAP – medarbejdere og studerende
Fordeling på brugere. NFIT, der kører mail for godt 3.000 ansatte på NAT og SAM og for 8-9.000 studerende på NAT, har beregnet dataforbruget. Der er ingen begrænsninger pr. postkasse, hverken på antal eller max størrelse. Heller ikke på studerende. Ansatte Studerende Gennemsnit/person Megabyte 1.400 30 gennemsnit antal mails 8.810 334 gennemsnitlig mailstørrelse Kilobyte 163 92 Største folder antal mails 155.000 17.000 Største folder Gigabyte 12 1 Største postkasse antal mails 1.000.000 30.000 Største postkasse Gigabyte 26 2 Største postkasse antal folders 7.500 334 NB: de sidste 5 optællingerne er uafhængige af hinanden. De tre "største postkasser" stammer fra tre forskellige. Omsat til 11000 ansatte 40000 studerende total lagerplads i alt TB 14,69 1,14 total antal mails millioner 92,42 12,74 Konklusion: Der skal i gennemsnit 47 studerende til at fylde det sammen som en enkelt ansat, svarende til at de 40.000 studerende fylder det samme som 850 ansatte. Samtlige studerende kræver en ekstra datalagerkapacitet på 8%.
Specielle anvendelse og integrationer.
HIH Integration til telefonanlæg/omstillingen
HIH har en Trio Present installation som bruges i omstillingen. Når der ringes forgæves ind til et nummer
ender kaldet i receptionen/omstillingen og der vises direkte hvad modtageren af kaldet har i kalenderen.
HIH hører undervisere sætter deres aftaler i kalenderen fordi ”ellers ved receptionen jo ikke hvad de laver”.
31. januar 2011
Nyt mail- og kalendersystem – V 1.0 Side 23
Andre brugere end receptionen kan bruge Trio systemet til ”presence information” men Outlook
foretrækkes.
HIH Mail/Kalender til de studerende
HIH har alle fuldtids studerende på Exchange. Med Outlook Anywhere og autokonfiguration af Outlook eller
Exchange Activesync. Teknisk er det ikke meget support på dette.
HIH vil dels lære de studerende at bruge elektronisk kalender i ”entreprise” setup, og dels give gode
muligheder for at arbejde mere ”professionelt” i samarbejdet mellem studerende og lærer. Bl.a. ved at de
studerende møder læreren med en forberedt dagsorden.
Alle undervisningsskemaer ligger KUN som elektroniske kalendere. (Bortset fra en opstartsfase på 1.
semester). Som en slags ressource mailboks hvor man åbner kalenderen der er delt.
HIH’s næste opgave er at få studieadministrationen til at sætte de studerende på mødeindkaldelserne
direkte så de får det i deres egen kalender. Ca. en fjerdedel af de studerende vil have kalender på
smartphone. De kan få fat i deres egen kalender med Activesync, men kan ikke få fat i en anden delt
kalender.
NAT
Stiller en kalendereksport til rådighed for interesserede. Den kan bruges til iCalendar og GoogleCalendar
Import fra skemasystemet. Fx er der lige blevet hældt 2415 skemalagte aktiviteter for efteråret 2010 ind i
kalenderen.
Bilag C – Projektgruppens arbejde Projektgruppen indledte med at kortlægge den nuværende anvendelse af mail- og kalender systemer (se
bilag 2). Derefter opstillede gruppen en række krav til det kommende system (se bilag 1.) Undervejs
besøgte gruppen CBS og KU. Formålet var især at blive præsenteret for CBS’s løsning overfor studerende:
Microsofts Live@EDU hhv. KU’s samlede Exchange løsning.
Leverandørpræsentation
Vi inviterede fem leverandører til at præsentere deres system i uge 46 og 47.
Microsoft med Exchange 2010
Oracle med Beehive
IBM med Lotus Notes / Domino
VMWare med Zimbra
Mikrograf/OpenText med FirstClass.
Efter de fire præsentationer besluttede gruppen at prioritere Microsoft og VMWare, fordi løsningerne
teknisk set ligger indenfor de kompetencer, vi strategisk har valgt at fortsætte med i organisationen.
Gruppen ønskede ikke at anmode leverandører om at bruge yderligere tid på arbejde, hvis sandsynligheden
for at de blev fravalgt af mere strategiske årsager, er meget store.
top related