Exchange-roadmap vervolgt zijn bochtige weg

Aan de onduidelijkheid omtrent Microsofts Exchange-server blijkt nog niet meteen een einde te komen aangezien de roadmap voor dit product opnieuw aangepast werd. Het gaat hierbij om een aanpassing met betrekking tot de Exchange Messaging Server en de Edge Services die eerst al afzonderlijk programma gelanceerd zouden worden maar nu in de toekomstige Exchange-versie geïmplementeerd zullen worden. Op die manier wil Microsoft van Exchange een compleet communicatieplatform maken. Bovendien zou Microsoft plannen hebben om toch af te stappen van het idee SQL Server als opslagplatform voor Exchange te gebruiken. In de plaats daarvan zou het de JET-technologie, die sinds versie 5.5 door het leven gaat als ESE en niet verward mag worden met de technologie uit Access, blijven gebruiken.

De volgende versie van Exchange gaat voorlopig door het leven onder de naam Exchange 12 en wordt verwacht tegen 2006 of 2007. Verschillende antispamtechnologieën zullen al in Service Pack 2 voor de huidige Exchange-software geïmplementeerd worden, maar de Edge Services die oorspronkelijk dit jaar gelanceerd zouden worden zullen volledig geïmplementeerd worden in Exchange 12. Ook het beheer van 'public folders' zal verbeterd worden en er zal een nieuwe gebruikersinterface ontwikkeld worden, aldus Microsoft-woordvoerders. Andere verbeteringen betreffen aanpasseingen aan de Exchange System Manager, backupondersteuning, opslagsystemen, zoekmogelijkheden en kalenderfuncties.

Reacties (27)

Bovendien zou Microsoft plannen hebben om af te stappen van SQL Server als opslagplatform voor Exchange en overweegt het de JET-technologie, bekend van Access, te gaan gebruiken.

Microsoft overweegt van het idee af te stappen om SQL server te gaan gebruiken voor de volgende release en te blijven bij het huidige gebruikte JET-engine.

Subtiel doch groot verschil.

Als ze nou eens eerst wat doen aan de gebruikersvriendelijksheid van de Exchange. Ik hoor menig verhaal over 3 uur durende telefoongesprekken met de microsoft helpdesk. De technologie zelf is goed, maar microsoft moet echt wat doen aan de interface, die is echt vreselijk om op te zetten.

Edit jegens Reason: De client-side van exchange is echter geen server product maar een ontvangende partij, Het is niet de bedoeling dat een kantoor zonder "interne" systeembeheerder geen exchange adres kunnen aanmaken of de server kunnen draaien. Dit is namelijk vaak genoeg het geval en daarin schiet microsoft ernstig tekort!

Exchange hoeft toch ook niet gebruikersvriendelijk te zijn. Het is een server product en het is de bedoeling dat hier expertise in is.
Ga jij de mailserver van linux maar eens optuigen dan is exchange ineens heel makkelijk..

@matiasjansen: Dat is wel zo, maar ook voor een beheer functie geldt dat je dit niet moet overlaten aan een gemiddelde pc gebruiker. Verder heeft microsoft inderdaad nog wel een lange weg te gaan, maar ze zijn verder dan alle linux distributies wat gebruikersvriendelijkheid betreft.

Ga jij de mailserver van linux maar eens optuigen dan is exchange ineens heel makkelijk..

Graag, want dat is pas een eitje.

Onder FreeBSD (Linux zal vergelijkbaar zijn):

$ portinstall -v postfix
$ vim /usr/local/etc/postfix/main.cf
$ postfix start

Tada. mailserver draait met slechts 1 bestand bewerken.

theRob, Unix en de daarvoor geschreven applicaties zijn uitermate transparent een hebben een hele modulaire opbouw. Waarom zou je een IMAP server of een POP3 server in een mail (SMTP) server will inbouwen? Veel Unix applicaties hanteren het moto "doe 1 ding en doe het verdomde goed".

Dus jij wilt er een IMAP server bij, prima:

$ portinstall -v courier-imap
$ vim /etc/rc.conf (vier regels toevoegen)
$ cd /usr/local/share/courier-imap; mkimapdcert
$ sh /usr/local/etc/rc.d/courier-authdaemond.sh start
$ sh /usr/local/etc/rc.d/courier-imap-imapd-ssl.sh start

Tada, IMAP server draait en maakt gebruik van SSL.

BTW 'portinstall' haalt de (gratis) software op, patch het indien nodig, compileert het, en installeert het.Wil je het niet compileren? Dan voeg je gewoon de parameter '-p' (van 'package') toe en dan wordt een voorgecompileerde versie van de software gebruikt.

Jij wilt virtual domains, prima dat gaat volgens een vergelijkbaar proces. Heel modulair, heel transparant, heel snel, verdomde stabiel en dat allemaal zonder een muisarm te krijgen van dat geklik!

Als iemand in Exchange al niet kan vinden hoe ie een mailaccount moet aanmaken, dan gaat het 'm nevernooitniet lukken om die command lines voor linux te vinden...

Dus dat jij thuis een mailserver hebt staan met 2 users is wat anders als een site beheren met tig mailservers en smtp gateways(smart hosts) en 20000 users.

even een kleine telling houden voor TheRob:

6 mailservers, verspreid over 2 lokaties, volledig redundant en failover.
een slordige 30.000 gebruikers, een gemiddelde van 1.000.000 mails per dag, inclusief virusscanning, spamfiltering, etc.

beheerd door mij, opgezet in een paar tellen als ik een nieuwe doos erbij wil hebben, 100% uptime over de 4 jaar dat die setup nu draait, alles FreeBSD, sendmail, mailscanner en nog wat meuk.

wat vind ik 't toch heerlijk om bij een ISP te werken.

"$ vim /usr/local/etc/postfix/main.cf"

tja...zo kun je de boel wel erg vereenvoudigen, want WAT
doe jij allemaal in dat configuratie-bestand ?

zo kan ik ook zelf handmatig een auto fabriceren met de volgende stappen:

- bedenk model,
- maak model,
- start model

en voila: een auto in drie stappen.

effuh serieus: Exchange kan natuurlijk veel meer doen dan alleen een beetje mail rondsturen. Probeer met postfix maar eens x.400 postbussen aan te spreken...of een kalenderfunctie...

Edit: voor de duidelijkheid: ik gebruik op het werk/thuis zowel Linux/Unix als Windows (en zeer binnenkort ook Mac OSX) en ik ken de kracht van 1 configuratie-bestand onder Linux.

tja...zo kun je de boel wel erg vereenvoudigen, want WAT doe jij allemaal in dat configuratie-bestand ?

Je hebt gelijk. Ik had erbij moeten vermelden dat het om twee regels ging:

myhostname = <m'n hostname>
mydomain = <m'n domainnaam>

:-)

effuh serieus: Exchange kan natuurlijk veel meer doen dan alleen een beetje mail rondsturen. Probeer met postfix maar eens x.400 postbussen aan te spreken...of een kalenderfunctie...

En dat is precies wat ik duidelijk wilde maken. Unix applicaties zijn transparant, hebben een zeker mate van gebruiks/installatie gemak, omdat ze zich concentreren op 1 ding en op dat ene ding heel erg goed doen. Dat vertaalt zich in de bijna kinderlijk simpele manier waarop je bijvoorbeeld een mailserver als Postfix kan installeren, of een IMAP server als Courier.

Unix en haar applicaties hanteren het KISS principe (Keep It Simple, Stupid), zonder daarbij aan features te hoeven inboeten.

Zucht ik slaak een zucht om jouw opmerkingen.
Postfix is SMTP geen groupware zoals Exchange.
Je moet Courier enz. installeren. Mysql erbij voor de virtual hosting enz. enz.

En je moet het nog compilen.

Dus dat jij thuis een mailserver hebt staan met 2 users is wat anders als een site beheren met tig mailservers en smtp gateways(smart hosts) en 20000 users.

Volgens mij ga jij dan pas echt zuchten

Er staat toch expliciet in het artikel genoemd dat Microsoft iets aan de interface gaat doen!

Ook het beheer van 'public folders' zal verbeterd worden en er zal een nieuwe gebruikersinterface ontwikkeld worden, aldus Microsoft-woordvoerders. Andere verbeteringen betreffen de Exchange System Manager, backupondersteuning, opslagsystemen, zoekmogelijkheden en kalenderfuncties.

Zegt nog steeds niks over de gebruikersvriendelijkheid lijkt me, de interface zelf is prima, zal gerust wel beter worden, maar het probleem is dat de leek er niks van begrijpt.

Klopt, maar hopelijk gaat men de 10 usability heuristics van Nielsen even naast hun huidige product leggen om te zien waar gebruikersvriendelijkheid een boost kan krijgen!

http://www.useit.com/papers/heuristic/heuristic_list.html

dat durven ze niet

In de 3rde klas hebben wij een project moeten doen. Het ging over een groot netwerk op zetten, met in totaal minimaal 6 servers. We hadden hier ook een Exchangen server in staan. Exchange 2003 kwam op een PC te staan. Niemand wist wat van dat programma. Maar toch draaide het na 3 muisklikken compleet. Enigste wat er moest gebeuren was een "advanced" knopje ergens aanvinken. En toen kon een protocol geselecteerd worden waarmee de mail opgehaalt moest worden. En de AD Database werd gebruikt om de gebruikers over te halen.

Dus als dit al zo makkelijk gaat, kan de rest toch ook niks voorstellen?

Enterprise messaging werkt *niet* na 3 muisklikken.
Maar dat leer je pas *na* je studie, IRL bij een 500+ man toko ..

Ok ok. Uiteraard is het opzetten voor een wat grotere toko wat lastiger.
Maar het aanmaken van email accounts is in beide gevallen exact hetzelfde.
Dus die ervaring is wel degelijk van toepassing op het verhaal van matiasjansen die dat blijkbaar al moeilijk vind.

De volgende release van SQL Server Yukon, 2005, kan ook met ongestructureerde data om en is zeer schaalbaar.
Er schijnt binnen MS al lang een stammen strijd te zijn tussen de ESE/JET engine aanhangers en SQL Server aanhangers.
Op de langere termijn zal SQL Server het opslag medium voor allerlijj storage binnen MS worden (bv ook als bestandsopslagmethode)

Ik geloof er niets van dat er zo'n stammenstrijd is bij MS.

ESE en SQL hebben gewoon allebei hun sterke punten, en daardoor is het een beter geschikt voor Exchange en het andere beter voor algemene databases.

Dat SQL ook voor bestandsopslag gebruikt gaat worden is nogal logisch. Het type load dat je bij bestandsopslag krijgt sluit keurig aan bij de sterke punten van SQL.

Sharepoint had daarom ook van het begin af aan op SQL gebouwd moeten worden. Een ESE database is gewoon ontzettend onlogisch daarvoor.
Maar Sharepoint komt uiteindelijk voort uit public folders met digital dashboard. En die developers waren dus gewend aan ESE.

Zelfs als je straks wel Exchange krijgt op een SQL database, dan ben ik er van overtuigd dat Microsoft zal aanraden daar een dedicated SQL Server voor te gebruiken aangezien de load op die databases zo totaal anders zal zijn dan alle andere SQL databases.

Kan iemand mij nu eens uitleggen wat het voordeel is van SQL Server t.o.v. ESE en visa versa.
Kijk, SQL Server is in feite altijd krachtiger geweest dan JET (toch???). Waarom zou een doorontwikkeling van JET (ESE dus) beter zijn dan een dikke SQL Server.
Wat maakt beide technieken dan uniek? Is het niet beter 1 database systeem te hebben, dan 2??

Dat is eigenlijk niet uit te leggen zonder heel diep in de techniek te duiken. Maar ik zal toch een poging wagen zonder dat te doen.

Het probleem tussen SQL en ESE is dat die databases op een totaal andere wijze worden aangesproken.

Bij SQL zul je bv een database hebben met relatief statische data waar veel zoek opdrachten op worden gedaan.

Bij Exchange (ESE) komt dat bijna niet voor. De data is gigantisch dynamisch en je zoekt zelden de hele database door. Verder zit er weinig structuur in de data.
Bv: een mailtje komt binnen. Het wordt door een gebruiker geopend. Er wordt een reply gemaakt waarbij die data opnieuw ingelezen moet worden. Het wordt verplaats naar een andere folder, en een uurtje later gewist. En dat moet bovendien allemaal supersnel gebeuren.

Vanwege dat grote verschil bleek al snel dat SQL niet genoeg prestatie zou kunnen leveren voor een Exchange database. Vandaar dat er dus voor Exchange een nieuwe database ontworpen is die optimaal geschikt is voor het soort load dat je in Exchange krijgt. (En die database heeft in zijn oorsprong banden met de access database, maar is inmiddels zodanig aangepast dat het niet meer te vergelijken is)

Nu kun je wel een SQL server ontwikkelen die ook goed geschikt is voor het soort databases dat Exchange nodig heeft, maar de vraag is of dat nuttig is. Want naast Exchange ken ik geen andere applicaties die een zelfde database belasting opleveren. Dus heeft het dan zin al die extra code in SQL te schrijven of kun je net zo goed die code in een apart programma houden?

Er zou heel wat minder "onduidelijkheid" over de Exchange roadmap zijn als mensen niet elk gerucht over die roadmap als waarheid beschouwen.

Wederom is het alleen maar een site die denkt dat Microsoft wat veranderd heeft, maar is er geen enkel bewijs en zelfs geen duidelijke indicatie dat dat werkelijk waar is.

zou Microsoft plannen hebben om af te stappen van SQL Server als opslagplatform voor Exchange en overweegt het de JET-technologie, bekend van Access, te gaan gebruiken

ik zou toch zweren dat het anders om was. Een aangepaste Jet was gebruikt omdat SQLserver nog erg moeilijk om ging met niet gestructureerde data. Dat zou in SQL 2000 beter moeten zijn en in de nieuwe helemaal super moeten zijn (?) .

Ik zou niet echt verbaasd zijn als ze inderdaad nog niet met SQL integreren.

De hele manier waarop een Exchange database noodzakelijkerwijs opgezet moet worden, en de soort load die zo'n database krijgt, is totaal verschillend van een normale sql database.
Uiteraard kun je het integreren, maar dan krijg je bij het aanmaken van een nieuwe database in SQL waarschijnlijk eerst de vraag of je een klassieke database wilt aanmaken, of een exchange compatible sql database.
Je moet je dan afvragen of je niet beter twee verschillende databases kunt houden, zodat beide producten optimaal op hun eigen type database zijn afgesteld.

Als Exchange admin zat ik niet echt op die SQL database te wachten. Het levert mij geen voordeel op. Die 64bit support zou wel mooi zijn want al dat geklooi met 3GB, userva switches en de geheugen fragmentatie zou dan een stuk minder worden.

Ik snap alleen niet waarom ze nog steeds met die public folders bezig blijven. Het concept lijkt aardig, maar in de praktijk werkt het gewoon niet in grote omgevingen. Ook bij Microsoft zelf worden die dingen bijna niet gebruikt.

In de plaats daarvan zou het de JET-technologie, die sinds versie 5.5 door het leven gaat als ESE en niet verward mag worden met de technologie uit Access, blijven gebruiken.

Juist niet dus.