Exchange Server SE'de IP-less DAG Kurulumu ve PowerShell ile Database Availability Group Yapılandırması

Exchange Server SubScription Edition (SE), Microsoft'un On-Premises Exchange platformunun 1 Temmuz 2025 tarihinde Generally Available (GA) olarak yayınlanan ve Modern Lifecycle Policy ile yönetilen Evergreen sürümüdür. RTM Build'i, Exchange Server 2019 CU15 ile kod düzeyinde eşdeğerdir. Bu nedenle yüksek erişilebilirlik mimarisi ve Database Availability Group (DAG) davranışı, Exchange Server 2016 ve Exchange Server 2019 ile birebir aynı çalışır.

Bu makalede, iki Mailbox Server üzerinde PowerShell kullanarak uçtan uca bir DAG kurulumunu adım adım yapılandırıyor olacağız. Kurulum boyunca Exchange Management Shell (EMS) yerine Windows PowerShell ISE tercih ettim. Bunun nedeni, çok adımlı ve Script tabanlı bir süreç olan DAG kurulumunda birden fazla cmdlet'i tek bir .ps1 dosyası içinde sıralı biçimde çalıştırmanın ve yönetmenin ISE ortamında çok daha pratik olmasıdır.

Database Availability Group, Exchange'in Native High Availability (yüksek erişilebilirlik) ve Site Resilience modelidir. Arka planda Windows Server Failover Clustering altyapısını kullanır, ancak Cluster'ı doğrudan Failover Cluster Manager üzerinden değil, Exchange cmdlet'leri üzerinden yönetirsiniz. Bir DAG en fazla 16 Mailbox Server'ı bir araya getirir ve aynı Mailbox Database'in farklı Server'lar üzerinde tutulan kopyaları arasında Continuous Replication çalıştırır. Aktif kopyada oluşan Transaction Log'lar, pasif kopyalara aktarılır ve Replay edilir. Böylece bir Server veya Disk arızasında Mailbox Database (veritabanı), otomatik olarak sağlıklı bir kopya üzerinde Mount edilir.

Çift sayıda üyeye sahip bir DAG'da Cluster'ın Quorum'unu koruyabilmesi için bir Witness Server gereklidir. Witness Server üzerinde Exchange tarafından otomatik oluşturulan File Share Witness, Quorum oylamasında belirleyici üçüncü oyu sağlar. Bu sayede iki üyeli bir DAG'da bir Server çevrimdışı kaldığında, ayakta kalan tek Server File Share Witness oyu ile birlikte Quorum çoğunluğunu korur ve Cluster, çalışır halde kalır. Bu kurulumda DAG, iki Mailbox Server ve bir Witness Server'dan oluşan klasik bir iki üyeli topolojiyi temel alır.

Ön Koşullar ve Lisanslama

DAG, arka planda hem Windows Server Failover Clustering altyapısına hem de Active Directory'ye dayanır. Bu nedenle ön koşullar; işletim sistemi Feature'larından Active Directory topolojisine ve Exchange Edition seviyesine kadar birden fazla katmanı kapsar. Aşağıdaki tablo, kuruluma başlamadan önce karşılanması gereken temel gereksinimleri özetler.

1- Failover Clustering Servisinin Kurulması

DAG, arka planda Windows Server Failover Clustering altyapısını kullandığı için ilk adım, her iki Mailbox Server üzerinde Failover Clustering Feature'ının kurulmasıdır. İlk olarak Add-PSSnapin *exc* komutuyla o andaki PowerShell Session'da (oturumda) Exchange snap-in eklenmesini, yani Exchange cmdlet'lerinin Session'a yüklenmesini sağlıyorum. Bu kurulumda birden çok cmdlet'i (komutu) art arda çalıştıracağım için, hepsini tek bir Session içinde kesintisiz yürütmenin bana sağladığı kolaylık nedeniyle bu yöntemi tercih ettim.

Ardından Invoke-Command komutu ile her iki Server üzerinde Failover Clustering Feature'ının durumu uzaktan sorguluyorum. Sorgu sonucunda Failover Clustering servisinin her iki Server üzerinde henüz kurulmadığı, InstallState değerinin "Available" olduğu görülür.

Add-PSSnapin *exc*

# 1- Installing Failover-Clustering Services

Invoke-Command -ComputerName TRISTSRVEXC01,TRISTSRVEXC02 -ScriptBlock {
    Get-WindowsFeature -Name Failover-Clustering
} | Select-Object PSComputerName, Name, DisplayName, InstallState | Format-Table -AutoSize

Feature'ın "Available" durumda olduğu doğrulandıktan sonra, Install-WindowsFeature cmdlet'i ile Failover Clustering ve yönetim araçları kurulur. Kurulum önce TRISTSRVEXC01 Server'ı üzerinde başlatılır ve ilerlemesi izlenir.
Aynı işlem TRISTSRVEXC02 Server'ı üzerinde tekrarlanır.

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools -ComputerName TRISTSRVEXC01

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools -ComputerName TRISTSRVEXC02

Kurulum tamamlandıktan sonra Feature durumu yeniden sorgulandığında, her iki Server üzerinde InstallState değerinin "Installed" olduğu doğrulanır.

Her iki Server Restart-Computer cmdlet'i ile yeniden başlatılır. Yeniden başlatma sırasında Server'ların erişilebilirliği sürekli ping ile izlenir. Request timed out satırları yeniden başlatma anına denk gelir, ardından yanıtların geri dönmesi Server'ın tekrar ayağa kalktığını gösterir.

Restart-Computer -ComputerName TRISTSRVEXC01 -Force

Restart-Computer -ComputerName TRISTSRVEXC02 -Force

2- IP-less DAG Oluşturulması

DAG oluşturulmadan önce dikkat edilmesi gereken kritik nokta, Exchange'in Witness Server üzerinde Witness dizinini ve paylaşımını yönetebilmesi için yeterli izne sahip olmasıdır. Microsoft'un belgelediği standart yöntem, Witness Server bir Exchange Server değilse Exchange Trusted Subsystem Universal Security Group'unu Witness Server'ın Local Administrators grubuna eklemektir. Bu üyelik, Exchange'in Witness dizinini ve paylaşımını kendisinin oluşturup güvenli hale getirebilmesi içindir.

Bu tek yol değildir. Witness dizinini ve paylaşımını önceden kendiniz oluşturup üzerinde Exchange Trusted Subsystem grubuna Full Control verirseniz, Exchange'in yeni bir dizin ve paylaşım oluşturmasına gerek kalmaz. Bu kurulumda Local Administrators üyeliği değiştirilmemiş, bunun yerine C:\EXC-DAG-WITNESS dizini ve paylaşımı önceden oluşturulup Exchange Trusted Subsystem grubuna hem NTFS hem de Share seviyesinde Full Control verilmiştir. Yapılan kontrolde bu izinlerin yerinde olduğu görülür ve DAG, bu sayede Local Administrators üyeliği eklenmeden başarıyla oluşturulmuştur.

İzinler doğrulandıktan sonra DAG, New-DatabaseAvailabilityGroup cmdlet'i ile oluşturulur. Bu kurulumda DAG, IP-less olarak yapılandırılmıştır. Windows Server 2012 R2 ve sonraki sürümlerde, DatabaseAvailabilityGroupIpAddresses parametresi belirtilmediğinde DAG varsayılan olarak Administrative Access Point olmadan oluşturulur. Bu nedenle komutta herhangi bir IP adresi belirtilmemesi, DAG'ın IP-less yapıda kurulduğu anlamına gelir. Oluşturma anında Member Servers değeri henüz boştur.

DAG oluşturulduktan hemen sonra Get-DatabaseAvailabilityGroup cmdlet'i ile durumu sorgulandığında, DAG'ın oluşturulduğu ancak henüz hiçbir üye Server içermediği görülür. WitnessShareInUse değeri de henüz boştur, çünkü Witness ancak DAG'a üyeler eklendiğinde devreye girer.
File Share Witness devreye alındığında, önceden oluşturulmuş Witness dizini altında DAG'a özel ve GUID adıyla bir alt klasör belirir. Bu klasörün içinde VerifyShareWriteAccess.txt ile Witness.log dosyaları yer alır.

# 2- Creating a new IPLESS DAG

New-DatabaseAvailabilityGroup -Name DAG-2552026 -WitnessServer TRISTSRVSYN01.ABC.LOCAL -WitnessDirectory C:\EXC-DAG-WITNESS

Get-DatabaseAvailabilityGroup -Identity DAG-2552026 -Status | FT Name, Witness*, Servers, Primaryactivemanager -Autosize

3- Exchange Server'ların DAG'a Üye Yapılması

DAG kabuğu oluşturulduktan sonra sıra, Mailbox Server'ları DAG'a üye yapmaya gelir. İlk üye TRISTSRVEXC01, Add-DatabaseAvailabilityGroupServer cmdlet'i ile eklenir. İlk Server eklenirken "Forming cluster" mesajı görüntülenir ve Windows Failover Cluster bu adımda otomatik olarak kurulur.

İlk Server başarıyla eklendikten sonra Exchange, mevcut tüm Mailbox Database'lerin MasterServerOrAvailabilityGroup özelliğini DAG adıyla günceller. Bu, veritabanlarının artık standalone bir Server'a değil, DAG'a ait olduğu anlamına gelir. Verbose çıktıda, eklenen Server için Information Store servisinin yeniden başlatılması gerektiğini bildiren bir WARNING satırı yer alır.

Information Store servisi, eklenen TRISTSRVEXC01 üzerinde yeniden başlatılır. Servisin durdurulup tekrar başlatılması sırasında bekleme mesajları görüntülenir.
Ardından ikinci Mailbox Server olan TRISTSRVEXC02, aynı cmdlet ile DAG'a eklenir. Bu Server Cluster'a katılırken "Adding server to the cluster" mesajı görüntülenir.
İkinci üye eklendiğinde DAG, çift sayıda üyeye ulaşır. Bu noktada Exchange, Quorum çoğunluğunu koruyabilmek için File Share Witness'ı otomatik olarak devreye alır. Verbose çıktıda, Witness paylaşımının çift sayıda üye için kullanıldığı ve File Share Witness kaynağının oluşturulup online hale getirildiği görülür.
İşlem tamamlandığında TRISTSRVEXC02'nin DAG'a başarıyla eklendiği ve cmdlet'in "Done" mesajıyla sonlandığı görülür.

İkinci Server için de Information Store servisi yeniden başlatılır. Bu kurulumda, TRISTSRVEXC02 üzerindeki servis -ComputerName parametresi kullanılarak uzaktan yeniden başlatılmıştır.
Her iki Server da DAG'a eklendikten sonra DAG durumu yeniden sorgulanır. Bu kez DAG'ın iki üyeye sahip olduğu, WitnessShareInUse değerinin "Primary" olarak göründüğü ve PrimaryActiveManager (PAM) rolünün TRISTSRVEXC01 üzerinde olduğu görülür. Primary Active Manager (PAM), DAG içinde veritabanı aktivasyon kararlarını koordine eden Cluster rolüdür.

# 3- Making Exchange Servers Members Of DAG

Add-DatabaseAvailabilityGroupServer -Identity DAG-2552026 -MailboxServer TRISTSRVEXC01 -Verbose

Get-Service | Where-Object { $_.Name -like "*MSExchangeIS*" } | Restart-Service -Force

Add-DatabaseAvailabilityGroupServer -Identity DAG-2552026 -MailboxServer TRISTSRVEXC02 -Verbose

Get-Service -ComputerName TRISTSRVEXC02 | Where-Object { $_.Name -like "*MSExchangeIS*" } | Restart-Service -Force

4- Veritabanlarının DAG'a Dahil Edilmesi

DAG topolojisi hazır olduğunda sıra, mevcut Mailbox Database'ler için pasif kopyalar oluşturmaya gelir. Bu kurulumda tüm veritabanları başlangıçta yalnızca TRISTSRVEXC01 üzerinde aktif olarak bulunur ve hedef Server olan TRISTSRVEXC02 üzerinde henüz kopyaları yoktur. Bu işlem için önce kaynak Server'da bulunup hedef Server'da kopyası eksik olan veritabanları tespit edilerek bir önizleme listesi üretilir. MissingCopyOn sütunu, her veritabanı için kopyanın hangi Server'da eksik olduğunu gösterir.

Ardından hedef Server'da kopyası eksik olan tüm veritabanları için ActivationPreference değeri 2 olacak şekilde sırayla kopya oluşturulur. Seeding işleminin ilerleyişi sırasında okunan, yazılan ve kalan byte miktarı izlenebilir.
Kopya oluşturma işlemleri ilerledikçe, eklenen yeni veritabanları için Information Store servisinin yeniden başlatılması gerektiğini bildiren WARNING satırları görüntülenir. Bu uyarı bir hata değildir. Servis yeniden başlatılmasa da DAG kurulur, kopyalar oluşur, Seeding tamamlanır ve veritabanları sorunsuz çalışmaya devam eder.

Uyarının nedeni RAM ile ilgilidir. Exchange'in veritabanı motoru ESE, performans için sık erişilen veritabanı sayfalarını RAM üzerindeki bir Database Cache içinde tutar. Sunucudaki kullanılabilir RAM, bu Cache için veritabanları arasında bölüştürülür ve bu bölüştürme hesabı Information Store servisi her başladığında yeniden yapılır. Yeni eklenen bir veritabanı, ancak servis yeniden başlatıldıktan sonra bu bölüştürmeye dahil olur.

Servis yeniden başlatılmazsa yeni veritabanı yine çalışır, fakat ESE Cache için RAM'den alması gereken payı tam olarak almaz. Bu nedenle Restart bir zorunluluk değil, performans için yapılan bir iyileştirmedir. Tek bir veritabanı için etkisi önemsizdir, ancak bu kurulumda 13 veritabanı eklendiği için uygun bir bakım zamanında Information Store servisini yeniden başlatmak yerinde olur.
Son olarak sistem veritabanı MBXSYSDB için de Seeding işlemi tamamlanır.

# 4- Adding Databases into DAG.
$SourceServer = "TRISTSRVEXC01"
$TargetServer = "TRISTSRVEXC02"

Get-MailboxDatabase -Server $SourceServer | ForEach-Object {
    $DB = $_

    $SourceCopy = Get-MailboxDatabaseCopyStatus -Identity "$($DB.Name)\$SourceServer" -ErrorAction SilentlyContinue
    $TargetCopy = Get-MailboxDatabaseCopyStatus -Identity "$($DB.Name)\$TargetServer" -ErrorAction SilentlyContinue

    if ($SourceCopy -and -not $TargetCopy) {
        [PSCustomObject]@{
            Database      = $DB.Name
            SourceServer  = $SourceServer
            SourceStatus  = $SourceCopy.Status
            MissingCopyOn = $TargetServer
        }
    }
} | Format-Table -AutoSize

Get-MailboxDatabase |
Where-Object {
    $_.MasterServerOrAvailabilityGroup -eq "DAG-2552026" -and
    $_.Servers.Name -notcontains "TRISTSRVEXC02"
} |
Add-MailboxDatabaseCopy `
    -MailboxServer TRISTSRVEXC02 `
    -ActivationPreference 2 `
    -Verbose

5- DAG Veritabanlarının Durumunun Kontrol Edilmesi

Tüm kopyalar oluşturulduktan sonra DAG'ın ve veritabanı kopyalarının sağlık durumu doğrulanır. İlk olarak Cluster Node'larının durumu Get-Cluster | Get-ClusterNode komutu ile sorgulanır. Her iki Node'un da "Up" durumda olması, Cluster'ın sağlıklı çalıştığını gösterir.
Ardından her iki Server için Get-MailboxDatabaseCopyStatus cmdlet'i ile veritabanı kopyalarının durumu kontrol edilir. TRISTSRVEXC01 üzerindeki kopyalar aktif kopyalar olduğu için "Mounted" durumdadır.
TRISTSRVEXC02 üzerindeki kopyalar ise pasif kopyalar olduğu için "Healthy" durumdadır. CopyQueueLength ve ReplayQueueLength değerlerinin 0 olması, Replication'ın gecikmesiz çalıştığını gösterir.

# 5- Checking Status of DAG Databases (Mailbox Database Copy Status)

Get-Cluster | Get-ClusterNode

Get-MailboxDatabaseCopyStatus -Server TRISTSRVEXC01 | Sort Name | ft -AutoSize

Get-MailboxDatabaseCopyStatus -Server TRISTSRVEXC02 | Sort Name | ft -AutoSize

6- Replication Sağlığının Test Edilmesi

DAG kurulumunun son doğrulama adımı, Replication sağlığının test edilmesidir. Test-ReplicationHealth cmdlet'i, bir DAG üyesi üzerinde Cluster servisi, Replay servisi, Active Manager, Quorum grubu, File Share Quorum, veritabanı yedekliliği ve veritabanı erişilebilirliği gibi kritik bileşenlerin sağlık durumunu kontrol eder. İlk olarak TRISTSRVEXC01 test edilir ve tüm kontrollerin "Passed" sonucunu verdiği görülür.
Ardından TRISTSRVEXC02 test edilir. Bu Server pasif kopyalar barındırdığı için, kullanıcı veritabanı kopyalarına yönelik DBCopySuspended, DBCopyFailed, DBLogCopyKeepingUp ve DBLogReplayKeepingUp gibi ek kontroller de listede yer alır. Tüm kontroller "Passed" sonucunu verir.

# 6- Testing Replication Health

Test-ReplicationHealth -Identity TRISTSRVEXC01

Test-ReplicationHealth -Identity TRISTSRVEXC02

Get-DatabaseAvailabilityGroup | Select -ExpandProperty Servers | Test-ReplicationHealth | Where { $_.Result -like "Passed" }

Get-DatabaseAvailabilityGroup | Select -ExpandProperty Servers | Test-ReplicationHealth | Where { $_.Result -like "Failed" }

Veritabanı Activation Preference Değerlerinin Doğrulanması

DAG topolojisinin doğru kurulduğunu teyit etmek için her veritabanının kopya dağılımı ve ActivationPreference değerleri kontrol edilir. Her veritabanı için Format-Table ile Server, DatabaseCopies ve ActivationPreference bilgileri listelenir.

Tek bir komutla TRISTSRVEXC01 üzerindeki tüm veritabanları topluca listelendiğinde, her veritabanının iki kopyaya sahip olduğu görülür. TRISTSRVEXC01 üzerindeki kopya ActivationPreference 1, TRISTSRVEXC02 üzerindeki kopya ise ActivationPreference 2 değerine sahiptir. Bu dağılım, TRISTSRVEXC01'in tüm veritabanları için birincil aktivasyon hedefi olduğunu gösterir.

Get-MailboxDatabase MBXUSRDB01 | Format-Table Server, DatabaseCopies, ActivationPreference

Get-MailboxDatabase -Server TRISTSRVEXC01 | Format-Table Server, DatabaseCopies, ActivationPreference

DAG Sağlık Raporunun Alınması

DAG'ın genel sağlık durumunu detaylı bir rapor halinde görüntülemek için topluluk tarafından geliştirilmiş Get-DAGHealth.ps1 Script'i kullanılmıştır. Bu Script, DAG üyeleri, veritabanı kopyaları ve Replication bileşenleri üzerinde bir dizi sağlık kontrolü yapar ve sonuçları ekrana veya HTML raporu olarak çıktılar. Script çalıştırıldığında, ortamda bir ignorelist.txt dosyası bulunmadığını bildiren bilgilendirme amaçlı bir uyarı görüntülenir. Bu uyarı bir hata değildir, yalnızca hiçbir Server, DAG veya veritabanının rapor dışında bırakılmayacağını belirtir.
Script -HTMLFile -Detailed parametreleriyle çalıştırıldığında, çalıştığı dizinde get-daghealth.html adında detaylı bir HTML raporu oluşturur.

Oluşturulan HTML raporunda DAG mimarisi sağlık özeti ve veritabanı bazında detaylar görüntülenir. Raporun üst bölümünde, her veritabanı için sağlıklı ve sağlıksız kopya, kuyruk ve indeks sayıları renkli tablolar halinde özetlenir.

Raporun alt bölümünde her veritabanı kopyası için Status, Copy Queue, Replay Queue ve Activation Preference değerleri ile DAG üyelerinin bileşen bazlı sağlık durumları detaylı olarak listelenir. Member Health tablosunda Cluster Service, Replay Service, Active Manager, File Share Quorum ve Database Availability gibi tüm kontrollerin "Passed" olması, DAG'ın sağlıklı ve operasyonel olduğunu doğrular.

Sonuç

Bu makalede, Exchange Server SE üzerinde iki Mailbox Server ve bir File Share Witness Server'dan oluşan bir IP-less DAG'ın PowerShell ile uçtan uca nasıl kurulduğunu adım adım inceledik. Failover Clustering Feature'ının kurulmasından başlayarak, DAG'ın oluşturulması, Server'ların üye yapılması, veritabanı kopyalarının Seeding ile oluşturulması ve Replication sağlığının doğrulanmasına kadar tüm süreci ele aldık. DAG kurulumu doğru yapılandırıldığında, Exchange ortamına Server ve veritabanı seviyesinde güçlü bir yüksek erişilebilirlik ve site dayanıklılığı kazandırır.

Faydalı olması dileğiyle...