Exchange Server SE'de PowerShell ile IP-less DAG Kurulum ve Yapılandırması

Database Availability Group (DAG), Exchange Server'da Mailbox Database'lere High Availability ve Site Resilience sağlayan temel bileşendir. Bir DAG, en fazla 16 Mailbox Server'ı bir araya getiren ve her Mailbox Database'in birden çok Database Copy'sini bu üyeler arasında tutan bir gruptur. Bir üyede Active Copy olarak çalışan bir veritabanı, diğer üyelerde Passive Copy olarak bulunur ve bir Mailbox Database ya da Server arızasında hizmet, otomatik olarak sağlıklı bir kopyaya devredilir. Böylece koruma, sunucunun tamamı yerine tek tek Mailbox Database düzeyinde elde edilir.

DAG, Exchange Server 2010 ile tanıtıldı ve kendisinden önceki High Availability (HA) teknolojilerinin yerini aldı. Exchange Server 2007 döneminde High Availability (HA) için Single Copy Cluster (SCC), Cluster Continuous Replication (CCR) ve Local Continuous Replication (LCR), Site Resilience için ise Standby Continuous Replication (SCR) gibi birbirinden ayrı teknolojiler kullanılırdı. Bu modeller hem yönetimi karmaşıklaştırıyor hem de Failover'ı sunucu düzeyinde gerçekleştiriyordu. Exchange Server 2010, CCR ile SCR'yi tek bir çatı altında birleştirip LCR ve SCC'yi tamamen kaldırarak DAG'ı ortaya çıkardı ve Failover'ı sunucu düzeyinden tek tek Mailbox Database düzeyine taşıdı. Aynı model Exchange Server 2013, 2016 ve 2019 ile gelişerek sürdü ve bugün, Exchange Server SE'de de High Availability'nin temelini oluşturdu.

Arka planda DAG, Windows Server Failover Clustering altyapısını kullanır, ancak Cluster'ı doğrudan yönetmek yerine bu altyapıyı Active Manager bileşeni üzerinden Exchange Server kendisi koordine eder. Active Manager, her Mailbox Server üzerinde çalışır ve Switchover ile Failover işlemlerini yönetir. Failover Cluster ise hangi üyelerin Online olduğuna ve hangi kopyanın Active olacağına karar verirken Quorum modelini kullanır. Çift sayıda üyeye sahip bir DAG'da Quorum'un korunması için bir File Share Witness devreye girer ve oy eşitliğini bozarak Cluster'ın tutarlı bir çoğunluk kararı vermesini mümkün kılar. Kopyalar arasındaki veri tutarlılığı ise Active Copy'deki Transaction Log dosyalarının Passive Copy'lere gönderilip Replay edilmesine dayanan Continuous Replication ile korunur. Böylece bir Mailbox Database ya da Server arızasında Active Manager, sağlıklı bir Database Copy'yi otomatik olarak aktive eder ve posta hizmeti kesintisiz sürer.

Bu makaledeki kurulum ise klasik DAG'dan farklı olarak IP-less mimariyle yapılandırılır. Administrative Access Point'siz, yani IP-less DAG, Exchange Server 2013 SP1 ile birlikte ve Windows Server 2012 R2 üzerinde desteklenmeye başladı. New-DatabaseAvailabilityGroup cmdlet'inde IP parametresi verilmediğinde DAG, bir Cluster Name Object (CNO), IP adresi veya Network Name içermeyecek şekilde oluşturulur. Bu model, DNS'e bir Cluster adı kaydetmez, yönetimi tamamen PowerShell üzerinden yapılır ve hem yönetim yükünü hem de saldırı yüzeyini azalttığı için Microsoft, üçüncü taraf bir uygulama Cluster'ın Administrative Access Point'ine ihtiyaç duymadığı sürece modern Exchange dağıtımlarında bu yaklaşımı önerir.

Bu makaledeki tüm işlemleri Exchange Management Shell (EMS) üzerinden gerçekleştiriyorum. Ortamda, DAG'ın iki üyesini oluşturacak olan TRISTSRVEXC01 ve TRISTSRVEXC02 Hostname'li iki Mailbox Server bulunuyor. File Share Witness rolünü ise Exchange barındırmayan, TRISTSRVSYN01 Hostname'li ayrı bir sunucu üstleniyor. Makaleme Failover Clustering kurulumundan başlayıp DAG'ı oluşturma, üyeleri ekleme ve Database Copy'lerini yapılandırma adımlarına kadar tüm süreci Exchange Server SE üzerinde adım adım ele alıyorum.

1- Failover Clustering Servisinin Kurulması

DAG arka planda Windows Server Failover Clustering altyapısını kullandığı için ilk adımım, her iki Mailbox Server üzerinde Failover Clustering Feature'ını kurmak. Kuruluma başlamadan önce bu Feature'ın mevcut durumunu Invoke-Command komutu ile her iki Server üzerinde uzaktan sorguluyorum.

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

Sorgu sonucunda Failover Clustering'in her iki Server üzerinde henüz kurulmadığını, InstallState değerinin Available olduğunu görüyorum.

Failover Clustering'i önce TRISTSRVEXC01 üzerinde Install-WindowsFeature komutu ile kuruyorum. Yönetim araçlarının da gelmesi için -IncludeManagementTools parametresini ekliyorum.

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

Kurulum ilerledikçe ilerleme yüzdesi ekranda görünüyor.

Kurulum tamamlandığında Success değeri True, Restart Needed değeri No ve Feature Result {Failover Clustering} olarak dönüyor. Restart Needed değerinin No olması, bu kurulum için yeniden başlatma gerekmediği anlamına geliyor.

EXC01 üzerindeki kurulumu, aynı durum sorgusunu tekrarlayarak doğruluyorum. InstallState değeri TRISTSRVEXC01 için Installed, TRISTSRVEXC02 için ise hala Available görünüyor.

Aynı işlemi TRISTSRVEXC02 üzerinde tekrarlıyorum.

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

Bu kurulumun ilerlemesini de ekranda izliyorum.


Kurulum tamamlandığında Success değeri True, Restart Needed değeri No ve Feature Result {Failover Clustering} olarak dönüyor. Restart Needed değerinin No olması, bu kurulum için yeniden başlatma gerekmediği anlamına geliyor.


Son olarak her iki Server üzerindeki Failover Clustering durumunu yeniden sorguluyorum. InstallState değerinin her iki Server için de Installed olması, Failover Clustering'in başarıyla kurulduğunu doğruluyor.
Her iki Server üzerinde InstallState değeri Installed olarak doğrulandıktan sonra, Failover Clustering bileşenlerinin tam olarak devreye girmesi için her iki Exchange Server'ı da yeniden başlatıyorum. Kurulum çıktılarında Restart Needed değeri No görünse de, Cluster oluşturma adımına geçmeden önce her iki Server'ı yeniden başlatarak temiz bir başlangıç sağlıyorum.

2- IP-less DAG Oluşturulması

Failover Clustering her iki Server üzerinde hazır olduğunda DAG'ı, New-DatabaseAvailabilityGroup cmdlet'i ile oluşturuyorum. -WitnessServer ve -WitnessDirectory parametreleriyle File Share Witness'ın hangi Server üzerinde ve hangi dizinde tutulacağını belirtiyorum. Komutta IP parametresi vermediğim için DAG, IP-less olarak oluşur.

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

Komutu çalıştırdığımda DAG nesnesi oluşuyor, ancak bir WARNING dönüyor. Exchange Trusted Subsystem'in Witness Server üzerindeki yerel Administrators grubuna üye olmaması nedeniyle "Access is denied" uyarısı görünüyor.
Bu uyarının nedenini anlamak için New-DatabaseAvailabilityGroup komutunun iki aşamalı çalıştığını bilmek gerekir. İlk aşamada DAG, Active Directory Configuration Partition içinde bir nesne olarak, yani DAG nesnesi, Active Directory'nin Configuration partition'ı içinde, CN=Database Availability Groups konteyneri altında bir msExchMDBAvailabilityGroup nesnesi olarak oluşturulur. Bu işlem Exchange'in kendi yetkileriyle yapıldığından Witness Server ile ilgisi yoktur ve başarıyla tamamlanır. İkinci aşamada Exchange, File Share Witness'ı hazırlamak için Witness Server'a erişmek ister, ancak Exchange Trusted Subsystem bu Server'ın yerel Administrators grubuna üye olmadığı için "Access is denied" alınır.

Çıktıda Member Servers değerinin {} olarak, yani boş bir liste şeklinde görünmesi, DAG'a henüz hiçbir üye Server eklenmediğini gösterir. Bu durum, "Access is denied" uyarısıyla doğrudan ilişkilidir. File Share Witness, yalnızca DAG üye aldığında ve Cluster, Quorum için Witness'a ihtiyaç duyduğunda fiilen devreye girer. Bu aşamada DAG'da henüz hiçbir üye olmadığı için Witness fiziksel olarak da oluşturulmaz ve işlevsel olarak hiçbir şey Witness'a bağlı değildir. Dolayısıyla bu uyarı kalıcı bir hasar bırakmaz, yalnızca üyeler eklenmeden, yani Witness gerçekten gerekli hale gelmeden önce tamamlanması gereken eksik bir izne işaret eder.

Uyarıyı gidermek için Exchange Trusted Subsystem grubunu, Witness Server'ın yerel Administrators grubuna ekliyorum. İşlemi Invoke-Command ile uzaktan gerçekleştiriyor, ardından Get-LocalGroupMember ile doğruluyorum.

Invoke-Command -ComputerName TRISTSRVSYN01.ABC.LOCAL -ScriptBlock {
    Add-LocalGroupMember -Group "Administrators" -Member "ABC\Exchange Trusted Subsystem"
}

Invoke-Command -ComputerName TRISTSRVSYN01.ABC.LOCAL -ScriptBlock {
    Get-LocalGroupMember -Group "Administrators"
}

Doğrulama sonucunda Witness Server'ın yerel Administrators grubunda Domain Admins, Exchange Trusted Subsystem ve yerel Administrator hesabının yer aldığını görüyorum. Exchange Trusted Subsystem artık gerekli izne sahip olduğu için Witness Server üzerindeki izin sorunu giderildi.

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

DAG'ı oluşturduktan sonra, üyeleri eklemeden önceki durumu Get-DatabaseAvailabilityGroup ile sorguluyorum. WitnessServer ve WitnessDirectory değerleri görünüyor, ancak Servers listesi boş ve WitnessShareInUse değeri henüz boş, çünkü DAG'a bu aşamada herhangi bir üye eklemedim.

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

Çıktıda Servers değerinin {} olarak, yani boş bir liste şeklinde görünmesi, DAG'ın henüz üyesiz olduğunu doğruluyor.

İlk Mailbox Server'ı Add-DatabaseAvailabilityGroupServer ile DAG'a ekliyorum. İlk üyenin eklenmesi aynı zamanda DAG'ın arka planındaki Failover Cluster'ı da oluşturur.

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

İşlem sırasında, eklemenin 45 saniyeye kadar sürebileceğini belirten bir ilerleme bilgisi görünüyor.
İşlem tamamlandığında, Information Store servisinin yeniden başlatılmasını öneren bir WARNING dönüyor.

Bu öneri doğrultusunda TRISTSRVEXC01 üzerindeki Information Store servisini yeniden başlatıyorum.

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

Servisin durdurulup yeniden başlatıldığı süreci çıktıda görüyorum.

Aynı işlemi ikinci Mailbox Server için tekrarlıyorum. İlk üye Failover Cluster'ı oluşturduğu için, bu kez TRISTSRVEXC02 mevcut Cluster'a katılır. Bunu çıktıda "Adding server to the cluster" ifadesinden anlıyorum.

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

İşlem devam ederken TRISTSRVEXC02'nin Cluster'a eklendiğini görüyorum.
İşlem tamamlandığında, bu Server için de Information Store servisinin yeniden başlatılmasını öneren bir WARNING dönüyor.

TRISTSRVEXC02 üzerindeki Information Store servisini de yeniden başlatıyorum. Bu kez işlem uzaktaki Server'a yönelik olduğu için -ComputerName parametresini kullanıyorum.

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

Servisin yeniden başlatıldığını çıktıda görüyorum.

Her iki üyeyi ekledikten sonra DAG durumunu aynı sorguyla yeniden kontrol ediyorum. Servers listesinde her iki Mailbox Server görünüyor ve PrimaryActiveManager olarak TRISTSRVEXC01 atanıyor. Önemli olan değişiklik, WitnessShareInUse değerinin artık Primary olması. Bu, çift sayıda üye nedeniyle Cluster'ın Node and File Share Majority Quorum moduna geçtiğini ve File Share Witness'ın fiilen kullanılmaya başlandığını gösterir.

Daha önce belirttiğim gibi Witness yapısı, DAG'a üye eklenip File Share Witness gerçekten gerekli hale geldiğinde Exchange tarafından otomatik oluşturulur. Bu noktada Witness Server üzerindeki C:\EXC-DAG-WITNESS dizini, DAG adıyla, yani DAG-2552026.abc.local adıyla paylaşıma açılmış oluyor. Paylaşımın açıklamasında bunun bu DAG için oluşturulan File Share Witness olduğu belirtiliyor.

Paylaşım izinlerini incelediğimde, Exchange Trusted Subsystem grubuna otomatik olarak Full Control verildiğini görüyorum.

NTFS, yani Security sekmesinde ise Exchange Trusted Subsystem ayrı bir satır olarak görünmüyor. Sekmede yalnızca CREATOR OWNER, SYSTEM, Administrators ve Users girdileri yer alıyor.

Exchange Trusted Subsystem'in Security yani NTFS sekmesinde ayrı bir satır olarak görünmemesinin nedeni, bu grubun bir önceki adımda Witness Server'ın yerel Administrators grubuna eklenmiş olmasıdır. Security sekmesinde zaten Full Control'e sahip olan Administrators girdisi bulunur ve Exchange Trusted Subsystem bu grubun üyesi olduğu için NTFS erişimini doğrudan bu girdi üzerinden, grup üyeliği yoluyla alır. Bu nedenle ayrı bir Exchange Trusted Subsystem satırına gerek yoktur. Paylaşım izinleri ise NTFS'ten tamamen ayrı bir ACL olduğundan ve yerel Administrators üyeliği bu ACL'ye yansımadığından, Exchange paylaşım üzerinde Exchange Trusted Subsystem'e açıkça Full Control verir.

Son olarak, üyelerin Cluster düzeyindeki durumunu ve File Share Witness'ın Cluster kaynağı olarak çevrimiçi olup olmadığını doğruluyorum. Get-ClusterNode ile Exchange Node'ların durumunu, Get-ClusterResource ile de Witness kaynağının durumunu sorguluyorum.

Get-Cluster | Get-ClusterNode

Get-ClusterNode -Name TRISTSRVEXC01 | Get-ClusterResource

İlk çıktıda her iki Exchange Node'un, yani TRISTSRVEXC01 ve TRISTSRVEXC02'nin State değerinin Up olduğunu görüyorum. Bu, her iki Mailbox Server'ın da Cluster'a sağlıklı birer Node olarak katıldığını gösterir.

İkinci çıktıda ise File Share Witness kaynağının State değerinin Online olduğunu, Cluster Group içinde yer aldığını ve \\tristsrvsyn01.abc.local\DAG-2552026.abc.local Path'ini işaret ettiğini görüyorum. Bu, daha önce oluşturulan Witness paylaşımının artık Cluster Quorum'una entegre, çevrimiçi bir kaynak olarak çalıştığını doğrular.

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

DAG üyeleri hazır olduğunda, mevcut Mailbox Database'lerin ikinci bir kopyasını diğer üyeye ekliyorum. Önce hangi veritabanlarının ikinci kopyaya sahip olmadığını tespit etmek için bir kontrol yapıyorum. Bunun için TRISTSRVEXC01 üzerindeki her veritabanını kontrol edip TRISTSRVEXC02 üzerinde kopyası bulunmayanları listeleyen bir Script çalıştırıyorum.

$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

Çıktıda 12 kullanıcı veritabanının, yani MBXUSRDB01'den MBXUSRDB12'ye kadar olanların ve sistem veritabanı MBXSYSDB'nin tümünün TRISTSRVEXC01 üzerinde Mounted durumda olduğunu, hiçbirinin TRISTSRVEXC02 üzerinde kopyası bulunmadığı için MissingCopyOn değerinin TRISTSRVEXC02 olduğunu görüyorum.

Eksik kopyaları belirledikten sonra, DAG'a ait olup TRISTSRVEXC02 üzerinde kopyası bulunmayan tüm veritabanlarına Add-MailboxDatabaseCopy ile ikinci kopyayı ekliyorum. -ActivationPreference 2 parametresi, eklenen yeni kopyaların etkinleştirme önceliğini 2 olarak ayarlar. Böylece mevcut kopyalar TRISTSRVEXC01 üzerinde öncelik 1 ile aktif kalırken, yeni kopyalar TRISTSRVEXC02 üzerinde öncelik 2 ile pasif kopya olarak yapılandırılır.

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

Komut çalıştığında her veritabanı için Seeding işlemi başlıyor. Seeding, aktif kopyadaki verinin pasif kopyaya ilk kez kopyalanması sürecidir. İlk veritabanı olan MBXUSRDB01 için Seeding'in ilerlediğini görüyorum.

Seeding işlemi tüm veritabanları için sırayla devam ediyor. Her yeni kopya eklendikçe, ilgili Server için Information Store servisinin yeniden başlatılmasını öneren bir WARNING satırı birikiyor.

Seeding, son kullanıcı veritabanı olan MBXUSRDB12 ve ardından sistem veritabanı MBXSYSDB için de tamamlanıyor.

Tüm kopyalar eklendiğinde komut tamamlanıyor ve eklenen her veritabanı için Information Store servisinin yeniden başlatılmasını öneren WARNING satırları topluca görünüyor.

Bu öneri doğrultusunda, tüm kopyaları ekledikten sonra her iki Mailbox Server üzerindeki Information Store servisini yeniden başlatıyorum. İlk komutu yerel Server olan TRISTSRVEXC01 üzerinde, ikinci komutu ise -ComputerName parametresiyle TRISTSRVEXC02 üzerinde çalıştırıyorum.

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

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

Her iki Server üzerinde Information Store servisinin durdurulup yeniden başlatıldığını çıktıda görüyorum.

5- DAG Veritabanı Kopyalarının Durumunun Kontrol Edilmesi

Kopyaları ekleyip Seeding tamamlandıktan sonra, veritabanı kopyalarının durumunu Get-MailboxDatabaseCopyStatus ile kontrol ediyorum. Önce aktif kopyaların bulunduğu TRISTSRVEXC01'i sorguluyorum.

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

TRISTSRVEXC01 üzerindeki tüm kopyaların Status değeri Mounted. Mounted, kopyanın aktif ve bağlı olduğunu, yani kullanıcı bağlantılarına hizmet veren kopya olduğunu gösterir. CopyQueueLength ve ReplayQueueLength değerlerinin 0 olması da bekleyen bir kopyalama veya yeniden oynatma kuyruğunun bulunmadığını gösterir.

Ardından pasif kopyaların bulunduğu TRISTSRVEXC02'yi sorguluyorum.

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

TRISTSRVEXC02 üzerindeki kopyaların Status değeri Healthy. Healthy, pasif kopyanın sağlıklı olduğunu ve aktif kopyayla senkron biçimde güncellendiğini gösterir. CopyQueueLength ve ReplayQueueLength değerlerinin 0 olması, replikasyonun gecikmesiz ilerlediğini doğrular.

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

Kopya durumlarını doğruladıktan sonra, DAG genelindeki replikasyon ve Cluster sağlığını Test-ReplicationHealth ile test ediyorum. Bu cmdlet, her üye için Cluster servisi, Replay servisi, Active Manager, Quorum ve veritabanı kopyalarına yönelik bir dizi kontrolü çalıştırır. Önce TRISTSRVEXC01'i test ediyorum.

Test-ReplicationHealth -Identity TRISTSRVEXC01

Tüm kontrollerin Result değeri Passed. ClusterService, ReplayService, ActiveManager, FileShareQuorum, DatabaseRedundancy ve DatabaseAvailability gibi kontrollerin tümünün başarılı olması, üyenin ve Cluster'ın sağlıklı çalıştığını gösterir.

Aynı testi TRISTSRVEXC02 için tekrarlıyorum.

Test-ReplicationHealth -Identity TRISTSRVEXC02

Bu Server üzerinde pasif kopyalar bulunduğu için, çıktıda ayrıca DBCopySuspended, DBCopyFailed, DBInitializing, DBDisconnected, DBLogCopyKeepingUp ve DBLogReplayKeepingUp gibi kopya odaklı kontroller de yer alır. Tüm kontrollerin Passed olması, pasif kopyaların sağlıklı olduğunu ve replikasyonun sorunsuz işlediğini doğrular.

Activation Preference Doğrulanması

Son olarak, veritabanı kopyalarının etkinleştirme önceliklerini doğru yapılandırıp yapılandırmadığımı kontrol ediyorum. Get-MailboxDatabase çıktısında DatabaseCopies ve ActivationPreference alanlarını inceliyorum. Önce tek bir veritabanını, ardından TRISTSRVEXC01 üzerindeki tüm veritabanlarını sorguluyorum.

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

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

Çıktıda her veritabanının iki kopyaya sahip olduğunu görüyorum. ActivationPreference değerleri, TRISTSRVEXC01 üzerindeki kopyaların 1, TRISTSRVEXC02 üzerindeki kopyaların 2 önceliğine sahip olduğunu gösterir. Bu, aktif kopyaların öncelikli olarak TRISTSRVEXC01 üzerinde tutulacağını, TRISTSRVEXC02'nin ise pasif kopya rolünü üstleneceğini doğrular.

Sonuç

Bu makalede, iki Mailbox Server'dan oluşan bir Exchange Server SE ortamında IP-less bir DAG'ı Exchange Management Shell üzerinden uçtan uca nasıl kurduğumu ele aldım. Failover Clustering Feature'ının kurulmasından başlayıp DAG'ı oluşturma, Witness Server izinlerini düzenleme, Mailbox Server'ları DAG'a üye yapma ve veritabanı kopyalarını ActivationPreference değerleriyle ekleme adımlarını tek tek uyguladım. Son olarak kopya durumlarını, replikasyon sağlığını, Cluster Node'larını ve File Share Witness kaynağını doğrulayarak kurulumun sağlıklı tamamlandığını teyit ettim.

IP-less DAG yaklaşımı, bir Cluster Name Object, IP adresi veya Network Name gerektirmediği için yönetim yükünü ve DNS bağımlılığını azaltır ve modern Exchange dağıtımlarında tercih edilen modeldir. Kurulum tamamlandıktan sonra DAG'ın sağlığını, Test-ReplicationHealth ve Get-MailboxDatabaseCopyStatus gibi yerleşik cmdlet'lerle düzenli olarak kontrol edebilirsiniz.

Faydalı olması dileğiyle...