Microsoft Exchange Server e-posta sistemi Active Directory Dizin hizmetine göbekten bağlıdır ve çalışmış olduğu süre içinde de onun sağlıklı olmasını ister.

Exchange server kurulum işlemlerinde ve kurulum sonrası çalışma süresi içinde ve yapacak olduğumuz en ufak bir değişiklikte Domain Controller sunucularını kullanmaktadır.

İki mimari bir-birine bağlıdır ve ayrı düşünülemez.

Ekranı görmektesiniz.

Bir önceki dersimizden kalan topolojiyi silmedim.

Topolojimiz içinde birden fazla domain, birden fazla veri merkezi ve birden fazla Domain Controller sunucusu bulunmakta.

Fakat mevcut topoloji içinde tek bir adet Exchange organizasyonu bulunmakta ve bu organizasyon içinde bulunan Exchange Server ‘lar da sadece tek bir veri merkezi içinde hizmet vermekte.

Daha önce konuşmuştuk, biz bu tasarıma merkezi Exchange server tasarımı demekteyiz.

Mevcut topoloji de Merkezi exchange server tasarımı yapılmış olsa bile organizasyon içinde bulunan her bir Exchange server, mevcut topoloji içinde bulunan bütün domain Controller sunucularını kullanmaktadır.

Bu çalışma mantığı Exchange Server ‘in doğasında bulunmakta ve bu kullanım senaryosu da Exchange server için bazen problemlere bazen de Exchange Server ‘in verimli çalışmasına etki etmektedir.

Daha sağlıklı, daha verimli ve optimize edilmiş bir e-posta sistemi için mevcut tasarımda neler yapabiliriz, yapacak olduğumuz Exchange Server Static domain Controller ayarları bize ne kazandırır yada ne kaybettirir, şimdi bunları konuşuyoruz.

Exchange Server ve Microsoft Active Directory Dizin hizmeti iki farklı amaca hizmet eden ve bir-birlerinden bağımsız çalışan sistemler olsa bile bir-birlerine göbekten bağlıdır ve ayrı düşünülemez.

İkişkileri o kadar derin ve o kadar sıkı ki Exchange server her 15 Dakika da bir Active directory dizin hizmetini ve içinde bulunan domain Controller sunucularını kontrol eder, sağlıklımı yada değil mi onaylamak ister ve güncel bilgileri onlardan talep eder.

Güncellemiş olduğu bilgilere örnek verelim.

Etki alanı içinde yeni bir kullanıcı var mı, bu kullanıcının SMTP adresi oluşturuldu mu, yeni veya mevcut kullanıcı için grup güncelleme işlemleri yapıldı mı, yeni gruplar oluşturuldu mu, bu ve bunun gibi işlemlerin her birisini etki alanı içinden çeker.

Biz bu bilgilere kullanıcı seviyesinde ki bilgiler demekteyiz ve bunun haricinde bir çok bilgiyi de Exchange server günceller.

Organizasyon içinde hangi sunucular var, hangi databaseler var, databaseler ayakta mı ve onlar hizmet veriyor mu, mevcut databaseler DAG üyesi yapıldı mı, süreklilik ayarları yapıldı mı gibi bilgileri de organizasyon seviyesinde günceller.

Exchange Server ‘in en temel görevi e-posta göndermek ve e-posta almak.

Exchange Server üzerinde tanımladığımız Connector bilgileri bile active directory dizin hizmeti içinde saklanır.

Organizasyon içinda hangi connectorler bulunmakta bu connectorleri kullanan exchange sunucuları kimdir ve bu connectorlere bağlanan domainler hangileridir.

Yani Exchange server için aklınıza gelen bütün bilgiler Active Direcotory dizin hizmeti içinde depolanır ve Exchange server lar da bu saklanan bilgilerden beslenir.

Exchange server aslında bir deri bir kemiktir ve Active Directory içinde ki bilgiler de bir elbisedir.

Taş devri döneminde yaşamadığımız için de Active Directory dizin hizmeti Exchange Server için vazgeçilmez bir mimaridir.

Zaten bunu bir çok kez konuşmuş ve Exchange server için temel şartlar bölümünde ilk sıraya yazmıştık.

Şimdi ise biraz daha teknik detaya inelim.

Exchange Server ‘in daha verimli daha optimize edilmiş ve daha sağlıklı çalışması için Active Directory ortamını nasıl optimize edebiliriz, nasıl bir domain yapısı kurabiliriz ve ne yapmalıyız bunları konuşalım.

Exchange Server, kurulmuş olduğu veri merkezi içinde ki Domain Controller sunucularını önceliklik olarak kullanır ve bu Domain Controller sunucularını da in-site etiketi ile olay günlüğüne yazar.

Öncelikli kullanılan Domain Controller sunucuları Exchange Server ‘in barınmış olduğu veri merkezi içinde ki Domain Controller sunucularıdır.

Bunların da nasıl yapılacağını konuşmuştuk bu ayarlar Active Directory site and services ayarları içinde yapılmaktadır ve mail flow mimarisini anlatmış olduğumuz derste bu detayları sizlere aktarmıştık.

Active Directory dizin hizmetinin ince ayarları da Exchange Server ‘dan bağımsız olarak yapılmalıdır ve  Bu ince ayarlar da e-posta sisteminin sağlıklı çalışması için önemlidir.

Çünkü, Exchange Server sadece barınmış olduğu veri merkezi içinde ki Domain Controller sunucularını kontrol etmez.

Kendi veri merkezi içinde ki domain controller sunucularını in-site olarak etiketlerken diğer veri merkezi içinde bulunan domain Controller sunucularını da out-site olarak etiketler ve onları da her 15 dakika da bir denetler ve onlardan da güncel bilgileri talep eder.

Uzak veri merkezi içinde ki Domain Controller sunucularını da out-site Domain Controller etiketi ile olay günlüğüne yazar ve bu sunucuları da kullanır.

Mevcut bu topoloji bizlere ne kaybettirir şimdi bunları konuşalım.

Exchange Server ‘in Active Directory içinde bulunan her domain Controller sunucusunu denetlediğini görebilmektesiniz.

Bu domain Controller sunucuları in-site olsa da out-site olsa da bu kural değişmez.

Exchange Server, Domain içinde bulunan bütün domain controller sunucuları ile Her 15 dakika da bir iletişim kurmakta ve bu çalışma şekli de az da olsa ağ üzerinde kaynak tüketmektedir.

Tüketmiş olduğu ağ kaynağından çok daha fazlasını da kendi üzerinde ki kaynaklar üzerinde tüketir ve bu kullanım sırasında Exchange Server verimliliği de düşebilir.

Bu sebepten ötürü Exchange Server üzerinde Static Domain Controller ayarları yapılmalıdır.

Active directory Dizin hizmeti zaten kendi için de her 15 dakika da bir replicasyon yapmakta ve dizin hizmeti içinde bulunan sunucular da kendilerini güncellemektedir.

Domain Controller sunucuları kendi aralarında güncellendikten sonra bizler de zaten static domain Controller ayarını yaptıysak Exchange server diğer Domain Controller sunucularına gitmeden aynı güncel bilgilere sahip olacaktır.

Exchange Server Static Domain Controller ayarlarını Exchange Server optmizasyon çalışmalarında yapmakta ve Exchange Server ‘in daha verimli çalışması için bu ince ayarları yapmaktayız.

Başka kullanım amaçları da vardır ve şimdi bunları konuşalım.

Biliyorsunuz her bir veri merkezi içinde tırnak içinde bu veri merkezleri Active Directory Jargonun da Site and Services olarak isimlendirilir ve her bir site içinde de en az bir adet domain Controller sunucusu olmalıdır.

En az bir adet olup en çok da veri merkezinin ihtiyaçlarına göre birden fazla Domain Controller sunucusu olabilir.

Bir problem var ve DC ‘ler arasında eşitsizlik bulunmakta.

Ölü domain Controller olabilir, kendini güncellemeyen Domain Controller olabilir, Replicasyon partnerini kaybetmiş bir domain Controller olabilir, bir bakım çalışması olabilir yada Domain Controller üzerinde güncelleme olabilir.

Bir çok nedeni olabilir ama sonuç olarak hatalı ve güncel olmayan bir Domain Controller sunucumuz var.

Biz bu problemi çözmeliyiz, çözmeliyiz ama Exchange Server ‘da her 15 dakika da bir Domain Controller sunucularını denetlemeye devam ediyor.

Problem çözümü için bize yeterli süreyi vermiyor.

İşte bu gibi durumlarda sazı elimize almalı ve Exchange Server ‘in bu problemli durumda kullanması gerektiği domain controller sunucularını static domain controller olarak işaretlemeliyiz.

Biz buna trobulshoting adımları demekteyiz.

Mevcut problem Exchange Server ‘dan bağımsız olsa da Exchange Server ‘in çalışmasına etki eden Active Directory problemidir.

Ilk Başta konuşmuş olduğumuz başlıkları hatırlayalım.

Kullanıcı bilgileri, sunucu bilgileri, domain bilgileri, süreklilik bilgileri ve çok daha fazlası etki alanı içinde depolanmakta ve exchange server da bunları kullanmakta.

Işte bu mimari gereği, exchange server da bir problem olmasa bile exchange server, etki alanı problemlerinden etkilenmektedir.

Problem zamanlarında, Sorun giderme anında Exchange server ‘in kullanacak olduğu Domain Controller sunucularını sınırlamak, static domain controller işlemini yapmak bizlere hızlı bir çözüm sağlayacaktır.

Exchange Server üzerinde Static Domain Kaydını girip, problemli Domain Controller ile Exchange Server ‘in bağlantısını kesip, Exchange Server ‘in diğer Domain Controller sunucularını kullanmasını sağlayabiliriz.

Static domain Controller işlemini yaptıktan sonra da Exchange Server problemi li domain controller sunucularına gitmeyecek, onlardan güncelleme istemeyecek ve bizler de bu işlemlerden sonra problemli Domain Controller sunucusu üzerinde düzeltme, onarma işlemlerimizi yapabileceğiz.

Lokal anestezi gibi.

Uyanığız, bütün uzullarımızı hissediyoruz ama doktor problemli bölgeyi uyuşturmuş ve bizler hiç bir şeyin farkında olmadan tedavi olmaktayız.

Bu işlemleri de Static domain Controller komutları ile yapmaktayız.

Static domain Controller komutlarını Exchange Server üzerinde optimizasyon ve verimlilik çalışması için kalıcı olarak kullandığımız gibi problemli zamanlar da geçici çözüm olarak da kullanabiliriz.

Bu işlem geçici süreli kullanıldığı zaman bu işlemlerin kitapta ki ismi Domain Controller Exculude etme işlemleridir.

Kalıcı olarak kullanıldığı zaman da optimizasyon işlemi olarak adlandırılır.

Başka topolojiler de başka kullanım senaryolarıda bulunmakta.

Daha önce paylaşmış olduğumuz dersler de Exchange Server DMZ bölgesi ayarlarını konuşmuş ve o çalışmamızda Static Domain Controller ayarlarının mutlaka yapılması gerektiğini belirtmiştik.

Eğer, Exchange Server DMZ network içinde çalıştırılacaksa arındırılmış network içinde mutlaka Domain Controller olmalı, bu domain Controller sunucuları da sadece Exchange server ‘a hizmet etmeli ve bu süreç de Static Domain Controller ayarlarının mutlaka yapılmış olması gerekmektedir.

Static domain Controller komutları DMZ bölgesi için yapıldığı zaman da ayrılmış domain controller olarak isimlendirilir.

Bir sonraki derste görüşmek üzere.