Exchange Server 2016, 2016 Standart Edition ve Enterprise Edition olmak üzere iki farklı sürüme sahip durumdadır ve her iki sürüm Database Availability Groups teknolojisini desteklemektedir. Fakat sürümler arasındaki farkı incelediğiniz zaman veri tabanı seviyesinde sınırlamalar bulunmaktadır.

• Exchange Server 2016 Standart Edition 5 Adet,
• Exchange Server 2016 Enterprise 100 Adet,

Veri tabanına ev sahipliği yapabilmektedir.
Büyük kurumlar genellikle Enterprise sürümü tercih etmekteler ve bu sınırlamalar ile çok fazla kafa yormuyorlar. Fakat kurumumuz Enterprise sürümünün sahip olduğu maliyetleri ödeyecek güce sahip değilse 5 adet Database sınırlandırması ile Exchange Server tasarımını yapmak zorunda kalmaktadır.

Bu makale içinde

• Exchange Server Varsayılan Veritabanının Yapılandırılması (Move-DatabasePath)
• Exchange 2016 Veritabanı Kopyalaması (Add-MailboxDatabaseCopy)
• Exchange 2016 Yeni Veritabanı Oluşturulması (New-MailboxDatabase)

Exchange Server Varsayılan Veritabanının Yapılandırılması (Move-DatabasePath)

Exchange server mimarisi Exchange 2016 sürümü ile birlikte değişmiş ve artık tek bir Rol olarak hizmet vermektedir. Organizasyon içine Exchange server 2016 kurulumunu gerçekleştirdikten sonra kurulumunu gerçekleştirmiş olduğumuz Exchange Server 2016, varsayılan değerlerde bir adet Database sahip durumda. Enterprise sürümüne sahip kurumlar için önemli değil ama Standart sürüme sahip kurumlar için sunucu başı 5 adet database sınırlaması varsayılan olarak gelen Database’ i kullanmaya, kurumun kullanımı için hazırlamaya ve üzerinde birtakım yapılandırmalar yapmayı zorunlu duruma getirmektedir.

Çünkü birçok kurum için 5 adet Database sayısı yeterli gelmemekte ve Enterprise sürümü içinde bütçe ayıramamaktadırlar.

Organizasyonumuz içinde iki adet Exchange 2016 Server bulunmakta ve Get-MailboxDatabase -Status komutunu çalıştırdığımız zaman veri tabanı seviyesinde bilgilere ulaşabilmekteyiz.

Get-MailboxDatabase -Status | select admindisplayname,MasterServerOrAvailabilityGroup,AllDatabaseCopies
Yukarıda paylaşmış olduğum Exchange Powershell komutu ile kurulum sonrası oluşan veritabanları, kurulum ile birlikte atanan varsayılan isimlerini görebilirsiniz.

Get-MailboxDatabase -Identity “Mailbox Database 1680252513” | Set-MailboxDatabase -Name “Database01”

Get-MailboxDatabase -Identity “Mailbox Database 0884819349” | Set-MailboxDatabase -Name “Database02”

Yukarıda paylaşmış olduğum iki powershell komutu ile varsayılan değerlerde gelen isimleri kurumumun isim politikasını göre değiştirebilmekteyim.

Kurulum sonrası otomatik atanan Mailbox Database 1680252513 isimli veri tabanının Admindisplayname bilgisini Database01 olarak değiştirdim.

Get-MailboxDatabase -Status | select edbfilepath,logfolderpath,admindisplayname,MasterServerOrAvailabilityGroup, AlldatabaseCopies | Format-list

Yukarıda paylaşmış olduğum powershell komutunu kullanıp, Exchange Server 2016 veri tabanlarının barınmış oldukları dizinleri, *.edb file path ve *.log folder path dizinlerini görebilmekteyiz. AdminDisplayName ismini bir önceki komut ile değiştirmiştik.

Exchange Server Veri Depolama Tasarımı makalesinde bahsetmiştik. Exchange Server 2016 kurulumunu varsayılan dizin üzerine kurduğunuz zaman Exchange Server Veri tabanları kurulumunu yapmış olduğunuz dizin üzerinde barınmaktadır.

Edbfile Path ve LogFolderPath dosyalarının aynı veri havuzu üzerinde c:\ dizini altında olduğunu görebilmektesiniz.

Move-DatabasePath “Database01” -EdbFilePath “S:\DatabaseEDBFile\Database01.edb” -LogFolderPath “E:\DatabaseLogFolder\Database01”

Yukarıda paylaşmış olduğum powershell komutunu kullanıp varsayılan dizin içinde barınan *.edb file path ve *.log Folder Path dizinlerini değiştirebilmektesiniz.

Komutu çalıştırdıktan sonra ilk işlem olarak Exchange Database’ sinin Log dosyalarının belirtmiş olduğumuz dizine kopyalandığını görebileceksiniz.

Paylaşmış olduğum komut içinde E:\DatabaseLogFolder\Database01 yoluna taşımayı gerçekleştirecektir.

Kopyalama işlemi yeni dizine gerçekleştirildikten sonra eski dizin içinde bulunan log files dosyaları otomatik olarak silinecektir.

Log dosyalarının taşıma işlemi tamamlandıktan sonra *.edb dosyası yani veri tabanının dosyası taşınmaya başlanacaktır. Bu işlem gerçekleştirilirken veri tabanı dismount olacak yani bu veri tabanı içinde bulunan hiçbir posta kutusu çalışmayacaktır. Bu işlem tamamlanana kadar bu veri tabanı seviyesinde hizmet kesintisi gerçekleşmiş olacaktır.

Exchange Veritabanının taşınmış olduğu diniz S:\DatabaseEDBFile\ yoludur ve dikkat ederseniz komut içinde Database01.edb olarak yeni bir *.edb dosyasının oluşturulduğunu göreceksiniz. Bu şu demek oluyor eski edb veri tabanı olduğu gibi 1:1 kopyalanmıyor, edb veri tabanı içinde bulunan nesneler, posta kutuları yeni oluşturulan *.edb dosyası içine 1:1 taşınıyor.

Ve böylelikle, admin display name ile birlikte veri tabanının ham verisini de taşımış oluyoruz.

Bir önceki makalemiz içinde paylaşmış olduğumuz dizaynı yukarıda görebilmektesiniz. Bu işlemlerden sonra Exchange Server Veri Tabanının dosyaları Windows kurulum dizininden tamamen ayrılmış oldular. Circular logging özelliğini kullanmıyoruz ve veri tabanımız *.log verilerine sahip durumda. *.log verileri ile *.edb verileri farklı performans gereksinimleri bulunmaktadır. Bu sebepten ötürü *.log verilerini daha performanslı veri havuzu olan Red Array disk kümesi altında barındırdım.

Yapılan değişikliklerden sonra Get-MailboxDatabase -Status komutu ile kontrolleri gerçekleştiriyorum.

Yapmış olduğum bu çalışmadan sonra Exchange Server 2016 üzerinde varsayılan olarak gelen veri tabanlarının Admin Display Name (görünen ismini), *.Edb file Path ve *.Log folder Path dizinlerini değiştirmiş bulunuyor.

Exchange 2016 Veritabanı Kopyalaması (Add-MailboxDatabaseCopy)

Exchange Server 2016 DAG Kurulumu ve IP-Less Dag ile Karşılaştırma makalesi içinde Dag kurulumunu gerçekleştirmiştik. Bu bölüme kadar olan bölümlerde ise Exchange 2016 kurulumu ile birlikte gelen versayılan very tabanlarının dizinlerini değiştirdik ve veri tabanlarımız için belirlemiş olduğumuz veri depolama havuzu üzerinde barınmasını sağladık.

Add-MailboxDatabaseCopy -Identity Database01 -MailboxServer EXCHANGE02 -ActivationPreference 2

Yukarıdaki komut ile Exchange01 üzerinde bulunan Exchange veritabanımızın bir kopyasını Dag kümesi içinde bulunan Exchange02 sunucumuzun üzerine kopyaladım. Aynı komutu Database02 içinde gerçekleştirdim ve Database02’ nin bir kopyasını Exchange02 isimli sunucumdan Exchange01 isimli sunucuma kopyaladım.

Get-MailboxDatabase | select Name, edbFilePath, LogFolderPath, AllDatabaseCopies, MasterServerOrAvailabilityGroup
Exchange2016 kurulumu ile birlikte gelen varsayılan veri tabanlarını organizasyonum içinde bulunan iki Exchange sunucum üzerine kopyalamış oldum. Veri tabanının barınmış olduğu Master server üzerinde yaşanacak olan herhangi bir kesinti durumunda Dag kümesi olan diğer sunucu üzerinde çalışabilmesi için yapılandırmış oldum.

DAg kümesi içinde bulunan Exchange sunucularının veri tabanlarının Database Copies özelliği ile yapılandırmadan önce veri tabanlarının barınmış olduğu veri depolama havuzlarının aynı harf yolu ile yapılandırılmış olduğundan emin olmalısınız. Dizinler aynı harf yolu ile yapılandırılmadığı zaman komutlar hata verecektir.

Dag kümesi içinde bulunan Exchange sunucuları üzerinde barınan veri tabanları, sunucular arasında eşitlendikten sonra Master sunucu üzerinde yaşanılacak herhangi bir plansız kesintide, diğer sunucu üzerinden kesinti yaşanmaksızın hizmet etmek üzere yapılandırmış olduk.

Exchange Management Shell üzerinde DAG kümesi içinde bulunan Exchange sunucuları arasında kopyalamış olduğumuz Exchange veri tabanlarını görsel arayüze sahip Exchange Control Panel içinden de yapabilmekteyiz.

ECP üzerinde servers\databases bölümüne erişim sağlayıp Database Copy olarak yapılandıracak olduğumuz veri tabanlarını seçiyoruz ve … nokta yardımı ile Add Database Copy sihirbazını çalıştırıyoruz. 

çalıştırmış olduğumuz sihirbazımız add mailbox database copy penceresini bizlere açacaktır. bu pencere içinde Specify Mailbox server bölümünden veri tabanının kopyalanacak olduğu Exchange sunucumuzu seçiyoruz. Activation Preference Number değerini 2 olarak işaretledim. Powershell komutlarında bu değeri 2 olarak belirttiğimi fark edeceksiniz.

Activation Preference Number nedir?

Database Availability Groups Tasarım Seçenekleri makalesi içinde detaylı olarak anlatmış ve farklı tasarımları paylaşmıştık. Aynı organizasyon içinde birden fazla Exchange sunucumuz bulunabilir ve sahip olduğumuz Exchange veri tabanını organizasyonumuz içinde bulunan bütün Exchange Mailbox sunucuları üzerinde çoğaltabiliriz.

Sadece bir tanesinde aktif olarak hizmet ederken diğer belirlemiş olduğumuz Exchange sunucuları üzerinde pasif durumda ve sürekli olarak eşitlenecek ve bir problem durumunda eşitlenmiş olduğu Exchange sunucusu üzerinde aktif olmak üzere planı gerçekleştirebiliriz.

Exchange Veri tabanını, DAG kümesi içinde birden fazla sunucuya eşitlediğimiz zaman problem anında hangi Exchange sunucusu üzerinde öncelikli olarak çalıştırılacağını belirliyoruz.

Database3 isimli veri tabanımız için örnek senaryo üretelim,

• Exchange01 sunucumuz üzerinde Active kopyası bulunmakta.
• Exchange02 sunucumuz üzerinde pasif kopyası bulunmakta ve Activation Preference Number değeri 2
• Exchange03 sunucumuz üzerinde pasif kopyası bulunmakta ve Activation Preference Number değeri 3

Exchange01 isimli sunucumuz üzerinde bir problem olduğunda DAG mimarisi nasıl davranacak? cevap basit, APN değeri en düşük olan Exchange sunucusu üzerinde veri tabanını çalıştıracak.

Powershell komutlarında bahsetmediğim Replay Lag time (time) değerini görebilmektesiniz. Bu değer, Exchange veri tabanının Aktif sunucu üzerinden Pasif sunucu üzerine eşitlenen Log dosyalarının ne kadar zaman sonra veri tabanına yazılacağını gösteren değerdir. Varsayılan olarak bu değer sıfırdır yani, sürekli olarak eşitler. 

TruncationLag Time Nedir?

Bu değer ECP üzerinde yapmış olduğumuz yapılandırma içinde görülmemektedir. Pasif veri tabanı içindeki *.log ların ne kadar zaman içinde silineceğini belirleyen parametredir. Bu konu ile birlikte yedekleme konusuna ışık yakmaktayız ve detaylandıracağız.

Bildiğiniz gibi her yedekleme görevi sonrasında Exchange Transaction Log’ ları otomatik olarak temizlenir. Aktif kopyadan yedek aldığınız zaman pasif kopya üzerinden yedekte alabilmekteyiz, fakat bu özellik çok özel durumlarda kullanılır. TruncationLag Time parametresi ise Aktif veri tabanı üzerinde yedek aldığımız zaman pasif veri tabanındaki loğların ne zaman silineceğini belirlemiş olduğumuz parametredir. Bu süre Exchange 2013 ve Exchange 2016 için en fazla 14 gün olabilir.

Get-MailboxDatabase -Status | select admindisplayname,ReplayLagTimes, TruncationLagTimes | Format-list

Yukarıda paylaşmış olduğum komut ile DAG mimarisi içinde bulunan veri tabanlarının ReplayLagTimes ve TruncationLagTimes sürelerini görebilirsiniz.

Set-MailboxDatabaseCopy -Identity Database01\EXCHANGE01 -ReplayLagTime 1.0:0:0 -TruncationLagTime 1.0:0:0 -ActivationPreference 2

Yukarıda paylaşmış olduğum komut ile Exchange01 üzerinde bulunan Database01 için ReplayLagtime ve TruncationLagTime sürelerini 1 gün olarak değiştirdim.

WARNING: The sum of ‘ReplayLagTime’ and ‘ReplayLagMaxDelay’ should not be higher than ‘SafetyNetHoldTime’ in
the Transport service as that can cause irrecoverable data loss. Please ensure that these parameters are set
such that their sum is equal or lower than the ‘SafetyNetHoldTime’ parameter, which is set using the
Set-TransportConfig cmdlet

Safety Net Hold Time Nedir?

Bu bölüm içinde bahsedecek olduğumuz Safty Net süresi bire-bir Exchange Dag mimarisi ile ilgili değildir. Fakat Exchange 2016 ile birlikte bütün Exchange Server Rolleri tek bir sunucu üzerinde birleştirildiği için bu terimden bahsetmeden DAG mimarisini Exchange 2016 ile birlikte gelişimini ve Aktif veri tabanından pasif veri tabanına giden maillerin güvenli bir şekilde iletildiğini bilmek biraz zor.

Dikkat ettiyseniz çalıştırmış olduğum komut çıktısının uyarı ile sonuçlandığını görebilmektesiniz. Bunun nedeni Exchange 2016 ile birlikte gelişim gösteren Safety Net değeridir. Varsayılan olarak bu değer iki gündür ve bizler çalıştırmış olduğumuz komut içinde iki günden daha az olan süreyi belirttiğimiz için işlem uyarı ile tamamlandı.

Safety Net yapılandırılması veri kayıplarının önüne geçilmesi için belirlenmiş bir değerdir. Aktif veri tabanından pasif veri tabanına, veriler kopyalanırken oluşabilecek problemlerin önüne geçmek için tasarlanmıştır ve yoğun mail trafik sonrası oluşabilecek kuyruk problemleri gibi nedenler için Exchange 2016 ile birlikte gelişim göstermiş yeni bir terimdir.

Bu değer sayesinde Aktif veri tabanından pasif veri tabanına verilerin bütünlüğü bozulmadan gittiğinden emin olana kadar kuyrukta bekleyen mailler saklanmaktadır.

Dag mimarisi ile tanışmış olduğumuz Exchange 2010 mimarisi içinde Shadow Redundancy, Transport Dumpster, Delayed Acknowledgement özellikleri kullanılmaktaydı. Exchange 2013 ile birlikte Safety Net. terimi geldi ve bu terim Transport Dumpster’in yerini aldı. Safety Net yapılandırması Transport Dumpster’ dan farklı olarak geri bildirim tekniği ile çalışmamaktadır.

Artık her bir Exchange Veri tabanının kendisine ait bir Safety Net kuyruğu bulunmaktadır. Bunun anlamı, DAG üyesi olmayan her bir sunucunun Safety Net değeri bulunmamaktadır.

Safety net değeri Organization Transport Settings bölümünde görülmekte ve değiştirilmektedir. Bu bölüm içinde yapacak olduğunuz değişiklik organizasyon içinde bulunan bütün sunucular için geçerli olacaktır.

Exchange Control panel üzerinde mail flow\ receive connectors bölümüne geldiğiniz zaman üç nokta yardımıyla Organization Transport Settings bölümüne ulaşacaksınız ve bu değeri değiştirebileceksiniz.

Get-TransportConfig | select SafetyNetHoldTime, ShadowMessageAutoDiscardInterval

Exchange Control panel üzerinde bu kadar yolu gitmek yerine yukarıda paylaşmış olduğum komut ile mevcut değerleri öğrenebilirsiniz.

Set-TransportConfig -ShadowMessageAutoDiscardInterval 1.00:00:00

Yukarıda paylaşmış olduğum değer ile mevcut değerleri değiştirebilirsiniz. Paylaşmış olduğum komut içinde değer bir gün olarak değiştirilmiştir.

Exchange Server Veri Depolama Tasarımı

Bu veri tabanının bulunmuş olduğu yer varsayılan olarak %ExchangeInstallPath%TransportRoles\data\Queue dizinidir ve yoğun mail trafiğinin olduğu kurumlarda bu dizini değiştirmeyi önermekteyiz.

Powershell komutları ile oluşturmuş olduğumuz veri tabanlarını ve Dag kümesi içinde ekledikten sonra ki Copy durumlarını ECP üzerinden görebilmekteyiz. 

Bir veri tabanını ilk defa DAG üyesi içine dahil ettiğimiz zaman, ilk eşitleme sonrasında ECP üzerinde content index state failedAndSuspended hatasını alabilirsiniz. Bu hatanın bir çok nedeni olabildiği gibi farklı çözümleri de bulunmaktadır. Fakat ilk yapılandırma sonrasında bu hatayı almanız çok normaldir ki ilk eşitleme sırasında verinin bütünlüğü, veri tabanı dosyası ve log dosyalarını bire-bir eşitlenmediği için bu hatayı alabiliyorsunuz. Nedeni basit, Dag mimarisi Aktif pasif çalışmakta ve Aktif veri tabanı sunucusu üzerinde oluşabilecek bir hataya karşı pasif veri tabanı hazır beklemekte. Bu hatanın nedeni ise pasif veri tabanı aktif veri tabanından verileri henüz bire-bir alamadığı için hazır durumda değil.

Ne mi yapıyoruz? Elbette ki eşitleme için biraz bekliyoruz. Bu bekleme süresi veri tabanımızın büyüklüğüne bağlı olarak değişmektedir.

Get–MailboxDatabaseCopyStatus * | ft –auto

Yukarıda paylaşmış olduğum komut ile DAG kümesi içinde bulunan bütün veri tabanlarının Database Copy Status larını görebilirsiniz.

Exchange 2016 Yeni Veritabanı Oluşturulması (New-MailboxDatabase)

Exchange Management Shell’ in sağlamış olduğu avantajları gördükten sonra Exchange Control Panel üzerinden işlem yapmayı çok fazla tercih etmiyorum. Ama yukarıdaki ekran görüntüsünü paylaştım ki biraz sonra Powershell komutları ile oluşturacak olduğum Exchange Database ‘lerini ECP üzerinde Servers bölümü altında Database satırına ulaşarak da oluşturabilirsiniz.

ECP üzerinde yeni bir veri tabanı oluşturmak istediğimizde edb file dosyasının ve log dosyaları için var sayılan kurulum dizini göstermektedir. ECP üzerinden işlem yapmamamdaki diğer bir nedense budur. ECP üzerinde veri tabanı oluşturma işlemlerinde Database file path ve Log Folder Path yollarını el-ile değiştirmemiz gerekmektedir. Bu varsayılan dizinlerin C:\Program Files…. yolunun gelme nedeni Exchange Server 2016 CU5 Kurulumu makalesinde yapmış olduğumuz adımlardan kaynaklıdır. Bu bölümde kurulum dizinini varsayılan path olarak bırakmıştık.

New-MailboxDatabase -server Exchange01 -Name “Database03” -EdbFilePath S:\DatabaseEDBFile\Database05.edb -LogFolderpath E:\DatabaseLogFolder\Database03

kullanmış olduğum Exchange Management Shell üzerindeki Powershell komutları yukarıdadır. Komut satısının açıklaması;

• Exchange01 isimli sunucum üzerinde Database03 isminde veri tabanı oluşturmasını
• Veri tabanı *.edb dosyasının S:\DatabaseEDBFile dizini altında barınmasını ve veri tabanı dosya isminin Database05.edb olmasını
• Veri tabanı *log dosyalarının E:\DatabaseLogFolder\Database03 dizini altında olmasını istiyorum.

Dikkat ettiyseniz bütün veri tabanlarımı Exchange01 isimli sunucum üzerinde oluşturdum ve bu komut ile oluşturmuş olduğum veri tabanları için Replication Type bölümünde None yazmaktadır. Exchange 2016 Veritabanı Kopyalaması (Add-MailboxDatabaseCopy) bölümündeki adımları bu yeni veri tabanlarım için gerçekleştirdiğim zaman bu yeni veri tabanlarımı DAG kümesi içinde bulunan sunucularım arasında eşitlemiş olacağım. Veri tabanlarımın her birisini Exchange01 üzerinde açmış olmamın bir önemi bulunmamaktadır.

Exchange 2016 sürümlerinin desteklemiş olduğu Database sayılarını Database Availability Groups (DAG) Gereksinimleri ve Hazırlıkları makalesi içinde anlatmıştık. Exchange Server 2016 Standart sürümü 5 adet veri tabanını eş-zamanlı çalıştırabilmektedir. daha fazla veri tabanını Standart sürüm üzerinde oluşturabiliriz ama Mount durumda bulunan 5 adet veri tabanı varsa ve mount etmek istersek bizlere aşağıdaki hataya benzer bir hata verecektir.

Failed to mount database “Database06”. Error: An Active Manager operation failed. Error: The database action
failed. Error: Operation failed with message: MapiExceptionTooManyMountedDatabases: Unable to mount database.
(hr=0x8004060e, ec=-2147219954)
Diagnostic context:

Bu hatanın bir benzerini Enterprise sürüme sahip ama Lisans aktivasyon işlemi gerçekleştirilmemiş Exchange Serverlar içinde geçerlidir. Lisans aktivasyon işlemi gerçekleştirilmemiş Exchange sunucuları ürün anahtarı girilene kadar Standart sürüm olarak hizmet edeceklerdir.