İşte tüm bu mail trafiğinin omurgasını pastadaki % 55 lik dilimiyle Microsoft Exchange Server yazılımı oluşturmaktadır. Çok önemli dataların tutulabildiği Exchange database’ini güvende tutmak ve sistem devamlılığının sağlamak üzerine konuşalım.

EXCHANGE SERVER DATABASE ININ YEDEKLENEMESI

Sistem yöneticilerinin korkulu rüyalarından birisidir exchange çökmesi fakat biraz tedbir ve doğru back-up ile yıkımlardan(disaster) kolayca kurtulmak mümkündür. Exchange’in Windows ile ortak çalıştığı, active directory ile bütünleştiği doğrudur. Ancak unutulmaması gereken nokta işletim sisteminden ayrı bir yazılım olduğudur. Demek oluyor ki NT back up aslında bir takım özel işlemleri gerçekleştirmeden Exchange database ini yedekleyemez.

Exchange yüklü bir server da NT back up çalıştırılıp tüm disk seçilmek süretiyle alınan yedeklerin raporlarına bakıldığında exchange için önem arzeden dosyaların yedeklerinin alınamadığını o anda kullanıldığı için es geçildiği (skip) açıkca gözlenir. Söz konusu dosyaların isimlerini hatırlamak gerekirse pub1.edb, pub1.stm, priv1.edb ve priv1.stm dir. Bu dosyaları c:\exchsrvr\mdbdata klasörü altında bulmak mümkündür, Her ne kadar ilişikli olsa da “genel olarak pub database’i mailboxlar, priv1 database’i ise public folder bilgilerini tutar.” cümlesi yanlış sayılamaz. Mdbdata klasörüne inildiği zaman eğer system managerda -logları üzerine yaz- check boxu işaretli değilse pek çok log dosyası da görünür. Aslında bu dosyalar exchange database’inin transaction loglarıdır. Exchange yaptığı tüm işleri bu loglara yazar. Exchange yedeklenirken bunları yedeklemek farz değildir ama database’lerin bozulduğu bir durumda loglar baz alınarak recovery işlemi yapılabilir. Böylece bir yıkım engellenmiş olur. Kişisel tavsiyem yedek alırken ilgili transaction loglarını da yedeklemektir.

* Yedekleme esnasında dikkat edilecek birinci husus sistemi offline konumuna getirmektir. Yani konu ilgili çalışan servisleri kapatmak;

Microsoft Exchange Internet Mail Service
Microsoft Exchange Event Service
Microsoft Exchange Message Transfer Agent
Microsoft Exchange Information Store
Microsoft Exchange Directory
Microsoft Exchange System Attendant

* Servislerin kapatılmasının ardından server bilgisayarın system state’ini ntback up veya üçüncü parti bir yazılımla yedeklemek gerekir.

Yukarda bahsettiğimiz gibi exchange, active directory’e ilişik biçimdedir ve bilindiği gibi active directory de ki her obje için bir SID bulunur bu SID ler Active Directory nin her kurulmasında değişir. İşletim sistemi ise objeleri bu SID ile bulur, sorgular. Aynı şartlar altında aynı domain de iki farklı Active Directory yüklemek ve aynı kullanıcı hesaplarını oluşturmak mümkün olsa iki directory içinde kullanıcılara tahsis edilen SID numaraları farklı olacaktır. Buradan çıkarmamız gereken sonuç, exchange sistem database’nin bir çökme ardından geri dönülmesi, sistemin çalıştığı andaki Active Directory ve SID numaralarının serverda bulunması gerekliliğini doğurur. Başka bir deyişle de Exchange database’ini rastgele bir Active Directory e geri döndermek mümkün değildir. Mutlaka serverı yıkımdan önceki duruma getirmek gerekir. System state’i bu sebele yedekliyoruz.

* Son olarak copy – paste veya ntbackup ile söz konusu databaseleri ve logları yedeklemek dir.

Bu yedekleme yapılırken de dikkat edilmesi gereken husus database’in işletim sistemi olmayan bir partition’a veya farklı bir HDD veya tape back-up ünitelerine yapılmasıdır. Bu 3 adım ile exchange serverı yedeklemiş olduk. Artık servislerimizi aktif hale getirebiliriz.

EXCHANGE SERVER DATABASE’İNİ YEDEKTEN GERİ YÜKLEMEK

Exchange’i yedeklemek ne kadar kolaysa yedekten geri dönülmesi de o kadar kolaydır. Yalnız geri dönüşüm esnasında bizi kısıtlayan etkenlerin fazlalığı konunun karışık görünmesine neden olabilir.

Yıkımlarda kendi aralarında farklılık gösterir. Örneğin sadece exchange server çökebilir, Active Directory çökebilir veya dump hali dediğimiz mavi ekranla karşılaşıp bilgisayarın hiç açılamaması olabilir hatta yıkımın ardından formatlanmış bir makine ile de karşılaşabiliriz. Bu tip durumları tek tek irdeleyelim.

Sadece exchange in çökmesi durumu demek mail transferinin tek yönlü veya iki yönlü tıkanması, posta alışverişinin durması demek. Tüm kontrolleri yaptınız sistemde normal ama mail transferi olmuyor. Exchange i kaldırıp, tekrar kurmak istiyorsunuz işletim sisteminiz ayakta. Exchange i tekrar install ettiniz. Yapmanız gereken tek şey MDBDATA klasörü altını tamamen boşalttıktan sonra Pub ve priv databaselerini bu klasörün altına yapıştırmak. Sistem log olmadığını görünce kendisi oluşturacaktır.

Tam disaster yani yıkım durumunda sistemin geri dönüşünü konunun anlaşılması açısından adım adım irdeleyeleyim

Öncelikle kısıtlarımızı gözden geçirmeliyiz.

* Yeni kurulacak makinenin FQDN (tam ismi) öncekiyle aynı olmalı.

* Yeni kurulacak makinede Active Directory bilgisi öncekiyle aynı olmalı.

* Yeni makinenin statik ipsi ilk aşamada öncekiyle aynı olmalı.

Bu kısıtlar ışığında

* Server işletim sistemini ayağa kaldırdıktan sonra Active Directory kurulur akabinde sistem restore mod da açılmak süretiyle system state restore edilir. System State in restore edilmesi Active Directory’mizi eski SID nolarıyla ayağa kaldırdığımız anlamına gelir.

* Exchange ilk kuruşta olduğu şekilde kurulur.

* Yukarda adı geçen servisler stop edilir.

* Mdbdata klasörüne inilir. Altı boşaltılır ve yedek database’lerimiz (loglar hariç) yerine kopyalanır.

* Servisler start edilir.

* Servislerin start edilmesinin ardından, mailboxların ve public folderların olduğu sanal M sürücüsünü isinteg işlemi için dismount etmek gerekmektedir. Dismount işlemi için system managerda first storege group genişletilerek mailboxlar ve public folderlar dismount store komutu ile sistemden ayrılır.

* Isinteg işlemi yeni kurulan exchange ile sonradan eklenen eski database arasında sistem bilgisinin güncellemesi ve tam senkronize çalışması için Microsoft tarafından tavsiye edilen bir işlemdir. Kimi durumlarda isinteg işlemi yapılmadan da sistem normale dönebilir. Bu işlemin nasıl yapıdığı konusuna gelince; c:\exchsrvr\bin klasörüne komut satırından gidilir. Burada isinteg komutunun help inden de anlaşılacağı şekilde yanına istediğiniz opsiyonları ekleyebilirsiniz. Yalnız dikkat edilmesi gereken husus testlerin hem mailbox (1) hem Public Folders (2) için yapılamsıdır. Isinteg için örnek syntax “isinteg –s servername –fix –verbose –test alltest”

* isinteg işlemini hem public hem mailboxlar için yaptıktan sonra sistemi tekrar first storage group dan mount ediyoruz. Böylece Exchange’i yedek aldığımız zamana geri döndermiş oluyoruz.

BOZUK EXCHANGE DATABASELERİNIN TAMİRİ VE DEFRAGMANTASYONU

Yukarda adı geçen pub ve priv dosyalarının exchange databaseleri olduğunu ve exchange bilgisinin bunlarda tutulduğunu öğrendik ancak bu ilgili exchange dosyalarının çok hasas olduğunu eklemek zamanıdır. Exchange 2000’de en çok rastlanan arızalardan birisi olan database’in bozulması, yine işletim sistemi içersindeki bazı yardımcı araçlarla düzeltilebilir. Bozuk exchange databaselerinin tamiri konusunu irdeleyelim.

Exchange 2000 serverların bir handikapı sanal bir sürücüye mount edilmesidir. Bu handikap 2003 serverda giderilmiştir. 2000 server için ise Remove the IFS Mapping for Drive M in Exchange 2000 Server (http://support.microsoft.com/default...305145&sd=tech) başlığı altında irdelenmiştir. Oradaki adımları dikkatlice uygulayarak exchange’in sanal diske mount etmesi engellenebilir. Nadiren işletim sistemindeki güncellemeler, service pack yüklemeleri, donanım destekleri; genelde de antivirüs programlarının sanal (M sürücüsünü taramaya çalışması, open relay ile server üzerinden donanım kapasitesi üzerimde spam mail gönderilmeye çalışılması ve public folderlara çok fazla veri girişi(domain altında çok fazla site varsa) exchange database’ini bozan etkenlerdendir.

Serverda ağırlaşma, store.exe dosyasının işlemcikaynaklarını tüketmesi(işlemcinin altını çiziyorum, RAM kaynaklarının tüketmesi farklı bir sıkıntıdır.), server restart edildikten bir süre sonra mail transferinin çift yönlü yavaşlaması veya tamamen durması, clientlerde mail gönderimi esnasında maillerin outbox ta çok uzun süre beklemesi, Outlooklardan görüldüğü halde system managerdan public folderların görüntülenememesi, yenilerinin oluşturulamaması veya pub database’i de bozulmuşsa maillere ulaşama(outlook isimleri çözdüğü halde) bozuk database symptomlarıdır, event viewer’a da konu ile ilgili çok açık loglar düşmez.

Sistem yukardaki belirtilerinin birini veya birkaçını gösteriyor ve exchange database’inizin bozulduğunu düşünüyorsunuz ve sistemin offline yedeği yok. Tam bir kabus. ESEUTIL komutlarını bilmeyen bir sistem yöneticisinin ömrünü epeyce törpüleyecek bir durum. Bu sıkıcı durumu atlatmak için yöntemler mevcuttur.

Eseutil komutu ile bazı parametreler kullanılarak defragmantasyon, recover, integrity(bütünlük), file dump(dosya dökümü), repair (tamir) restore, checksum işlemleri yapılabilir. Fakat ençok recovery ve repair fonksiyonları kullanılır.

Recovery fonksiyonu, bozuk exchange’i, transaction loglarını okuyarak düzeltir. Bu işlemde veri kaybı yoktur. Yukarda yedekleme anlatılırken logların yedeklenmesini bu tip durumlar için tavsiye etmiştim. Bir recovery işlemi için:

.

*İlgili serviceler stop edilir.

*Sistem dismount edilir.

*Komut satırından exchsrvr\bin klasörüne gidilir

*Aşağıdaki örnek sysntax kendi sisteminize uyarlanılarak yazılır

Eseutil /r e00 /l ”c:\exchsrvr\mdbdata”

Burada eseutil komutumuz, r recovery parametresi , e00 log dosyalarının ortak olan ilk 3 karakteri (default u e00 dır), tırnak içerisinde ise log dosyalarının bulunduğu path yazılır. Logların ve database’in aynı klasörde olduğunu varsayıyoruz.

*Eseutil işleminin ardından servisler start edilir sistem mount edilmez.

*Isinteg işlemi yapılır .

*Sistem mount edilir.

Tüm bunların ardından sistem ayağa kalkmıyorsa paniklemeyin sistemi restart etmek düzeltebilir.

Repair işlemi, genelde kötü kapatılma sonucu sistem ve mismatch hatalarının giderilmesi ayrıca bozuk exchange database’lerinin onarımı için kullanılır. Burada veri kaybı söz konusu olabilir. Bir repair işlemi için:

*İlgili servisler stop edilir.

*Sistem dismount edilir.

*Komut satırından exchsrvr\bin klasörüne gidilir.

*Aşağıdaki örnek sysntax kendi sisteminize uyarlanarak yazılır.

Eseutil /p “c:\exchsrvr\mdbdata\priv1.edb”

Burada eseutil komutumuz, p repair parametremiz, tırnak içerisinde ise databaseimizin path’i yazılır. Komut dahada uzatılabilir. Bir temp database’i kullanması ve bu database’i farklı isimde kaydetmesi gibi spesifikasyonlarda vardır. Ancak bu kadarı yeterlidir. Bu işlem database’in büyüklüğüne göre uzun sürebilir.

*Yukardaki işlemler pub1 databasei içinde yapılır.

Eseutil /p “c:\exchsrvr\mdbdata\pub1.edb”

*Database in defrag edilmeside sistemin hızlanmasına yardımcı bir durumdur. Repair işlemi ardından şiddetle tavsiye edilir.

Eseutil /d “c:\exchsrvr\mdbdata\pub1.edb”

Eseutil /d “c:\exchsrvr\mdbdata\priv1.edb”

*Eseutil işleminin ardından servisler start edilir sistem mount edilmez.

*Isinteg işlemi yapılır.

*Sistem mount edilir.

Recovey ve repair işlemleri ardından sistemin normale döndüğünü fakat bir süre sonra tekrar bozulduğunu fark ederseniz. Database’in bozulmasına neden olan tetikleyici unsurları araştırmalısınız, ki bunlar daha önce bahsettiğimiz gibi üçüncü parti yazılımlar (antivirus, firewall gibi), public folder’a yoğun bulk insertler gibi. Diğer site’lardaki databaselerin boyut farklarıda bu araştırmaya yardımcı olabilir.

EXCHANGE YÖNETİCİLERİNE TAVSİYELER

*Exchange yedeklenirken yeterli alanınız varsa loglarıda yedekleyin.

*SMTP trafiğini tarayan bir antivirus yazılımı mutlaka kullanın.

*Trafiği yoğun sistemlerde ikinci server mümkünse bir dc-adc değilde bir front end -back end şeklinde çalıştırın.

*Kullanıcı maillerinin mutlaka pc lerdeki pstlere aktarılmasını sağlayın (hem serverı fazla meşgul etmeme, hızlı çalışma hemde userla sorumluluk paylaşma açısından)

*Her mailbox için mutlaka uygun bir kota koyun uygun bir attachment boyutu sınırı tahsis edin.

*Userlara birçok SMTP adresi eklemek veya forwarders olarak kullanmak yerine gruplar oluşturun userları bu gruplara üye edin.

*Exchange yedeklemesi için bir pacth dosyasını hazırlayın scheduled tasktan bunu gece saatlerine ayarlayın.(offline yedekleme esnasında thirty party bir yedekleme yazılımı kullanmıyorsanız mail transferi yedekleme zamanı kadar duracaktır)

*OWA dll lerine ve shema bilgisine mümkün olduğu kadar az, hatta hiç müdahale etmeyin.

*Her site daki kullanıcıların maillerini o site daki Domain Controller de tutulmasını sağlayın.