none
exchange 2010 consiglio nome dominio .local .it RRS feed

  • Domanda

  • Ciao e buon anno a tutti.

    Dovremmo sostituire un server esistente (win2003 + exch 2003) con un nuovo win2008r2+exchange2010.

    Avendo solo 12 client e nessuna configurazione particolare  preferiremmo ripartire da zero con una nuova Active directory + join dei client.

    Il dominio .it e le 12 caselle mail sono ospitate presso un provider. Exchange attualmente scarica e ridistribuisce le mail tramite un connettore pop3 di terze parti. Invia tramite smarthost.  Questa situazione rimarrà anche col nuovo server.

    In caso di guasti (adsl) gli utenti si collegano alla webmail del provider per vedere le mail non ancora scaricate.

    Vi chiedo un consiglio: ripartendo da zero, è meglio utilizzare come nome dominio interno: azienda.local o azienda.it? Tenendo conto che il dominio reale e le caselle mail effettive sono depositate su un provider.

    Io pensavo al .local, così se un giorno dovessi creare una casella .it che rimarrà sul provider ma non apparterà a nessun client interno (consultazione solo via web), exchange non tenterà di inviarla internamente.

    E' solo un'idea, accetto consigli.

    Garzie

     

    Marco

    lunedì 2 gennaio 2012 09:05

Risposte

  • Giusto per completare le informazioni che ti ha dato ObiWan, un altra posibilità potrebbe essere lo Split-brain DNS / split-horizon DNS,  questa modalità permette di utilizzare il dominio registrato sia internamente che esternamente, in pratica le richieste DNS provenienti dalla rete interna (nel tuo caso la rete aziendale) avranno la vista globale dei record DNS (host interni, record msdcs, www etc.) mentre le richieste dall'esterno avranno una vista parziale, limitata solo ai servizi disponibili esternamente  (esempio, mx, www, ftp, vpn...) . Questa separazione delle "viste" dei DNS, richiede la gestione di propri DNS e ovviamente comportano ulteriori compentenze/lavoro/costi... ma in alcune situazioni, tali soluzioni possono essere necessarie o di facile implementazione (riconfigurando opportunamente i dns  già di proprietà).

     Una curiosità: quando uscì windows 2000 che implementava i nuovi servizi di Active Directory e dove, per la prima volta, il DNS diventava parte cruciale dell'infrastruttura microsoft, dalle "best practice" il colosso di Seattle consigliava di usare il nome del dominio pubblico per la propria AD, ma  subito problemi di collisione affiorarono (qui implementai il primo split-brain) e nelle specifiche successive comparve il consiglio di usare il .local ...

    link storico su brain-split di Active Directory con BIND !!  http://msdn.microsoft.com/en-us/library/ms954396.aspx  

    Per quanto riguarda le caselle di email seguirei il consiglio di ObiWan: mx principale exchange (che ovviamente comporta ip pubblico statico, che probabilmente non sfruttate/avete, visto che usate un ISP + popconnector) lascierei anche come mx secondario il vostro attuale ISP, che vi garantisce un ulteriore sicurezza in caso di "down" del sistema interno, una sorta di ETRN casereccio, ovviamente anche questa soluzione comporta un lavoro supplementare e un ulteriore porta di accesso per  lo spam.

    Utilizzare il vostro exchange come server di mail principale, vi garantirebbe accesso alle cartelle publiche, rubriche aziendali, calendari via OWA e la possibilità di utilizzare smartphone costantemente sincronizzati con l'intranet aziendale...

     

     

     


    Gastone Canali >http://www.armadillo.it
    lunedì 2 gennaio 2012 20:19
    Moderatore
  • Dovremmo sostituire un server esistente (win2003 + exch 2003) con un nuovo win2008r2+exchange2010.

    Avendo solo 12 client e nessuna configurazione particolare  preferiremmo ripartire da zero con una nuova Active directory + join dei client.

    Il dominio .it e le 12 caselle mail sono ospitate presso un provider. Exchange attualmente scarica e ridistribuisce le mail tramite un connettore pop3 di terze parti. Invia tramite smarthost.  Questa situazione rimarrà anche col nuovo server.

    In caso di guasti (adsl) gli utenti si collegano alla webmail del provider per vedere le mail non ancora scaricate.

    Vi chiedo un consiglio: ripartendo da zero, è meglio utilizzare come nome dominio interno: azienda.local o azienda.it? Tenendo conto che il dominio reale e le caselle mail effettive sono depositate su un provider.

    Io pensavo al .local, così se un giorno dovessi creare una casella .it che rimarrà sul provider ma non apparterà a nessun client interno (consultazione solo via web), exchange non tenterà di inviarla internamente.

    Come opinione personale, se avete un dominio pubblico registrato, credo che potreste usare un "child domain" dello stesso per la rete locale; per capirci, supponiamo che il vostro dominio pubblico sia "example.com" a questo punto basterebbe usare (es.) "ad.example.com" come dominio AD per evitare problemi di collisione ed allo stesso tempo per usare un dominio perfettamente valido/legittimo (del resto qualsiasi child domain del dominio principale è comunque vostra proprietà :D); il mio unico dubbio è... per quale motivo visto che avete un exchange in casa utilizzate un mail service di terze parti ? Se si considera che exchange è perfettamente in grado di fungere da MX per il dominio, non vedo per quale motivo perdere di flessibilità andando ad usare servizi esterni e, tra l'altro, perdendo anche la possibilità di personalizzare e "tarare" il filtraggio delle emails in ingresso.

     

    • Modificato ObiWan lunedì 2 gennaio 2012 16:26
    • Contrassegnato come risposta mrcmobile martedì 3 gennaio 2012 10:21
    lunedì 2 gennaio 2012 16:24

Tutte le risposte

  • Dovremmo sostituire un server esistente (win2003 + exch 2003) con un nuovo win2008r2+exchange2010.

    Avendo solo 12 client e nessuna configurazione particolare  preferiremmo ripartire da zero con una nuova Active directory + join dei client.

    Il dominio .it e le 12 caselle mail sono ospitate presso un provider. Exchange attualmente scarica e ridistribuisce le mail tramite un connettore pop3 di terze parti. Invia tramite smarthost.  Questa situazione rimarrà anche col nuovo server.

    In caso di guasti (adsl) gli utenti si collegano alla webmail del provider per vedere le mail non ancora scaricate.

    Vi chiedo un consiglio: ripartendo da zero, è meglio utilizzare come nome dominio interno: azienda.local o azienda.it? Tenendo conto che il dominio reale e le caselle mail effettive sono depositate su un provider.

    Io pensavo al .local, così se un giorno dovessi creare una casella .it che rimarrà sul provider ma non apparterà a nessun client interno (consultazione solo via web), exchange non tenterà di inviarla internamente.

    Come opinione personale, se avete un dominio pubblico registrato, credo che potreste usare un "child domain" dello stesso per la rete locale; per capirci, supponiamo che il vostro dominio pubblico sia "example.com" a questo punto basterebbe usare (es.) "ad.example.com" come dominio AD per evitare problemi di collisione ed allo stesso tempo per usare un dominio perfettamente valido/legittimo (del resto qualsiasi child domain del dominio principale è comunque vostra proprietà :D); il mio unico dubbio è... per quale motivo visto che avete un exchange in casa utilizzate un mail service di terze parti ? Se si considera che exchange è perfettamente in grado di fungere da MX per il dominio, non vedo per quale motivo perdere di flessibilità andando ad usare servizi esterni e, tra l'altro, perdendo anche la possibilità di personalizzare e "tarare" il filtraggio delle emails in ingresso.

     

    • Modificato ObiWan lunedì 2 gennaio 2012 16:26
    • Contrassegnato come risposta mrcmobile martedì 3 gennaio 2012 10:21
    lunedì 2 gennaio 2012 16:24
  • Giusto per completare le informazioni che ti ha dato ObiWan, un altra posibilità potrebbe essere lo Split-brain DNS / split-horizon DNS,  questa modalità permette di utilizzare il dominio registrato sia internamente che esternamente, in pratica le richieste DNS provenienti dalla rete interna (nel tuo caso la rete aziendale) avranno la vista globale dei record DNS (host interni, record msdcs, www etc.) mentre le richieste dall'esterno avranno una vista parziale, limitata solo ai servizi disponibili esternamente  (esempio, mx, www, ftp, vpn...) . Questa separazione delle "viste" dei DNS, richiede la gestione di propri DNS e ovviamente comportano ulteriori compentenze/lavoro/costi... ma in alcune situazioni, tali soluzioni possono essere necessarie o di facile implementazione (riconfigurando opportunamente i dns  già di proprietà).

     Una curiosità: quando uscì windows 2000 che implementava i nuovi servizi di Active Directory e dove, per la prima volta, il DNS diventava parte cruciale dell'infrastruttura microsoft, dalle "best practice" il colosso di Seattle consigliava di usare il nome del dominio pubblico per la propria AD, ma  subito problemi di collisione affiorarono (qui implementai il primo split-brain) e nelle specifiche successive comparve il consiglio di usare il .local ...

    link storico su brain-split di Active Directory con BIND !!  http://msdn.microsoft.com/en-us/library/ms954396.aspx  

    Per quanto riguarda le caselle di email seguirei il consiglio di ObiWan: mx principale exchange (che ovviamente comporta ip pubblico statico, che probabilmente non sfruttate/avete, visto che usate un ISP + popconnector) lascierei anche come mx secondario il vostro attuale ISP, che vi garantisce un ulteriore sicurezza in caso di "down" del sistema interno, una sorta di ETRN casereccio, ovviamente anche questa soluzione comporta un lavoro supplementare e un ulteriore porta di accesso per  lo spam.

    Utilizzare il vostro exchange come server di mail principale, vi garantirebbe accesso alle cartelle publiche, rubriche aziendali, calendari via OWA e la possibilità di utilizzare smartphone costantemente sincronizzati con l'intranet aziendale...

     

     

     


    Gastone Canali >http://www.armadillo.it
    lunedì 2 gennaio 2012 20:19
    Moderatore
  • Grazie ObiWan per il suggerimento. Vedremo di utilizzare ad.azienda.it. Mi sembra un buon consiglio.

     

    marco

    martedì 3 gennaio 2012 10:22
  • Utilizzare il vostro exchange come server di mail principale, vi garantirebbe accesso alle cartelle publiche, rubriche aziendali, calendari via OWA e la possibilità di utilizzare smartphone costantemente sincronizzati con l'intranet aziendale...

     

    Ciao Gastone, ma anche in questo modo riesco a vedere tramite smartphone i calendari e le mail aziendali, l'ho fatto in altre situazioni simili con small business server. Immagino non sia molto differente in questo caso. O sbaglio?

     

    marco

    martedì 3 gennaio 2012 10:24
  • Giusto per completare le informazioni che ti ha dato ObiWan, un altra posibilità potrebbe essere lo Split-brain DNS / split-horizon DNS,  questa modalità permette di utilizzare il dominio registrato sia internamente che esternamente, in pratica le richieste DNS provenienti dalla rete interna (nel tuo caso la rete aziendale) avranno la vista globale dei record DNS (host interni, record msdcs, www etc.) mentre le richieste dall'esterno avranno una vista parziale, limitata solo ai servizi disponibili esternamente  (esempio, mx, www, ftp, vpn...) . Questa separazione delle "viste" dei DNS, richiede la gestione di propri DNS e ovviamente comportano ulteriori compentenze/lavoro/costi... ma in alcune situazioni, tali soluzioni possono essere necessarie o di facile implementazione (riconfigurando opportunamente i dns  già di proprietà).

    Si, esiste anche la possibilità di usare "split-brain" (o "split-horizon") ma ho preferito evitare di consigliarla dato che comporta alcuni accorgimenti ed un minimo di manutenzione e, considerando che l'uso di un child-domain al posto dello split-brain non crea problemi nè collisioni e che l'implementazione è semplice e flessibile, ho preferito suggerire tale soluzione; tra l'altro l'idea del child domain in realtà più complesse può essere sfruttata anche per la gestione di sedi remote; in tal caso avendo (es.) una sede a Roma, una a Milano ed una a Napoli (più la sede principale) e supponendo che il dominio pubblico sia "example.com" potremmo avere "ad.example.com" come dominio AD per la sede principale e quindi "rm.ad.example.com", "mi.ad.example.com" e "na.ad.example.com" come domini AD per le sedi remote :) poi ok, ci sarebbe da discutere sul modo migliore di implementare il tutto ma l'idea, per esperienza personale, è piuttosto valida

    link storico su brain-split di Active Directory con BIND !!  http://msdn.microsoft.com/en-us/library/ms954396.aspx  

    Beh, con BIND il problema non si pone; quantomeno NON con BIND v9 dato che lo stesso implementa una feature (che ho chiesto tante volte di implementare anche nel DNS Microsoft) chiamata "views"; in pratica con il v9 è possibile creare delle "viste" di una data zona DNS in modo che le informazioni ritornate dal DNS siano diverse a seconda di "chi" le richiede; ad esempio una query per www.example.com potrebbe ricevere come risposta 192.0.2.100 se richiesta dall'esterno e 10.1.2.40 se richiesta dalla rete locale :)

    Per quanto riguarda le caselle di email seguirei il consiglio di ObiWan: mx principale exchange (che ovviamente comporta ip pubblico statico, che probabilmente non sfruttate/avete, visto che usate un ISP + popconnector) lascierei anche come mx secondario il vostro attuale ISP, che vi garantisce un ulteriore sicurezza in caso di "down" del sistema interno, una sorta di ETRN casereccio, ovviamente anche questa soluzione comporta un lavoro supplementare e un ulteriore porta di accesso per  lo spam.

    Utilizzare il vostro exchange come server di mail principale, vi garantirebbe accesso alle cartelle publiche, rubriche aziendali, calendari via OWA e la possibilità di utilizzare smartphone costantemente sincronizzati con l'intranet aziendale...

    Prima di quanto sopra direi che sarebbe il caso di valutare per bene come sia configurata la connessione internet; al giorno d'oggi è difficile che vi siano problemi di connettività prolungati ed avendo una linea sufficientemente veloce ed un IP statico, credo che l'uso di exchange come MX sia consigliabile; se poi si desiderasse avere un "backup" basterebbe acquistare una seconda linea separata ed attestare due IP pubblici al server exchange in modo da garantire continuità di servizio; eviterei invece l'uso di un MX secondario posto all'esterno e non "correlato" dato che oltre a porre dei problemi di gestione, causerebbe un aumento della quantità di "spam" in ingresso visto che a quel punto si sarebbe costretti ad accettare qualunque cosa arrivi da tale MX secondario ... in caso contrario si genererebbero dei bounces e questi NON sono una buona cosa; per il resto, va tenuto presente che il meccanismo SMTP prevede il "retry" e che questo è normalmente configurato per ritentare l'invio ad intervalli di 15...30 minuti e per un periodo di 4..6 giorni; quanto sopra significa che se anche il mailserver fosse offline, la mancanza di connettività NON causerebbe "perdita" di emails dato che queste arriverebbero non appena il mailserver tornasse online e, sinceramente, credo sia difficile avere un blackout della durata di 6 giorni :)

     

     

    martedì 3 gennaio 2012 10:47
  • Ciao Gastone, ma anche in questo modo riesco a vedere tramite smartphone i calendari e le mail aziendali, l'ho fatto in altre situazioni simili con small business server. Immagino non sia molto differente in questo caso. O sbaglio?


    Il discorso è semplice; prima di tutto, utilizzando exchange come MX (e per tutto il resto) avrai l'integrazione completa con AD il che ti permetterà di semplificare la gestione di utenti, gruppi, rubriche etc..., in secondo luogo eviterai di dover creare la stessa mailbox 2 volte (presso il server esterno ed in AD/Exchange) cosa che tra l'altro può creare ANCHE dei problemi di sicurezza dato che implementare una corretta policy di "cambio password" in modo da forzare gli utenti a cambiare le proprie passwords ad intervalli regolari sarebbe praticamente impossibile... e poi ovviamente c'è da considerare anche la flessibilità che avresti usando il TUO mailserver, flessibilità che ti permetterebbe di gestire come preferisci il filtraggio "spam", di creare o modificare a piacimento indirizzi, gruppi di distribuzione etc... ed in generale di sfruttare al meglio le varie funzionalità messe a disposizione da Exchange

    ciao

     

    martedì 3 gennaio 2012 10:58
  • Grazie ObiWan per il suggerimento. Vedremo di utilizzare ad.azienda.it. Mi sembra un buon consiglio.

    Di nulla; per quanto riguarda la config, ti offro uno spunto; non dico che debba essere qualcosa del genere ma ritengo che, quando si pensa di "rifare" un'infrastuttura, possa essere utile avere un'idea di ciò che la stessa potrebbe diventare in un eventuale futuro ed avendo tale "schema" in mente, progettare il tutto in modo da renderlo "scalabile" per quanto possibile (es. virtualizzazione, cablaggi ed infrastuttura fatti per bene... ecc..); iniziamo da uno schema "di massima"

    e, sebbene un'immagine valga più di mille parole, lasciami spiegare quanto sopra :)

    Il front-end router/firewall è un modello con doppia interfaccia WAN (double WAN) configurato in modalità "load balancing" ma con priorità per la connessione 1; questo significa che, di norma, il traffico verrà veicolato verso la prima connessione WAN e che la seconda verrà usata solo se/quando la mole di traffico divenga superiore alla soglia impostata; oltre a ciò, tale front-end provvede anche a pubblicare su ENTRAMBI gli IP (nell'esempio 1... e 2....) il servizio di email (volendo anche www/ftp e DNS, ma questo è un discorso che esula dalla problematica in oggetto); tali servizi, come è possibile notare, non sono attestati sulla rete locale ma bensì tra due firewalls (il front-end ed il back-end) ossia in una zona separata ed isolata della rete comunemente chiamata DMZ; questo è utile al fine di evitare problemi di sicurezza, se si considera che i servers sono "esposti ad internet" e che non c'è una garanzia del 100% che non esistano bugs o vulnerabilità o problemi di sicurezza, il fatto di isolare tali servers dalla rete interna permette di evitare che un'eventuale intrusione su uno di tali server possa causare la compromissione della sicurezza della rete interna (e protetta); questo grazie al fatto che tale rete è protetta dal back-end firewall ed è isolata dalla DMZ (quest'ultima è a sua volta isolata da internet dal firewall front-end); ad ogni modo... proseguendo con lo schema di cui sopra, abbiamo poi il back-end firewall che, come detto, provvede a separare la DMZ dalla LAN e, in LAN abbiamo finalmente in nostro Exchange e due DC che fungono anche da DNS resolvers e da DHCP per la LAN.

    Tornando alla configurazione in oggetto, per quanto riguarda il mailserver di frontend, che fungerà da MX, si potrà tranquillamente installare un exchange o, se si preferisce, si potrà utilizzare uno "spamfilter" come ad esempio Vamsoft ORF che oltre a mettere a disposizione un "arsenale" di strumenti di filtraggio, si integra molto bene con Exchange; questo programma funge in pratica da "proxy" ed intercetta il traffico in ingresso/uscita permettendo di filtrarlo attraverso una serie di strumenti ed allo stesso tempo permettendo di isolare il server exchange da internet (prevenendo così qualsivoglia problema di sicurezza); il server di backend sarà ovviamente il nostro exchange che però, a questo punto, non utilizzerà alcun tipo di filtraggio antispam (a parte, se lo si desidera, uno scanner antivirus ... in modo da controllare le emails in transito all'INTERNO della rete) dato che il vero filtraggio relativo a spam/virus/... verrà effettuato dal server front-end (che ovviamente fungerà da MX per il dominio); sempre restando in ambito DMZ, visto che l'appetito vien mangiando, ci vuol poco ad aggiungere un server che funga da FTP (per lo scambio files) e, visto che ci siamo, anche da webserver e, sempre visto che ci siamo... un DNS configurato come autoritativo (con ricorsione disattivata) e che funga da DNS autoritativo per il nostro dominio; in questo modo volendo aggiungere o modificare hosts nel dominio pubblico, sarà sufficiente modificare la zona nel NOSTRO DNS (quello in DMZ) per ritrovare le modifiche pubblicate automaticamente :)

    Che altro... ah si, in una configurazione del genere, visto che abbiamo configurato un paio di connessioni WAN in modo da garantire la fault-tolerance, nella zona DNS pubblica del nostro dominio dovremmo avere qualcosa di questo genere

    @      IN MX 10 mail.example.com.
    
    mail   IN A  1.x.y.z
    mail   IN A  2.x.y.z
    
    @      IN TXT "v=spf1 mx -all"
    @      IN TXT "spf2.0/mfrom mx -all"
    
    

    quanto sopra specifica che il Mail eXchanger (MX) per il nostro dominio (example.com nell'esempio) è "mail.example.com" e che tale host ha DUE indirizzi IP, ossia 1.x.y.z e 2.x.y.z; inoltre i due records TXT contengono le informazioni per SPFv1 e SenderID che autorizzano il nostro MX a spedire posta per il dominio in questione

    Beh... più o meno credo sia tutto, spero sia chiaro; considera che NON sto suggerendoti di mettere in piedi un'infrastuttura di questo tipo "da subito" ma sto semplicemente cercando di fornirti un'idea di massima sul come potrebbe "evolversi" la tua infrastuttura in un futuro ... allo scopo (ok, tentando di) aiutarti nel pianificare il tutto

    ciao

     


    • Modificato ObiWan martedì 3 gennaio 2012 14:01
    martedì 3 gennaio 2012 13:59
  • Ciao ObiWan,

    mi fa piacere, leggendo i tuoi commenti, che ti manchi l'implementazione delle viste nel dns di ms e capisco anche il motivo per cui abbia evitato di citare lo split-brain...

    Riguardo il "down" concordo che i problemi di connettività siano rari e non talmente prolungati da essere vitali, ma con una duplicazione delle  (12) caselle e con qualche accorgimento si potrebbero continuare a ricevere e spedire mail grantendo la business continuity anche nel caso di crash di exchange (e anche qui non si finirebbe di parlare su configurazioni fault-tolerant che probabilmente non tutti possono permettersi) la NON "perdita" delle mail la davo per scontata (ho iniziato usare sendmail su SunOS [ahimè] nel lontano '89) 

    Per quanto riguarda Mail eXchanger secondario io consigliavo di mantenere quello attuale (caselle comprese), quindi lo spam rimarrebbe equivalente, si tratterebbe di un mx "semicorrelato" con ovviamente una gestione supplementare per il sinc (accettabile, visto l'esiguo numero di caselle ), forse in un prossimo futuro sarebbe interessante usare un servizio di "cloud" ( come sono trendy ;) es. google docs/liveMail, correlato con il proprio exchange interno (un msn connector aziendale per exchange)

    Grazie a Marco per aver dato lo spunto e il voto al thread e grazie Obi per il piacevole confronto (probabilmente riusciremmo a parlare ore e ore sull'implementazione di un servizio di email... )


    Gastone Canali >http://www.armadillo.it

    martedì 3 gennaio 2012 14:08
    Moderatore
  • mi fa piacere, leggendo i tuoi commenti, che ti manchi l'implementazione delle viste nel dns di ms e capisco anche il motivo per cui abbia evitato di citare lo split-brain...
    Beh, per dirla tutta, se facciamo riferimento alle features di BINDv9, ce ne sono diverse che vedrei bene implementate nel DNS di Windows, ad esempio quella relativa alle ACL e quella relativa alla recursion ... che permette al DNS di offrire risoluzione ricorsiva solo a determinati hosts (IP blocks) e di fungere da "auth only" per altri ... ma ok, questo è un discorso secondario anzi... off-topic
    Riguardo il "down" concordo che i problemi di connettività siano rari e non talmente prolungati da essere vitali, ma con una duplicazione delle  (12) caselle e con qualche accorgimento si potrebbero continuare a ricevere e spedire mail grantendo la business continuity anche nel caso di crash di exchange
    Prima di tutto, credo che in qualsiasi caso sia opportuno valutare e, possibilmente, implementare una policy di backup e di "disaster recovery", quantomeno per quelli che sono i sistemi "vitali" per l'infrastuttura di rete e, in considerazione di quanto sopra, penso che il discorso "duplicazione" possa essere evitato, quantomeno al momento attuale; per quanto invece riguarda il discorso "inviare e ricevere", come ho già scritto ci vuol poco a prendere una seconda ADSL magari anche con banda ridotta (basta che abbia un IP statico) ed usarla come backup... ed alla fine della fiera i costi di "gestione" (TCO se preferisci) saranno probabilmente inferiori a quelli relativi alla "duplicazione" del mailserver e, di contro, eviteranno complicazioni inutili nella gestione delle emails
    (e anche qui non si finirebbe di parlare su configurazioni fault-tolerant che probabilmente non tutti possono permettersi) la NON "perdita" delle mail la davo per scontata (ho iniziato usare sendmail su SunOS [ahimè] nel lontano '89) 

    Ma... guarda, dipende da come si vuole approcciare il problema, personalmente sono del parere che, sebbene mettere in piedi configurazioni "faraoniche" per una rete di piccole dimensioni non sia esattamente appropriato, il progettare l'infrastuttura in modo che possa essere aggiornata SENZA dover essere ridisegnata è sempre un buon approccio; tanto per capirci, volendo implementare una connessione ridondata basterebbe (es.) prendere un routerino "draytek" ed una linea di backup con requisiti minimi che permetta comunque di garantire la continuità di servizio; idem per il "disaster", esistono NAS a prezzi abbordabili e la stessa cosa vale per i sw di backup/imaging e questi potrebbero permettere di mettere in piedi una strategia di disaster recovery che, seppur economica, permetterebbe comunque di "tornare online" in tempi brevi... ovvio che se poi l'infrastuttura crescesse si potrà/dovrà aggiornare il tutto, ma l'importante è che si tratti di un aggiornamento e non di un completo stravolgimento dell'intera infrastuttura che... comporterebbe costi e problemi BEN maggiori :)

    A proposito di SunOS :) ... e di 1989 ... bei tempi ! Anzi visto che parli di quegli anni, forse ti ricordi anche di Microsoft Xenix :)

     

    Per quanto riguarda Mail eXchanger secondario io consigliavo di mantenere quello attuale (caselle comprese), quindi lo spam rimarrebbe equivalente, si tratterebbe di un mx "semicorrelato" con ovviamente una gestione supplementare per il sinc (accettabile, visto
    Scusa ma non capisco perchè tu parli di "sync"; alla fine se quello che serve è un backup MX, basta configurare il server esterno come MX "alto" e poi configurare exchange come MX primario facendo in modo che exchange accetti le email provenienti dal secondario, non c'è alcun bisogno di fare "polling" o di usare connectors, il protocollo SMTP prevede già di suo una configurazione di questo genere
    l'esiguo numero di caselle ), forse in un prossimo futuro sarebbe interessante usare un servizio di "cloud" ( come sono trendy ;) es. google docs/liveMail, correlato con il proprio exchange interno (un msn connector aziendale per exchange)

    Ah beh, se proprio vuoi andare su un servizio esterno, a questo punto, tanto vale usare "Exchange online" oppure, se ciò non fosse desiderato, appoggiarsi ad un servizio come quello offerto da "Exchange Defender" ... con tutti i vantaggi e gli svantaggi che tali soluzioni comportano :) personalmente, visto che "mrcmobile" ha già exchange e SE volesse per forza usare un servizio terzo, penso che mi orienterei su exchange defender dato che offre un servizio estremamente flessibile e con tutti i requisiti poi... ok, questa è solo una mia opinione personale :)

    ciao

    martedì 3 gennaio 2012 15:34
  •  

    Ottima soluzione, se posso permettermi, visto che è una soluzione a cui "tendere" io raddoppierei il  front-end e il back-end giusto per eliminare due point of failure:
    Front-end exchange in load balancing +  l'exchange server di  BackEnd in cluster.

    Se non si vuole spendere e si vuole avere un smtp proxy che funga da spamfilter/antivirus io userei
    Linux Debian+RBL+Amavis+Clamav+spamassassin (spf/dkim enabled)  ma forse sono andato OT (prima ho scritto SunOS ora Linux allora per par condicio citerò "Microsoft Mail Gateway" :)

    e grazie per le dritte sui due provider esterni

    Ciao

     


    Gastone Canali >http://www.armadillo.it

    martedì 3 gennaio 2012 16:50
    Moderatore
  •  

    Ottima soluzione, se posso permettermi, visto che è una soluzione a cui "tendere" io raddoppierei il  front-end e il back-end giusto per eliminare due point of failure:
    Front-end exchange in load balancing +  l'exchange server di  BackEnd in cluster.

    Non credo sia necessario per l'installazione attuale, e comunque l'infrastuttura rappresentata permetterebbe di modificare il tutto facilmente per includere, in un futuro, una configurazione di quel genere ma, ripeto, non mi sembra nè opportuna nè necessaria, quantomeno per il tipo di realtà prospettata

    Se non si vuole spendere e si vuole avere un smtp proxy che funga da spamfilter/antivirus io userei
    Linux Debian+RBL+Amavis+Clamav+spamassassin (spf/dkim enabled)  ma forse sono andato OT (prima ho scritto SunOS ora Linux allora per par condicio citerò "Microsoft Mail Gateway" :)

    Non mi sembra una buona idea; stiamo parlando in ogni caso di un sistema aziendale e, mettere in piedi qualcosa per cui non c'è know-how nè "assistenza ufficiale" non mi sembra il modo migliore di risolvere il problema, anzi, sarebbe il modo migliore per CREARE problemi; d'altro canto, metterci un "mail gateway" o una seconda istanza di exchange sarebbe, credo, fuori budget e, sebbene (di nuovo) la configurazione permetta di espandere il tutto in tal senso, non credo sia opportuno farlo ora

    Ripeto, quello schema è solo ed unicamente un'idea di massima che, spero, possa servire da traccia al fine di mettere in piedi l'infrastuttura; è ovvio che, volendo limitare i costi, si potranno evitare alcuni componenti o prendere qualcosa di relativamente economico ma, seguendo l'idea di base, si potrà riuscire a mettere in piedi un'infrastuttura facilmente scalabile se/quando necessario

     

    martedì 3 gennaio 2012 17:10