Από τον Exchange 2007 και μετά, ένα νέο χαρακτηριστικό ήρθε να διευκολύνει τις διαδικασίες disaster recovery: το dial-tone database recovery. Η διαδικασία αυτή βασίζεται στην επίσης νέα δυνατότητα mount μιας database από ένα Exchange server σε οποιονδήποτε άλλο χωρίς την ανάγκη περίπλοκων βημάτων. Στο blog post αυτό θα συνοψίσουμε τα κύρια βήματα που απαιτούνται στην περίπτωση κατά την οποία έχουμε μια corrupt database, η οποία έχουμε αποφασίσει ότι δεν "στρώνει" και πρόκειται να ανακτηθεί από tape και να αντικατασταθεί:

• Κάνουμε dismount την προβληματική database και μετακινούμε τo αρχείo .edb & τα transaction logs σε ένα προσωρινό folder, αφού μπορεί να χρειαστούν για recovery αργότερα
• Κάνουμε πάλι mount την database, και έτσι δημιουργούνται νέα αρχεία .edb & logs (αγνοούμε τη σχετική  προειδοποίηση). Έτσι, οι χρήστες μπορούν άμεσα να συνεχίσουν να στέλνουν και να λαμβάνουν e-mails, αλλά δεν θα έχουν πρόσβαση στα παλιότερα e-mails τους μέχρι να γίνει restore η database από backup.
• Ακολουθούμε τη διαδικασία ανάκτησης της database μέσω του λογισμικού backup που χρησιμοποιεί ο οργανισμός μας και του Recovery Storage Group αλλά δεν κάνουμε mount ακόμα την recovery database
• Αντιγράφουμε τα transaction logs της corrupt database στο χώρο που ορίσαμε για transaction logs στην recovered database
• Ξεκινάμε τη διαδικασία του “swap database” (υπάρχει μικρό downtime μέχρι να γίνει η εναλλαγή των βάσεων)
• Όταν γίνει η εναλλαγή μπορούμε να κάνουμε Merge τα μηνύματα που αποθηκεύτηκαν όσο ήταν online η dial-tone database μέσω της διαδικασίας του Recovery Storage Group.

Η διαδικασία που περιγράφτηκε πιο πάνω έχει σαφώς περισσότερα βήματα (και απαιτεί ήδη υπάρχουσα γνώση για τα Recovery Storage Groups) αλλά δίνει μια ιδέα για το χαρακτηριστικό αυτό του Exchange 2007.

Όταν είσαι στην ευχάριστη θέση να στήνεις ένα καινούργιο Certification Authority στα Windows 2008, δεν περνά απαρατήρητο το γεγονός ότι υπάρχει η δυνατότητα επιλογής του hash πρωτοκόλλου SHA2. Είναι νέο, ωραίο και (παρ' ότι δεν είναι η default επιλογή) σου κλείνει το μάτι να το χρησιμοποιήσεις. Υποκύπτεις, λοιπόν, στον πειρασμό και αντί για SHA256 επιλέγεις SHA2 κατά τη διάρκεια της εγκατάστασης. Όλα καλά και όλα ωραία, μέχρι να φτάσει η ώρα να εκδόσεις certificate σε λειτουργικά Windows Server 2003 ή Windows XP SP2. Εκεί είναι που ανακαλύπτεις το αναπάντεχο σφάλμα που πάει ως εξής: "Cannot find the requested object." Φυσικά δεν τίθεται θέμα χαμένου certificate ούτε κάποιου παρόμοιου σφάλματος. Απλά τα συγκεκριμένα λειτουργικά δεν υποστηρίζουν SHA2 CA implementations και η λύση φαίνεται να είναι το σχετικό hotfix που βρίσκεται εδώ: http://support.microsoft.com/kb/968730. Επιπλέον, τα ΧΡ SP3 υποστηρίζουν και όλες τις εκδοχές του SHA2, πλην της SHA224 (προσοχή σε αυτή τη λεπτομέρεια).

Είσαι σε μια χαλαρή κατάσταση και θες να κάνεις μια απλή εγκατάσταση του SP3 για το Microsoft Exchange 2007. Δεν υπάρχει κάτι ιδιαίτερο, πλην του schema update που απαιτείται στην αρχή. Το udpate αυτό γίνεται είτε ξεχωριστά είτε μέσα από την πρώτη γραφική εγκατάσταση του SP3 στον Exchange που θα επιλεχθεί ως πρώτος. Ούτε σε cluster θα πει (ακόμα) ούτε σε κανένα mailbοx server με χιλιάδες mailboxes (ακόμα). Τι θα μπορούσε να πάει στραβά; Ως συνήθως... πολλά! Άλλα σχετίζονται με ιδιαιτερότητες του ίδιου του προϊόντος και άλλα με 3rd-party applications που συνδέονται με τον Exchange. Σε μια πολύ πρόσφατη τέτοια εγκατάσταση, συνέβη κάτι που μπορεί να επηρεάσει μόνο αυτούς που έχουν στήσει certification authority προκειμένου να υπογράφουν ψηφιακά οι χρήστες τα e-mails τους. Συγκεκριμένα, είναι ένα πρόβλημα που περιγράφεται στο http://msexchangeteam.com/archive/2010/07/09/455445.aspx και έχει να κάνει με ένα λάθος αριθμό version στο σχετικό ActiveX control του Exchange που μπερδεύει το OWA και κάνει το αρχείο να προσπαθεί να κατέβει κάθε φορά που κάνει login ο χρήστης. Στον ίδιο πελάτη, μετά την εγκατάσταση, ένα πρόγραμμα αρχειοθέτησης των παλιότερων e-mails έχασε ξαφνικά τις επιπλέον επιλογές που είχε προσθέσει στο OWA. Προφανώς κάποιες προσθήκες που είχαν γίνει στο IIS configuration του OWA, επανήλθαν στην αρχική κατάστασή τους. Ηθικό δίδαγμα: καμια εγκατάσταση δεν είναι τόσο άπλή όσο αρχικά φαίνεται και όσο και να έχεις προετοιμαστεί, πάντα θα υπάρχει κάποια custom κατάσταση που θα φέρει τα πάνω-κάτω.

Η διαδικασία του graylisting είναι μια πολύ απλή μέθοδος αντιμετώπισης του μαζικού spam, βάσει της οποίας ένας mail server αρνείται να παραλάβει email από ένα αποστολέα που δε γνωρίζει, την πρώτη φορά που θα επιχειρηθεί να γίνει η σύνδεση. Ωστόσο, τη δεύτερη φορά που ο αποστέλλων server θα ξαναδοκιμάσει τη σύνδεση, αυτή θα γίνει αποδεκτή και η αποστολή θα γίνει κανονικά. Η μικρή (ανάλογα και με τις ρυθμίσεις, βέβαια) αυτή καθυστέρηση έχει ιδιαίτερο νόημα, αφού η πλειοψηφία των mail servers που αποστέλλουν spam δεν έχουν ρύθμιση επανάληψης της αποστολής προς ένα συγκεκριμένο παραλήπτη από τη στιγμή που η πρώτη σύνδεση αποτύχει, για λόγους ταχύτητας αποστολής.
Για τον Exchange 2007 και μόνο, υπάρχει ένας greylisting agent υπό μορφή project σε C#, που μπορείτε να βρείτε εδώ: http://msdn.microsoft.com/en-us/library/bb402057.aspx. Το project αυτό απαιτεί την εγκατάσταση Visual Studio στον Edge Server και φυσικά compilation.
Αν από την άλλη δεν έχετε πρόβλημα να εγκαταστήστε ένα unsupported 3rd-party tool στον internet-facing Exchange σας, υπάρχει και το JEP(S), το οποίο έχει και το επιπλέον πλεονέκτημα της λειτουργίας σε Exchange 2000/2003/2007 & 2010. Θα το βρείτε εδώ: http://www.proxmea.com/index.php?q=node/19.