Microsoft Exchange Database Optimization ve Mailbox Migration Stratejileri

Microsoft Exchange Database Optimization ve Mailbox Migration stratejileri ile  Exchange Server ortamınızın performansını artırma, white space yönetimi ve güvenli mailbox taşıma süreçlerini bu makale içinde paylaşılmıştır.

Microsoft Exchange Database Optimization ve Mailbox Migration stratejileri , kurumsal iletişimin sürekliliği ve sağlıklı işleyişi açısından hayati önem taşır. Zaman içinde büyüyen Exchange veritabanları, artan kullanıcı sayısı ve yoğun mesaj trafiği; Exchange Server altyapısını performans açısından zorlayabilir. Bu nedenle, Microsoft Exchange Database’lerinin düzenli olarak optimize edilmesi, sistem kaynaklarının verimli kullanımı, veri bütünlüğünün korunması ve kullanıcı deneyiminin iyileştirilmesi açısından kritik bir gerekliliktir.

Pera Bilgi Sistemleri Blog sayfamızda, Microsoft Exchange Server Optimization süreçlerine dair birçok teknik makaleye yer verdik. Ayrıca Vlog bölümümüzde, bu süreçleri adım adım anlattığımız detaylı videolarla konuyu görsel olarak da destekledik.

Bu yazımızda, şimdiye kadar paylaşmış olduğumuz içerikleri Microsoft Exchange Server Database Optimization başlığı altında derleyerek, süreci bütüncül bir bakış açısıyla sizlerle paylaşmak istiyoruz.

Microsoft Exchange Server Database Optimization makalesi içinde aşağıda ki bilgilere sahip olacaksınız

1. Proaktif İzleme Sorunları Oluşmadan Önce Görmek ve Müdahale Etmek

Microsoft Exchange Server altyapısında performans sorunlarını yalnızca meydana geldikten sonra çözmeye çalışmak, operasyonel kesintilere ve kullanıcı memnuniyetsizliğine yol açabilir.

Bu nedenle, proaktif izleme yaklaşımları, veritabanı performansını ve genel sistem sağlığını sürekli takip ederek potansiyel sorunları erken aşamada tespit etmeyi amaçlar.

Disk Gecikmeleri (Disk Latency), Database IOPS, RPC Client Access, log diski doluluk oranı, indexing kuyrukları, arka plan bakım görevleri gibi birçok kritik metrik, proaktif izleme kapsamında düzenli olarak analiz edilmelidir. Böylece performans dar boğazları, veri bozulmaları veya kapasite taşmaları gibi riskler henüz kullanıcıları etkilemeden fark edilip aksiyon alınabilir.

Exchange ortamlarında bu yaklaşım, sadece sorun çözmekten öteye geçerek; sistem sağlığını sürekli kontrol altında tutan, sürdürülebilir ve güvenilir bir operasyonel yapı oluşturmanın temelini atar.

Microsoft Exchange Server alt yapısını izlemek için bir den fazla izleme çözümü bulunmakta olup her kuruluş kendi iş ihtiyaçları ve bütçesine bağlı olarak en uygun çözümü seçmektedir. Proaktif hizmetler kapsamında ki en uygun çözüm ise en iyi kullandığınız üründür.

Pera Bilgi Sistemleri Proaktif hizmetler kapsamında bir çok izleme çözümüne odaklanmakta ve özellikle Azure Monitor çözümü ile müşterilerimizin ihtiyaçlarını karşılamaktayız.

Microsoft Azure Monitor ile Proaktif hizmetlerimizi sorunsuz olarak sunabilmekte ve Azure Monitor ile Kapsamlı Telemetri verilerini Toplamakta ve onları görselleştirebilmekteyiz.

Modern BT altyapıları artık yalnızca bir veri merkezinden ya da yalnızca bir bulut ortamından oluşmuyor. Hibrit ve çoklu bulut yapılarının hızla yaygınlaştığı günümüzde, sistemlerin güvenilirliği ve performansı açısından merkezi ve bütüncül izleme çözümleri daha da kritik hale gelmiştir. İşte bu noktada devreye Microsoft Azure Monitor giriyor.

Azure Monitor Nedir ve Log Analytics Workspace Ayarları konu başlığında Azure Montior için makale ve video içeriğimizi sizler ile paylaşmıştık.

Microsoft Exchange Server Database Optimization konusuna geri dönecek olursak; yukarıda paylaştığımız ekran görüntüsü, yönetmekte olduğumuz Exchange altyapısındaki sunucuların disk doluluk oranlarını merkezi olarak izlememizi sağlamaktadır.

Hazırladığımız bu Azure Monitor Dashboard, Exchange Server’lar üzerindeki diskleri görsel olarak takip etme imkânı sunar. Bu dashboard sayesinde Hangi Exchange sunucusunda kaç adet disk bulunduğu, Bu diskler üzerinde kaç adet Exchange veritabanı (Database) çalıştığı gibi bilgilere hızlı ve bütünsel bir bakışla erişilebilmektedir.

Exchange Server ortamına özel olarak yapılandırılmış bu dashboard sadece Disk alanı ve Exchange Server Database ‘leri söylese de Azure Monitor yetenekleri bunun ile sınırlı değildir. Exchange Performance Counters etiketleri ile sizlere paylaşmış olduğumuz içeriklerde Mailbox database performansı, RPC bağlantı durumları, Arka plan bakım görevleri, Aktif kuyruk yapıları gibi kritik Exchange servis bileşenleri de Azure Monitor Query’leri aracılığıyla uçtan uca izlenebilmektedir.

Sonuç olarak, Azure Monitor sayesinde hem operasyonel görünürlük artırılmış, hem de performans dar boğazları oluşmadan önce tespit edilerek önleyici aksiyonlar alınabilir hale gelmiştir.

Microsoft Exchange Server altyapısını izlemek için birçok farklı izleme çözümü bulunmaktadır. Her kurum, kendi operasyonel ihtiyaçları, teknik yetkinlikleri ve bütçesi doğrultusunda en uygun çözümü tercih eder. Proaktif izleme hizmetlerinde en etkili sonuç, kurumun hâlihazırda en iyi bildiği ve en etkin kullandığı araçlarla sağlanır.

Önemli olan yalnızca gelişmiş bir ürüne sahip olmak değil, o ürünü kurum içinde doğru yapılandırmak, etkili yorumlayabilmek ve sürdürülebilir şekilde kullanabilmektir. Bu nedenle, izleme çözümü tercihi yaparken teknolojik kabiliyetten çok, operasyonel uyumluluğu ön planda tutmak kritik başarı faktörüdür.

2. Exchange Mailbox Database White Space Yönetimi ve Performans İyileştirme Yöntemleri

Microsoft Exchange Mailbox Database White Space Nedir başlıklı blog yazımızda, bu kavramı detaylı bir şekilde ele almış ve Exchange Mailbox Database üzerinde white space oluştuğunda neler yapılması gerektiğini aktarmıştık.

Kısaca özetlemek gerekirse: Microsoft Exchange Server Mailbox Database üzerindeki Available New Mailbox Space, veritabanında yeni posta kutuları için ayrılmış, kullanılabilir boş alanı ifade eder.

Bu boş alan genellikle bir posta kutusu veya içerisindeki e-postalar ve ekler silindiğinde oluşur.

Ancak bu değeri, ilk bölümde bahsettiğimiz Proaktif İzleme adımlarında göremeyiz. Çünkü proaktif izleme sırasında değerlendirilen kullanım oranları, genellikle Windows Server altyapısına ait fiziksel kaynaklardır. Detaylar için Azure Monitor Infrastructure başlıklı makale ve video içeriklerimizi inceleyebilirsiniz.

Exchange Mailbox Database üzerindeki white space ise, fiziksel değil mantıksal katmanda oluşur. Yani veritabanı geçmişte (X zamanı) belirli bir boyuta kadar büyümüş, ancak daha sonra bazı posta kutuları veya içerikler (T zamanında) silinmiştir. Exchange veritabanı ise bu silinen içeriklere rağmen otomatik olarak küçülmez. Bu nedenle, o silinmiş verilerin yer kapladığı alan artık “white space”, yani Available New Mailbox Space olarak adlandırılır.

Bu boşluk, öncelikle mevcut veritabanı içerisindeki posta kutuları tarafından kullanılır. Yeni veri yazılmadan önce, Exchange bu mevcut white space alanını kullanmaya çalışır. Böylece fiziksel boyut büyümeden içerideki boş alan değerlendirilmiş olur.

Ancak tam da bu noktada, bazı performans sorunları baş gösterebilir. Mevcut kullanıcılar, silinmiş verilerden arta kalan bu alanı kullanabilmek için, Exchange veritabanının içindeki indexleme işlemlerinin tamamlanmasını beklemek zorunda kalabilir. Bu da zamanla sistemin hantallaşmasına ve genel performans düşüşüne neden olabilir.

Exchange Server Mailbox Database Mimarisi başlıklı blog yazımızda, bu süreci detaylı şekilde anlatmış ve yüksek boyutlara ulaşan Exchange Mailbox Database’leri için Exchange Mailbox Database Offline Defragmentation işlemini önermiştik.

Ancak, Offline Defragmentation işlemi kesinti gerektiren bir süreçtir. Eğer söz konusu Exchange Mailbox Database bir DAG (Database Availability Group) kümesi içinde çalışıyorsa, bu işlem doğrudan uygulanamaz. Çünkü defragmentation yapılabilmesi için ilgili veritabanının DAG kümesinden çıkarılması gereklidir.

Üstelik bu işlem, sadece teknik olarak değil, iş süreçleri açısından da risklidir. Kesinti süresinin doğru planlanması ve operasyonun hassasiyeti nedeniyle çoğu zaman tercih edilmez. Ancak, çok yüksek miktarda white space içeren bir Exchange Mailbox Database yeterli performansı sağlayamaz ve bu durumda iyileştirme zorunlu hale gelir.

İşte bu noktada, kesintisiz ve kontrollü bir yöntem olan Mailbox Move Request işlemleri devreye girer.

3. Microsoft Exchange Server Database Optimization Süreçleri

Offline Defragmentation işlemi, taşıdığı kesinti riskleri ve operasyonel zorlukları nedeniyle çoğu Exchange ortamında tercih edilmez. Bu nedenle, Microsoft Exchange Server Database Optimization sürecinin Mailbox Move Request işlemi ile gerçekleştirilmesi, daha uygulanabilir ve sürdürülebilir bir yöntem olarak öne çıkar.

Bu yönteme geçmeden önce, organizasyonunuzdaki tüm Exchange Mailbox Database‘lerinin hem toplam boyutunu hem de sahip oldukları white space (Available New Mailbox Space) miktarını analiz etmek gerekir.

Aşağıdaki Exchange Management Shell komutu, organizasyon genelinde bulunan tüm Mailbox Database’lerinin boyutlarını ve white space alanlarını listelemenizi sağlar.

Bu komut sayesinde, optimizasyon sürecine başlamadan önce mevcut durumu net bir şekilde görebilir ve hangi veritabanlarında iyileştirmeye ihtiyaç olduğunu tespit edebilirsiniz.

Mailbox Database’lerin EDB dosya boyutlarını ve sahip oldukları white space alanlarını inceledikten sonra, hangi veritabanında optimizasyon yapılması gerektiğini belirlemiş olduk.

Bir sonraki adımda ise, seçilen Exchange Mailbox Database içerisinde bulunan kullanıcı posta kutularını analiz etmemiz gerekir. Bu analiz sayesinde, ilgili veritabanında hangi kullanıcıların bulunduğunu ve her bir posta kutusunun ne kadar veri boyutuna sahip olduğunu görebiliriz. Böylece, Mailbox Move Request işlemleri için önceliklendirme ve planlama yapılabilir.

Aşağıdaki Exchange Management Shell komutu, optimizasyon işlemini yapacak olduğumuz Exchange Mailbox Databse içinde bulunan kullanıcı mailbox ‘larnın boyutlarını bizlere söyleyecektir.

Yani, Mailbox Move Request işlemini yapacak olduğumuz kullanıcılar ve onların sahip oldukları Mailbox boyutlarını.

Artık elimizde, hedeflenen Exchange Mailbox Database’in toplam boyutu, içerisindeki white space (kullanılabilir alan) miktarı ve bu alanda yer alan kullanıcıların posta kutularına ait veri boyutları bulunmakta.
Bu bilgiler doğrultusunda, Mailbox Move Request işlemi için taşınacak kullanıcıları belirlemiş olduk.

Ancak burada dikkat edilmesi gereken kritik bir nokta var:
Elde ettiğimiz veri sadece birincil (Primary) Mailbox boyutlarını kapsamaktadır. Bu kullanıcıların ayrıca bir Archive Mailbox (Arşiv Posta Kutusu) olup olmadığını henüz bilmiyoruz. Eğer bu bilgiyi göz ardı ederek taşıma işlemini başlatırsak, süreç planladığımızdan uzun sürebilir, Exchange sunucu kaynakları beklenmedik şekilde zorlanabilir ve genel taşıma performansı olumsuz etkilenebilir.

Kısacası, eksik bilgiyle başlatılan bir taşıma işlemi, Exchange Mailbox Database Optimization sürecinde ciddi sorunlara yol açabilir.

Bu nedenle adımları sıralarsak:

1. Database boyutu ve white space miktarı belirlendi.
2. Kullanıcı listesi ve her birinin veri boyutu tespit edildi.
3. Son adım olarak, bu kullanıcıların Archive Mailbox‘a sahip olup olmadığını kontrol ederek, taşınacak toplam veri miktarını netleştirmemiz gerekiyor.

Database02 içinde bulunan kullanıcılarımızdan sadece destek@pera.net.tr kullanıcısı Archive mailbox ‘a sahip durumda ve bu archive mailbox ‘da archive15 isimli Database üzerinde bulunmakta.

yani Destek kullanıcısının iki postası var bir tanesi Database01 içinde bir diğeri archive15 içinde. Bizim amacımız Database02 içinde işlem yapmak olduğu için ve destek kullanıcısını da bu işleme dahil edersek ve bu kullanıcının da ikinci bir Mailbox ‘ı olduğu için problem olacaktır.

4. Mailbox Move Request İşlemleri

Exchange Mailbox Database optimizasyonunun en etkili ve en güvenli yöntemlerinden biri, posta kutularının başka bir veritabanına Mailbox Move Request işlemi ile taşınmasıdır. Bu süreç, özellikle yüksek white space’e sahip, performansı düşmüş veya yeniden dengelenmesi gereken veritabanlarında sıkça tercih edilir.

Mailbox Move Request, taşınacak posta kutusunun verilerini hedef veritabanına kopyalar ve bu işlem sırasında kullanıcı erişimini kesintiye uğratmadan çalışır. Böylece hem veritabanı yapısı yeniden düzenlenir hem de optimizasyon adımı kontrollü bir şekilde tamamlanır.

Bu nedenden ötürü, archive mailbox ‘a sahip kullanıcılar ile olmayan kullanıcılar üzerinde ki işlemleri ayırmamız gerekmektedir.

4.1 Mailbox Move Request (Exchange Management Shel)

Exchange Management Shell ile yapmış olduğumuz Mailbox Move Request işlemleri, tek tek PowerShell ile Mailbox Taşıma işlemidir. Her bir kullanıcı için bireysel taşıma komutu oluşturulduğu, daha kontrollü fakat zaman alan yöntemdir.

Yukarıda paylaşmış olduğum komut içerinde destek@pera.net.tr kullanıcısı bulunmamakta ve bu kullanıcı olmadan Database02 içinde ki kullanıcıları Database01 ‘e taşımak için tek bir komut yazdım.

Exchange Management Shell komutu düzenlenebilir ve her bir taşınacak kullanıcı için ayrı-ayrı görev yazmak yerine isterseniz yukarıda ki komutu kullanabilir, tek bir komut ile birden fazla kullanıcıyı taşıyabilirsiniz. Bu komut ile her bir kullanıcı için ayrı ayrı düzenlemeniz gerekmektedir.

Her bir taşınacak kullanıcı için ayrı-ayrı görev yazmak isterseniz yukarıda ki komutu kullanabilirsiniz. Bu komut ile her bir kullanıcı için ayrı ayrı düzenlemeniz gerekmektedir.

Son olarak destek@pera.net.tr kullanıcısının archive mailbox bulunmakta ve bizler sadece birincil (primary) posta kutusunu taşımak istiyoruz. Bu durumda New-MoveRequest komutunda -PrimaryOnly parametresini kullanmamız gerekmekte.

PrimaryOnlyparametresi sayesinde sadece ana posta kutusu taşınır ve Archive mailbox olduğu halde arşiv taşınmaz ve olduğu yerde kalır.

4.2 Mailbox Move Request (CSV Migration)

Exchange Mailbox Move Request işlemini CSV Dosyası Kullanarak Toplu Mailbox Taşıma işlemini de tercih edebilirsiniz. önceden hazırlayacak olduğunuz CSV dosyası ile çok sayıda posta kutusunun tek seferde ve standart bir formatla taşınmasını sağlayan, operasyonel ortamlarda daha pratik yöntemdir.

Her iki yaklaşım da Exchange organizasyonunun boyutuna, operasyonel ihtiyaca ve planlanan optimizasyon senaryosuna göre tercih edilebilir. Bu bölümde, her iki yöntemin de detaylı kullanım örneklerini ve en doğru uygulama şekillerini bulacaksınız.

Bu komut, Database84 isimli Exchange Mailbox Database’in iki önemli bilgisini hızlıca görüntülemek için kullanılır.

• DatabaseSize, veritabanının toplam fiziksel boyutunu ifade eder ve EDB dosyasının diskte kapladığı gerçek alanı gösterir. Bu bilgi, veritabanının ne kadar büyüdüğünü anlamak ve kapasite planlaması yapmak açısından önemlidir.
• AvailableNewMailboxSpace (White Space) ise silinmiş öğelerden geriye kalan ve Exchange tarafından yeniden kullanılabilir durumda olan boş alanı gösterir. Exchange veritabanları silinen içeriği fiziksel olarak küçültmediği için bu boşluk mantıksal bir alan olarak içeride tutulur.

Bu değer, veritabanında ne kadar optimize edilebilecek veya yeniden kullanılabilecek alan bulunduğunu anlamak açısından kritik bir metriktir.

Bu komut, Database84 isimli Mailbox Database içinde bulunan toplam posta kutusu sayısını hızlı bir şekilde belirlemek için kullanılır.

• Get-Mailbox -Database “Database84” ifadesi ilgili veritabanındaki tüm posta kutularını listeler,
• -ResultSize Unlimited parametresi ise sayı sınırı olmadan tüm nesnelerin getirilmesini sağlar.
• Measure-Object, getirilen posta kutularını sayarak toplam kaç mailbox bulunduğunu hesaplar.

Kısacası bu komut, ilgili veritabanında kaç adet kullanıcı posta kutusu olduğunu en pratik şekilde öğrenmenizi sağlar.

Bu komut, Database84 isimli Mailbox Database içinde bulunan tüm posta kutularının bir listesini çıkararak CSV formatında dışarıya aktarmak için kullanılır. İlk olarak;

• Get-Mailbox -Database “Database84” ifadesi veritabanındaki tüm kullanıcı posta kutularını getirir,
• ResultSize Unlimited parametresi ise herhangi bir sınır olmadan tüm kayıtların alınmasını sağlar.
• Select-Object, her bir posta kutusunun yalnızca PrimarySMTPAddress bilgisini seçerek “EmailAddress” adıyla düzenler. Son olarak bu liste
• Export-Csv komutu ile C:\PiReports dizinine Database84-MoveList.csv adıyla kaydedilir. UTF-8 formatında oluşturulan bu CSV dosyası, Mailbox Move Request işlemlerinde kullanılmak üzere temiz ve düzenli bir e-posta listesi elde etmenizi sağlar.

Dışarıya çıkartmış olduğunuz CSV formatını Exchange Control Panel üzerinden Mailbox Move Request işlemi yapacaksanız eğer kabul gören CSV format biçimi aşağıda ki gibi olmalıdır.

Exchange Control Panel (ECP) üzerinden yeni bir “local mailbox move” başlatırken, kullanıcıları tek tek seçmek yerine çok daha hızlı ve pratik bir yöntem olan CSV dosyası ile toplu taşıma seçeneği kullanılabilir. Bu ekran, oluşturduğumuz CSV dosyasının sisteme yüklenmesini sağlayarak yüzlerce mailbox’ı aynı anda taşıma imkânı sunar.

Ekranda bulunan “Specify the users with a CSV file” seçeneği işaretlendiğinde, Exchange sizden yalnızca e-posta adreslerinin yer aldığı bir CSV dosyası yüklemenizi ister. Bu CSV genellikle şu şekilde oluşturulur:

• İlk satırda kolon adı: EmailAddress
• Alt satırlarda taşınacak kullanıcıların SMTP adresleri

Daha önce PowerShell ile oluşturduğumuz Database84-MoveList.csv dosyası tam olarak bu formatı taşır ve bu ekrandaki “change” butonu aracılığıyla yüklenir.

CSV import işlemi sayesinde:

• Taşınacak kullanıcılar otomatik olarak sisteme aktarılır,
• Tek tek seçim yapma ihtiyacı ortadan kalkar,
• Büyük Exchange organizasyonlarında taşıma operasyonları çok daha hızlı ve hatasız şekilde yürütülür.

Bu bölüm, Mailbox Move Request süreçlerinde özellikle büyük hacimli kullanıcı taşıma işlemleri için en pratik yöntemdir.

CSV dosyası başarıyla yüklendikten sonra, Exchange Control Panel (ECP) sizi “Move configuration” ekranına yönlendirir. Bu bölüm, taşıma işleminin nasıl gerçekleşeceğini ve taşınacak posta kutularının hangi veritabanına aktarılacağını belirlediğiniz temel yapılandırma ekranıdır.

Bu sayfa üzerinden öncelikle Migration Batch Name tanımlanır. Taşıma işleminin bir batch (görev) olarak çalışacağı düşünüldüğünde, anlamlı ve takip edilebilir bir isim yazmak operasyonel açıdan önemlidir. Örnekte Database84-MoveList ismi kullanılmıştır ve bu isim daha önce CSV export ettiğimiz dosyanın ismidir.

Ardından Archive seçenekleri karşınıza çıkar. Exchange kullanıcılarının birincil (Primary) mailbox’larının yanında bir de Archive mailbox’ları olabilir. Bu bölümde:

• Move primary mailbox and the archive mailbox if one exists Hem birincil posta kutusunu hem de varsa arşiv posta kutusunu birlikte taşır.
• Move primary mailbox only, without moving archive mailbox Sadece birincil posta kutusunu taşır. Archive mailbox olduğu yerde kalır. Bu seçenek Exchange 2010 ve üzeri sürümlerde desteklenir.
• Move archive mailbox only, without moving primary mailbox Sadece arşiv posta kutusunu taşımak isterseniz bu seçenek kullanılır.

Çoğu optimizasyon senaryosunda tercih edilen yöntem, yalnızca Primary mailbox taşımaktır. Bu sayede archive mailbox farklı bir database’de kalabilir ve gereksiz veri yükü taşınmamış olur.

Sonraki adımda Target database belirlenir. Bu alan, CSV dosyasındaki tüm kullanıcıların hangi Mailbox Database’e taşınacağını ifade eder. Örnekte hedef olarak Database02 seçilmiştir.

Eğer kullanıcıların archive mailbox’ları da taşınacak olsaydı, alt bölümdeki Target archive database kutusuna ikinci bir veritabanı seçilmesi gerekirdi. Ancak çoğu senaryoda bu alan boş bırakılır.

Tüm seçimler tamamlandıktan sonra Next butonuna basılarak taşıma işleminin oluşturulması için bir sonraki adıma geçilir.

Bu ekran, CSV ile toplu taşıma operasyonunun en kritik noktasıdır; çünkü tüm batch’in nasıl çalışacağı, nereye taşınacağı ve archive mailbox davranışının nasıl olacağı burada net şekilde belirlenir.

Mailbox taşıma yapılandırması tamamlandıktan sonra, işlem “Start the batch” ekranına gelir. Bu bölüm, oluşturulan migration batch’in ne zaman başlatılacağını, nasıl tamamlanacağını ve işlem sonuç raporlarının kime gönderileceğini belirlediğiniz son adımdır.

Ekranda ilk olarak rapor alıcıları (report recipients) tanımlanır. Taşıma batch’i tamamlandığında Exchange otomatik olarak bir özet raporu e-posta olarak gönderir. Bu nedenle en az bir yönetici hesabının seçilmesi zorunludur. Örnekte admexch kullanıcısı rapor alıcısı olarak eklenmiştir.

Ardından batch’in ne zaman başlatılacağı seçilir:

• Manually start the batch later Batch hemen başlatılmaz. Migration Dashboard üzerinden yönetici tarafından elle başlatılması gerekir. Bu seçenek, taşıma işlemini belirli bir bakım saatine veya planlanmış zaman penceresine göre başlatmak isteyenler için uygundur.
• Automatically start the batch Batch oluşturulur oluşturulmaz otomatik olarak çalışmaya başlar. Küçük taşıma operasyonlarında veya acil durumlarda genellikle bu seçenek tercih edilir.

Son olarak batch’in nasıl tamamlanacağı belirlenir:

• Manual Complete the batch Taşıma bitse bile batch otomatik kapanmaz. Yönetici, dashboard üzerinden “Complete this migration batch” seçeneğine tıklayarak işlemi elle tamamlar.
  Özellikle kritik taşımalarda, yöneticinin son kontrolleri yapmasına imkân tanır.
• Automatically complete the migration batch Tüm mailbox’lar taşındığında batch otomatik olarak kapatılır ve işlem sonlandırılır.
  Standart operasyonlarda en sık kullanılan seçenektir.

Tüm ayarlar yapıldıktan sonra “new” butonuna basılarak migration batch resmen oluşturulur ve planlanan şekilde çalışmaya başlar. Bu ekran, batch’in zamanlaması ve otomasyon seviyesini belirlediği için taşıma operasyonunda kritik bir adımdır.

Migration batch oluşturulduktan sonra Exchange Control Panel (ECP), taşıma işlemini gerçek zamanlı olarak takip edebileceğiniz ayrıntılı bir izleme ekranı sunar. Bu ekran, CSV ile başlattığınız Database84-MoveList batch’i içindeki tüm kullanıcıların durumunu tek bir yerden görmenizi sağlar.

Her bir posta kutusu için Identity, Status, Items Migrated ve Items Skipped gibi kritik bilgiler yer alır. Bu aşamada kullanıcıların büyük çoğunluğu “Validating” durumunda görünür. Bu durum, Exchange’in taşıma işlemine başlamadan önce ilgili posta kutusunu kontrol ettiği anlamına gelir. Validating aşaması şu kontrolleri içerir:

• Mailbox’ın mevcut database üzerinde erişilebilir olup olmadığı
• Hedef database’in uygunluğu
• Kullanıcı üzerinde devam eden başka bir taşıma veya bakım görevinin bulunmaması
• Archive mailbox’ın durumunun doğrulanması
• Veritabanları arasındaki bağlantı ve replikasyon sağlığı

Validating aşaması başarılı şekilde tamamlandığında, move request otomatik olarak Queued → InProgress → Completed adımlarına ilerler.

Sağ taraftaki detay panelinde seçili kullanıcıya ait daha fazla bilgi görüntülenir:

• Status: Kullanıcının mevcut taşıma aşaması
• Skipped item details: Taşıma sırasında atlanan veya kopyalanamayan öğeler varsa burada görüntülenir
• Migration rate: Veri kopyalanmaya başladıktan sonra hız bilgisi
• Report: Kullanıcı bazında detaylı taşıma raporunu indirmenizi sağlar

Bu ekran sayesinde, 80 mailbox gibi büyük hacimli taşıma operasyonlarında bile her bir posta kutusunun anlık durumunu, olası hataları ve taşıma ilerlemesini merkezi olarak izlemek mümkündür.

5. Mailbox Database Optimizasyonu İçin En Etkili Yöntem

Microsoft Exchange Server altyapılarında veritabanı performansını korumak, yüksek erişilebilirlik yapısını sürdürülebilir kılmak ve kullanıcı deneyimini kesintisiz hale getirmek modern kurumsal işletmeler için kritik önem taşır. Zaman içinde büyüyen EDB dosyaları, artan white space miktarı, yoğun kullanıcı trafiği ve arka plan bakım süreçleri veritabanı yükünü artırarak performans darboğazlarına yol açabilir.

Bu makalede Exchange Mailbox Database optimizasyonunu proaktif izleme, white space yönetimi ve en güvenli yöntem olan Mailbox Move Request süreçleriyle bütünsel bir bakış açısıyla ele aldık.

5.1 Proaktif İzleme – Sorunları Oluşmadan Önce Fark Etme

Azure Monitor gibi modern izleme çözümleri, fiziksel disk gecikmelerinden RPC bağlantı durumlarına kadar tüm kritik metrikleri takip ederek olası performans düşüşlerini daha kullanıcılar hissetmeden görünür kılar. Bu da optimizasyon kararlarının doğru zamanda alınmasını sağlar.

5.2 White Space Yönetimi – Mantıksal Boşluğun Doğru Yorumlanması

Exchange veritabanları silinen veriler nedeniyle oluşan white space alanını otomatik olarak küçültmez. Bu alan kritik öneme sahiptir; çünkü database boyutu aynı kalsa bile içeride mantıksal boşluk büyür ve veritabanı verimliliğini olumsuz etkiler. Bu yüzden white space analizi, optimizasyon sürecinin ilk adımıdır.

5.3 Mailbox Move Request – Kesintisiz ve Kontrollü Optimizasyon

Offline defragmentation gibi yöntemlerin kesinti, risk ve operasyonel zorluklar içermesi nedeniyle güncel Exchange altyapılarında en çok tercih edilen yol Mailbox Move Request yöntemidir.
Bu yöntem sayesinde:

• Kullanıcı erişimi kesilmez
• Veritabanı iç yapısı yeniden düzenlenir
• White space temizlenmiş olur
• Yeni database üzerinde daha stabil bir yapı elde edilir
• DAG içinde güvenli şekilde uygulanabilir

Migration süreci hem tek tek PowerShell komutlarıyla hem de CSV dosyasıyla toplu şekilde yönetilebilir. Bu makalede her iki yöntemi de ekran görüntüleri ve örnek komutlarla detaylı şekilde açıkladık.

Sonuç olarak Exchange altyapısında uzun vadeli sağlık, stabil performans ve sürdürülebilir yönetim için aşağıdaki üçlü yaklaşım artık standart bir ihtiyaçtır:

• Doğru izleme
• Doğru analiz
• Doğru taşıma (Move Request)

Bu yaklaşım sayesinde veritabanları:

• daha verimli çalışır,
• beklenmedik kapasite taşmaları engellenir,
• archivelı kullanıcılar sorun yaratmadan yönetilir,
• DAG ortamları daha stabil hale gelir,
• operasyonlar kontrollü ve kestirilebilir olur.

Pera Bilgi Sistemleri olarak, yönettiğimiz müşterilerde bu üç adımı standartlaştırarak hem güvenli hem de performans odaklı bir Exchange Server mimarisi sunuyoruz.

Exchange Server Database Optimization konusunu uçtan uca ele alan bu rehberin, kendi ortamınızda benzer bir iyileştirme süreci planlarken yol gösterici olacağını düşünüyoruz. Sorularınız veya ihtiyaç duyduğunuz özel senaryolar için bizimle her zaman iletişime geçebilirsiniz.