Waarom migreren bedrijven van Lotus Domino naar MS Exchange?

[Jazzy]

Ik heb het al vaker gezegd (keer of drie) maar als je een goede vergelijking wilt dan moet je applicaties buiten beschouwing laten. Exchange is geen applicatie-platform.

IM zit niet meer in Exchange, die rol is verhuisd naar een veel meer volwassen product wat Office Communication Server heet. Uiteraard integreert OCS volledig in Exchange en wordt zelfs onderdeel van de webinterface.

Voor de rest zie ik geen bijzondere punten die niet in één of andere vorm bestaan in Exchange. Jammer trouwens dat je niet in gaat op de stevige kritiek die je hierboven op je argumenten hebt gekregen.

[alt-92]

martdj schreef op maandag 03 mei 2010 @ 20:55:
Zoals gezegd ken ik Exchange / Outlook 2010 niet

En daardoor vallen je eigen vergelijkingen dan ook gelijk in het water.
Je kan alleen nog als een hangende plaat elke keer dezelfde riedel afdraaien - zelfs als anderen met ervaring op beide platforms je vertellen dat er niet sprake is van een 'one solution fits all' oplossing.
Dat noemen we ook wel een betonnen plaat voor je hoofd hebben.

[martdj]

KnetterGek schreef op maandag 03 mei 2010 @ 19:34:
[...]
[...]
Dat kan niemand behalve jij navolgen - jij liegt gewoon een paar verzonnen feitjes (zie je startpost en elke volgende "argumentatie" waarom LN iets zou kunnen wat minstens net zo goed in LN kan als in Exchange) bij elkaar en roept dan "Zie je wel, LN is beter".
Het is voor ons als techneuten nieuw dat populistisch schreeuwen ook in discussies over techniek gebruikt wordt - wij zijn nog gewend dat je met feiten moet komen om overtuigend te zijn. Maar dat kan aan ons liggen.
[...]

Ik zie gewoon een hoop misverstanden over Lotus Notes / Domino en als ik die duid en aangeef hoe het precies zit, kom ik met "verzonnen feitjes" en ben ik populistisch aan het schreeuwen. Dat klinkt toch sterk naar een flame en vind ik ook erg jammer in een technisch forum waarvan je mag verwachten dat mensen kennis van zaken hebben. Als je denkt dat ik feitjes verzin moet je gewoon even Googlen en dan zul je zien dat al die "verzonnen feitjes" gewoon 100% kloppen. Dat licentiegeld verhaal kun je overigens ook gewoon verifiëren als je bij een Forrester of Gartner zoekt op TCO Exchange vs Domino.

Zulke Oost-Indisch dove mensen in je verkoop- of consultingtak zijn een gewéldige manier om je klanten weg te werken: puur omdat ze die consultant/verkoper niet meer willen zien of spreken en niet vertrouwen. Het soort dat je na het handenschudden onbewust checkt of je horloge er nog is en naderhand je handen gaat wassen vóór je naar de WC gaat.

Ik weet niet wat jouw functie is, maar een technisch consultant die duidelijk weet waar ie over praat en een klant goed kan uitleggen hoe hij meer uit zijn investering kan halen wordt juist erg gewaardeerd.

Zal ik je even bijbabbelen dan? [..]

Je hangt Office Communications Server in je netwerk en AD. [..]

Ah, ik vermoedde al zoiets. Dat betekent dus wel dat dit geen functionaliteit is van Exchange, maar van OCS. Zonder OCS heb je deze functionaliteit immers niet. Als je dan gaat vergelijken met de Lotus productportfolio moet je er dus Lotus Sametime Unified Communications bijhalen. Niet mijn specialisme, maar Sametime is op dit gebied wel marktleider (verzonnen feit? Check Google maar ).

[martdj]

Rolfie schreef op maandag 03 mei 2010 @ 20:28:
[...]

Das leuk ,maar als je een SAN met highend SAS schijven moet neer zetten of een SAN met SATA disken, dat scheelt wel een paar euro's. Exchange 2010 is juist geoptimaliseerd voor SATA schijven. Hierop is juist dus een grote kosten bespraken op te halen.

Niet lullig bedoeld, maar dan heeft Microsoft in Exchange 2010 blijkbaar eindelijk een van zijn grote nadelen t.o.v..Domino aangepakt. Domino heeft namelijk nooit een SAN met highend SAS schijven nodig gehad. De i/o van Domino ligt een stuk lager dan die van de oudere Exchange versies.

[Jazzy]

martdj schreef op maandag 03 mei 2010 @ 21:18:
Dat licentiegeld verhaal kun je overigens ook gewoon verifiëren als je bij een Forrester of Gartner zoekt op TCO Exchange vs Domino.
..maar Sametime is op dit gebied wel marktleider (verzonnen feit? Check Google maar ).

Waarom moeten wij met Google gaan zoeken naar de onderbouwing die jij niet wilt geven?

Overigens beschikt Exchange native over Unified Messaging, denk aan voicemail in je mailbox ontvangen en 'inbellen' in je mailbox. Daar heb je geen OCS voor nodig.

[Gomez12]

martdj schreef op maandag 03 mei 2010 @ 20:55:
Als we dan toch aan productvergelijking doen lijkt het me overigens handig om dan ook de unieke features van Lotus Notes / Domino te noemen. Zoals gezegd ken ik Exchange / Outlook 2010 niet, dus verbeter me maar als er punten in zitten die Exchange / Outlook inmiddels wel kunnen.

De filosofie van de huidige Lotus Notes client is dat je alle informatie die jij nodig hebt om je werk te kunnen doen bij elkaar hebt in 1 applicatie. Daarvoor zijn een aantal functionaliteiten in de client die dit mogelijk maken:

Composite applications
Tja, download .net express edities en je kan je lol op qua webservices / outlook plugins, of je hier als bedrijf zin in hebt is iets anders maar ok. Met vbscript kan je op de client het ook zo gek maken als je wilt. Wederom zou ik het niet aanraden, maar bij mij moeten eindgebruikers ook geen apps maken...

Live Text
Klinkt me nou niet echt speciaal in de oren, misschien dat je het moet zien. Maar als bedrijf wat alleen maar over internet werkt zou ik dus overal in zo ongeveer elk mailtje irritante links krijgen?

Chat / Sametime
OCS

RSS feeds
Ik dacht vanaf outlook 2007

Kalender integratie:
Ik dacht vanaf outlook 2007

Customization:
Lijkt mij rete-irritant om support over te moeten geven, bij iedereen alles anders, of je moet het echt in de richting van policy's bedoelen en dan voorziet exchange / AD / Outlook daar weer in.

Domain monitoring:
Tja, dit wil ik nog niet eens op een mail-server hebben. Niets zo irritant als op elke server/app een apart monitoring systeem hebben. Het integreert maar in ons huidige monitoring systeem ( waar exchange dan weer voldoende mogelijkheden voor biedt )

Applicatie platform
Simpel gezegd, dat is exchange niet. Gaat het ook nooit worden ook, daarvoor hebben ze andere pakketten...

Ik vraag me dit schrijvende af of Exchange inmiddels al een goede oplossing heeft gevonden voor de afdelingsmailboxen.

Geen idee hoe dat in 2008 is, maar wmb een terecht pijnpuntje van exchange.
Daar heb ik het nog nooit normaal werkend gezien zonder custom scripting... Altijd bleven die send items maar in de user-map terecht komen ipv in de afdelingsmap.

Maarja, die hele send-as technology heb ik binnen exchange nooit goed werkend gekregen ( ik verwacht een kopie in de sent map van de user en in de sent map van degene als wie het verzonden is) , anderen mogen best als mij versturen, zolang ik het maar kan nagaan

[Jazzy]

martdj schreef op maandag 03 mei 2010 @ 21:21:
Niet lullig bedoeld, maar dan heeft Microsoft in Exchange 2010 blijkbaar eindelijk een van zijn grote nadelen t.o.v..Domino aangepakt. Domino heeft namelijk nooit een SAN met highend SAS schijven nodig gehad. De i/o van Domino ligt een stuk lager dan die van de oudere Exchange versies.

Feiten graag. En we zouden het bij de hudige versies houden, is het niet?

Maar om het even concreet te houden. Hoeveel IOPs veroorzaakt een gebruiker met een gemiddeld mailprofiel van laten we zeggen 100 berichten per dag (20 zenden, 80 ontvangen). Of kies zelf een profiel wat je past, maar roep een IOPs.

Edit: Laat maar, ik doe het zelf wel. Een gebruiker met Lotus Notes 8.5.1 produceert 0,175 tot 0,21 IOPs. Bij Exchange 2010 en Outlook 2010 is dat 0,1 tot 0,12. Dat betekent dat de hudige versie van Lotus Notes ca. 1,5 zo veel IOPs genereert dan Exchange.

Bron:
http://www.ibm.com/develo...ary/domino85-performance/
http://technet.microsoft....ibrary/ee832791.aspx#iops

[ Voor 22% gewijzigd door Jazzy op 03-05-2010 21:45 ]

[martdj]

Gomez12 schreef op maandag 03 mei 2010 @ 21:06:
[...]

Tja, dan is het hele topic een doelloze excercitie. Dan kun je de clients niet vergelijken, dan kun je de VOIP mogelijkheden niet vergelijken etc etc.
Dan kun je het net zo goed gaan vergelijken met sendmail in zijn ruwste vorm. De MTA is namelijk zo ongeveer het enigste wat hetzelfde moet doen.

Als je Lotus Notes hebt met apps in Domino dan moeten die mee naar Exchange ( linksom of rechtsom )
Als je exchange hebt met VOIP eraan gekoppeld dan moet dat mee naar Lotus Notes ( linksom of rechtsom )

Exchange / Domino zijn redelijke totaal-producten, of alles moet over of niets moet over. Je kan niet gaan zeggen dit is wel positief, dat is negatief als je gedeeltes weg gaat laten.

Daar heb ik niets aan toe te voegen.

@martdj : Vraagje, wij gaan als bedrijf over 6 maanden over van een linux-server naar een sbs-server ( keuze is in principe al gemaakt ).
Wat zouden de argumenten voor mij ( als beslisser ) zijn om te kijken naar Domino?

Kleine situatie schets :
- We hebben nu 1 linux server en 1 windows server
- Linux server verzorgt files / mail / calendars etc. en is DC
- Linux server gaat eruit ( dus er komt hoe dan ook nieuwe hardware in )
- Gebruikersaantal is 25
- Beheersgroep heeft ervaring met linux en windows

Wat zijn nou de killing features van Domino waarvoor we daarvoor zouden moeten kiezen en niet voor de MS oplossing die ons gelijk een hoop andere voordelen geeft?

Als je deze overweging maakt, zou je eigenlijk ook naar Lotus Foundations (goede link met Nederlandstalige info) moeten kijken. Dat is vergelijkbaar met MS SBS, maar dan gebaseerd op Linux en Domino (waarbij de beheerkant daarvan zo is ingericht dat je je nauwelijks met de producten zelf hoeft bezig te houden.

Als je puur Domino tegenover SBS zet, denk ik dat sterke punten zijn:

• Je kunt Linux als Server OS blijven draaien, waarmee je op licentiekosten spaart.
• Applicaties schrijven in Lotus Domino is heel makkelijk te leren (en zijn door korte ontwikkeltijd ook goedkoop in te kopen), maar kunnen erg krachtig zijn om zaken die voor jouw business uniek zijn te automatiseren
• De gratis Sametime limited licentie die je bedrijf chat mogelijkheden geeft voor je medewerkers
• Domino replicatie, waarmee je zowel je mail/calendar als applicaties altijd offline kunt benaderen

Edit:
@hStuivenberg De klant heeft hier al een Linux server en een Linux DC. Geen Linux consultancykosten nodig dus, terwijl de migratie van de DC waarschijnlijk eenvoudiger is, omdat die op Linux blijft (uitgaand van het 2e scenario van Domino los van Lotus Foundations).

Edit2:
Zoals Jazzy zeer terecht opmerkt moet je MS SBS vergelijken met Lotus Foundations omdat je anders appels met peren vergelijkt.

[ Voor 7% gewijzigd door martdj op 03-05-2010 22:23 ]

[Jazzy]

Gomez12 schreef op maandag 03 mei 2010 @ 21:06:
[...]

Tja, dan is het hele topic een doelloze excercitie. Dan kun je de clients niet vergelijken, dan kun je de VOIP mogelijkheden niet vergelijken etc etc.

Dat is niet wat ik wilde zeggen. Je kunt een platform wat messaging en applicaties doet nu eenmaal niet vergelijken met een platform wat messaging doet.

Vorig jaar heb ik nog een migratie gedaan voor 3 organisaties in een fusie. Twee daarvan hadden Lotus Notes en eentje had Exchange 2003. Voor de nieuwe omgeving heeft klant gekozen voor Exchange 2007. Die omgeving hebben wij ontworpen, gebouwd en de maildata en fucntionaliteit naar toe gemigreerd. Lotus Domino is daar gewoon blijven draaien omdat men geen haast had met migreren van de applicaties naar andere oplossingen. Maar Notes was na de migratie definitief uit gebruik.

Wat ik daarmee zeggen wil, bij Domino is het heel goed mogelijk om de applicatiekant te scheiden van de messagingkant. Je moet wel, want voor zover ik weet is er geen (volwassen) oplossing die de zelfde functionaliteit biedt.

Wat zouden de argumenten voor mij ( als beslisser ) zijn om te kijken naar Domino?

Ik weet er wel eentje, maar ik zal eerst de TS even aan de beurt laten.

[hstuivenberg]

martdj schreef op maandag 03 mei 2010 @ 21:45:

Als je puur Domino tegenover SBS zet, denk ik dat sterke punten zijn:

• Je kunt Linux als Server OS blijven draaien, waarmee je op licentiekosten spaart.
• Applicaties schrijven in Lotus Domino is heel makkelijk te leren (en zijn door korte ontwikkeltijd ook goedkoop in te kopen), maar kunnen erg krachtig zijn om zaken die voor jouw business uniek zijn te automatiseren
• De gratis Sametime limited licentie die je bedrijf chat mogelijkheden geeft voor je medewerkers
• Domino replicatie, waarmee je zowel je mail/calendar als applicaties altijd offline kunt benaderen

Licentiekosten SBS (1e de beste webwinkel via google): € 1104,- incl 5 users. Daarnaast 246 per 5 users, maakt een totaal van 2088 euro ex btw. Dat zijn ongeveer 2 consultancy dagjes op linux en dan heb je het al terug verdiend.....Met SBS heb je niet alleen groupware, maar ook meteen een intranet (sharepoint).

Domino replicatie: kan met outlook ook (Outlook in Cached mode), of gewoon via de webmail.

[ Voor 3% gewijzigd door hstuivenberg op 03-05-2010 21:59 ]

[Jazzy]

Kom op dan martdj, nu kun je scoren en laat je het nog liggen!

Het grote verschil tussen SBS en Lotus Foundation is dat je bij laatste een security suite krijgt en een Office suite. Verder is die laatste een fractie goedkoper, maar dat ligt niet aan Linux omdat je bij beide suits een totaalprijs betaalt voor alle functionaliteit.

[martdj]

Gomez12 schreef op maandag 03 mei 2010 @ 21:27:
[...]

Composite applications
Tja, download .net express edities en je kan je lol op qua webservices / outlook plugins, of je hier als bedrijf zin in hebt is iets anders maar ok. Met vbscript kan je op de client het ook zo gek maken als je wilt. Wederom zou ik het niet aanraden, maar bij mij moeten eindgebruikers ook geen apps maken...

Het idee is niet dat gebruikers dit zelf doen, maar deze applicaties als gewone Domino applicaties beschikbaar worden gemaakt.

Live Text
Klinkt me nou niet echt speciaal in de oren, misschien dat je het moet zien. Maar als bedrijf wat alleen maar over internet werkt zou ik dus overal in zo ongeveer elk mailtje irritante links krijgen?

Ook dit kun je op afstand beschikbaar maken, waarbij je als gebruiker kiest of je het (per "widget") aan wilt zetten of niet.

Chat / Sametime
OCS

Niet gratis bij Exchange tenzij ik me vergis.

[..]
Customization:
Lijkt mij rete-irritant om support over te moeten geven, bij iedereen alles anders, of je moet het echt in de richting van policy's bedoelen en dan voorziet exchange / AD / Outlook daar weer in.

Zo'n bedrijfslogo wat ik als voorbeeld gaf stel je vanuit de beheerafdeling in in het mail template. Of je gebruikers de mogelijkheid om hun mailfile te customizen (eigen agents te bouwen etc) danwel eigen applicaties te bouwen, is ook een keuze die je als bedrijf maakt (kun je dus wel of niet mogelijk maken). Wat ik bedoelde aan te geven is dat je als bedrijf de standaard templates eenvoudig kunt aanpassen naar je eigen wensen.

[martdj]

Jazzy schreef op maandag 03 mei 2010 @ 21:56:
Kom op dan martdj, nu kun je scoren en laat je het nog liggen!

Het grote verschil tussen SBS en Lotus Foundation is dat je bij laatste een security suite krijgt en een Office suite. Verder is die laatste een fractie goedkoper, maar dat ligt niet aan Linux omdat je bij beide suits een totaalprijs betaalt voor alle functionaliteit.

Ik probeerde 2 omgevingen te schetsen (Lotus Foundations vs Linux + Domino), maar dat kwam blijkbaar niet duidelijk over. Ik zou zelf hier ook eerder Lotus Foundations adviseren dan Linux apart + Domino, maar bedankt voor jouw verduidelijking en toelichting

Edit:
Wat posten jullie trouwens snel. Tegen de tijd dat ik een verhaal heb geschreven staan er al weer 3 nieuwe posts

[ Voor 8% gewijzigd door martdj op 03-05-2010 22:09 ]

[Gomez12]

martdj schreef op maandag 03 mei 2010 @ 21:45:
[...]
Als je deze overweging maakt, zou je eigenlijk ook naar Lotus Foundations (goede link met Nederlandstalige info) moeten kijken. Dat is vergelijkbaar met MS SBS, maar dan gebaseerd op Linux en Domino (waarbij de beheerkant daarvan zo is ingericht dat je je nauwelijks met de producten zelf hoeft bezig te houden.

Tja, voor zover ik zie is Lotus Foundations puur en alleen een oplossing voor een simpel probleem ( Mail + calendar + files + print ), hierin is het afaik uitgebreider dan SBS ( ik dacht dat daarin in zichzelf geen spam-filter zat ).
Maar behalve beheersgemak zie ik niet echt wat het meer biedt boven een standaard linux-server install.

Terwijl we met SBS juist vanwege de vendor lock-in meer integratie met programma's die wij gebruiken kunnen verwachten ( er zijn afaik iets meer courante outlook / exchange plugins dan notes / foundation plugins ) en maatwerk-plugins worden erg kostbaar met 25 man.

Als je puur Domino tegenover SBS zet, denk ik dat sterke punten zijn:

• Je kunt Linux als Server OS blijven draaien, waarmee je op licentiekosten spaart.
• Applicaties schrijven in Lotus Domino is heel makkelijk te leren (en zijn door korte ontwikkeltijd ook goedkoop in te kopen), maar kunnen erg krachtig zijn om zaken die voor jouw business uniek zijn te automatiseren
• De gratis Sametime limited licentie die je bedrijf chat mogelijkheden geeft voor je medewerkers
• Domino replicatie, waarmee je zowel je mail/calendar als applicaties altijd offline kunt benaderen

Simpel gezegd, licentiekosten zijn geen issue. Opleidings/gewennings kosten als we van office pakket over zouden stappen zijn iets duurder.
Voor de rest zie ik niet echt een voordeel zolang we zelf niet willen programmeren.
Chat klinkt leuk, maar Sametime limited dan krijg ik het idee dat we net zo goed zelf een jabber server of MSN oid kunnen gebruiken. Voor de echte leuke dingen hebben we toch de officiele nodig en dan kunnen we net zo goed voor OCS gaan.

Edit:
@hStuivenberg De klant heeft hier al een Linux server en een Linux DC. Geen Linux consultancykosten nodig dus, terwijl de migratie van de DC waarschijnlijk eenvoudiger is, omdat die op Linux blijft (uitgaand van het 2e scenario van Domino los van Lotus Foundations).

Ho wacht, stop. Zoals ik al zei gaat er compleet nieuwe HW komen. Qua dagelijks beheer kennen we onze weg of onder linux of onder windows.
Maar complete re-install kost ons iets te veel tijd om zelf te gaan doen. Dat is momenteel gewoon begroot als 3 dagen install tijd ( onder windows of onder linux )
Linux biedt dus geen kostenbesparing, het is lood om oud ijzer wat dat betreft. Zelfde met uitleg qua beheerstools, het kan er nog zo mooi en simpel uitzien. Maar of het nu windows of linux wordt, de installerende partij mag er ( momenteel in 1e schattingen ) 2 dagen over doen om alles te gaan documenteren / uitleggen.

Linux / Windows is dus wat dit betreft gewoon lood om oud ijzer, wij stellen gewoon als eis dat alles 99% gedocumenteerd wordt, hier zijn in principe geen short-cuts in te maken.

Edit2:
Zoals Jazzy zeer terecht opmerkt moet je MS SBS vergelijken met Lotus Foundations omdat je anders appels met peren vergelijkt.

Puur persoonlijk denk ik dat je in een MKB ( met een gering aantal servers ) appels met peren vergelijkt als je linux met Windows gaat vergelijken.
In een bedrijf met meerdere servers heb je al snel een troep-server voor de programma's met wat meer kuren.

In een bedrijf met 2 servers zou Lotus foundations echt betekenen dat alle crappy windows apps op 1 server terecht komen.

[Verwijderd]

Tja, voor zover ik zie is Lotus Foundations puur en alleen een oplossing voor een simpel probleem ( Mail + calendar + files + print ), hierin is het afaik uitgebreider dan SBS ( ik dacht dat daarin in zichzelf geen spam-filter zat ).

Ten eerste: Interrestante topic ondanks het hoge LN verkoop gehalte.
Ten tweede: Indien men over SBS gaat praten (en nog erger linux) gaat deze discussie totaal de verkeerde kant op. Het gaat toch over Domino <> Exchange?
Ten derde:

Van de meeste middleware appicaties kunnen we absoluut niet accepteren dat je je data moet migreren in plaats van even een laatste versie erop te zetten (denk aan CRM systemen, Financiële pakketten etc), maar voor mail zou dat zelfs te prefereren zijn?

Kun je niet accepteren dat er veranderingen (verplaatsingen) in je omgeving plaats vinden? Dan zou ik toch maar eens op zoek gaan naar andere oplossingen... Een IT omgeving hoort dynamisch te zijn....

Het leuke van Domino is dat je niet hoeft te testen of je mail na een server upgrade nog werkt, want daar mag je gewoon vanuit gaan. Ik heb in mijn rijke ervaring nog nooit een Domino mail server gezien die na een upgrade terug moest naar een vorige versie.

Dat is een flame of een niet onderbouwde mening. Ik heb tientallen defecte exchange servers gezien maar nooit vanwege exchange zelf. Altijd verkeerd geconfigureerde virusscanners of defecte (cheap) hardware.
Tevens spreek je jezelf daaronder weer tegen.

Bedenk ook goed dat een migratie extra hardware betekent, extra server licenties etc.

Dat is totaal afhankelijk van de situatie. De meeste exchange omgevingen die ik tegenkom draaien op VMware. Licenties zijn ook niet als argument te noemen omdat deze in iedere situatie anders is.

Persoonlijk denk ik dat veel beheerders gewoon steeds meer Microsoft "kiezen" uit gemak. Alle novell mensen wilden ook hun edirectory in de lucht houden maar deze en AD onderhouden levert gewoon teveel beheer op. Het algehele platform van Microsoft is zo omvangrijk dat de keuze eerder "wanneer" is geworden.
Neem daarbij dat Microsoft zeer scherpe prijzen kan afleveren met bepaalde bundels waarmee ze andere producten "pushen": http://www.microsoft.com/.../us/products/default.aspx
Daar is echter voor de klant niets mis mee. Die betaald alleen minder.

[Gomez12]

Verwijderd schreef op dinsdag 04 mei 2010 @ 00:48:
[...]
Ten tweede: Indien men over SBS gaat praten (en nog erger linux) gaat deze discussie totaal de verkeerde kant op. Het gaat toch over Domino <> Exchange?

Het punt is alleen dat Exchange op zichzelf vrij weinig is en vrij weinig doet. Net zoals Domino.

Het zijn alletwee totaalpakketten die afhankelijk zijn van de mate van integratie.

Allebei zijn ze even waardeloos als je thunderbird ( zonder extensions ) als client gebruikt.
Hoe meer je gaat integreren hoe meer je de verschillen gaat zien ( zoals Knettergek mooi laat zien ) maar dan krijg je weer de discussie is die mate van integratie core of geen core.

Daarom dacht ik van : ik noem even een praktijkcase waar ik straks mee ga zitten. Het is extreem kleinschalige case, maar het toont wmb wel goed aan dat het niet echt over domino vs. exchange gaat, maar meer om de servercultuur die de klant eromheen heeft.

Wil je puur een MTA ( neem sendmail ) wil je daar een agenda bij ( neem Google Apps ) Wil je vooruit kunnen en verregaande integratie hebben, dan is het wmb voornamelijk de vraag wat heb je nu al en wat wil je.

En daar zit denk ik ook het grootste mentaliteitsverschil in in deze discussie, de ene kant wil het liefste hobbyen tot hij erbij neervalt of het werkt ( de Domino kant met RAD ), de andere kant wil gewoon dat het werkt en is bereid daarvoor geld op tafel te leggen ( De exchange kant ) als het niet al gratis bij pakketten komt.

Heb je 200 linux bakken draaien, dan is het gekkenwerk om een exchange neer te zetten.
Heb je 200 windows bakken draaien, dan is het gekkenwerk om een domino neer te zetten.
Heb je 100 om 100 draaien dan is het afhankelijk van wat je ermee wil en wat je al hebt.

[Jazzy]

Gomez12 schreef op dinsdag 04 mei 2010 @ 01:10:
[...]

Het punt is alleen dat Exchange op zichzelf vrij weinig is en vrij weinig doet. Net zoals Domino.

Hetis al een raar topic, maar jij maakt het nog fraaier.

[alt-92]

Weet je.. uiteindelijk is het de (eind)gebruiker die bepaalt wat er in een MKB ingezet wordt.
En dan bedoel ik niet dat ie om de tafel zit bij de onderhandelingen, maar dat ie zonder extra cursussen gewoon zijn of haar werk kan doen met z'n bestaande kennis.

Je hoeft echt niet aan te komen met Domino als dat betekent dat er eerst nog een cursus omscholing bij komt zodat men naar hartelust op een nieuw platform een compleet homebrew ERP in elkaar gaat zetten als een halve Domino consultant - er moet gewoon gewerkt kunnen worden door Jessica met haar Word template zonder dat ze als tiepgeit eerst alles opnieuw moet aanleren..

En dat betekent dat de grote kracht van LN/Domino eigenlijk verspild wordt en het niks meer als een mailserver gaat worden - en hey, daar is dat andere bekendere pakket met Exchange weer - dat kennen ze, kunnen ze beheren en ze kunnen omgaan met de nukken.

In Enterprise land gaat een ander verhaal op, namelijk dat daar veel meer functionaliteit opgesplitst wordt.
Een mailomgeving is een mailomgeving, een Database wordt puur als DB ingezet (Oracle/DB2/MSSQL) en je zal zelden zien dat LN daar voor alles en nog wat tegelijk ingezet wordt op grote schaal.
Hell, onze intranet sites zijn van LN geconverteerd naar SPS omdat het zonde van het geld en de moeite was om LN alleen maar als webapp platform te gebruiken.
Dan gebruik je maar één functionaliteit van een totaal oplossing en dat is niet kosteneffectief meer.

[martdj]

Verwijderd schreef op dinsdag 04 mei 2010 @ 00:48:
[...]
[...]
Kun je niet accepteren dat er veranderingen (verplaatsingen) in je omgeving plaats vinden? Dan zou ik toch maar eens op zoek gaan naar andere oplossingen... Een IT omgeving hoort dynamisch te zijn....
Ten derde:

Nu maak je het toch wel erg bont. Natuurlijk moet een IT omgeving dynamisch zijn, maar dat moet niet afgedwongen worden door een fabrikant die het niet voor elkaar krijgt om zijn product zo te maken dat je een in-place upgrade kan doen. Dit is echt een zwaktebod van Microsoft wat ze overigens zelf op blogs ook toegeven (verontschuldiging dat vanwege de grote veranderingen het niet mogelijk is om een in-place upgrade te doen). Als je denkt dat het normaal is dat je geen in-place upgrade kunt doen komt het op mij over dat je, sorry dat ik het zeg, gebrainwashed bent door Microsoft om de manier die zij kiezen per definitie de beste te vinden. Doel voor elke fabrikant is om een upgrade naar een nieuwe versie zo te maken dat je die in-place uit kunt voeren. Microsoft krijgt dat met Exchange echter tot nu toe nooit voor elkaar en dat is echt een minpunt van Exchange.

[...]
Dat is een flame of een niet onderbouwde mening. Ik heb tientallen defecte exchange servers gezien maar nooit vanwege exchange zelf. Altijd verkeerd geconfigureerde virusscanners of defecte (cheap) hardware.
Tevens spreek je jezelf daaronder weer tegen.

Ik zeg niets over Exchange. Ik zeg hoe de situatie is bij Domino waar je dus wel een in-place upgrade kunt doen en als ik er zelf daarvan al tientallen zo niet honderden heb uitgevoerd lijkt me dat voldoende onderbouwing.

[sanfranjake]

martdj schreef op dinsdag 04 mei 2010 @ 08:32:
[...]

Nu maak je het toch wel erg bont. Natuurlijk moet een IT omgeving dynamisch zijn, maar dat moet niet afgedwongen worden door een fabrikant die het niet voor elkaar krijgt om zijn product zo te maken dat je een in-place upgrade kan doen. Dit is echt een zwaktebod van Microsoft wat ze overigens zelf op blogs ook toegeven (verontschuldiging dat vanwege de grote veranderingen het niet mogelijk is om een in-place upgrade te doen). Als je denkt dat het normaal is dat je geen in-place upgrade kunt doen komt het op mij over dat je, sorry dat ik het zeg, gebrainwashed bent door Microsoft om de manier die zij kiezen per definitie de beste te vinden. Doel voor elke fabrikant is om een upgrade naar een nieuwe versie zo te maken dat je die in-place uit kunt voeren. Microsoft krijgt dat met Exchange echter tot nu toe nooit voor elkaar en dat is echt een minpunt van Exchange.

Zonder op alle posts hierboven in te gaan kan ik het toch niet langer laten me afzijdig te houden.

Maar waarom is een in-place upgrade zo'n groot voordeel, en zo'n must voor een messaging omgeving? De bedrijven waar ik doorgaans kom zullen drie tot vijf jaar met de geboden oplossing gaan draaien, en zullen daarna een traject in gaan om zowel hardware, server- als clientsoftware te vervangen.
Een inplace-upgrade is leuk, en misschien voor de beheerder handig. Echter vind ik het in een discussie over voor- en nadelen een loos argument, omdat je niet elke week/maand/jaar je mailserver gaat upgraden

Overigens slaat jouw opmerking dat inplace-upgrades met Exchange niet mogelijk zijn nergens op. Het was tot 2003 een standaardfunctionaliteit, welke er bewust uit gehaald is vanwege diverse veranderingen, om zo ook de stabiliteit van omgevingen te kunnen garanderen. Wie zegt er namelijk dat je bij een inplace upgrade niet tegen allerlei gekke problemen aan gaat lopen die 4 jaar geleden ongedocumenteerd eens door een stagiair gecreerd zijn? Je neemt een stuk historie mee wat per definitie gewoon niet 100% hetzelfde zal zijn als een schone omgeving.

Het is geen zwaktebod van Microsoft, maar een hele bewuste keuze om de stabiliteit zoals we die gewend zijn van Exchange te kunnen garanderen. Daarnaast speelt een klein beetje mee dat er bij Exchange 2003 > 2007 een transitie werd gemaakt van 32- naar een 64-bits platform, wat een inplace-upgrade overwegen onzinnig maakt (dit kan technisch niet). Ik neem voor het gemak aan dat dit op linux/domino hetzelfde is, gelukkig ben ik niet gehinderd door enige kennis van die producten.

Ook wil ik nog even vermelden dat ik de negatieve toon in jouw posts, waarbij je continue alle feiten probeert omver te praten met IBM-marketingpraatjes erg jammer vind. Toen ik dit topic vorige week voor het eerst opende dacht ik dat er een open discussie uit zou ontstaan, waar we inderdaad van elkaar kunnen leren. Al was het alleen maar om nog meer argumenten te verzamelen voor onze eigen standpunten.
Echter zoals ik het nu bekijk zitten we 2 millimeter verwijderd van een flamewar, als we er al niet middenin zitten. Ik heb het idee dat er verschillende niveaus langs elkaar heen zitten te praten, waar ik doel op sales/marketing en techniek. Hopelijk kun je er wat mee, en stel je je in volgende post wat minder defensief op!

[mjtdevries]

Sowieso is een in-place upgrade iets dat in een enterprise omgeving "not done" is.
Niet alleen voor Exchange, maar voor elke bedrijfskritische applicatie. (Ik ken werkelijk NIEMAND die dat doet)

Dat is volgens mij echt een argument dat alleen speelt bij zeer kleine omgevingen.
Idem voor het "hardware" argument. Hoe kan de eis voor x64 hardware nou ooit een probleem zijn?

Op het moment dat Exchange 2007 uit waren x64 processors al doodnormaal. Vrijwel iedereen had die dingen zelfs al in hun desktoppie thuis zitten. Hoe kan je dan met droge ogen dat als een serieus argument aanhalen?

En wat hierboven al zeer terecht opgemerkt werd: in een Enterprise omgeving laat je software upgrade altijd samen lopen met een hardware upgrade.


Wellicht moet je de discussie opnieuw opstarten met als onderwerp:
wat zijn voor en nadelen van Notes vs Exchange in een kleine omgeving

Of wellicht: Kan iemand mij de nieuwe features van Exchange 2007 en 2010 vertellen, want ik ken die versies totaal niet en ik zie steeds meer Notes klanten op die versies overstappen?


P.S.
hebben de andere Exchange specialisten hier ook met stomme verbazing naar die Google cijfers zitten te kijken? (ze zullen niet volledig verzonnen zijn neem ik aan....) Ik kan me zelfs met Exchange versies eerder dan 2007 en 2010 niet voorstellen hoe je ooit zoveel geplande en ongeplande downtime per maand kan hebben.
Ik draai een omgeving met 8000 mailboxen in een org van 120.000 mailboxen.
Met 2007 zit ik op een ongeplande downtime van een paar minuten per jaar. (een keertje een failover, waar de gebruikers met outlook in cached mode niet eens wat van merken)
Met 2003 heb ik ooit een keertje 24 uur downtime gehad, maar dat lag niet aan Exchange, maar een corrupte array controller een storage team dat de backups niet goed gemonitoord had zodat de laatste backup 2 weken oud was. toen moest ik dus op een zondag een repair/p doen.
Maar verder met 2003 ooit nooit iets bijzonders. Idem voor 2000 en 5.5

Wat die jongens per maand claimen is ettelijke factoren hoger dan ik met al die verschillende versies per jaar aan outage heb gehad.

En met 2007 en 2010 is high availability zodanig veel beter en makkelijker geworden dat die cijfers sowieso nutteloos zijn geworden.

[ Voor 4% gewijzigd door mjtdevries op 04-05-2010 10:52 ]

[Verwijderd]

mjtdevries schreef op dinsdag 04 mei 2010 @ 10:19:
Sowieso is een in-place upgrade iets dat in een enterprise omgeving "not done" is.
Niet alleen voor Exchange, maar voor elke bedrijfskritische applicatie. (Ik ken werkelijk NIEMAND die dat doet)

Dat is volgens mij echt een argument dat alleen speelt bij zeer kleine omgevingen.
Idem voor het "hardware" argument. Hoe kan de eis voor x64 hardware nou ooit een probleem zijn?

Op het moment dat Exchange 2007 uit waren x64 processors al doodnormaal. Vrijwel iedereen had die dingen zelfs al in hun desktoppie thuis zitten. Hoe kan je dan met droge ogen dat als een serieus argument aanhalen?

En wat hierboven al zeer terecht opgemerkt werd: in een Enterprise omgeving laat je software upgrade altijd samen lopen met een hardware upgrade.


Wellicht moet je de discussie opnieuw opstarten met als onderwerp:
wat zijn voor en nadelen van Notes vs Exchange in een kleine omgeving.


P.S.
hebben de andere Exchange specialisten hier ook met stomme verbazing naar die Google cijfers zitten te kijken? (ze zullen niet volledig verzonnen zijn neem ik aan....) Ik kan me zelfs met Exchange versies eerder dan 2007 en 2010 niet voorstellen hoe je ooit zoveel geplande en ongeplande downtime per maand kan hebben.
Ik draai een omgeving met 8000 mailboxen in een org van 120.000 mailboxen.
Met 2007 zit ik op een ongeplande downtime van een paar minuten per jaar. (een keertje een failover, waar de gebruikers met outlook in cached mode niet eens wat van merken)
Met 2003 heb ik ooit een keertje 24 uur downtime gehad, maar dat lag niet aan Exchange, maar een corrupte array controller een storage team dat de backups niet goed gemonitoord had zodat de laatste backup 2 weken oud was. toen moest ik dus op een zondag een repair/p doen.
Maar verder met 2003 ooit nooit iets bijzonders. Idem voor 2000 en 5.5

Wat die jongens per maand claimen is ettelijke factoren hoger dan ik met al die verschillende versies per jaar aan outage heb gehad.

En met 2007 en 2010 is high availability zodanig veel beter en makkelijker geworden dat die cijfers sowieso nutteloos zijn geworden.

Het 64bits hardware argument is iets dat <insert flame here> mensen zeggen.. wie koopt er de laatste jaren nog 32bits hardware? Is niet te koop, punt uit. Dus +1 voor jou.

Wat betreft OS versies hetzelfde, wie wil er nou Exchange op Windows 2000 kunnen instaleren. Dom argument gewoon aangezien je juist vooruit wil en gebruik wil maken van de nieuwe features om kosten te verlagen.

Wat betreft security; Single Identity is een strategie. 2 keer inloggen is ouderwets en kost teveel geld. Je wil juist 1 database zodat je minder kosten hebt en gebruik kunt maken van technologie als unified comms en niet allerlei houtje touwtje meuk om security databases te syncen (wat imo alleen maar insecure is).

Wat betreft availability, als je wil is er geen downtime meer dus ik kijk er ook een beetje van op. Als je een 3 node DAG hebt zie ik niet in waarom je downtime zou moeten hebben, planned of niet.

Verder wil ik nog wel evene kwijt dat de keuze van een platform vooral strategisch is en moet passen bij het bedrijf en de manier van werken. Wat mij betreft is er niet 1 platform dat superieur is. Ik zie ook de nadelen van Exchange wel, het zou dom zijn niet de zwaktes te onderkennen.
Dus waarom zouden bedrijven van Domino naar Exchange gaan; nou kosten vooral denk ik. Dat is eigenlijk de enige driver die er is. Dat wil niet zeggen dat Exchange altijd goedkoper is, maar wellicht in die ene situatie toevallig wel. En kosten zijn dus niet alleen licenties en hardware he..want dat wordt ook vaak even zo afgedaan. Dat een migratie duur is kan, wellicht is dat een afweging om nu even de pijn te pakken om over 3 jaar winst te boeken..maar dat verschilt per bedrijf denk ik. Besteed je die migratie uit of doe je het zelf bijv.

[ Voor 11% gewijzigd door Verwijderd op 04-05-2010 10:59 ]

[martdj]

mjtdevries schreef op dinsdag 04 mei 2010 @ 10:19:
Sowieso is een in-place upgrade iets dat in een enterprise omgeving "not done" is.
Niet alleen voor Exchange, maar voor elke bedrijfskritische applicatie. (Ik ken werkelijk NIEMAND die dat doet)

Dat is volgens mij echt een argument dat alleen speelt bij zeer kleine omgevingen.
Idem voor het "hardware" argument. Hoe kan de eis voor x64 hardware nou ooit een probleem zijn?

Hier kan ik me los van de Domino Exchange discussie toch echt niet in vinden. Bij de meeste upgrades in de IT wil je namelijk zoveel mogelijk factoren gelijk houden, zodat als je een product upgrade en er gaat iets mis je gericht kunt troubleshooten. Als je én je hardware én je Server OS én je messaging platform in 1x gaat vervangen en er gaat iets mis, moet je maar raden of het een hardware probleem, OS probleem of een middleware probleem is en dat maakt troubleshooten verdomde lastig. Bij de grote bedrijven waar ik kom wordt daarom liefst maar 1 ding per keer geupgrade (overigens komt een nieuwe server natuurlijk wel vaak met een recent server OS, zodat je als je je hele server vervangt je wel vaak ook je server OS vervangt. Dat is echter geen goed moment om ook al je applicaties op die server te gaan upgraden als stabiliteit van je omgeving belangrijk is).

Een klant van me heeft overigens een omgeving met 150.000 Domino mailboxen (da's dus geen kleine omgeving ). Van 6.5 naar 7 gewoon in-place ge-upgrade. Van 7.0.2 naar 7.0.4 ook gewoon in-place. Dit is dus zeker niet iets van kleinere omgevingen. Aangezien bij Domino latere (major) versies minder resources gebruiken, is er ook geen directe reden om je hardware te vervangen bij een upgrade (bron).

[sanfranjake]

martdj schreef op dinsdag 04 mei 2010 @ 11:41:
[...]

Hier kan ik me los van de Domino Exchange discussie toch echt niet in vinden. Bij de meeste upgrades in de IT wil je namelijk zoveel mogelijk factoren gelijk houden, zodat als je een product upgrade en er gaat iets mis je gericht kunt troubleshooten. Als je én je hardware én je Server OS én je messaging platform in 1x gaat vervangen en er gaat iets mis, moet je maar raden of het een hardware probleem, OS probleem of een middleware probleem is en dat maakt troubleshooten verdomde lastig.

Sorry, maar ik denk dat dit toch echt heel erg ligt aan de engineers die bij dergelijke projecten betrokken zijn. Elk Microsoft product komt tegenwoordig met heel erg veel troubleshootingtools, net als alle hardware overigens. In mijn ogen is de engineer niet geschikt als deze niet in staat is om op een dergelijk globaal niveau storingen te analyseren.

Bij de grote bedrijven waar ik kom wordt daarom liefst maar 1 ding per keer geupgrade (overigens komt een nieuwe server natuurlijk wel vaak met een recent server OS, zodat je als je je hele server vervangt je wel vaak ook je server OS vervangt. Dat is echter geen goed moment om ook al je applicaties op die server te gaan upgraden als stabiliteit van je omgeving belangrijk is).

Sorry hoor, maar kiezen klanten dit traject omdat jij het ze geadviseerd hebt, of uit zichzelf... mijn ervaring is namelijk dat vernieuwingen vaak in projecten gecombineerd worden, om zo de continuiteit van processen zo min mogelijk te beinvloeden. Wat heb je aan een weekend downtime voor Exchange upgrade, en dan vervolgens nog een keer een weekend voor Windows upgrade. Er is gewoon geen logische reden voor te bedenken.

Waarom is dit geen goed moment om applicaties te vernieuwen? Je zet dit neer als een feit, maar volgens mij ben je vergeten om daarna een door feiten gestaafde argumentatie (ik schat 2 alinea's) neer te zetten. Dit komt de discussiewaarde niet ten goede, sterker nog, je trapt er wederom deuren mee dicht.

Kun je misschien uitleggen waarom je zo defensief staat tegen alle argumenten die gebruikt worden om van dit topic een leuke discussie te maken? Misschien begrijpen we het dan beter.

Een klant van me heeft overigens een omgeving met 150.000 Domino mailboxen (da's dus geen kleine omgeving ). Van 6.5 naar 7 gewoon in-place ge-upgrade. Van 7.0.2 naar 7.0.4 ook gewoon in-place. Dit is dus zeker niet iets van kleinere omgevingen. Aangezien bij Domino latere (major) versies minder resources gebruiken, is er ook geen directe reden om je hardware te vervangen bij een upgrade (bron).

Maar wat is nu precies het vereiste/voordeel wat je met een inplace upgrade behaalt dan? Zoals hierboven al is aangegeven zien wij er vrijwel alleen nadelen in, en is het aan jou om je stelling te onderbouwen. Linken naar documentjes kan ik ook.... Overigens wederom sterk gekleurde bevindingen omdat het een document is wat rechtstreeks bij IBM vandaan komt. Niet bepaald objectief. Vertel bijvoorbeeld eens over je eigen ervaringen, geef wat praktijkvoorbeelden, doe in ieder geval iets

[ Voor 3% gewijzigd door sanfranjake op 04-05-2010 12:19 ]

[Razwer]

martdj heeft aandelen IBM gekocht en wil ze nu ff omhoog praten

[mjtdevries]

martdj schreef op dinsdag 04 mei 2010 @ 11:41:
Hier kan ik me los van de Domino Exchange discussie toch echt niet in vinden. Bij de meeste upgrades in de IT wil je namelijk zoveel mogelijk factoren gelijk houden, zodat als je een product upgrade en er gaat iets mis je gericht kunt troubleshooten.

Op dat moment zit je met een complete outage van je systeem en dat is niet acceptabel voor een bedrijfskritische applicatie.
Leuk dat je gericht kunt troubleshooten, maar je wilt uberhaupt niet in die situatie terecht komen.

De manier om dat de vermijden is om een nieuwe omgeving naast je bestaande op te bouwen. Vervolgens migreer je een aantal handvol mensen daarna gebruik je de IT afdeling als pilot groep. Op die manier kun je verzekeren dat de zaak technisch en functioneel allemaal correct functioneert. (evt neem je nog een groep normale gebruikers mee voor functionele tests)
Uiteraard kun je lange tijd in een test omgeving doorbrengen, maar daarin mis je altijd zaken die wel na een paar dagen in een productie omgeving opduiken. (of problemen die alleen in productie voorkomen)

Daarna kun je dan de rest van je gebruikers in 1 klap overzetten.
Zelfs al mocht er iets onverwachts gebeuren dan heb je een heel simpel en zeker fallback plan. Bij een in-place upgrade is dat nooit zo zeker en makkelijk.

Helaas heb ik ook een applicatie die alleen maar in-place upgrades heeft. (Enterprise Vault) En dan is elke upgrade een zenuwslopende actie. Terwijl elke Exchange migratie altijd een hele soepele actie is geweest waarbij niemand zenuwachtig was.

Juist omdat zo'n migratie zo bedrijfszeker word, kun je ook makkelijk hardware en OS tegelijkertijd vervangen.
Dat betekent dan bovendien dat op je een later tijdstip 2x een geplande downtime vermijd, die je anders nodig had om die zaken te upgraden. (voor een 24x7 organisatie een belangrijk punt)

Als je én je hardware én je Server OS én je messaging platform in 1x gaat vervangen en er gaat iets mis, moet je maar raden of het een hardware probleem, OS probleem of een middleware probleem is en dat maakt troubleshooten verdomde lastig. Bij de grote bedrijven waar ik kom wordt daarom liefst maar 1 ding per keer geupgrade (overigens komt een nieuwe server natuurlijk wel vaak met een recent server OS, zodat je als je je hele server vervangt je wel vaak ook je server OS vervangt. Dat is echter geen goed moment om ook al je applicaties op die server te gaan upgraden als stabiliteit van je omgeving belangrijk is).

Als stabiliteit van je omgeving belangrijk is, dan ga je dat server OS helemaal niet vervangen en de hardware ook niet!
Waarom zou je immers? Je neemt een risico op outage terwijl dat voor je applicatie helemaal niet nodig is.

Tussendoor een OS upgraden ipv dat tegelijk te doen met de upgrade van de applicatie levert de beheerders ontzettend veel extra werk op en extra risico.
Ipv dat je applicatie A op OS B test, moet je applicatie A ineens ook op OS C testen. Dubbel zoveel werk dus. Ook dubbel zoveel kans op incompatibiliteit en dubbel zoveel kans op outage.

Een klant van me heeft overigens een omgeving met 150.000 Domino mailboxen (da's dus geen kleine omgeving ). Van 6.5 naar 7 gewoon in-place ge-upgrade. Van 7.0.2 naar 7.0.4 ook gewoon in-place. Dit is dus zeker niet iets van kleinere omgevingen. Aangezien bij Domino latere (major) versies minder resources gebruiken, is er ook geen directe reden om je hardware te vervangen bij een upgrade (bron).

Ook klanten met grote omgevingen doen onverstandige acties
Van een klant van een dergelijke omvang mag je ook verwachten dat ze zelf voldoende mensen met kennis van zaken hebben en dus helemaal geen consultant hoeven in te huren, dus ik ben sowieso verbaasd dat ze een klant van je zijn, maar dat is weer wat anders. (of was het soms een overheidsorganisatie? dat verklaart dan ook die onverstandige actie )

Wat betreft resources. Een nieuwe versie geeft meestal nieuwe functionaliteit en bovendien veranderen de gebruikersbehoeften. Dat heeft impact op je hardware behoeften.

Exchange vergt ook bij elke versie minder resources. (70% minder diskIO bv) Maar ondertussen worden mailboxen en de mails die gestuurd worden steeds groter. Dus zul je hardware daaraan moeten aanpassen.
Bv meer op disk capaciteit en minder op disk performance.

Dat geldt overigens niet alleen voor zaken als Exchange. Met laptops in je bedrijf doe je toch hetzelfde?
Daar laat je ook niet mensen dit jaar voor de upgrade naar Win7 komen, en dan volgend jaar terugkomen voor Office 2010, en dan het jaar daarna voor nieuwe hardware.
Nee dat doe je allemaal tegelijk, en daarna laat je ze 3 jaar met rust.

[martdj]

sanfranjake schreef op dinsdag 04 mei 2010 @ 09:47:
[...]
Ook wil ik nog even vermelden dat ik de negatieve toon in jouw posts, waarbij je continue alle feiten probeert omver te praten met IBM-marketingpraatjes erg jammer vind. Toen ik dit topic vorige week voor het eerst opende dacht ik dat er een open discussie uit zou ontstaan, waar we inderdaad van elkaar kunnen leren. Al was het alleen maar om nog meer argumenten te verzamelen voor onze eigen standpunten.
Echter zoals ik het nu bekijk zitten we 2 millimeter verwijderd van een flamewar, als we er al niet middenin zitten. Ik heb het idee dat er verschillende niveaus langs elkaar heen zitten te praten, waar ik doel op sales/marketing en techniek. Hopelijk kun je er wat mee, en stel je je in volgende post wat minder defensief op!

Point taken. Het is mijn zwakke plek wanneer ik dingen over Lotus Notes / Domino beweerd zie worden die mijns inziens voortkomen uit een gebrek aan kennis over het product, maar ik zal me pogen wat meer in te houden. Overigens hoop ik dat ik met een aantal van mijn posts al wel een aantal misverstanden uit de weg heb geruimd.

Om nog even terug te gaan naar de beginvraag. Wat zijn de punten die zijn langsgekomen als redenen om te migreren (ik zal dit keer proberen ze objectief op te schrijven):

1. Strategische keuzes. Men wil standaardiseren op 1 platform en kiest daar Microsoft voor
2. Technische keuzes. In heel specifieke situaties past Exchange beter bij de archtitectuur wensen van de klant dan Lotus Domino
3. Kostengebaseerde keuzes - Wanneer je puur en alleen mailt en met kalenders werkt, je gebruikt Windows servers en Microsoft Office en je hebt geen plannen om daar in de nabije toekomst verandering in te brengen is Exchange qua licenties goedkoper. Daarnaast heeft Microsoft binnen het MKB met de Small Business Server een interessante aanbieding, waarbij de IBM tegenpool, Lotus Foundations nog weinig bekendheid geniet
4. Fusies - 1 fusie partner gebruikt Exchange, de andere Domino. Er moet een keuze gemaakt worden
5. Politieke redenen - Hier vallen ook onder de business deals als "ik koop product X van jou, maar dan moet je wel migreren naar Exchange (ik ken ook de verhalen van de migratie naar Domino bij Philips (deal i.c.m. monitorlevering aan IBM). De migratie naar Exchange schijnt om eenzelfde reden geinitieerd te zijn).
6. Gebruikers-georienteerde keuzes. Veel gebruikers komen van werkgevers / opleidingen waar Outlook gebruikt werd en hebben een weerstand tegen de filosofie van Lotus Notes / elke andere mail client

Naast deze redenen, waarbij ik de laatste twijfelachtig vind omdat die meestal voortkomt uit gebrek aan kennis over de huidige productrange van Lotus Notes / Domino danwel dat mensen de handigheidjes van Lotus Notes niet kennen (vaak relatief goedkoop met wat educatie op te lossen), zijn er nog de vage/foute redenen:

• Willen scoren als IT manager - Regelmatig worden dit soort migratietrajecten geinitialiseerd door een nieuwe IT manager die zich wil doen gelden en daar een Lotus Domino (wat ie niet kent) naar Exchange migratie als een goede manier voor ziet. Als medewerker moet je alle kosten die jij wilt maken voor het bedrijf uitgebreid verantwoorden, maar zo'n IT manager mag gerust een paar miljoen verspillen (in 99,9% van deze gevallen is het pure verspilling).
• Gehoord op de golfbaan - Manager / decision maker hoort op de golfbaan dat iedereen Exchange gebruikt en denkt zonder zich verder goed te laten informeren dat hij dat dan ook maar moet doen
• Laten ompraten door gladde sales met leugentjes en halve waarheden - Met alle respect voor eventuele Microsoft sales hier, maar het schijnt daadwerkelijk in het MS sales trainings programma te zitten om termen als Lotus Notes is dood / legacy, vraag IBM maar eens om een 5-jaar roadmap voor Lotus Notes, hebben ze niet, niemand gebruikt meer Lotus Notes etc paraat te hebben en rond te strooien bij klanten (voor alle duidelijkheid, al die kreten zijn dus onzin). Sommige klanten trappen hier helaas in en tekenen zonder de verhalen te controleren bij IBM of een IBM business partner.

Nu kunnen de meeste van bovenstaande redenen overigens (zeker de 1e 5) ook redenen zijn om te migreren van Exchange naar Domino. Dat werkt natuurlijk 2 kanten op. Dat gebeurt gelukkig (voor mij ) ook wel, maar het momentum ligt in Nederland momenteel bij Exchange. Wat dat betreft heeft dat denk ik ook te maken met zwakke marketing én after sales door IBM in Nederland m.b.t. de Lotus product portfolio.

[martdj]

mjtdevries schreef op dinsdag 04 mei 2010 @ 12:46:
[...]

Op dat moment zit je met een complete outage van je systeem en dat is niet acceptabel voor een bedrijfskritische applicatie.
Leuk dat je gericht kunt troubleshooten, maar je wilt uberhaupt niet in die situatie terecht komen.
{..]

Daar heb je binnen 24x7 organisaties clusters voor (cluster partner down brengen, domino server upgraden en 5 minuten later breng je de server weer op en doe je de andere server in het cluster. Daar hoeft een gebruiker dus niets van te merken (zeker niet als je het in het weekend doet). Voor kleinere organisaties kun je het ook gewoon in het weekend doen.
Hoe zet je overigens je gebruikers over zonder downtime voor die gebruiker?

Ik ben het met je eens dat je hardware liever niet vervangt als het niet strikt noodzakelijk is. Soms is het dat wel en dan is het in mijn ervaring handig om dat los van een upgrade van je middleware te doen.
Die klant is overigens geen overheidsinstelling, maar vrijwel elke grote organisatie heeft in z'n IT afdeling een aantal externen zitten (danwel heeft zijn hele IT afdeling ge-outsourced).

[alt-92]

Ik vraag me af of je wel doorhebt dat je huidige aanpak niet echt bijdraagt aan een betere marketing en aftersales
Je zit er heel technisch in, kent je produkt goed, maar je mist ten enen male de touch om die kennis ook in daadwerkeljk voordeel om te zetten qua marketing.

[mjtdevries]

tja, met alleen kennis van het ene product ben je er niet.

Als je werkelijk je eigen product goed wil marketen tov het product van de tegenpartij, dan zal je ook meer kennis van dat andere product moeten hebben.

Zowel de sterke als zwakke punten.

Als een klant in de gaten krijgt dat je echt weet waar je het over hebt, ipv dat je de marketing van IBM napraat, dan zullen ze ook eerder ingaan op je voorstellen.

[mjtdevries]

martdj schreef op dinsdag 04 mei 2010 @ 13:39:
[...]
Daar heb je binnen 24x7 organisaties clusters voor (cluster partner down brengen, domino server upgraden en 5 minuten later breng je de server weer op en doe je de andere server in het cluster. Daar hoeft een gebruiker dus niets van te merken (zeker niet als je het in het weekend doet). Voor kleinere organisaties kun je het ook gewoon in het weekend doen.

De meeste applicaties vinden het niet leuk als de ene node versie 1 gebruikt en de andere node versie2. Zeker niet als het langer gaat duren omdat je aan het troubleshooten bent. (heb het dus niet over een servicepack met wat fixes, maar echt een versie verschil)
Worden er nooit structurelen wijzigingen aan de database gedaan met een nieuwe versie?
En zo als dat wel gebeurd, hoe gaat de oude node dan om met de wijzigingen in de database? Ik ben heel benieuwd hoe ze dat oplossen?

Hoe zet je overigens je gebruikers over zonder downtime voor die gebruiker?

"Online mailbox move". Dat is een feature van 2010 die je voor de migratie van 2007 naar 2010 kunt gebruiken. Het enige wat de gebruiker er van merkt is dat ie eenmalig een melding krijgt dat ie even outlook moet herstarten en vanaf dat moment is ie over op 2010.
Bij eerdere migraties deed je zoiets 's want dan kon het inderdaad zijn dat een gebruiker 15min niet bij zijn mailbox kon.

Ik ben het met je eens dat je hardware liever niet vervangt als het niet strikt noodzakelijk is. Soms is het dat wel en dan is het in mijn ervaring handig om dat los van een upgrade van je middleware te doen.
Die klant is overigens geen overheidsinstelling, maar vrijwel elke grote organisatie heeft in z'n IT afdeling een aantal externen zitten (danwel heeft zijn hele IT afdeling ge-outsourced).

Waarom zou je als grote organisatie externen willen inzetten?
Daar zijn wat mij betreft maar twee goede redenen voor:
1. je wilt geen permanente krachten inzetten vanwege onzekere financiele situatie. (externen kan je makkelijk lozen)
2. je hebt nog geen vaste werknemer kunnen vinden.

Voor een klein bedrijf kan het te duur zijn om applicatie specialisten in te zetten en dan kan het wel beter zijn om externen in te huren met specialistische kennis.

Wat je bij grote bedrijven wel eens ziet is dat ze externen inhuren voor kennis waarvan ze denken dat ze die alleen tijdens een migratie nodig hebben. Vervolgens blijkt echter altijd dat dat een misvatting is.
Als je beheerders niet voldoende kennis hebben om een migratie zelf uit te voeren, dan hebben ze ook niet voldoende kennis om beheer te doen.
En als een developer customization gaat doen, dan komen ze er vanzelf achter dat dat niet eenmalig is, maar dat je daarna ook steeds weer aan die customization moet sleutelen. Dus ook dan moet je gewoon een vaste werknemer hebben die dat kan.
Let wel, allemaal dus voor grote organisaties waarbij je IT organisatie dus ook groot genoeg is om specialisten per applicatie in dienst te hebben.

[Jazzy]

mjtdevries schreef op dinsdag 04 mei 2010 @ 15:05:
Als je beheerders niet voldoende kennis hebben om een migratie zelf uit te voeren, dan hebben ze ook niet voldoende kennis om beheer te doen.

Daar ben ik het niet mee eens. Laat de beheerders maar op cursus gaan om training te krijgen over de nieuwe oplossing. Dan maak ik me wel druk over de migratie, connectors, en alle eenmalige werkzaamheden die daar bij horen. Waarom zouden de beheerders dat zelf allemaal uit moeten zoeken als ik het dagelijks doe en alle best practices en do's en don'ts ken. Als zij zometeem maar gebruikers aan kunnen maken en de instellingen van een send connector kunnen wijzigen wanneer nodig.

Een externe partij inhuren voor specialistische kennis die je maar kort nodig hebt is juist heel verstandig. Mijn ervaring is bovendien dat beheerders heel goed zijn in het beheren van een platform, maar een migratieproject vaak niet goed kunnen overzien. Daar til je ze als externe als het ware overheen, zodat zij kunnen doen waar ze goed in zijn: beheren.

[martdj]

mjtdevries schreef op dinsdag 04 mei 2010 @ 15:05:
[...]

De meeste applicaties vinden het niet leuk als de ene node versie 1 gebruikt en de andere node versie2. Zeker niet als het langer gaat duren omdat je aan het troubleshooten bent. (heb het dus niet over een servicepack met wat fixes, maar echt een versie verschil)
Worden er nooit structurelen wijzigingen aan de database gedaan met een nieuwe versie?
En zo als dat wel gebeurd, hoe gaat de oude node dan om met de wijzigingen in de database? Ik ben heel benieuwd hoe ze dat oplossen?

Domino data is opgeslagen in .nsf databases, waarbij hoe de data in die database op de disk is opgeslagen wordt bepaald door het ods (on disk system). ods en Domino versie staan in die zin los van elkaar dat je het ods van een database niet hoeft te upgraden als je de versie upgrade. Wel is het vaak nodig om het ods te upgraden om nieuwe functionaliteiten in een nieuwe versie te kunnen benutten, maar dat gebeurt dus op een later moment. Bij een Domino upgrade upgrade je eerst de Domino Directory op je administration server naar de nieuwe versie (het Domino directory is altijd backwards compatibel), dan de code en vervolgens de andere servers. Pas later upgrade je het ODS en ga je nieuwe functionaliteiten inschakelen. Alleen voor de code upgrade moet de server plat (en dat kan zoals eerder gezegd in 5 minuten gedaan zijn tussen down en weer op). De ODS upgrade kan tijdens de standaard onderhoudstaken gebeuren en daar hoeft de server dus verder niet voor gestopt te worden.
Kern van het verhaal is dat je bij wijze van spreken een replica van een database op Domino 5 en Domino 8.5 kan hebben, waarbij dat voor de database niet uitmaakt. Alleen zal diezelfde database op de Domino 8.5 server (als de daarvoor bedoelde vinkjes zijn aangevinkt) veel minder plek innemen en een stuk beter presteren. Ook zal de database op de Domino 5 server code die gebruikt maakt van functionaliteit uit latere versies niet kunnen uitvoeren, maar dat heeft geen gevolgen voor de integriteit van de data.

Waarom zou je als grote organisatie externen willen inzetten?
Daar zijn wat mij betreft maar twee goede redenen voor:
1. je wilt geen permanente krachten inzetten vanwege onzekere financiele situatie. (externen kan je makkelijk lozen)
2. je hebt nog geen vaste werknemer kunnen vinden.

[..]

Theoretisch heb je gelijk, maar de praktijk is anders. Als je bij grote bedrijven als Shell, Philips, IBM of een willekeurige financiële instelling gaat kijken zie je daar op de IT afdelingen (en daarbuiten trouwens ook) altijd een aantal externen rondlopen die daar dan vaak al vele jaren zitten (ik ken voorbeelden van afdelingen waar sommige externen er al langer zitten dan de langstzittende interne). Zo'n externe heeft vaak teveel nuttige kennis voor het bedrijf om 'm te vervangen voor een interne, terwijl het voor de externe zelf financieel slimmer is om extern te blijven dan om bij het bedrijf in dienst te treden.

[downtime]

mjtdevries schreef op dinsdag 04 mei 2010 @ 15:05:
Waarom zou je als grote organisatie externen willen inzetten?
Daar zijn wat mij betreft maar twee goede redenen voor:
1. je wilt geen permanente krachten inzetten vanwege onzekere financiele situatie. (externen kan je makkelijk lozen)
2. je hebt nog geen vaste werknemer kunnen vinden.

3. Je wilt op projectbasis mensen inhuren om nieuwe kennis in te brengen en die aan interne mensen over te dragen. Als het project afgelopen is, heb je de "expert" ook niet meer nodig omdat de interne mensen dan voldoende kennis en ervaring met het nieuwe product hebben om de kar verder te trekken.

Wat je bij grote bedrijven wel eens ziet is dat ze externen inhuren voor kennis waarvan ze denken dat ze die alleen tijdens een migratie nodig hebben. Vervolgens blijkt echter altijd dat dat een misvatting is.
Als je beheerders niet voldoende kennis hebben om een migratie zelf uit te voeren, dan hebben ze ook niet voldoende kennis om beheer te doen.

In mijn ogen is een mix van interne en externe mensen de meest wenselijke aanpak bij zo'n project. Interne mensen brengen kennis van de organisatie in, kennen ook de knelpunten van de bestaande omgeving, en externen brengen kennis van migraties en hands-on ervaring met de nieuwste versie van het product in.
Als je de taken goed verdeelt moet er een behoorlijke kennisoverdracht plaats kunnen vinden en moeten de externe mensen na het project gewoon weer verder kunnen naar de volgende opdracht.

[martdj]

Ik zat net dit artikel te lezen en zag dat veel van de dingen die in dit topic zijn langs gekomen daaruit komen. Het is wel grappig om te lezen hoe Microsoft feiten verdraait, features noemt en presenteert alsof ze uniek zijn zonder te noemen dat Domino die ook gewoon heeft en rapporten over oude versies presenteert alsof die nog steeds relevant zijn. Microsoft blijft wat dat betreft de meester in het verspreiden van fud en het gebruiken van twijfelachtige (onethische) sales technieken (dit soort leugenachtige vergelijkingen zijn binnen IBM Lotus echt "not done". Misschien is dat jammer).

Aan de andere kant is het zorgwekkend dat Microsoft het voor elkaar heeft gekregen om deze pagina hoog in de zoekresultaten op Google te krijgen waardoor het voor de passant met minder kennis van zaken lijkt alsof Exchange 2010 echt beter zou zijn dan Domino 8.5.1. Ik denk dat ik in mijn eerdere commentaren al voldoende heb verduidelijkt dat deze verlijkingspagina kant noch wal raakt, maar het blijft jammer dat er niet gewoon een vergelijkbare pagina van IBM is die de andere kant belicht. Grappig overigens dat als je op exchange vs domino zoekt, deze thread direct onder Microsofts pagina staat.

Hier is overigens wel een redelijk objectieve vergelijking tussen de 2, waarbij er puur is gekeken naar de messaging kant. Ook de commentaren zijn wel interessant overigens.

[ Voor 9% gewijzigd door martdj op 04-05-2010 17:31 ]

[alt-92]

Ja joh, tis een complot.

[Jazzy]

Je laat me lachen.

Edit: Ik bedoelde martdj.

[ Voor 46% gewijzigd door Jazzy op 04-05-2010 17:50 ]

[Verwijderd]

martdj schreef op dinsdag 04 mei 2010 @ 17:22:
Ik zat net dit artikel te lezen en zag dat veel van de dingen die in dit topic zijn langs gekomen daaruit komen. Het is wel grappig om te lezen hoe Microsoft feiten verdraait, features noemt en presenteert alsof ze uniek zijn zonder te noemen dat Domino die ook gewoon heeft en rapporten over oude versies presenteert alsof die nog steeds relevant zijn. Microsoft blijft wat dat betreft de meester in het verspreiden van fud en het gebruiken van twijfelachtige (onethische) sales technieken (dit soort leugenachtige vergelijkingen zijn binnen IBM Lotus echt "not done". Misschien is dat jammer).

Aan de andere kant is het zorgwekkend dat Microsoft het voor elkaar heeft gekregen om deze pagina hoog in de zoekresultaten op Google te krijgen waardoor het voor de passant met minder kennis van zaken lijkt alsof Exchange 2010 echt beter zou zijn dan Domino 8.5.1. Ik denk dat ik in mijn eerdere commentaren al voldoende heb verduidelijkt dat deze verlijkingspagina kant noch wal raakt, maar het blijft jammer dat er niet gewoon een vergelijkbare pagina van IBM is die de andere kant belicht. Grappig overigens dat als je op exchange vs domino zoekt, deze thread direct onder Microsofts pagina staat.

Hier is overigens wel een redelijk objectieve vergelijking tussen de 2, waarbij er puur is gekeken naar de messaging kant. Ook de commentaren zijn wel interessant overigens.

Tsja, zo valt er weinig meer te discussieren. Ik heb het nog een poosje aangekeken, maar met zulke posts lijkt me een slotje beter op z'n plaats. Zie ook de feedback van meerdere andere users in dit topic. Jammer, er zat potentie in, helaas komt dat er zo niet uit.