Exchange Server’da Retention Policy Yönetimi
Mail ortamlarında en çok ihmal edilen konulardan biri retention policy yönetimidir. Yıllarca çalışmış Exchange ortamlarını devraldığımda, posta kutularının dolup taştığını, kullanıcıların “silmek istemiyorum ama yerim de yok” diye şikayet ettiğini ve IT ekibinin storage alarmlarıyla boğuştuğunu görüyorum. Oysa doğru kurgulanmış bir retention policy hem uyumluluk gereksinimlerini karşılar hem de sistemi nefes aldırır. Bu yazıda Exchange Server’da retention policy yönetimini, gerçek dünya senaryolarıyla ve elle tutulur komutlarla anlatacağım.
Retention Policy Nedir ve Neden Önemlidir
Exchange Server’da retention policy, belirli bir süre sonra mesajlara ne olacağını tanımlayan kural setidir. Mesajlar silinebilir, arşive taşınabilir ya da belirli bir klasörde tutulabilir. Bu yapı hem KVKK uyumluluğu hem de şirket iç politikaları açısından kritiktir.
Türkiye’deki birçok kurumda şunu görüyorum: Mail arşivleme “Gönderilen Öğeler” klasörünün dolmasına izin vermek olarak algılanıyor. Bu yanlış anlayış, hem storage maliyetlerini artırıyor hem de bir ihlal ya da denetim durumunda kurumu savunmasız bırakıyor. Retention policy, bu kaosun önüne geçmek için var.
Exchange’de iki temel kavram üzerine kurulmuştur bu yapı:
- Retention Tag (Saklama Etiketi): Belirli bir klasöre veya mesaj tipine uygulanır. Süre ve eylem tanımlar.
- Retention Policy (Saklama İlkesi): Bir veya daha fazla retention tag’i bir araya getirerek posta kutusuna atanır.
Exchange Management Shell ile Temel Komutlar
Önce mevcut durumu görmek gerekir. Yeni bir ortama girdiğimde ilk çalıştırdığım komutlar şunlardır:
# Mevcut retention tag'leri listele
Get-RetentionPolicyTag | Format-Table Name, Type, AgeLimitForRetention, RetentionAction
# Mevcut retention policy'leri listele
Get-RetentionPolicy | Format-Table Name, RetentionPolicyTagLinks
# Hangi posta kutusuna hangi policy atanmış?
Get-Mailbox -ResultSize Unlimited | Select-Object DisplayName, RetentionPolicy | Sort-Object RetentionPolicy
Bu üç komutla ortamın genel fotoğrafını çekebilirsiniz. Çoğu zaman “Default MRM Policy” atanmış ama hiç özelleştirilmemiş onlarca posta kutusu görürsünüz.
Retention Tag Tipleri
Retention tag oluştururken tip seçimi çok önemlidir. Yanlış tip seçimi beklediğiniz davranışı vermez.
- All (Default Policy Tag): Posta kutusundaki tüm öğelere uygulanır, başka tag yoksa devreye girer
- Inbox: Gelen Kutusu klasörüne özgü kural
- SentItems: Gönderilen öğeler için
- DeletedItems: Silinmiş öğeler klasörü
- Calendar: Takvim öğeleri
- Tasks: Görevler
- Notes: Notlar
- Contacts: Kişiler
- RecoverableItems: Kurtarılabilir öğeler klasörü
- Personal: Kullanıcının kendi oluşturduğu klasörlere uygulayabileceği etiketler
Retention Action Seçenekleri
Bir tag oluştururken hangi eylemin gerçekleşeceğini de tanımlamanız gerekir:
- DeleteAndAllowRecovery: Siler, geri dönüşüm kutusuna taşır
- PermanentlyDelete: Kalıcı siler, kurtarılamaz
- MoveToArchive: Arşiv posta kutusuna taşır
- MoveToDeletedItems: Silinmiş öğeler klasörüne taşır
Gerçek Dünya Senaryosu 1: Standart Kurumsal Retention Policy
Diyelim ki orta ölçekli bir şirket için retention policy kuruyorsunuz. Gereksinimler şöyle:
- Gelen kutusu: 1 yıl sonra arşive taşı
- Gönderilen öğeler: 6 ay sonra arşive taşı
- Silinmiş öğeler: 30 gün sonra kalıcı sil
- Junk mail: 14 gün sonra kalıcı sil
- Genel kutu politikası: 2 yıl sonra arşive taşı
# Gelen kutusu tag'i: 365 gün sonra arşive taşı
New-RetentionPolicyTag -Name "Inbox - 1 Yil Arsiv" `
-Type Inbox `
-AgeLimitForRetention 365 `
-RetentionAction MoveToArchive
# Gönderilen öğeler: 180 gün sonra arşive taşı
New-RetentionPolicyTag -Name "Gonderilen - 6 Ay Arsiv" `
-Type SentItems `
-AgeLimitForRetention 180 `
-RetentionAction MoveToArchive
# Silinmiş öğeler: 30 gün sonra kalıcı sil
New-RetentionPolicyTag -Name "Silinmis - 30 Gun Kalici Sil" `
-Type DeletedItems `
-AgeLimitForRetention 30 `
-RetentionAction PermanentlyDelete
# Junk mail: 14 gün sonra kalıcı sil
New-RetentionPolicyTag -Name "Junk - 14 Gun Sil" `
-Type JunkEmail `
-AgeLimitForRetention 14 `
-RetentionAction PermanentlyDelete
# Default policy tag: 2 yıl sonra arşive taşı (genel kural)
New-RetentionPolicyTag -Name "Genel - 2 Yil Arsiv" `
-Type All `
-AgeLimitForRetention 730 `
-RetentionAction MoveToArchive
# Tüm tag'leri bir araya getir
New-RetentionPolicy -Name "Kurumsal Standart Policy" `
-RetentionPolicyTagLinks "Inbox - 1 Yil Arsiv", `
"Gonderilen - 6 Ay Arsiv", `
"Silinmis - 30 Gun Kalici Sil", `
"Junk - 14 Gun Sil", `
"Genel - 2 Yil Arsiv"
Policy’yi oluşturduktan sonra posta kutularına atayın:
# Tüm kullanıcılara tek seferde uygula
Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | `
Set-Mailbox -RetentionPolicy "Kurumsal Standart Policy"
# Tek bir kullanıcıya uygula
Set-Mailbox -Identity "ahmet.yilmaz" -RetentionPolicy "Kurumsal Standart Policy"
# Belirli bir OU'daki kullanıcılara uygula
Get-Mailbox -OrganizationalUnit "OU=Muhasebe,DC=sirket,DC=local" | `
Set-Mailbox -RetentionPolicy "Kurumsal Standart Policy"
Managed Folder Assistant: Policy’nin Motoru
Retention policy’yi atamak yetmez. Arkada çalışan Managed Folder Assistant (MFA) bu kuralları fiilen uygular. Varsayılan olarak her gün bir kez çalışır ama manuel tetiklemek de mümkündür.
# Managed Folder Assistant'ı tüm sunucu için başlat
Start-ManagedFolderAssistant -Server "MAILSERVER01"
# Tek bir posta kutusu için tetikle
Start-ManagedFolderAssistant -Identity "ahmet.yilmaz"
# MFA'nın ne zaman çalıştığını kontrol et
Get-MailboxServer -Identity "MAILSERVER01" | `
Select-Object ManagedFolderAssistantSchedule
MFA’nın çalışma zamanını özelleştirmek isterseniz:
# MFA'yı gece 02:00 - 06:00 arası çalışacak şekilde ayarla
Set-MailboxServer -Identity "MAILSERVER01" `
-ManagedFolderAssistantSchedule "Sun.2:00 AM-Sun.6:00 AM, Mon.2:00 AM-Mon.6:00 AM, Tue.2:00 AM-Tue.6:00 AM, Wed.2:00 AM-Wed.6:00 AM, Thu.2:00 AM-Thu.6:00 AM, Fri.2:00 AM-Fri.6:00 AM, Sat.2:00 AM-Sat.6:00 AM"
Yoğun saatlerde MFA, disk I/O’yu ciddi şekilde artırabilir. Bu nedenle düşük trafikli saatlere ayarlamak iyi bir pratiktir.
Gerçek Dünya Senaryosu 2: Departman Bazlı Farklı Policy’ler
Hukuk departmanı için mevzuat gereği 5 yıl saklama gerekiyorken, pazarlama ekibinin maillerinin 1 yıl sonra arşive gitmesi yeterli olabilir. Bunun için farklı policy’ler oluşturmanız gerekir.
# Hukuk departmanı için özel tag
New-RetentionPolicyTag -Name "Hukuk - 5 Yil Sakla" `
-Type All `
-AgeLimitForRetention 1825 `
-RetentionAction MoveToArchive
# Hukuk policy'si
New-RetentionPolicy -Name "Hukuk Departmani Policy" `
-RetentionPolicyTagLinks "Hukuk - 5 Yil Sakla", `
"Silinmis - 30 Gun Kalici Sil", `
"Junk - 14 Gun Sil"
# Hukuk departmanı kullanıcılarına ata
Get-Mailbox -OrganizationalUnit "OU=Hukuk,DC=sirket,DC=local" | `
Set-Mailbox -RetentionPolicy "Hukuk Departmani Policy"
Personal Tag Kullanımı ve Kullanıcı Kontrolü
Retention policy yönetiminin gözden kaçan boyutu kullanıcı deneyimidir. Outlook üzerinden kullanıcıların kendi klasörlerine farklı retention tag uygulayabilmesine izin verebilirsiniz. Bunun için Personal tipte tag’ler oluşturun.
# Kullanıcıların seçebileceği "asla silme" tag'i
New-RetentionPolicyTag -Name "Onemli - Sakla" `
-Type Personal `
-RetentionEnabled $false
# Kullanıcıların seçebileceği 1 yıllık kişisel tag
New-RetentionPolicyTag -Name "Kisisel - 1 Yil Sonra Sil" `
-Type Personal `
-AgeLimitForRetention 365 `
-RetentionAction DeleteAndAllowRecovery
# Bu tag'leri mevcut policy'ye ekle
Set-RetentionPolicy -Identity "Kurumsal Standart Policy" `
-RetentionPolicyTagLinks "Inbox - 1 Yil Arsiv", `
"Gonderilen - 6 Ay Arsiv", `
"Silinmis - 30 Gun Kalici Sil", `
"Junk - 14 Gun Sil", `
"Genel - 2 Yil Arsiv", `
"Onemli - Sakla", `
"Kisisel - 1 Yil Sonra Sil"
Burada dikkat edilmesi gereken bir nokta var: Bir policy’ye çok fazla tag eklemek Outlook’ta karmaşıklık yaratır. Kullanıcıya sunulacak seçenek sayısını makul tutmak gerekir.
Litigation Hold ile Retention Policy İlişkisi
Sık karşılaşılan bir soru: Litigation Hold aktifken retention policy çalışır mı? Kısa cevap: çalışır ama silme işlemleri gerçekten gerçekleşmez.
Litigation Hold etkin bir posta kutusunda, retention policy öğeleri “silinmiş” olarak işaretler ama RecoverableItems klasöründe saklamaya devam eder. Bu durum storage açısından kritik bir öneme sahiptir. Litigation Hold aktif olan posta kutuları için storage büyümesini mutlaka izleyin.
# Litigation Hold aktif posta kutularını listele
Get-Mailbox -ResultSize Unlimited | `
Where-Object {$_.LitigationHoldEnabled -eq $true} | `
Select-Object DisplayName, LitigationHoldEnabled, LitigationHoldDuration
# Posta kutusunun RecoverableItems boyutunu kontrol et
Get-MailboxStatistics -Identity "ahmet.yilmaz" | `
Select-Object DisplayName, TotalDeletedItemSize, TotalItemSize
Policy Uygulamasını Doğrulama ve Sorun Giderme
Policy atandı, MFA çalıştı ama maillerin yaşlanmadığını görüyorsunuz. Bu durumda debug adımlarım şöyle:
# Posta kutusuna hangi policy atandığını doğrula
Get-Mailbox -Identity "ahmet.yilmaz" | Select-Object RetentionPolicy, RetentionHoldEnabled
# Policy'deki tag'leri listele
(Get-RetentionPolicy "Kurumsal Standart Policy").RetentionPolicyTagLinks | `
Get-RetentionPolicyTag | `
Select-Object Name, Type, AgeLimitForRetention, RetentionAction, RetentionEnabled
# Posta kutusundaki öğelerin retention bilgisini al
Get-MailboxFolderStatistics -Identity "ahmet.yilmaz" -IncludeOldestAndNewestItems | `
Select-Object Name, ItemsInFolder, OldestItemReceivedDate, NewestItemReceivedDate
# Retention hold aktif mi? (Bu aktifse MFA çalışmaz)
Get-Mailbox -Identity "ahmet.yilmaz" | Select-Object RetentionHoldEnabled, EndDateForRetentionHold
RetentionHoldEnabled true ise, o posta kutusu için retention geçici olarak durdurulmuş demektir. Tatil dönüşleri ya da özel durumlar için kullanışlıdır ama unutulursa ciddi sorunlara yol açar.
# Retention hold'u kaldır
Set-Mailbox -Identity "ahmet.yilmaz" -RetentionHoldEnabled $false
Exchange Admin Center ile Yönetim
EAC üzerinden de bu işlemlerin büyük kısmını yapabilirsiniz. Compliance Management > Retention Policies yolu sizi doğru yere götürür. Ancak şunu söyleyeyim: Ondan fazla posta kutusunu etkileyen değişiklikleri her zaman PowerShell ile yapın. EAC’da gözden kaçırmak kolaydır, PowerShell’de her şey kayıt altındadır.
Ayrıca EAC bazı gelişmiş filtreleme seçeneklerini sunmaz. Örneğin belirli bir OU’daki ya da belirli bir attribute değerine sahip kullanıcılara toplu atama yapmak için mutlaka shell kullanmanız gerekir.
Raporlama ve İzleme
Retention policy yönetimi, bir kez kurup unutulan bir şey değildir. Düzenli raporlama şarttır.
# Tüm posta kutularının policy durumu raporu
Get-Mailbox -ResultSize Unlimited | `
Select-Object DisplayName, PrimarySmtpAddress, RetentionPolicy, `
RetentionHoldEnabled, LitigationHoldEnabled | `
Export-Csv -Path "C:Reportsretention_raporu.csv" -NoTypeInformation -Encoding UTF8
# Policy atanmamış posta kutularını bul
Get-Mailbox -ResultSize Unlimited | `
Where-Object {$_.RetentionPolicy -eq $null} | `
Select-Object DisplayName, PrimarySmtpAddress
Bu raporu aylık almak ve gözden geçirmek, hem uyumluluk hem de sorun önleme açısından değerlidir. Yeni açılan posta kutularının policy almadığını bu şekilde fark edebilirsiniz.
Yaygın Hatalar ve Dikkat Edilmesi Gerekenler
Yıllar içinde gördüğüm hataları listeliyorum:
- Policy atamak MFA’nın çalışacağı anlamına gelmez: MFA’nın aktif ve düzgün schedule edilmiş olduğunu kontrol edin.
- AgeLimitForRetention mesajın alındığı tarihe göre çalışır: Mesajı taşıdığınızda veya kopyaladığınızda tarih değişmez, orijinal tarih baz alınır.
- Personal tag’ler DPT’yi override eder: Kullanıcı bir klasöre personal tag uyguladıysa, default policy tag o klasörde geçersiz kalır.
- Arşiv posta kutusu yoksa MoveToArchive çalışmaz: Arşiv hedefli policy atamadan önce in-place archive aktif olduğundan emin olun.
- Exchange Online ile Exchange On-Premises farkı: Exchange Online’da Compliance Center üzerinden farklı bir yapıyla yönetilir, buradaki komutlar doğrudan geçerli olmayabilir.
Sonuç
Exchange’de retention policy yönetimi, kulağa kuru bir uyumluluk konusu gibi gelebilir ama aslında posta altyapısının sağlığını doğrudan etkileyen kritik bir operasyonel görevdir. Doğru kurgulanmış bir policy seti storage maliyetlerini kontrol altına alır, kullanıcıların posta kutusu dolmadan verimli çalışmasını sağlar ve olası hukuki ya da denetim süreçlerinde sizi korur.
En temel tavsiyem şu: Önce mevcut durumu haritalayın, sonra iş birimiyle konuşarak gerçek saklama gereksinimlerini anlayın, ardından policy’leri oluşturun ve test ortamında doğrulayın. Canlıya geçerken de düzenli raporlamayı ihmal etmeyin. Retention policy, bir kez kurulan değil sürekli izlenen bir yapıdır.
