Newsgroup: it.comp.os.win.win2000
Titolo: Mail Server sotto win2000

salve,
nella lan in cui opero vorrei implementare un mail server per la
messagistica interna. Per evitare di installare Exchange2000 mi sono
orientato su un server di posta freeware, "Hamster"; vorrei sapere se
esistono altre valide alternative in ambiente win2k (tipo qmail e sendamil
x linux), possibilmente freeware od open source....
grazie   ciao
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 sendamil x linux), possibilmente freeware od open source....
E' una faq piuttosto ricorrente :-)
Comunque, cosi' a occhio:
 - Mailtraq 
www.mailtraq.com
, free fino a 4 users: gira come servizio,
server POP3, SMTP, NNTP, proxy e qualcos'altro che non mi ricordo
- 602 Pro LAN Suite 
www.software602.com
, free fino a 5 users: gira come
servizio, server POP3, SMTP e WebMail (ero rivenditore della 602 software,
ma questo prodotto personalmente mi ha deluso perche', dopo tre anni, hanno
rimesso fuori lo stesso prodotto di prima, con un'interfaccia webmail
palesemente scritta da qualcun altro ...)
- Hermes 
www.alixoft.com
, free illimitato: gira come servizio, server POP3 e
SMTP e open source. Unico neo, non ha il fetch POP3 da server esterni.
Pero', se ti serve una cosa simile a sendmail penso vada benissimo. E'
piccolo ma tosto.
E perche' non una bella linux box con postfix? ;-)
Ciao
Luca

 ha scritto nel messaggio
news:atqaer$rnb$1...@news.newsland.it...


>
anche il server di eudora e' ottimo
open source, per solo 1.300 euro hai un ottimo prodotto, ma e' per
linux... non per win

E perche' non una bella linux box con postfix? ;-)
il che scritto da un MVP da da pensare.... :-)
-- 
Max Marini

Ti consiglio MDaemon. Non è free ma ha un costo limitato, è molto
leggero e molto versatile. Infine è estremamente stabile.
www.mdaemon.com
Ciao.
UJ


 il che scritto da un MVP da da pensare.... :-)
E perche'?
Come sostengo da sempre a spada tratta, non esiste *il* sistema migliore in
assoluto (e per fortuna); ci sono varie piattaforme hardware e vari sistemi
operativi, ognuno con le proprie peculiarita'. C'e' solo da scegliere.
Vai te a dire a un grafico di mettere da parte il suo Mac, oppure ad un
modellatore 3D di cambiare la sua stazione SGI con un pc Windows ...:-)
Linux mi sembra eccellente come sistema per server: non posso dire la stessa
cosa come workstation, per esempio; allo stesso modo, non ha caratteristiche
che lo rendano comparabile con AD. In queste situazioni, IMHO Windows 2000
e' da preferire.
Vedremo poi, con gli sviluppi di .NET e con il 64 bit, cosa saltera' fuori.
In ufficio ho di tutto, e tutte le macchine fortunatamente svolgono il
proprio compito decorosamente; non e' certamente mia intenzione volermi
omologare a questo o a quel vendor.
Ciao
Luca

Vedremo poi, con gli sviluppi di .NET e con il 64 bit, cosa saltera' fuori.
a favore di exchange devo dire la facilita' di setup e
l'intuitivita'... e' tutto nel solito stile ms quindi anche un
amministratore di sistema alle prime armi riesce a mettere su un mail
server decente.
a sfavore:
a. c'e' un limite di 16Gb nella dimensione dei file di posta
b. per fare un recovery devi necessariamente sovrascrivere il file di
produzione
c. per fare il backup devi necessariamente fermare il server di
produzione
d. se usi ntbackup come sw di backup, stai attento a che tipo di
unita' a nastro usi perche' il recovery non puo' avvenire altrimenti
che da quell'unita' (cioe' ti ci vuole una macchina esattamente uguale
in tutto e per tutto), persino l'albero delle directory deve essere
uguale, senno' ti attacchi.
a favore di linux?
velocita', configurabilita', possibilita' di eseguire un
backup/recovery con mezzi no cost (il semplice tar...) e granularita'
tale da permettere persino il recovery di un singolo messaggio di
posta (con exchange, ricordo, devi ripristinare la posta di tutti...)
a sfavore?
il tempo che occorre per apprendere come eseguire dei semplici setup
di files di testo, ma chi e' nato sotto il dos e oggi usa win, non
dovrebbe trovare difficile questo ambiente.
infine, altra considerazione, altri prodotti, come eudora world mail
server (gratuito per apple mac...) e' ancora piu' semplice da gestire
che exchange, costa meno ed e' multipiattaforma...


A me piace molto MailEenable. Si integra perfettamente con MMC, è facile ed
intuitivo e nella versione standard è gratuito anche per uso professionale.
http://www.mailenable.com/
Magari provalo e mi fai sapere cosa ne pensi.
Ciao, Antonio

omologare a questo o a quel vendor.
infatti era ironica :-)
anche io sebbene per lavoro sono costretto a supportare la piattaforma
MS se esistono soluzioni (anzi... "quando" esistono soluzioni)
migliori le propongo sempre :-)
-- 
Max Marini

che exchange, costa meno ed e' multipiattaforma...
Mettiamola in questi termini: non si può paragonare un server di posta
POP3 con uno MAPI.
Prova a proporre ad un cliente con 5000 utenti una soluzione di posta
aziendale in cui ogni utente ha nella sua macchina la posta personale
anzichè centralizzata su server... minimo minimo ti spara :-)
Ammetto di non sapere se in ambiente unix/linux esistono server di
posta elettronica aziendali paragonabili al MAPI di exchange.
Se ci sono benvenga, viva la concorrenza, ma finora chi paragona
exchange ad un server pop3 per linux forse non ha mai avuto a che fare
con realtà aziendali. 
l'unica cosa che ti posso concedere è la velocità, e il costo che
sicuramente è molto elevato (hardware, licenze, software ecc.)
-- 
Max Marini




>c. per fare il backup devi necessariamente fermare il server di


ma qui si parlava di "soluzioni a basso costo"...
infatti dicevo che da quel punto di vista ti davo ragione :)
-- 
Max Marini

no, dal sito ufficiale di microsoft...
beh, ora mi trovi la pagina dove hai letto questa info :)
non solo... ti dico io: NON è assolutamente possibile fare il backup
di exchange se spegni i servizi o se tiri giu l'information store 
o peggio gli store delle delle maibox 
(copiare la cartella del DB+i LOG non è un backup.. è una copia!)
-- 
Max Marini

>a favore di linux?


>d. se usi ntbackup come sw di backup, stai attento a che tipo di


POP3 con uno MAPI.
e perche'?

anzichč centralizzata su server... minimo minimo ti spara :-)
certo, ma difatti le soluzioni linux che ho indicato io sono anche
soluzioni IMAP....
ti dice niente questo protocollo?!

Se ci sono benvenga, viva la concorrenza, ma finora chi paragona


posta elettronica aziendali paragonabili al MAPI di exchange.
qmail
postfix
suse openexchange
lotus domino
iplanet mail server
netscape mail server
ad esempio...
ma sarebbe opportuno spiegare meglio cosa intendi tu per "MAPI" cioe'
quali sarebbero queste peculiarita' di MAPI non riproducibili da
altri?
ed inoltre, lasciando da parte la piattaforma linux, che tanto prudore
provoca...e restiamo in ambito "win32", parliamo allora delle
funzionalita' del server lotus domino...

 wrote: 

non ho tempo di farlo...
spegnere il servizio, ho detto, no exchange.
tu mi dici allora che esiste un modo per continuare a farmi inviare e
ricevere posta mentre nt backup sta facendo la copia del suo tanto
amato file di posta "MAPI"...?

 ha scritto nel messaggio
news:SSDLC5...@sasdelli.it...

Parole Sante .....
Ciao

amato file di posta "MAPI"...?
certo.
gli utenti continuano tranquillamente a scambiarsi i messaggi,
spedire, ricevere come nulla fosse anche se il database sta facendo
backup.
ma ti dirò di piu.. NON puoi assolutamente farlo in altra maniera,
cioè, per fare il backup i servizi e tutto il resto DEVONO essere
rigorosamente attivi (e quindi ricevono e spediscono posta).
-- 
Max Marini

difendersi?!
??? ma hai voglia di attaccare briga? io assolutamente no. 
hai visto gli smile che uso nelle frasi? c'è sempre il sorriso di chi
discute tranquillamente confrontando le idee e le opinioni.
se non lo sapessi :-)  è uno smile di un sorriso e per guardarlo basta
inchinare la testa verso sinistra.
Li ho messo apposta per farti capire che non ti stavo
accusando/attaccando ma semplicemente si chiaccherava.
-- 
Max Marini

o backup exec...
si ma il problema non è di exchange, ma del backup di windows :)
-- 
Max Marini

 wrote: 

una curiosità, ma tu la sai la differenza tra i due protocolli?
se la risposta è si, non avresto dovuto farmi questa domanda per ovvie
ragioni, se la risposta è no e se non hai voglia di litigare ma di
scambiare opinioni (il motivo per cui si discute nei newsgroup) 
sono ben lieto di illustrartene le motivazioni
-- 
Max Marini

ti dice niente questo protocollo?!
parliamoci chiaro, l'IMAP sarà anche un protocollo migliore del POP3
ma da qui a paragonarlo al MAPI ci passa una bella differenza :-)
il MAPI è estremamente piu flessibile, vuoi per la posta, vuoi per le
cartelle di archivio pubblico, vuoi per gli appuntamenti aziendali
condivisi, vuoi per le capacità di "scambio di informazioni mantenendo
un database centralizzato" che è in grado di offrire..
bada bene.. non sto dicendo che il MAPI è la manna dal cielo, dico
solo nella stragrande maggioranza delle realtà aziendali di medio
grosso livello è una delle soluzioni piu adottate.. 
-- 
Max Marini

ci sara' un motivo no?
certo, ma non è quello che pensi tu.
domino è un gran prodotto, con grandi funzionalità (MAPI!) per certi
versi nettamente superiore ad exchange, per altri nettamente
inferiore. qua si tratta di scelte aziendali 
devi sapere che esiste anche una cosa chiamata marketing :)))
altrimenti non si spiega come visto che linux è superiore a windows
continuano a circolare quantita infinitamente piu grandi di
quest'ultimo... vuol dire che è migliore lui??? non è certo questo il
termine di paragone.
ricordati che dietro exchange c'è microsoft e dietro dominio c'è ibm.
le realtà aziendali che lavorano a stretto contatto con ibm per
forniture macchine o altro spingono verso domino
tutto qua..
-- 
Max Marini

 wrote in message
news:n0p50vcj3seglcl2o...@4ax.com...

con il pop3, ogni client scarica in locale la propria posta.
il backup come lo fai? un tape drive per ogni client?
con mapi, il client è perennemente connesso con il server e può svolgere
altre funzionalità, oltre al semplice scaricare la posta.
nel secondo caso, ovviamente sono richieste maggiori risorse sia al client
che al server.
se anche prendi imap (in molte situazioni più indicato del pop3), una delle
differenze principali rispetto al mapi, è che non hai un collegamento
continuo.
i msg restano sul server, ma cmq il client deve collegarsi periodicamente
per verificare se ne sono arrivati di nuovi.
tieni presente che le mie sono solo considerazioni generali.
se vuoi entrare nello specifico, c'è da tirar fuori il mondo, pro e contro
una qualsiasi delle tre opzioni qui sopra :-)
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.431 / Virus Database: 242 - Release Date: 17/12/2002

 wrote: 

vediamo se ho capito...
In Exchange, l'Information Store è fondamentale per la gestione del
database. Questo componente è responsabile della memorizzazione dei
dati, come i messaggi di posta elettronica nelle caselle postali degli
utenti e le informazioni contenute nelle cartelle pubbliche.
L'Information Store è in realtà composto da due database separati. Il
database delle informazioni private, chiamato Priv.edb, gestisce i
dati nelle mailbox degli utenti. Il database delle informazioni
pubbliche, chiamato Pub.edb, gestisce i dati nelle cartelle pubbliche.
L'Information Store lavora insieme alla Messagging Application
Programming Interface (MAPI) e al motore del database Exchange per
assicurare che tutte le operazioni degli utenti vengano registrate
sull'hard disk del server. Per esempio, quando un utente salva un
messaggio nel client di collaborazione e messaggistica Microsoft
Outlook, MAPI chiama innanzitutto l'Information Store, che a sua volta
chiama il motore del database, che quindi scrive i cambiamenti sul
disco. 
La struttura di Exchange è basata sulla tecnologia database standard.
Il sistema dipende da un motore di database incorporato, che organizza
la struttura del disco per Exchange e gestisce la memoria. La
tecnologia del motore di database utilizzato in Exchange è presente
anche in altre applicazioni per il sistema operativo Windows, come
WINS e DHCP. E Microsoft SQL Server utilizza un motore di database
basato su una tecnologia simile. 
Il motore di database Exchange gestisce la memoria cache, trasferendo
gruppi di dati di 4 KB, chiamati pagine, dentro e fuori la memoria.
Il motore aggiorna le pagine in memoria e si occupa di scrivere le
pagine nuove o aggiornate sull'hard disk. In questo modo, quando le
richieste arrivano al sistema, il motore del database può salvare i
dati in memoria, senza dover accedere continuamente al disco.
Il sistema diventa così più efficiente perché scrivere sulla memoria è
"meno costoso" ( o più veloce) che scrivere sul disco.
(qui si tornerebbe alla questione "ma allora a che serve il file di
swap" passata in questi giorni sul gruppo...)
Quando gli utenti fanno delle richieste, il motore del database
comincia a caricarle in memoria e marca le pagine come "sporche" (una
pagina sporca è una pagina in memoria su cui sono stati scritti dei
dati). Queste pagine sono poi scritte sul database su disco. 
Sebbene la memorizzazione dei dati nella memoria cache rappresenti il
modo più rapido ed efficiente di elaborare i dati, ciò significa che
mentre Exchange gira, le informazioni sul disco non sono mai
completamente aggiornate.
L'ultima versione del database risiede in memoria, e poiché molti
cambiamenti avvenuti nella memoria non sono ancora stati trasposti sul
disco, il database e la memoria non sono sincronizzati. Se in memoria
vi sono delle pagine modificate non ancora scaricate e scritte sul
disco, i database vengono etichettati come incoerenti.
Così, per quanto possa sembrare strano, non appena Exchange si avvia,
mentre sta girando normalmente, i database sono tecnicamente
incoerenti. L'unica volta in cui i database Exchange sono realmente in
uno stato coerente è quando tutte le pagine sporche in memoria vengono
spostate sul disco in seguito a un arresto regolare senza errori. 
Ora, non ci vuole molto per rendersi conto che se qualcosa va storto,
risulta difficile ripristinare il tutto. Se perdete i contenuti della
memoria (diciamo che il server si guasti) prima che i dati vengano
scritti sul disco, vi ritrovate con un database incoerente. Di
conseguenza, Exchange necessita di un modo per riprendersi da questa
situazione. In altre parole, Exchange necessita di un modo per
assicurarsi una copia di tutto ciò che è cambiato nella memoria fino a
che non venga scritto sul database su disco. 
Prima dell'introduzione di Exchange Server 5.5, la cache utilizzata
dal motore del database aveva dimensioni fisse. Se Exchange
necessitava di più memoria, l'amministratore doveva cambiare
manualmente le dimensioni del buffer. 
Il motore del database integra una dinamica allocazione del buffer, in
modo che cresca o diminuisca in modo dinamico, a seconda della memoria
disponibile e delle richieste degli altri servizi che girano su
computer basati su Microsoft Windows NT Server.
Se la memoria non viene utilizzata da altri servizi di sistema, come
Microsoft Internet Information Service (IIS), il motore di database
Exchange occuperà tutta la memoria di cui necessita. Quando altri
servizi necessitano di memoria, il motore del database Exchange
rinuncerà a una parte della sua memoria, scaricando pagine sul disco e
diminuendo le dimensioni della cache. 
Quando si parla di Exchange, ci si riferisce a un sistema di posta
elettronica "basato su transazioni" e dell'Information Store come di
un database transazionale. Ma cosa significa tutto questo? Viene
definita transazione una serie di cambiamenti, quali inserimenti,
cancellazioni e aggiornamenti, effettuati su un database, in cui il
sistema rispetta le seguenti invarianti (ACID): 
Atomic
Tutte le operazioni avvengono contemporaneamente oppure non avvengono
affatto. 
Consistent
Il database è trasformato da uno stato corretto a un altro. 
Isolated
I cambiamenti sono invisibili fino a che non vengono effettuati. 
Durable
Le transazioni effettuate sono preservate nel database anche se il
sistema va in crash. 
Il motore del database "effettua" una transazione solo quando può
garantire che i dati siano "durevoli" o "continui", e protetti contro
crash o altri guasti. 
Per esempio, per spostare un messaggio di posta elettronica da una
cartella, come "Posta in arrivo", a un'altra chiamato "Importante",
Exchange deve eseguire le seguenti operazioni. 
Cancellare il messaggio di posta elettronica dalla cartella "Posta in
arrivo". 
Inserire il messaggio nella cartella "Importante". 
Aggiornare le informazioni su ciascuna cartella per riflettere
correttamente il numero di oggetti presenti e il numero di elementi
non letti.
Poiché queste operazioni sono effettuate in una transazione, Exchange
le eseguirà tutte insieme oppure non le eseguirà affatto.
Di conseguenza, non è importante l'ordine di esecuzione di tali
operazioni. Il messaggio può essere cancellato in modo sicuro da
"Posta in arrivo" perché il sistema sa che la cancellazione avviene
solo se il messaggio è inserito anche nella cartella "Importante".
ma continuiamo...
L'utente manda un messaggio.
MAPI contatta l'Information Store per comunicare che l'utente sta
inviando il messaggio. 
L'Information Store avvia una transazione nel motore di database ed
effettua i cambiamenti corrispondenti sui dati. 
Il motore di database registra la transazione in memoria, "sporcando"
una nuova pagina in memoria. 
Quasi contemporaneamente, il motore di database protegge la
transazione nel file di log di transazione e crea un apposito
registro. Quando il motore raggiunge la fine di un file di log di
transazione, prosegue e crea un nuovo file di registro in sequenza. 
Il motore di database scrive la pagina sporca sul file di database sul
disco. 
Il file di controllo viene aggiornato.
La maggior parte delle persone pensa che i file di database
costituiscano l'aspetto principale nel processo di recupero dei dati. 
Ma i file di log di transazione sono in realtà più importanti perché
riflettono ciò che accadrà con i dati, e non ciò che è già successo.
Infatti i file di log contengono informazioni che i file di database
non possiedono. Di conseguenza, dovreste memorizzare i file di log su
dischi ad alte prestazioni, sebbene questo significhi mettere i file
di database su dischi più lenti. 
Exchange utilizza i file di log di transazione per tenere traccia
delle informazioni presenti in memoria che non sono ancora arrivate al
database su disco. I file di log sono una sequenza di file il cui
scopo è di tenere sul disco una copia sicura di dati volatili presenti
in memoria, in modo che il sistema possa essere ripristinato in caso
di crash.
Per essere ancor più utili, è meglio che i file di log si trovino su
un disco dedicato, in modo che nessun guasto del disco che corrompe i
database influisca sui registri. 
Oltre a fornire un meccanismo di sicurezza per i dati contenuti in
memoria, i file di log di transazione consentono anche di scrivere i
dati in modo rapido, poiché l'aggiornamento di pagine in sequenza in
un file di log è un'operazione meno costosa rispetto
all'individuazione del punto corretto in cui inserire pagine nel
database. Quando si apporta un cambiamento al database, il motore di
quest'ultimo aggiorna i dati in memoria e contemporaneamente registra
la transazione sul file di log, che comunica come ripetere la
transazione in caso di crash del sistema. Quindi il motore scrive i
dati nel database sul disco. Per salvare l'I/O (Ingresso/Uscita) del
disco, il motore del database non scarica le pagine sul disco a ogni
transazione, ma le salva in modalità batch. 
Ogni file di log di una sequenza può contenere fino a 5 MB di dati.
Quando il file di log è pieno, passa a un nuovo file.
Per tenere il conto dei file di log, Exchange associa ciascun file a
un numero di generazione.
Per esempio, quando Exchange viene avviato per la prima volta, crea un
file di registro chiamato Edb.log con un numero pari a 1. Quando il
file di log è pieno ed Exchange passa a un nuovo file, quest'ultimo
diventa Edb.log con un numero di generazione pari a 2, e il vecchio
file Edb.log viene rinominato Edbnnnnn.log. Questo continua fino a che
non inizia la sequenza successiva di file di log.
Se perdete tutti i file di log, quando riavviate l'Information Store,
Exchange creerà una nuova sequenza di file di log iniziando con un
numero di generazione pari a 1. Poiché i file di log possono avere lo
stesso nome, il motore di database marca l'intestazione di ciascun
file appartenente alla sequenza con una firma esclusiva, in modo da
poter distinguere le diverse generazioni di file di log. 
Logicamente potreste pensare che i dati si spostino dalla memoria al
file di log per passare poi al database su disco, ma in realtà accade
che i dati si muovono direttamente dalla memoria al database sul
disco. I file di log sono ottimizzati per scritture ad alta velocità,
quindi durante le normali operazioni, il motore del database non legge
mai i file di log. Leggerebbe dai file di log soltanto se il servizio
di Information Store si fermasse in modo anomalo o si guastasse, e il
motore del database dovrebbe quindi ripristinarsi leggendo i file di
log. 
Per tenere traccia dei dati che non sono ancora stati scritti sul file
di database sul disco, il motore del database mantiene un file di
controllo chiamato Edb.chk per ogni sequenza di file di log. Il file
di controllo è un puntatore nella sequenza di log che tiene traccia
dello stato tra la memoria e il file di database sul disco. Indica il
punto nel file di log da cui l'Information Store deve iniziare il
ripristino nel caso in cui si verifichi un guasto.
In effetti, il file di controllo è essenziale per un ripristino
efficiente; se non ci fosse, infatti, l'Information Store dovrebbe
tentare il ripristino ricominciando dall'inizio del file di log più
vecchio trovato sul disco, e poi controllare ogni pagina in ogni file
di log per stabilire se sia già stato scritto sul database. Questo
processo, naturalmente, necessiterebbe di molto tempo, soprattutto se
il vostro obiettivo fosse unicamente quello di rendere coerente il
database. 
Il file di controllo è localizzato sul disco di sistema, così se
dovete ripristinare il vostro disco di sistema, è probabile che questo
file manchi o che abbiate una versione non valida. 
Questo mi e' gia successo...
Oltre al normale processo di logging, che protegge i dati fino a
quando non vengono scritti sul disco, Exchange supporta anche una
funzionalità denominata circular logging. Tale caratteristica risale
ai tempi in cui era molto difficile trovare spazio sul disco del
server.
Subito dopo la diffusione di Exchange, molti utenti temevano di più la
possibilità di non avere più spazio su disco che non il recupero dei
dati.
Di conseguenza, per mantenere file di log con dimensioni fisse ed
evitare l'accumulo di file di log, il circular logging è attivo di
default. Ciò significa che, una volta raggiunto il limite di 5 MB per
i file di log, il motore del database lo cancella e crea un nuovo file
di log nella sequenza. Così facendo, Exchange mantiene sul disco
soltanto una quantità di dati sufficiente a garantire la coerenza del
database in caso di crash. 
Nella maggior parte dei casi, se la protezione dei vostri dati vi
interessa particolarmente, la prima cosa da fare sarebbe quella di
disabilitare il circular logging sul vostro computer. Sebbene il
circular logging riduca la necessità di spazio su disco, al tempo
stesso impedisce di recuperare tutti i cambiamenti avvenuti
dall'ultimo backup, nel caso in cui l'Information Store risultasse
corrotto a causa di un guasto hardware.
ed e' questo quello che mi e' successo...
Questo avviene perché il circular logging mantiene soltanto un numero
ridotto di file di log per assicurare l'integrità delle transazioni
nella fase di ripristino, in seguito a guasti non riguardanti
l'hardware.
Il circular logging nega i vantaggi offerti dall'utilizzo di un
sistema basato su transazioni e sacrifica la capacità di ripristino se
qualcosa va storto nel sistema e i contenuti presenti in memoria vanno
persi.
Di conseguenza, non è consigliabile per la maggior parte delle
installazioni di Exchange. Per garantire il ripristino da qualsiasi
guasto riguardante l'Information Store, non dovreste utilizzare il
circular logging. 
Il circular logging funziona più o meno come il logging normale, ad
eccezione del file di controllo che non è più soltanto una
caratteristica di ottimizzazione, ma è essenziale per tenere traccia
delle informazioni che sono state scaricate sul disco.
Durante il circular logging, mentre il file di controllo avanza verso
il file di log successivo, i vecchi file vengono riutilizzati nella
generazione seguente. Quando questo accade, si perde la capacità di
utilizzare i file di log sul disco insieme agli strumenti di backup
per ripristinare fino alla più recente transazione effettuata. 
Può capitare che talvolta il sistema fallisca ed Exchange registri un
errore che richieda al sistema di ritornare a uno stato di corretto
funzionamento. La maggior parte delle volte, gli errori sono causati
da problemi hardware.
E' importante capire che esistono differenti tipi di errori nel
database, con sintomi molto diversi tra loro. Di conseguenza, non è
possibile correggere tutte le corruzioni di database allo stesso modo.
E' necessario utilizzare tecniche e strumenti diversi per individuare
e risolvere i vari problemi. 
Segue un elenco dei tipi più comuni di errori che mi sono capitati e
che ho risolto.... (e quindi caro mio ho esperienza di sistemi
aziendali e te lo dimostro...)
Corruzione fisica
A basso livello, i vostri dati possono corrompersi fisicamente sul
disco. In genere questo è un problema collegato all'hardware, per la
cui risoluzione è sempre necessario ripartire dal backup. 
Corruzione logica
Le corruzioni logiche avvengono generalmente a livello di database.
Per esempio, un errore nel motore del database può essere il motivo
per cui gli indici nel database puntano a valori mancanti. Le
corruzioni logiche possono anche avvenire a livello di applicazione,
per esempio, nelle caselle postali, nei messaggi, nelle cartelle e
negli allegati. 
Corruzione fisica
Probabilmente il problema peggiore che vi possa capitare è una
corruzione fisica che distrugga i vostri dati. Le corruzioni fisiche
sono molto gravi per i database perché non è possibile ripararle.
Per riportare il vostro sistema a uno stato di perfetto funzionamento,
è necessario che ripartiate dal backup. Di conseguenza, è molto
importante individuare le corruzioni fisiche sin dall'inizio e
risolvere i problemi in modo rapido. 
ma non c'e' un tool in ntbackup che lo consenta...
Per esempio, quando eseguite un backup online, il software di Backup
legge ogni pagina di 4 KB nel file del database, la passa al motore
del database e quindi scrive le pagine sul nastro.
Ogni volta che il motore del database accede a una pagina, verifica
che il checksum su quella pagina sia corretto. Se tale somma non
corrisponde a quella che il motore del database calcola, c'è una
corruzione fisica nel vostro database sul disco e Backup terminerà con
un errore 1018. 
Errori che in genere indicano corruzioni fisiche 
Se vedete i seguenti errori nel vostro event log, è molto probabile
che abbiate una corruzione fisica nell'information store. 
1018 (JET_errReadVerifyFailure)
I dati letti dal disco non sono gli stessi che sono stati scritti sul
disco. 
1022 (JET_errDiskIO)
L'hardware, il driver per dispositivi o il sistema operativo rimandano
errori. 
510 JET_errLogWriteFail
I file di registro hanno esaurito lo spazio su disco oppure c'è un
guasto nell'hardware con il disco del file di registro. 
Prevenire le corruzioni fisiche 
Il modo migliore per evitare le corruzioni fisiche è di dotare il
vostro server di componenti hardware di qualità e di configurare il
vostro sistema correttamente. Inoltre dovreste anche assicurarvi di
non far girare utility file-level (come il software anti-virus) sui
file di log e database del vostro computer Exchange.
E questo l'ho capito a mie spese... dopo avere avuto danni enormi
causati dal mcafee antivirus...
La buona notizia è che se possedete hardware affidabile, probabilmente
non vedrete mai una corruzione fisica. Ma, se incontrate continuamente
errori -1018, è molto probabile che abbiate un disco o un controller
del disco non molto efficaci, oppure qualche altro problema
nell'hardware che dovrete quindi risolvere. 
Allora, e' meglio utilizzare la funzionalità di write-back caching
oppure no? 
Alcuni controller di write-back caching rimandano erroneamente delle
risposte positive sulle transazioni prima che i dati siano stati
memorizzati sul disco. Il miglior modo di agire è di invalidare la
funzionalità di write-back caching, a meno che non abbiate un
controller di caching supportato da batterie che scriva le
informazioni sul disco.
Se utilizzate la funzionalità di write-back caching, assicuratevi che
i dati siano interamente protetti e che disponiate delle procedure
corrette per essere certi che, dopo un guasto, i dati contenuti in una
cache siano sempre replicati sui dischi giusti. Questo è importante
perché, se perdete i dati nella cache, molto probabilmente vi
ritroverete con un database corrotto. 
In realtà, non esiste un modo del tutto sicuro per riparare una
corruzione fisica sul database. Potete far girare Eseutil.exe in
modalità riparazione per riportare il database a uno stato di corretto
funzionamento. Tuttavia, questo non è consigliabile perché Eseutil
elimina semplicemente la pagina corrotta, e voi finite col perdere i
dati.
L'unico modo di riparare una corruzione fisica nel vostro database è
di effettuare un'operazione di ripristino dal vostro ultimo backup
positivo (se il vostro backup precedente non ha incontrato errori,
sapete che è positivo) per portare il vostro sistema a uno stato
regolare e non corrotto. Se il vostro backup fallisce ancora, è molto
probabile che abbiate un problema con il disco dove è localizzato il
database. 
Evitare di utilizzare Eseutil /p se possibile 
Eseutil è uno strumento distribuito insieme a Exchange, che può essere
utilizzato come ultima risorsa, quando qualsiasi altra cosa non riesce
a riparare le corruzioni dei database. Eseutil in modalità riparazione
(Eseutil /p ) opera a livello del motore di database per riparare un
database e farlo girare nuovamente eliminando semplicemente le pagine
corrotte. Di conseguenza, Eseutil non dovrebbe mai essere utilizzato
per il recupero dei dati. 
Dopo aver fatto girare Eseutil /p, è necessario far girare Isinteg
-test alltests -fix per riportare un database a uno stato regolare. 
Corruzione logica 
Le corruzioni logiche sono molto più difficili da individuare e
riparare rispetto alle corruzioni fisiche, perché sono imprevedibili e
in genere causate da errori software. A volte, non sapete nemmeno che
ci sia una corruzione logica finché non accade qualcosa che vi avverta
della presenza di un problema. 
Se vi trovate di fronte a una corruzione logica, dovete impratichirvi
nel troubleshooting il più presto possibile. Questo non significa che
dobbiate necessariamente essere il più grande esperto mondiale di
Exchange, ma piuttosto che dovete lavorare con costanza e metodo, e
prendere nota di qualsiasi cosa facciate. 
Evitare le corruzioni logiche 
Poiché le corruzioni logiche sono imprevedibili di natura, non esiste
un metodo infallibile per evitarle. Tuttavia, ecco alcuni consigli
utili per ridurre i rischi. 
Assicuratevi che nessuno cambi la vostra configurazione di Exchange a
vostra insaputa. 
Se pur avendo seguito questi consigli, vi ritrovate con lo stesso
problema, significa che avete scoperto un nuovo errore. A questo
punto, dovreste comunicarlo a Microsoft il più presto possibile, in
modo che possiamo risolvere la questione nel successivo aggiornamento
del prodotto. 
ma qui si tratta di fare gratis un lavoro che invece ms vuole venga
pagato se chiedete supporto...
andiamo avanti...
Le corruzioni logiche possono aver luogo nell'information store o nel
motore del database. Poiché le corruzioni logiche possono seriamente
danneggiare i vostri dati, non dovreste ignorare gli errori che
colpiscono l'information store o il motore del database.
Potete utilizzare ISENTEG per controllare che non vi siano problemi
nell'information store, o ESEUTIL per controllare che non vi siano
problemi nel motore del database.
Importante Dovreste utilizzare ISINTEG e ESEUTIL come ultime risorse
solo dopo aver provato a ripristinare il vostro sistema dal backup. 
ISENTEG 
Information Store Integrity Checker (ISENTEG) trova ed elimina gli
errori dai database che raccolgono le informazioni pubbliche e
private. Questi errori possono impedire l'avvio dell'information
store, oppure impedire agli utenti di accedere, ricevere, aprire o
cancellare la posta elettronica. Per esempio, è possibile utilizzare
ISENTEG per correggere i contatori dell'information store presenti in
memoria quando, in seguito a un guasto nel sistema, non sono più
sincronizzati. ISINTEG non è stato pensato per essere utilizzato come
parte della normale manutenzione dell'information store. Ha il compito
di supportare l'utente nelle situazioni di ripristino in cui il
database è stato danneggiato. 
Poiché ISINTEG opera a livello di schema logico, è in grado di
recuperare i dati che ESEUTIL non riesce. Questo accade perché i dati
che sono validi per ESEUTIL a livello di schema fisico, possono essere
semanticamente invalidi a livello di schema logico. ISINTEG registra
le informazioni sull'event log in modo che possiate seguire tutta la
fase di ripristino. 
ISINTEG svolge due funzioni fondamentali: 
E' in grado di riparare l'information store in seguito a un ripristino
da un backup offline. 
E' in grado di controllare ed eventualmente di correggere gli errori
nell'information store 
Per qualsiasi altra informazione su ISINTEG, potete consultare il
documento Isinteg.rtf sul CD di Exchange 5.5 nella directory
Support\utils. 
ESEUTIL 
ESEUTIL deframmenta, ripara e controlla l'integrità dell'information
store e della directory. A differenza di ISINTEG, che è sensibile
all'utilizzo e ai contenuti dei dati presenti nell'information store,
ESEUTIL esamina la struttura delle tabelle e dei record del database.
ESEUTIL, in modalità riparazione, elimina semplicemente le pagine
corrotte per riportare il sistema a uno stato di corretto
funzionamento. Pertanto, se cercate di recuperare i dati, dovreste
utilizzare ESEUTIL solo dopo aver provato a effettuare il ripristino
dal backup. 
Il software di backup esegue le seguenti operazioni. 
Backup copia il database su nastro. 
Un sottoinsieme di pagine, che sono cambiate dopo la copiatura su
nastro, vengono aggiunte sul file .Pat. 
L'attuale file Edb.log viene rinominato Edbnnnnn.log e viene creata
una nuova generazione di log. 
Se si tratta di un backup completo, il file .Pat e tutti i file di log
dopo il punto di controllo (a eccezione del nuovo Edb.log) sono
copiati sul nastro. Se invece si tratta di un backup di una copia,
tutti i file di log prima e dopo il punto di controllo sono salvati. 
Se si tratta di un backup completo, i file di log di transazione
precedenti al punto di controllo vengono eliminati. Se invece si
tratta di un backup di una copia, non viene eliminato alcun file di
log di transazione. 
Il software di backup esegue le seguenti operazioni durante un backup
incrementale o differenziale. 
L'attuale file Edb.log viene rinominato Edbnnnnn.log e viene creata
una nuova generazione di log. 
Il backup copia tutti i file di log (ad eccezione del nuovo file
Edb.log) sul nastro. 
Se si tratta di un backup incrementale, i file di log di transazione
precedenti al punto di controllo vengono eliminati. Se invece si
tratta di un backup differenziale, non viene eliminato alcun file di
log. 
Nell'ideare una strategia di backup, pensate innanzitutto a come deve
essere il vostro processo di ripristino. Le procedure scelte
dovrebbero essere le più semplici, con il minor numero di passaggi, in
modo che possiate eseguire le stesse operazioni quando ripristinate
ciascun server. 
E' utile eseguire il seguente test prima di implementare Exchange
Server in un ambiente di produzione. 
Salvate i vostri database Exchange su nastro. 
Generate alcuni carichi di lavoro sul sistema in modo da produrre una
certa attività nei vostri file di log. Questo è possibile facendo
girare Loadsim o Mailstorm. 
Simulate un guasto. 
Ripristinate i file del vostro database dal backup su nastro e
assicuratevi che i file di log tornino a funzionare nel modo da voi
previsto. 
Quando intendete recuperare i dati da un backup su nastro, il processo
di ripristino riporta sul disco tutti i file che sono stati salvati. 
Il System Attendant avvia l'information store. 
L'information store controlla RestoreInProgress nel registro e
stabilisce se il database sia stato ripristinato da un backup online. 
RestoreInProgress comunica all'information store dove cominciare a
riprodurre i file di log. Non controlla Edb.log. 
L'information store scrive le pagine contenute nel file .Pat nei file
del database, fa ripartire i file di log specificati da
RestoreInProgress, e opera attraverso qualsiasi altro registro sul
disco. 
Se dovete ripristinare un information store corrotto, ecco le
operazioni che un ripristino completo include. 
Avanzamento di tutti i file di log di transazione. 
Ricordate che l'aspetto che richiede più tempo in un processo di
ripristino non corrisponde alla copiatura dei file del database sul
disco, ma alla riproduzione dei file di log.
Infatti, a seconda della frequenza con cui eseguite dei backup
completi, possono essere necessarie diverse ore per riprodurre i file
di log su server di grandi dimensioni durante un processo di
ripristino. 
Questo avviene perché il motore del database deve gestire ogni
transazione avvenuta dall'ultimo backup. La velocità di riproduzione
dei file di log varia anche a seconda del tipo di transazioni che
devono essere ripetute.
Per esempio, l'information store impiega molto più tempo a riprodurre
i file di log con numerose operazioni di cancellazione o allegati. In
media, ci vogliono dai 30 secondi ai 4 minuti per ciascun file di log.
Sarebbe bene che controllaste i vostri file di log per valutare con
maggior precisione il tempo necessario per effettuare questo tipo di
operazione nel vostro sistema. 
Ad eccezione dei backup, Exchange si occupa automaticamente della
manutenzione di tutti i database mentre il server è online. La maggior
parte di queste attività avvengono come processi di background durante
la regolare manutenzione dell'information store. L'information store
effettua generalmente la manutenzione on-line di notte ed esegue
funzioni molto importanti quali l'elaborazione della cache Deleted
Item, la pulizia generale e la deframmentazione online. 
questi sono i sw suggeriti da ms come sw di backup
Cheyenne ARCserve. 
Legato NetWorker. 
Seagate BackupExec. 

sono ben lieto di illustrartene le motivazioni
si la differenza la conosco, non ho voglia di litigare ma di discutere
con argomentazioni.

ma da qui a paragonarlo al MAPI ci passa una bella differenza :-)
partendo da presupposto che una delle features del mapi e' il common
store centralizzato, ho citato imap perche' anche questo lo supporta,
a differenza del pop3, che e' piu' simile, diciamo cosi', al
protocollo smtp.
ma penso che una disquisizione sui protocolli potrebbe essere off
topic...
tu che ne dici?

??? ma hai voglia di attaccare briga? io assolutamente no. 
no

io mi riferivo a exchange2000 ma il discorso non cambia.
secondo me si, invece, perche' nel 2000 ci sono funzionalita' migliori
ovviamente che nel 5.5, ed e' per questo che dove e' possibile
implemento il 2000 e non il 5.5, purtroppo pero' non e' cambiato
niente a livello di tool di backup "gratuito" offerto da ms... forse
non vuole intromettersi in questo settore... non lo so.

oppure no? 
domanda da un milione di dollari.
il punto è: in queste cose si preferisce l'affidabilità alla velocità
(non per nulla quando si promuove una macchina a domain controller lei
automaticamente disabilita dai dischi che contengono il db+log di AD
il write-back per evitare che una mancanza di corrente possa lasciare
il db inconsistente
-- 
Max Marini

IMAP ;-)
?!

allora, stabilito che non siamo qui per litigare ma per discutere


IMAP ;-)
argomentazioni perfette e argomento interessante ma mi mancano
esattamente 20 minuti alle ferie.  :-D
si riprende a gennaio
buone feste a tutti!
-- 
Max Marini

ma se sempre tu che ti autorispondi?
assolutamente no... c'era un messaggio di TINTO, forse il tuo server
delle news ancora non ha ricevuto il feed.. boh.
-- 
Max Marini