ANSKAFFELSE AF FÆLLES MAIL OG KALENDER SYSTEM

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


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


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


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


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.

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.

31. januar 2011


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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.

ANSKAFFELSE AF FÆLLES MAIL OG KALENDER SYSTEM

Documents

Transcript of ANSKAFFELSE AF FÆLLES MAIL OG KALENDER SYSTEM