Exchange Server organizasyonlarında ortak posta kutusu kullanımı veya ajanda, klasör bazlı paylaşımları pek çok kez görebiliriz. En bilindik senaryo olan üst düzey yöneticilerin ajandalarını asistanları ile paylaması gibi. Bu örnek senaryolarda kullanıcı kendi posta kutusundaki istediği bir klasörü paylaştırabilmektedir.

Örneğin ben kendi posta kutum içerisindeki Inbox klasörüne sağ tıklatıp özellikler bölümünden istediğim kullanıcıya yetki verebiliyorum

Benze durum ajanda paylaşımı içinde geçerlidir;

Ancak bizim ihtiyacımız tüm posta kutusuna erişim ise bu durumda sistem yöneticisinin aksiyon alması gerekmektedir. Yani Exchange yönetim konsolu üzerinden “Managed Full Access Permission” izni vermelidir.

Bu izin ise tahmin edebileceğiniz gibi çok fazla yetki içerdiği için bizim bu makalede konu alan sadece bir posta kutusunu ( tüm klasörleri ile ) izleme yani okuma izni vermemiz gereken senaryolar olabilir. Bu izni ne yazık ki ne Outlook üzerinden ne de Exchange konsol üzerinden veremiyoruz. Bunun için kullanacağımız Powershell “Add-MailboxFolderPermission” olup örnekler ile çözüm üreteceğiz.

Add-MailboxFolderPermission -Identity serkanuzuner:\ -User huzuner -AccessRights Reviewer

Yukarıdaki komut, Hakan kullanıcısına, Serkan kullanıcısının posta kutusunda en üst seviyeden izin verir.

Ancak bu izin miras olarak alt kademelere gitmediği için ek olarak görmek istediğiniz klasörleri de PS ile yetkilendirmeniz gereklidir.

Add-MailboxFolderPermission -Identity serkanuzuner:\inbox -User huzuner -AccessRights Reviewer

Add-MailboxFolderPermission -Identity serkanuzuner:\ Calendar -User huzuner -AccessRights Reviewer

Yukarıdaki komutları kullanabilirsiniz. Ancak tahmin edeceğiniz gibi bunları tek tek çalıştırmak zor olacaktır, bu nedenle Paul Cunningham tarafından hazırlanmış olan aşağıdaki PS komut seti ile tüm posta kutusu için okuma izni verebilirsiniz

https://github.com/cunninghamp/Powershell-Exchange/tree/master/MailboxFolderPermissions

Burada iki komut seti olup birisi izin vermek için kullanılırken diğeri bu izinleri almak için kullanılmaktadır.

Bu PS komutlarını indirdikten sonra kullanımı aşağıdaki gibidir;

MailboxFolderPermissions.ps1 -Mailbox serkanuzuner -User huzuner -Access reviewer

PS1 dosyasını hangi isim ile kayıt ettiyseniz siz o şekilde çalıştırabilirsiniz, ben MailboxFolderPermissions olarak kayıt etmiştim, sonuç aşağıdaki gibidir;

Bundan önce elle birkaç tane izin verdiğim için ana dizinde ve ajanda için hali hazırda izin olduğunu söyledi ve diğer tüm klasörler için yetki tanımlamasını gerçekleştirdi.

Artık tüm posta kutusunu Outlook üzerine ekleyebilirsiniz

Bağlantı kurduktan sonra aşağıdaki gibi posta kutusundaki öğeleri görüntüleyebiliyoruz

Ancak silmeye kalktığımızda yetkimizin olmadığını gösteren bir uyarı görüyoruz

Bu yetkiyi kaldırmak için ise aşağıdaki komut setini kullanabiliriz

.\Remove-MailboxFolderPermissions.ps1 -Mailbox serkanuzuner -user huzuner

Not: buradaki Remove-MailboxFolderPermissions.ps1 yine internet üzerinden indirdiğiniz komut seti olup nasıl kayıt etti iseniz o şekilde çağırın lütfen.

Artık posta kutusunu görüntüleme yetkimiz bulunmamaktadır.

Umarım faydalı bir makale olmuştur, bir sonraki makalemde görüşmek üzere

Kaynak

https://github.com/cunninghamp/Powershell-Exchange/tree/master/MailboxFolderPermissions

(202)

Exchange Server 2013 kullanıcıları kimi zaman bu exe’ nin çok CPU veya RAM tükettiğine şahit olabilirler. Bu exe, Exchange Server Search sisteminin bir bileşeni olup maillerinizin indekslenmesi için kullanılır. Yani bu exe çalışıyor ise mailleriniz OWA ve Outlook online aramaları için ( tabiki active sync vb içinde geçerlidir ) daha hızlı sonuçlar almanızı sağlar.

Eğer posta kutusu taşıma, yeni kurulumlar veya taşıma işlemleri yapmış iseniz beklediğinizden fazla kaynak tüketebilir. Yani örneğin sisteminizde 32GB ram var ve sorunsuz bir şekilde çalışıyor, bir gün RAM kullanımı %100 oldu ve baktığınız zaman bu kullanımın noderunner.exe üzerinden gerçekleştiğini gördünüz, bu durumda toplu bir taşıma işlemi gerçekleşmiş olabilir, mevcut arama indeksleriniz bozulmuş yenileniyor olabilir veya servisi durdurmuşsunuzdur (Microsoft Exchange Search Host Controller servisi yama yüklerken servis disable konuma gelir belki tekrar eski hala gelmemiş ve gözünüzden kaçmış olabilir ) bu servisi tekrar açtığınız zaman bu sefer indeksleme tekrar yüksek kaynak kullanmaya başlar. Eğer o anda ciddi bir kaynak sorunu teşkil ediyor ise servislerden Microsoft Exchange Search Host Controller servisini geçici olarak durdurmanız kaynak kullanımını düşürecektir, daha sonra ise yani akşam saatlerinde servisi açarak indeks işleminin kaldığı yerden devam etmesini sağlayabilirsiniz.

(105)

8 Mart 2007 yılında aramıza katılan Exchange Server 2007 için artık yolun sonuna az bir zaman kaldı. Exchange Server 2007’nin standart desteği 10 Nisan 2012’de sonlanmıştı. Ancak ek sunulan genişletilmiş destek süresi de 11 Nisan 2017’de tamamlanacak. Bu tarihten sonra yeni güvenlik güncelleştirmeleri, güvenlikle ilgili olmayan düzeltmeler, ücretsiz veya ücret karşılığında destekli yardım seçenekleri ya da çevrimiçi teknik içerik güncelleştirmeleri sağlanamayacak. Bunlara ek olarak Outlook 2016 kullanıcıları da, Exchange Server 2007 ile çalışma opsiyonuna sahip olamayacaklar.

İşinizi riske atmayın!

Kurumlarda en temel alt yapı ürünlerinden biri olan Exchange Server için zaman kaybetmeden aksiyon almanız şirketinizin daha güvenli ve istikrarlı bir e-posta alt yapısına kavuşması açısından önemli bir karar olacaktır.

Geçiş için fayda/maliyet analizi yapıldığında, Türkiye’de birçok kurum gibi siz de e-posta altyapınızı Office 365’e güncelleyerek 50 GB kapasiteli e-posta ve sınırsız arşiv hizmetini çok daha ekonomik ve ölçeklenebilir modelde alabilirsiniz. Böylece yedekleme, anti virüs, anti spam, barındırma, bilgisayar gücü, disk kapasitesi, sertifika, güncelleme ve benzeri maliyetleri azaltmış olursunuz.
Office 365 için Sınırlı Süreli Teklif!

Genişletilmiş desteği de sona erecek olan Exchange Server 2007 altyapınızı 30 Haziran 2016 tarihine kadar Office 365’e güncellediğiniz takdirde Microsoft olarak Office 365 e-posta planlama ve geçiş sürecinizde size destek oluyoruz*.

Ayrıntılı bilgi için müşteri temsilciniz ya da iş ortağınız ile iletişime geçiniz.
*E-posta geçiş hizmeti, Microsoft Fasttrack tarafından en az 50 kullanıcı için uygun Office 365 planı satın alındığında sağlanmaktadır.

(49)

Exchange Server gibi son kullanıcı etkileşimi son derece yüksek olan ürünlerin izlenmesi her sistem yöneticisi için kritik bir iştir. Öncelikle son kullanıcıların memnuniyeti açısından günümüzün en çok kullanılan iletişim araçlarından olan mail sisteminin kesintisiz çalışması gereklidir. Bu nedenle biz sistem yöneticileri Microsoft System Center ürün ailesinden Operation Manager veya benzeri 3 parti programlar ile özellikle servisleri, disk durumunu, kuyruktaki mailler ve benzeri olayları yakından takip ederiz. Ancak bir sorun çıktığında ki bu ürünlerin de bize bilgi vermesi ile heyecan başlar. Eğer disk dolması veya bir servis durması ise bir nebze kök nedeni bulmak ve sorunu çözmek daha kolay olabilir, ancak her sistemci için en can sıkıcı sorun “yavaşlık” sorunudur. Yani son derece değişken ve her kullanıcıya göre göreceli ola bu kavram kimi zaman “mailler çalışmıyor” yorumuna kadar ilerler. Böyle bir durumda tabi ki tecrübeli mail sistemi yöneten uzmanlar ( özellikle 1000 ve kullanıcı üstü mail sistemi yöneten pek çok sistem mühendisi arkadaşım en azından böyle yapıyor ) zaten alışkın olduğu için bu konuda bir ürün satıl almış oluyor ve bunun üzerinden kök nedeni bulmaya çalışıyor. Ancak herkes bu kadar şanslı olmayabilir, yani elinizde performans noktasındaki sorunları size raporlayacak bir ürününüz yok ise önerim ücretsiz olan ExMon kullanmanız olacaktır.

Peki bu ürün bize ne tür bilgiler sunmaktadır, Exmon ile aşağıdaki bilgileri istatistik olarak alabiliriz

• RPC data based on the user
• RPC data based on the RPC Operation
• RPC data based on the specific application
• RPC data based on the Admin Client Type
• RPC data in the Raw form
• RPC data in the Admin Raw form
• RPC data in the Task by client Type
• RPC data in the Task raw

Yine her bir başlık için kullanın Outlook sürümü veya bağlantı modelini, CPU kullanımını, gecikmeleri, yaptığı operasyonları görebiliriz.

Temel olarak aslında ExMon, hangi kullanıcının sunucu kaynaklarını aşırı kullanarak ( CPU, network vb ) soruna neden olduğunu tespit etmek için kullanılır.

Ancak bu ürün ile neleri yapamayacağınızı iyi biliyor olmanız gerekli.

Örneğin size toplu bir mail saldırıcı olduğunda bu araç yardımcı olamaz, zaten böyle bir durumda SMTP gateway veya SMTP protokol loğlarından siz bunu tespit edebilirsiniz.

Yine benzer şekilde MAPI client olmayan bağlantıları yani POP ve IMAP desteği yoktur.

Benzer şekilde bazı Active Sync trafiği içinde kullanılamaz. ( hepsi değil yani active sync trafiğini uygulama sekmesinde görebiliyorsunuz )

Özetle daha çok Outlook kaynaklı sorunlar için kullanılabilir şeklinde özetleyebiliriz.

Kurulum için mutlaka bir Mailbox server olması gereklidir, her bir mailbox server için ayrı ayrı kurabilirsiniz, ama genelde sorun yaşayan mailbox server da kurulmaktadır. Yani özetle bir mailbox server a kurup tüm organizasyondaki mailbox sunucularından bilgi çekemezsiniz.

Ürünün kurulumu son derece kolaydır, aşağıdaki link üzerinden indirip kurulumu gerçekleştirebilirsiniz.

https://www.microsoft.com/en-us/download/details.aspx?id=51101

Ürünü kurduktan sonra temel iki veri toplama özelliğinden birini kullanabilirsiniz. Eğer o anlık hızlı bir şekilde sunucuda neler oluyor bakmak isterseniz ExMon varsayılan olarak 1dk aralıklar ile veri toplar (ETL dosya uzantısı ile ve bunu kurulum dizininde tutar) ve size bunu sunar.

Eğer uzun soluklu veri toplayıp yorumlamak istiyorsanız (bunu istemiyorsanız lütfen bu komutları geçiniz, yani Exmon kullanımı için şart değildir) https://technet.microsoft.com/en-us/library/bb490956.aspx adresinden detaylı bilgi alabileceğiniz logman komut setini kullanabilirsiniz.

Öncelikle aşağıdaki komut ile bir sağlayıcı oluturuyoruz ( yani exmon un anlayacağı bir veri tipi toplamaya çalışıyoruz)

logman create trace Exmon_Trace -p {2EACCEDF-8648-453e-9250-27F0069F71D2} -o c:\Tracing\exmon

Komutun sağlıklı çalışıp çalışmadığını kontrol etmek için logman yazmanız yeterli

Şimdi toplama işlemini başlatıyoruz

logman start Exmon_Trace

Yeterince veri toplandığını düşündüğünüz ancak ki bu bir gün de olabilir bir saat veya ihtiyacınız kadar aşağıdaki komut ile durduruyoruz.

logman stop Exmon_Trace

Daha sonra ilgili dizinde dosyanın oluştuğunu görebiliyoruz

Daha sonra bu dosyayı ExMon ile görüntülemek için dosya bölümünden açmanız yeterli olacaktır

Peki, ExMon üzerinde neler görebiliyoruz?

Öncelikle ExMon programını açın ve üst menüde yer alan start butonuna basın, daha sonra 1dk bekleyin ( veya tazele butonuna basınız ), karşınıza aşağıdaki gibi son 1dk içerisindeki bağlantı bilgileri gelecektir

Canlı bir sistemde tabiki burada daha ok satır olacaktır. Şu anda benim sistemime bağlı 3 kullanıcı görüyorum ki zaten ikisi Sistem posta kutusu.

Üst menüde görebileceğiniz gibi ExRPc sekmesi varsayılan sekme olup burada kullanıcı bazlı, operasyon bazlı, uygulama bazlı veya istemci sürüm bazlı gibi gelen bu isteklerin gruplanmış halde görebiliriz.

Örneğin ikinci sekmeye bastığımız zaman aşağıdaki gibi bir ekran gelecektir

Sizinde görebileceğiniz gibi istemcilerin yaptıkları operasyonlara göre bir rapor alabilirsiniz, yani “OpenFolder” açılan klasörleri temsil eder, 73 adet bu operasyondan yapılmış son 1dk içerisinde benzer şekilde “CreateMesage” yine son 1 dk içerisinde iki mesaj oluşturulduğunu gösteriyor.

Uygulamaya göre bakmak istersek yine yukarıda görebileceğiniz gibi PRC bağlantısı, OWA bağlantısı, Active Sync bağlantısını görebiliyoruz. Örneğin Hakan.Uzu olarak görünen bu ActiveSync bağlantısı bana ait olup eğer detaylı incelemek istiyorsanız üstüne çift tıklamanız yeterlidir.

Pencerenin üst bölümünde bu kullanıcı için active sync bağlantısı üzerinden yapılan paket hareketleri, operasyonlar, aldığı hata, CPU kullanımı gibi değerleri görebiliyoruz.

Bu özelliği her bir rapor sekmesinde yine her bir satır için kullanabilirsiniz.

En çok kullanılan sekmeler aşağıdaki gibidir;

• User View
• Operation View
• Application View
• Version View
• Raw View

Örneğin kullanıcı görünümde aşağıdaki temel bilgileri alabilirsiniz

UserName: Posta kutusunun GUID’ si olarak yansır

Packets: Server tarafından işlenen RPC paket sayısıdır

Operations: RPC paketi içerisindeki operasyonların sayısıdır.

Operations in Error: RPC operasyonlarındaki hataları gösterir

CPU Time (in ms): Milisaniyedeki işlemci kullanım süresi toplamıdır

Bytes In: Exchange Server a gönderilen veri toplamı (sıkıştırmadan sonra)

Bytes Out: Exchange Server’ ın gönderdiği veri toplamı (sıkıştırmadan sonra)

Görüntülediğiniz bu verileri hızlı bir şekilde export etmek isterseniz seçip kopyalamanız yeterlidir. Aşağıda görebileceğiniz gibi sadece kopyalama ve yapıştırma ile bu verileri export etmek mümkün

Eğer veri tabanı hakkında daha fazla bilgi almak istiyorsanız aşağıdaki özellikleri açabilirsiniz

Bu sayede Exmon bilgi toplarken veri tabanı ile de ilgili bilgileri toplayacağı için özellikle storage kaynaklı yavaşlıkları tespit edebilirsiniz.

Benzer şekilde aynı menüde seçtiğiniz “Enable RPC Tracing” sayesinde topladığınız verilere RPC analizi de eklenecektir.

Umarım faydalı bir makale olmuştur, bir sonraki makalemde görüşme dileği ile esen kalın.

Kaynak: ExMon Documentation

(159)

Eğer uzak bir Exchange Server sunucusuna RDP yapamıyor ve hali hazırda kullandığınız bilgisayar üzerinde Exchange Management Tool yüklü değil ise aşağıdaki adımları takip ederek hızlı bir şekilde bir Exchange server a PS ile bağlanıp gerekli olan komut setlerini çalıştırabilirsiniz

Bu komutların çalışması için kullanacağınız bilgisayarda olması gereken yazılımlar

Kullanabileceğiniz işletim sistemleri;

◦Windows 10
◦Windows 8.1*
◦Windows Server 2012 R2*
◦Windows Server 2012**

*  .NET Framework 4.5.2
** Windows Management Framework 4.0

Komutlar aşağıdaki gibidir;

Set-ExecutionPolicy RemoteSigned

$UserCredential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<FQDN of Exchange 2016 Mailbox server>/PowerShell/ -Authentication Kerberos -Credential $UserCredential

Import-PSSession $Session

Get-ExchangeServer ve benzeri hangi Exchange Server komutuna ihtiyacınız var ise komutları kullanın ve işiniz bitince session’ ı kapatın.

Remove-PSSession $Session

(61)

Exchange Server bir şirket ortamında çalışan nerede ise tüm beyaz yakalıların aktif olarak kullandığı bir ürün olup son kullanıcı etkileşimi yüksektir. Durum böyle olunca da bu ürün üzerindeki değişikliklerin yakından takip edilmesi gereklidir. Tabiki şirket politikaları veya kurumunuzun içinde bulunduğu sektörün uymak zorunda olduğu bir takım kurallar, kanunlar ( regülasyonlar ) gereği hali hazırda zaten Exchange Server mimarisinde “Audit” yani izleme yapıyor olabilirsiniz. Bu izlemeyi ister Exchange Server ile beraber gelen Audit özelliği ile yapabilirsiniz, isterseniz Lepide, Change Auditor ve benzeri ürünler ile takip edebilirsiniz. Ben bu makalemde varsayılan Admin ve Mailbox Audit özelliğinden bahsedeceğim.

Exchange Server 2007 SP2 ile beraber hayatımıza giren Admin Audit, yani yöneticilerin Exchange server üzerinde yaptığı değişikliklerin bir yere kayıt edilmesi ve gerekli durumlarda raporlanması özelliği şu anda en güncel sürüm olan Exchange Server 2016 ile de devam etmektedir. Sadece ilk çıktığında varsayılan olarak açık gelmeyen bu özellik, Exchange Server 2010 SP1 ve sonrası için artık varsayılan olarak açık gelen bir özelliktir ( Admin Audit Log açık olup, mailbox Audit log varsayılan olarak kapalıdır).

Audit işlemleri özel bir yetki gerektirdiği için eğer Organizasyon seviyesinde yetkiniz yok ise aşağıdaki PS yardımı ile Audit için içerisinde olmanız gereken role gruplarını görüntüleyebilirsiniz

Get-ManagementRole | Get-ManagementRoleAssignment | Where-Object {$_.Role -like “*audit*”} | FT Role,RoleAssigneeName -wrap –autosize

Yani amacınız görüntüleme ise “Comliance Management” üyeliği yeterli olacaktır, ancak daha fazla ayar için Organization Management grubu üyesi olmanız gereklidir.

Aslında bu bilinen bir durum yani PS i neden kullandık diye düşünebilirsiniz? Buradaki amaç kurumsal ve büyük yapılarda farklı işler için farklı role grupları oluşturulmuş olabilir ve bu nedenle Organization Management hakkı istemeden veya birisine vermeden Audit operasyonlarını yapabileceğiniz gruplar var ise onları tespit etmiş olursunuz ( teknik olarak bu grupları zaten siz açtığınız için biliyorsunuzdur, ancak sizin devraldığınız bir sistem ise bu komut çok yararlı olacaktır).

Gerekli yetkiye sahip iseniz yapılandırmayı kontrol etmek ile işe başlayabiliriz.

Aşağıdaki powershell komutu ile mevcut durumu kontrol edebilirsiniz;

Get-AdminAuditLogConfig

Yukarıdaki ekranda “AdminAuditLogEnabled” karşısındaki True, sizde Admin Audit loglama özelliğinin açık olduğunu gösterir.

Aslında bu izleme temel olarak Exchange Management Shell için yapılır, çünkü konsol veya web tabanlı yönetim panellerinde yaptığınız bütün işlemler aslında arka planda PS çalıştırır. Ancak Get- ve Search- ile başlayan komutlar kesinlikle takip edilmez. Çünkü Audit sisteminin temel amacı değişiklik yönetimidir. Yani kim hangi listeyi çekmiş tarzından bir bilgi alamazsınız.

Toplanan tüm bu loglar özel bir sistem posta kutusunda saklanmaktadır. Bu posta kutusuna yetkisi olan kullanıcılar Exchange Control Panel (ECP) Auditing Reports sayfası, Search-AdminAuditLog veya New-AdminAuditLogSearch PS ile erişebilir. Bu alanları kullanacak kullanıcı Exchange Server organizasyonunda Compliance Management grubu üyesi olmalıdır.

Genel olarak AdminAuditLog açma ve kapama işlemleri aşağıdaki gibidir;

Set-AdminAuditLogConfig -AdminAuditLogEnabled $False

Tabiki bu son hareketiniz de loglanacağını unutmayın. Tekrar açıyorum

Set-AdminAuditLogConfig -AdminAuditLogEnabled $True

Varsayılan olarak AdminAuditLog açtığınız zaman her türlü değişikliğe neden olan cmd komut seti loglanır, ancak siz örneğin grup üyeliklerinin güncellenmesi gibi sizin için çok kritik olmayan bir komut setinin loglanmasını istemeyebilirsiniz.

Set-AdminAuditLogConfig -AdminAuditLogCmdlets *

Yukarıdaki komut tüm komut setleri için izlemeyi açar ( Get ve Search hariç ). 

Set-AdminAuditLogConfig -AdminAuditLogEnabled $true -AdminAuditLogCmdlets * -AdminAuditLogParameters *

Veya yukarıdaki komut seti benzer şekilde tüm komut setleri ve bu komut setlerinin tüm parametreleri için admin audit log açılmasını sağlar. Ama siz tüm komut setlerini veya tüm parametreleri açmak istemiyorsanız sizin belirlediğiniz komut setlerini ve parametrelerini izlemek isteyebilirsiniz. Bu durumda * yerine aşağıdaki gibi farklı yazım modellerini kullanarak sınırlama yapabilirsiniz

• New-Mailbox
  

• *TransportRule
  

• *Management*
  

• Set-Transport*
  

Örneğin bunların hepsini içerecek şekilde gerçekleştirebilirsiniz

Set-AdminAuditLogConfig -AdminAuditLogCmdlets New-Mailbox, *TransportRule, *Management*, Set-Transport* -AdminAuditLogParameters *

Veya aşağıdaki gibi başka bir örnek paylaşabiliriz.

Set-AdminAuditLogConfig -AdminAuditLogEnabled $true -AdminAuditLogCmdlets *Mailbox, *Management*, *TransportRule* -AdminAuditLogParameters *

Yukarıdaki her iki komut komut setleri seviyesinde sınırlama yaparken parametre seviyesinde bir sınırlama yapmaz.

Set-AdminAuditLogConfig -AdminAuditLogEnabled $true -AdminAuditLogCmdlets *Mailbox* -AdminAuditLogParameters *Address*

Yukarıdaki komut setinde ise parametre de sınırlandırılmıştır.

Ancak çoğu işletme varsayılan olarak tüm komut setleri ve tüm parametreleri izler çünkü ya içinde bulunduğu sektörün gereksinimi olarak audit olmalıdır ve denetlenmektedir veya şirket yöneticileri Exchange’ i yöneten sistem uzmanlarının tüm hareketlerini görmek istemektedir.

Not: Yukarıda yapılan değişiklikler, tüm Exchange sunucularında aktif olması için AD replikasyonuna bağlıdır. Bildiğiniz gibi bu tür değişiklikler AD Configuration partition bölümünde replike olur ve eğer ortamınızda farklı site’ lar var ise bu yaptığınız değişikliklerin tüm Exchange sunucularında geçerli olması belirli bir süre alabilir. Komutu çalıştırınca 60dk yazar ama bu tamamen yapınıza bağlı olarak değişiklik göstermektedir.

Diğer parametreler ise aşağıdaki gibidir;

AdminAuditLogAgeLimit: Bu komut seti ile audit loglarının ne kadar süre ile saklanacağını ayarlayabiliriz. Formatı aşağıdaki gibidir;

dd.hh:mm:ss

Yani gün, saat, dakika ve saniye cinsinden verebiliriz. Örnek bir komut;

Set-AdminAuditLogConfig -AdminAuditLogAgeLimit 913.00:00:00

Eğer bu değeri 00:00:00:00 olarak ayarlarsanız bu durumda tüm Audit logları silinecektir. Tabiki silinmeden önce bunu kimin yaptığını kayıt edecektir en son olarak.

AdminAuditLogCmdlets: Hangi komut setlerini izleyeceğinizi belirleyebileceğiniz parametredir. Bu konuda örnek komutlar paylaştım.

AdminAuditLogEnabled: Admin Audit Log özelliğini açmaya ve kapatmaya yarayan parametredir.

AdminAuditLogExcludedCmdlets: Bazı komut setlerini izlemek istemiyorsak bu parametreyi kullanabiliriz. Örnek komut aşağıdaki gibidir;

Set-AdminAuditLogConfig -AdminAuditLogEnabled $true -AdminAuditLogCmdlets * -AdminAuditLogParameters * -AdminAuditLogExcludedCmdlets *Mailbox*, *TransportRule*

Bu komut ile Admin Audit log aktif ediyoruz, tüm cmdlet ve parametrelerini takip ediyorken içerisinde Mailbox ve TransportRule geçen komut setleri ve dolayısıyla onlar ile beraber kullanılan parametreleri takip etmiyoruz. Eğer bu komutu iptal etmek istiyorsanız yani bu Exclude edilecek komutları istemiyor ve tüm komutların takip edilmesini istiyorsanız değer olarak “$null” girmeniz gereklidir.

AdminAuditLogParameters: Kullanacağımız cmdlet için yine kullanılacak ve takip edilecek parametreleri bu komut seti ile belirleyebiliyoruz. Bu konuda örnek komutlar paylaştım.

LogLevel: Varsayılan izleme bilgilerine ek olarak daha çok bilgiye ihtiyaç duymanız halinde bu komutu kullanabilirsiniz.

Varsayılan olarak CmdletName, ObjectName, Parameters (values), ve Caller, Succeeded, ve RunDate gibi bilgileri alabiliyorsunuz. Daha fazla bilgi için parametreyi None’ dan Verbose a çekebilirsiniz. Bu durumda ek olarak ModifiedProperties (eski ve yeni değerler) ve ModifiedObjectResolvedName alanlarıda gelmektedir.

TestCmdletLoggingEnabled: Test ile başlayan komutlarında loglanmasını istiyorsanız bu parametreyi kullanabilirsiniz.

Set-AdminAuditLogConfig -TestCmdletLoggingEnabled $True

Peki, varsayılan olarak aktif olan bu özellik bu güne kadar sizin sisteminizde ne kadar disk alanı kapladı? Bu sorunun cevabı için ilgili özel sistem posta kutusu içerisindeki AdminAuditLog klasörünün boyutunun kontrol edebilirsiniz

Get-MailboxFolderstatistics “SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}” -FolderScope RecoverableItems –IncludeAnalysis >c:\hakanuzuner.txt

Hakanuzuner.txt içerisinde arayacağınız bölüm aşağıdaki gibidir, misal bende sadece 5MB lık bir kayıt var ancak bu ÇözümPark mail sunucusu olduğu için çok fazla admin hareketi olmadığı için çok fazla log yok.

Buraya kadar temel olarak Admin Audit logları için yapılandırma ayarlarının kontrol edilmesi ve şirket ihtiyaçlarına göre ayarlanmasını gördük. Bu yapılan değişikliklerin raporlanması için birkaç seçeneğim mevcuttur.

En kolay yöntem EAC üzerinden raporlara erişmektir.

EAC > Compliance management > Auditing

View the Administrator audit log linkine tıklayın, bir tarih aralığı verin ve aramayı başlatın

Sonuç yukarıda olduğu gibi admin log özelliğini “Administrator” isimli kullanıcının kapadığını rahatlıkla görebilirsiniz.( örnek olarak)

Hemen yine bu ekranda Management Role Group için yapılan değişikliklerin de raporunu alabileceğiniz bir ekran yer almaktadır.

Eğer yönetici, role gruplarda bir değişiklik yapar ise bunu da bu ekrandan rahatlıkla görebilirsiniz. Aslında bu da Admin Audit Log içerisindeki bir veri olmasına karşın Exchange Server yönetiminde Role Group mimarisi çok önemli olduğu için ona ayrı bir rapor ekranı sunulmuştur.

Eğer Admin hareketlerini EAC üzerinden çekmek yerine PS ile çekmek isterseniz aşağıdaki gibi bir komut seti kullanabilirsiniz;

Search-AdminAuditLog -Cmdlets New-RoleGroup, New-ManagementRoleAssignment

Yukarıdaki komut ile adminlerin “New-RoleGroup” veya “New-ManagementRoleAssignment” komutlarını kullandıkları hareketlerin dökümünü görebilirsiniz.

Daha detaylı arama yapmak için örnek bir komut aşağıdaki gibidir;

Cmdlets Set-Mailbox

Parameters UseDatabaseQuotaDefaults, ProhibitSendReceiveQuota, ProhibitSendQuota

StartDate 01/24/2012

EndDate 02/12/2012

The command completed successfully

Search-AdminAuditLog -Cmdlets Set-Mailbox -Parameters UseDatabaseQuotaDefaults, ProhibitSendReceiveQuota, ProhibitSendQuota -StartDate 01/24/2012 -EndDate 02/12/2012 -IsSuccess $true

Kullanılan komut seti, parametreleri, tarih aralığı ve sonuç yani başarılı mı yoksa başarısız mı durumuna göre yukarıdaki gibi örnek bir komut ile Admin Audit Logların da arama yapabilirsiniz.

Yukarıdaki aramayı benzer şekilde New-AdminAuditLogSearch komutu ile aşağıdaki gibi yapabiliriz;

Cmdlets Set-Mailbox

Parameters UseDatabaseQuotaDefaults, ProhibitSendReceiveQuota, ProhibitSendQuota

StartDate 01/24/2012

EndDate 02/12/2012

New-AdminAuditLogSearch -Name “Mailbox Quota Change Audit” -Cmdlets Set-Mailbox -Parameters UseDatabaseQuotaDefaults, ProhibitSendReceiveQuota, ProhibitSendQuota -StartDate 01/24/2012 -EndDate 02/12/2012 -StatusMailRecipients hakan@cozumpark.com, hakan@mayasoft.com.tr

İki komut arasında fark, ilk komut görüntüleme içindir, ikinci komut ise sonucu rapor olarak iletmek yani bir nevi export etmek içindir. Bu komutu çalıştırmak için minimum “View-only administrator audit Logging” yetkisine sahip bir kullanıcı olmanız gereklidir. Komut raporu 24 saat içerisinde size toplam dosya boyutu maksimum 10mb olacak şekilde ulaştıracaktır. Dosya formatı XML olduğu ve varsayılan olarak OWA da bu format yasaklı olduğu için önerim outlook üzerinden almanızdır. Eğer illaki OWA dan bakmanız gerekiyor ise bu durumda geçici olarak izin vermeniz gereklidir.

Örnek Komut

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default –AllowedFileTypes ‘.xml’

Mevcut logları export edip incelemek isterseniz powershell yerine yine EAC üzerinden bu işlemi kolaylıkla yapabilirsiniz.

Ben 28 Ocak günü 8.55 de çalıştırdığım bu raporu ertesi gün 06:07 de aldım. Yani yaklaşık 21 saat sonra.

Dosya içeriği ise aşağıdaki gibidir;

Bunu daha anlamlı bir rapor haline getirmek için size gelen ekteki XML dosyasını aşağıdaki gibi bir dizine kayıt edin

C:\rapor

Daha sonra PS açarak aşağıdaki komutları yazınız

[xml]$xml = Get-Content C:\rapor\SearchResult.xml

$xml

$xml.SearchResults

$xml.SearchResults.Event

Gördüğünüz gibi olaylar şimdi anlamlı bir şekilde listelendi. Tabiki çok fazla komut var, bunun arasından isterseniz filtreleme yapabiliriz

$xml.SearchResults.Event | select caller, cmdlet

Veya daha detaylı olarak listeleyebilirim

$xml.SearchResults.Event | Format-Table rundate, caller, cmdlet –AutoSize

Burada gördüğünüz gibi tarih, kullanıcı bilgisi ve kullandığı komut seti yer alıyor.

Bu XML içerisindeki son event’ e bakmak isterseniz, yani en son admin hareketi ne zaman yapıldı

$xml.SearchResults.Event[0].rundate

Not: Tabiki bu rapor 24 saat içerisinde hazırlandığı için böyle bir bilgiyi güncel olarak sistemde EAC üzerinden veya PS ile almanızı tavsiye ederim.

Son olarak daha detaylı arama, listeleme yapmak istiyorsanız GridView parametresini kullanabiliriz.

$xml.SearchResults.Event | select caller, rundate, cmdlet | Out-GridView

Exchange Server bu logları varsayılan olarak gelen bir agent sayesinde gerçekleştirir. Bu Built-in agent Admin Audit Config bilgisini okuyarak neleri kayıt edeceğine karar verir ve bunları saklar. Aşağıda gördüğünüz gibi Audit Agent varsayılan olarak yüklü ve aktif bir system ajanıdır.

Bu bölüme kadar Exchange Server ile beraber gelen özellikleri anlatmaya çalıştım, bundan sonra ise Admin Audit Loglarının düzenli olarak size HTML rapor olarak gönderilmesinin nasıl gerçekleştirileceğini göstereceğim.

Kaynak

https://technet.microsoft.com/en-us/library/dd298169%28v=exchg.160%29.aspx

https://technet.microsoft.com/en-us/library/ff459250%28v=exchg.160%29.aspx

http://www.shudnow.net/2010/08/03/changes-in-exchange-2010-sp1-administrator-audit-logging/

http://blogs.technet.com/b/heyscriptingguy/archive/2012/01/26/use-powershell-to-parse-xml-exchange-audit-results.aspx

(188)

Exchange server shared mailbox, birden çok kullanıcının mail okuması ve mail göndermesi için kullanılan bir ortak posta kutusudur. Benzer şekilde ortak bir ajanda olarak da kullanılması mümkündür.

Peki, neden böyle bir ortak posta kutusuna ihtiyaç duyarsınız?

Ortak veya gerçekte bir sahibi olmayan genel email adresleri için. Örneğin info, ik,satis, depo, teknik vb mail adreslerinin kullanımı, kontrol edilmesi ve buradan cevap verilmesi.

Şirket içerisindeki departmanların ortak olarak hizmet vermesi durumlarında. Örneğin kullanıcı destek servisi, insan kaynakları servisi, çıktılar veya faks ve benzeri merkezi iletişim araçlarının desteğini veren kişilerin sunduğu hizmetler için kullanılan posta kutularının düşünebilirsiniz.

Birden çok kullanıcının okuduğu ve ya cevap verdiği durumlar için kullanılabilir. Örneğin büyük kurumlarda ki izleme servisi bir ve ya birkaç tane mail kullanır. Ancak vardiya ve ya kritik kesintiler nedeni ile o posta kutusu pek çok kullanıcı tarafından kontrol edilmeli ve kullanılmalıdır.

Teknik olarak aslında shared mailbox bir kullanıcı posta kutusu gibidir, tek farkı bir kullanıcı adı ve şifresi yoktur. Bu nedenle aslında bir kullanıcı direkt olarak bu posta kutusuna bağlanamaz. Bunun için öncelikle bu posta kutusu üzerinde yetkili bir kullanıcı hesabı ile Outlook programını açmalı ki bu posta kutusuna bağlanabilsin.

Exchange Server 2007 den önce ortak posta kutusu kavramı aslında yönetici tarafından bir den çok kullanıcıya yetki verilmesi ile oluşan normal bir kullanıcı posta kutusu idi. Ancak Exchange Server 2007 ve sonrasında bu posta kutusu AD üzerinde öz nitelik seviyesinde de ayrılmıştır. Aşağıda görüldüğü gibi bu posta kutusu kendi alıcı tipine sahiptir.

RecipientType: UserMailbox

RecipientTypeDetails: SharedMailbox

Peki, ortak bir posta kutusunu nasıl açıyoruz?

EAC üzerinde aşağıdaki adımları takip edebilirsiniz;

Recipients > Shared > Daha sonra “+” ikonuna tıklıyoruz.

Karşımıza aşağıdaki gibi ek bir pencere çıkacaktır

İlgili alanları doldurduktan sonra alt bölümde Send As yetkisi vardır oraya bu posta kutusu üzerinden mail göndermek için kimi yetkilendirmek istiyorsanız onu ekleyebilirsiniz.

Not: Exchange Server 2016 da sadece Send As bölümü aşağıdaki gibi görüntülenmektedir

Yukarıda da belirtildiği gibi Exchange 2013 de sadece mail gönderme yetkisi veren bu alan Exchange 2016 üzerinde hem mail gönderimi hem de full erişim yetkisi vermektedir, aşağıdaki gibi

Şu anda Hakan kullanıcısı Outlook veya owa üzerinden mail from yani gönderici olarak satis@cozumpark.com mail adresini seçerek mail gönderimi yapabilir;

Not: Bu işlemi denemek için ortak posta kutusu açıldıktan sonra 2 saat gibi bir süre bekleyiniz. Bu süre maksimum bir süre olup daha önce de mail gönderimi yapabilirsiniz.

Ben satis mail adresinden Mayasoft mail adresime mail gönderdim ve mail aşağıdaki gibi görünmektedir;

Gelelim şimdi izinlere. Ben yukarıda gördüğünüz gibi temel olarak mail gönderme izni verdim ama 3 tip izin verebiliriz;

Not: temel mail gönderme izni Exchange 2013 üzerinde ki sistemde verildi, ama sizin sisteminiz Exchange Server 2016 ise zaten bu iki izni yani mail gönderimi ve full erişimi aynı anda veriyordur. Bunları ayırmak için ortak posta kutusunu oluşturduktan sonra özelliklerinden isterseniz full erişim yetkisini kaldırabilirsiniz.

Full Access

Bu posta kutusunda tam yetkiye sahip olması gereken, yani tüm yazma, silme, okuma, ajanda öğesi oluşturma ve benzeri işlemleri yapacak kullanıcılara verilecek izin tipidir. Ancak bu izin kullanıcının bu posta kutusu üzerinden mail göndermesi iznini içermez. Yani eğer ek olarak mail de göndermesi gerekiyor ise Send As veya Send on Behalf izni de ayrıca vermeniz gereklidir.

Send As

Eğer bir kullanıcının bu ortak posta kutusu adına mail atmasını istiyorsanız bu yetkiyi verebilirsiniz. Yani maili Hakan gönderecek ancak alıcı bunu satis olarak görecek.

Send on Behalf

Yukarıdaki senaryoya çok benziyor, ancak tek fark yine hakan kullanıcısı, satis ortak posta kutusu adına mail atmasına karşın, alıcı bu maili yetkisi dahilinde satis posta kutusunu temsilen hakan kullanıcısının gönderdiğini görebiliyor.

Bu izinleri değiştirmek için mevcut ortak posta kutusu üzerinde değişiklik yapabilirsiniz.

İlgili ortak posta kutusunu seçip kalem ikonuna tıklayınız

Mailbox delegation kısmından bu izinleri verebilirsiniz.

Send on Behalf yetkisini EAC üzerinden veremiyorsunuz, bunun için aşağıdaki gibi PS kullanabilirsiniz

set-mailbox Satis -GrantSendOnbehalfto hakan.uzuner@cozumpark.com

Veya bu yetki kimlerde var onu görebilirsiniz

get-mailbox satis | ft Name,grantsendonbehalfto

Eğer tüm shared mailboxlardaki full Access erişimleri görmek istiyorsanız aşağıdaki komutu kullanabilirsiniz

Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails SharedMailbox | Get-MailboxPermission | ? {$_.User -ne “NT AUTHORITY\SELF” -and $_.IsInherited -ne $true -and $_.user -notlike “S-1-5-*” -and $_.AccessRights -eq “FullAccess”} | ft Identity,@{n=”User”;e={(get-user $_.user).userprincipalname}},AccessRights,IsInherited -AutoSize

Genel olarak ortak posta kutusu açma işlemlerini PS ile yapmak için ise örnek komut aşağıdaki gibidir;

New-Mailbox -Shared -Name “Sales Department” -DisplayName “Sales Department” -Alias Sales | Set-Mailbox -GrantSendOnBehalfTo MarketingSG | Add-MailboxPermission -User MarketingSG -AccessRights FullAccess -InheritanceType All

Peki eğer full erişim hakkınız var ise bu posta kutusunu nasıl göreceksiniz?

Outlook için ek olarak bir şey yapmanıza gerek yoktur, otomatik olarak Outlook profilinize eklenir, eğer Auto map özelliğini kapattıysanız gelmeyecektir, bu durumda Outlook profilinize eklemeniz gereklidir

OWA üzerinde ise sağ üst köşeden farklı bir posta kutusu aç diyerek bu posta kutusuna ulaşabilirsiniz.

Özetle ortak posta kutusu için temel kullanım senaryoları ve teknik yapılandırma konularından bahsettim, umarım faydalı bir makale olmuştur. Bir sonraki makalemde görüşmek üzere.

Kaynak

https://technet.microsoft.com/en-us/library/jj150498(v=exchg.150).aspx

(153)

Exchange Server üzerinde sahip olduğunuz her bir kullanıcı posta kutusu aslında Active Directory üzerinde bir kullanıcı objesi ve Exchange Server posta kutusu veri tabanı üzerinde bir veri deposundan oluşur.

Posta kutusu ile ilgili tüm ayarlar AD veri tabanında kullanıcı öz niteliklerinde yer alırken, mail bilgileri Exchange server posta kutusu veri tabanında saklanır.

Peki, Disconnected Mailbox ne demektir? Exchange Server mailbox database üzerinde bulunan ama AD üzerinde herhangi bir kullanıcı ile ilişkilendirilmemiş olan posta kutularına verilen isimdir.

Disconnected posta kutuları da kendi içerisinde ikiye ayrılmaktadır;

Disabled mailboxes

Bir posta kutusu Exchange Administration Center (EAC) veya Powershell ile (Disable-Mailbox veya Remove-Mailbox) kapatılabilir veya silinebilir. Hangi işlemi yaparsanız yapın yani ister Disabled konuma getirin ister silin mailbox veri tabanı üzerinde o posta kutusu “disabled state” dediğimiz duruma alınır. Tabiki bu iki işlemin farkı vardır. Eğer bir posta kutusunu kapatırsanız yani disable konumuna getirirseniz active directory üzerinde bu posta kutusu ile ilişkili olan kullanıcı üzerinden ilgili ayarların (Exchange attributes) silinmesi gerçekleştirilir, ancak kullanıcı hala aktif olarak çalışmaya devam eder. Eğer posta kutusunu silerseniz bu durumda ilişkili olduğu active directory kullanıcı hesabı da silinecektir. Ancak hangi komutu veya seçeneği kullanırsanız kullanın posta kutusu varsayılan olarak 30 gün olan “deleted mailbox retention period” silinme süreci boyunca veri tabanında saklanacaktır. Bu sayede olası bir yanlışlık ve benzeri bir durumda bu posta kutusunu kurtarabilirsiniz.

Özetle bir posta kutusunu isterseniz kapatın, isterseniz silin varsayılan olarak 30 gün veri tabanınızda yer kaplamaya devam edecektir. Bunun tek istisnası silme işlemini powershell ile yaparken eğer aşağıdaki iki parametreden birini kullanırsanız bu durumda posta kutusu anında silinecektir

Permanent veya StoreMailboxIdentity

Ortamınızdaki Disabled Mailbox’ ları tespit etmek için aşağıdaki powershell komutunu kullanabilirsiniz

Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisconnectReason -eq “Disabled” } | ft DisplayName,Database,DisconnectDate

Eğer bu silme işlemini aşağıdaki gibi yaparsanız 30 gün boyunca veri tabanında saklanmadan hemen silinecektir.

Remove-Mailbox -Identity "satis" -Permanent $true

Yukarıdaki komutu çalıştırdıktan sonra artık EAC üzerinde “satis” isminde bir posta kutusu göremezsiniz, ayrıca yine AD üzerinde satis kullanıcısını da göremeyeceksiniz. Son olarak aşağıdaki komut ile posta kutusunun olmadığını doğrulayabilirsiniz

Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisplayName -eq “satis” }

Bu komutun çıktısında bir sonuç almayacaksınız, yani satis posta kutusu kalici olarak posta kutusu veri tabanından silinmiştir.

Diğer bir disconnected posta kutusu ise

Soft-deleted mailboxes

Bir posta kutusunu bir posta kutusu veri tabanından bir diğerine taşıdıktan sonra, taşıma işlemi eğer başarılı tamamlanır ise kaynak veri tabanındaki posta kutusu “soft-deleted” olarak işaretlenir. Bu veri tabanları var varsayılan olarak 30 gün boyunca saklanır. Bu şekilde bekleyen veri tabanlarını görmek için ise aşağıdaki pwersehll komutunu kullanabilirsiniz

Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisconnectReason -eq "SoftDeleted" } | ft DisplayName,Database,DisconnectDate

Yine buradaki istisna, eğer taşıma işleminden sonra bir sorun yok ve bu posta kutularının 30 gün saklanmasını istemiyorsanız “Remove-StoreMailbox” komutunu kullanarak bunları temizleyebilirsiniz.

Gelelim ne şekilde silmiş olursanız olun (Disabled mailboxes veya Soft-deleted mailboxes ) şu anda ortamınızda Disconnected mailbox olarak duran posta kutularını silmek istiyorsanız eğer silinme yöntemine göre aşağıdaki powershell komutlarını kullanarak bunları kalıcı olarak temizleyebilirsiniz.

Öncelikle bir kullanıcı için posta kutusunun durumunu aşağıdaki powershell komutu ile kontrol edebiliriz

Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisplayName -eq “<display name>” } | fl DisplayName,MailboxGuid,Database,DisconnectReason,DisconnectDate

Ben komutun display name bölümüne “Hakan Uzuner – INFO” yazdım ve gördüğünüz gibi iki tane posta kutusu olduğunu görüyorum. Birisi aktif olan diğeri ise taşınmadan kaynaklı “SoftDeleted” olarak işaretlenen posta kutusu.

Bir diğer kullanıcı için durum ise aşağıdaki gibidir

Bu kullanıcı ise Disabled konumundadır. İsterseniz aşağıdaki komut ile tüm organizasyonunuz için bir rapor alabilirsiniz

Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisconnectReason -ne $null } | fl DisplayName,MailboxGuid,Database,DisconnectReason,DisconnectDate

Gördüğünüz gibi iki posta kutusu da listelendi.

Gelelim bunları silme işlemine;

Silmek istediğimiz posta kutusunun GUID sini alıyoruz ve aşağıdaki komut yardımı ile kalıcı olarak siliyoruz

Remove-StoreMailbox -Database CPDB01 -Identity "a5ff3fdc-725f-4acf-98b6-48a40b50da02" -MailboxState SoftDeleted

Şimdi ikinci posta kutusunu kalıcı olarak siliyorum

Remove-StoreMailbox -Database CPDB01 -Identity "
				ff0087f5-70a9-4aa9-b762-dcc628fc2a66" -MailboxState Disabled

Artık organizasyonumda hiç disconnected mailbox kalmadı. Eğer daha fazla posta kutusunu bir arada silmek istiyorsanız örneğin organizasyondaki tüm sofdeleted konumundaki posta kutularını kalıcı olarak silmek için aşağıdaki powershell komutunu kullanabilirsiniz

Get-MailboxStatistics -Database DBismi | where {$_.DisconnectReason -eq “SoftDeleted”} | ForEach {Remove-StoreMailbox -Database $_.Database -Identity $_.MailboxGuid -MailboxState SoftDeleted}

Benzer şekilde SoftDeleted olan bölümleri Disabled olarak değiştirerek diğer bir disconnected posta kutusu çeşidi olan posta kutularını da toplu olarak silebilirsiniz.

Tabiki Disconnected posta kutusu için yapılabilecek tek eylem silmek değildir. Aslında normal durumlarda bu tür işlemler yapılmaz, ancak çok büyük şirketlerde kullanıcı sayısı, posta kutusu boyutlarının büyük olması veya AD kullanıcısı silinip posta kutusu silinmediği durumlarda veri tabanları şişmeye başlar. Ancak normal durumlarda disconnected mailbox daha çok yanlışlıkla silinmiş veya bir şekilde işten ayrılmış bir kullanıcı posta kutusundan bir veri alınması gerektiğinde tekrar bağlanmak için kullanılır. Bu durumda disconnected mailbox için aşağıdaki eylemler geçerlidir;

Mevcut kullanıcıya tekrar bağlamak

Başka bir kullanıcıya bağlamak (posta kutusu olmayan)

Posta kutusu olan bir kullanıcı posta kutusuna geri dönmek

Kalıcı olarak silmek

Son adımı zaten sizler ile paylaştım, gelelim diğer adımlara. Bir posta kutusunu yanlışlıkla Disable etmeniz halinde AD kullanıcısı hala durduğu için kolaylıkla onu tekrar ilgili kullanıcıya bağlayabilirsiniz. Bunun için öncelikle aşağıdaki komut ile DB bazında disconnected mailboxların durumunu güncellemeniz gereklidir

Get-MailboxStatistics -Database CPDB02 | ForEach {Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$False}

Daha sonra aşağıdaki komut ile bunların durumunu çekebiliriz

Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisconnectReason -ne $null } | fl DisplayName,MailboxGuid,Database,DisconnectReason

Yukarıda ben Hakan Uzuner INFO hesabı için bir move işlemi yapmış ve bunun sonucu olarak 1 adet aktif bir adet SoftDeleted posta kutusu görmüştük ve sizler ile beraber SoftDeleted olan ve 30 gün boyunca bekleyecek olan posta kutusunu silmiştik. Peki bu yukarıdaki sonuç nedir? Yine Demo amaçlı ben aktif olan kullanıcıyı sildim ve otomatik olarak posta kutusu da Disabled şeklinde bir Disconnected Mailbox’ a dönüşmüş oldu. Ben bunu tekrar kurtarmak için öncelikle AD üzerinden kullanıcıyı tekrar geri döndürmem lazım.

Kullanıcı tekrar aktif olarak AD de görünüyor

Aşağıdaki komutu tekrar çalıştırıyoruz ve otomatik olarak posta kutusunun tekrar EAC üzerinde görüntülendiğini görebiliyoruz

Get-MailboxStatistics -Database CPDB02 | ForEach {Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$False}

Eğer kısa bir sürede bu gerçekleşmez ise elle bu işlemi aşağıdaki şekilde yapabilirsiniz. EAC üzerinde mailboxes kısmında 3 noktaya tıklayıp “Connect a mailbox” linkine tıklayınız.

Yukarıdaki gibi disconnected olan posta kutularını göreceksiniz, eğer aradığınız posta kutusunu burada göremiyorsanız yine aşağıdaki tazeleme – güncelleme komutunu çalıştırabilirsiniz

Not: bunu her bir db için çalıştırmanız gerekli, veya silinmiş posta kutusunun hangi db de olduğunu biliyorsanız o db de çalıştırmanız yeterlidir

Get-MailboxStatistics -Database CPDB02 | ForEach {Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$False}

Daha sonra açılan menüdeki mektup zarfı ikonuna tıklamanız yeterlidir.

Otomatik olarak eski kullanıcıya posta kutusu bağlanacaktır.

Eğer uygun bir kullanıcı yok ise connect dediniz ama sistem uygun bir kullanıcı bulamadığında size aşağıdaki gibi bir soru soracaktır

Siz bu bölüme tıklarsanız nasıl bir posta kutusuna bağlamak istediğinizi soracaktır

Bir sonraki adımda bağlamak istediğiniz kullanıcıyı seçiyorsunuz

Bu sayede hakan uzuner info posta kutusunu posta kutusu olmayan başka bir kullanıcıya bağlamış oldunuz.

Eğer bu bağlama işlemlerini powershell ile yapmak isterseniz

Connect-Mailbox -Identity “Hakan UZUNER – INFO” -Database CPDB02 -User “Hakan info” -Alias hakaninfo

Bir diğer kullanım senaryosu ise bu posta kutusunun içeriğini başka bir posta kutusuna dönmek olacaktır.

Öncelikle silinmiş olan posta kutusunun GUID bilgisi için aşağıdaki komutu kullanın

Get-MailboxDatabase | Get-MailboxStatistics | Where {$_.DisconnectReason -eq "Disabled"} | fl DisplayName,MailboxGuid,LegacyDN,Database

GUID yi aldıktan sonra ise aşağıdaki gibi dönüş işlemi yapabilirsiniz

New-MailboxRestoreRequest -SourceStoreMailbox e4890ee7-79a2-4f94-9569-91e61eac372b -SourceDatabase CPB02 -TargetMailbox "Levent Uzuner" -AllowLegacyDNMismatch

Bir diğer senaryo ise taşıdığınız ancak sorun yaşadığınız için kaynak posta kutusunun restore edilmesi durumudur. Yani siz bir kullanıcı posta kutusunu taşıdığınız zaman, bu taşıma işlemi başarılı tamamlandıktan sonra kaynak veri tabanı üzerinde bu posta kutusu softDeleted olarak işaretlenir, bunu zaten makalemin başlangıcında paylaşmamıştım. Ancak bir nedenden dolayı bu posta kutusuna ihtiyaç duyarsanız eğer öncelikle seftdeleted olan posta kutularını aşağıdaki komut ile listeleyin

Get-MailboxDatabase | Get-MailboxStatistics | Where {$_.DisconnectReason -eq “SoftDeleted”} | fl DisplayName,MailboxGuid,LegacyDN,Database

Daha sonra ihtiyaç duyduğunuz posta kutusuna ait olan GUID’ yi not alın ve aşağıdaki komut ile başka bir kullanıcı posta kutusuna dönün

New-MailboxRestoreRequest -SourceStoreMailbox dc35895a-a628-4bba-9aa9-650f5cdb9ae7 -SourceDatabase MBXDB01 -TargetMailbox “Hasan UZUNER” –AllowLegacyDNMismatch

Bu son komut ile makalemin sonuna geldik, umarım faydalı bir makale olmuştur, bir sonraki makalemde görüşmek üzere

Kaynaklar

https://technet.microsoft.com/en-us/library/jj863435%28v=exchg.150%29.aspx

https://technet.microsoft.com/en-us/library/jj863438%28v=exchg.150%29.aspx

(191)

MAPI istemcisi olarak bağlanan bir Outlook programı ister Autodiscover yani profil ayarlarının otomatik olarak oluşmasını sağlayan web servisi üzerinden isterseniz elle ayarlamış olun eğer Outlook anywhere özelliğini kullanıyor ise aşağıdaki gibi “Connection” sekmesini görebiliriz

Bu sekme aslında bize Outlook anywhere ayarlarının detaylarını gösterir. Ancak siz Outlook 2013 veya 2016 için yukarıdaki bölümde “General”, “Advanced”, “Security” görüyor ancak “Connection” görünmüyor ise yani durum aşağıdaki gibi ise

Bunun temel sebebi bu hesap Exchange Server’ a MAPI over HTTP üzerinden bağlanmaktadır. Bunu ise yine sağ alt köşedeki Outlook ikonuna ctrl tuşuna basılı tutarken sağ tıklayıp Connection Status bölümünden kontrol edebilirsiniz

Bende pek çok mail hesabı olduğu için tabi ki sizde muhtemel 2 veya 3 bağlantı görünecektir, ama burada önemli olan Protocol bölümündeki sonuçlar.

Örneğin HTTP görüyorsanız siz Exchange Server’ a MAPI over HTTP ile bağlanıyorsunuz ve Connection Sekmesini göremezsiniz, RPC/HTTP görüyorsanız Outlook Anyhwere kullanıyorsunuz ki o durumda zaten Connection sekmesi gelir.

MAPI over HTTP hakkında daha fazla bilgi ise aşağıdaki gibidir;

Exchange Server’ a bağlı bir Outlook programı zaman içerisindeki aşağıdaki protokolleri kullanarak bağlanmıştır.

RPC over TCP

RPC over HTTP ki bu Outlook Anywhere olarak bilinir

MAPI over HTTP ( Exchange Server 2013 SP1 ile gelen yeni ve en güncel bağlantı protokolüdür.

Eğer Exchange Server 2013 SP1 ve sonrasını kullanıyorsanız MAPI over HTTP protokolünü destekleyen bir alt yapınız var demektir. Bu desteği sağlamak için aşağıdaki adımları yerine getirebilirsiniz.

Öncelikle MAPI Virtual directory için iç v dış URL adreslerini belirleyin.

Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -InternalUrl https://mail.cozumpark.com/mapi -ExternallUrl https://mail.cozumpark.com/mapi -IISAuthenticationMethods Negotiate

URL adreslerini ayarladıktan sonra bu adres için uygun sertifika kullanmanız ve tabiki OWA, Active Sync vb firewall yönlendirmesini bu virtual directory içinde yapmanız gereklidir ( muhtemel sunucu bazında 80 ve 443 ü yönlendirdiğiniz için ek bir ayara gerek yoktur, ama önce bir NLB cihazı var ise veya bir Proxy server bu durumda virtual directory için de ( /mapi ) ayar yapmanız gereklidir.

Bundan sonra ise organizasyon seviyesinde izin veriyoruz

Set-OrganizationConfig -MapiHttpEnabled $true

Artık istemciler MAPI over http protokolü ile bağlanacaktır ve karşılarına bir uyarı çıkarak Outlook u kapatıp açmalarını söyleyecektir.

Eğer isterseniz kullanıcı bazlı da bu bağlantı modelini aşağıdaki komut seti ile yönetebilirsiniz

Set-CasMailbox <user or mailbox ID> -MapiHttpEnabled $true

Normalde bu ayar tüm kullanıcılarda Null yani organizasyon seviyesinden ne gelir ise onu kabul eder, ama siz örneğin organizasyon seviyesinde true ama siz buna False yaparsanız bu ayar daha baskın olacaktır.

(151)

Exchange Server şirket organizasyonları içerisinde en çok değişiklik gerçekleştirdiğimiz alt yapı ürünlerinin başında yer almaktadır. Organizasyon konfigürasyonu olarak geçen ve genellikle kurulum sonrasında yapılan ayarları nadir olarak yapılan güncellemelerin izlediği değişikliklerin dışında gündelik hayatta özellikle kullanıcı posta kutusu ile ilgili pek çok değişiklik yapılmaktadır. Gerek organizasyon, gerek sunucu veya kullanıcı değişiklikleri gündelik iş akışımızı etkilediği için son derece dikkatli ve kontrollü bir şekilde gerçekleştirilmelidir. Kimi zaman ise bu değişiklikler organizasyon seviyesinde kesintilere veya bilgi çalınmasına neden olabilmektedir. Bu nedenle şirketin en üst düzey yöneticisinden en temel personeline kadar herkesin mail bilgisinin saklandığı bu platform üzerindeki değişikliklerin düzenli olarak izlenmesi gerekmektedir. Microsoft bu konuda hali hazırda bir takım özellikler sunmaktadır. Bu konuda daha fazla bilgi için aşağıdaki makaleleri inceleyebilirsiniz.

Exchange Server Admin Audit Log – Deep Dive

Exchange Server 2013 Mailbox Audit Logging

Benim amacım ise, bu izleme işini son derece kolay bir hale getiren ve hatta özel raporlar, kritik değişikliklerin olması durumunda size mail veya benzeri bilgilendirme yapılmasının sağlanması başta olmak üzere pek çok yönetimsel kolaylık sağlayan ( Exchange Server üzerinden alamadığınız pek çok ek rapor içermektedir) Lepide Auditor Suite programı ile bunu işi nasıl kolay bir şekilde gerçekleştireceğinizi görmektir.

Lepide Auditor Suite ürünü kurulumu hakkında aşağıdaki makalemi inceleyebilirsiniz

https://www.cozumpark.com/blogs/3party/archive/2016/06/12/lepide-auditor-suite-active-directory-gpo-exchange-server-auditing-kurulum.aspx

Eğer kurulumu başarılı bir şekilde gerçekleştirdiyseniz Exchange Server tarafındaki değişiklikleri incelemeye başlayabilirsiniz.

Lepide Auditor Suite programını ana konsolunu açıp kısa bir süre bekledikten sonra aşağıdaki gibi ortamınız hakkında özet bilgiler alabilirsiniz

Detayları görmek için bu ekranların üzerindeki linklere tıklayabilirsiniz veya yine rapor bölümüne geçebilirsiniz.

Audit raporları temel olarak iki bölümden oluşmaktadır.

Exchange Modification Reports – Exchange server üzerindeki tüm değişikliklerin takip edildiği bölümdür.

Auditing – Posta kutuları seviyesinde kullanıcı, delege edilen yetkili kullanıcı ( özel kalem, asistan vb) ve yönetici hareketlerini raporlayabiliriz.

İlk bölüm adında da anlaşılacağı gibi kim Exchange Server üzerinde neler yapmış onu hızlı bir şekilde görebileceğimiz bir bölüm. Eğer nokta atışı bir değişiklik görmek istiyorsanız örneğin Adres defterinde kim değişiklik yapmış gibi bu durumda “Address Book Modifications” bölümüne gelip bir rapor çekebilirsiniz.

Bu değişikliklerin kimin tarafından ne zaman ve ne şekilde bir değişiklik yapıldığını detaylı bir şekilde görebilirsiniz. Kullanılan komutları, eski ve yeni değerleri görmek için her bir değişikliğin üzerine çit tıklayabilir veya ekranın sağ bölümündeki ön izleme penceresini kullanabilirsiniz. Bu pencereyi isterseniz ekranın alt bölümüne de alabilirsiniz. Ben alışkanlık olarak çift tıklayarak açılan yeni pencerede tüm detayları görmeyi tercih ediyorum.

Eğer Exchange Server üzerindeki tüm değişiklikleri görmek istiyorsanız “All Modifications in Exchange Server” bölümüne tıklayabilirsiniz. Daha sonra sağ bölümde yer alan filtreleri kullanıp istediğiniz bir zaman, kişi, değişiklik vb seçim yapıp sağ bölümden raporu oluştur (Generate Report) demeniz yeterli;

Böyle bir rapordaki en kullanışlı alan tüm sütunların istediği gibi yer değiştirmesi ve kolay bir şekilde süzülmesi. Örneğin bana gelen bu 1500 değişiklik içerisinde ben sadece silme operasyonlarını getir demek için “Operation” bölümüne delete yazmam yeterli olacaktır

Yani son derece hızlı ve dinamik bir filtreleme özelliğine sahiptir.

Tek tek tüm raporların üzerinden geçmek ciddi bir zaman ama bu birkaç örnek ile aslında Exchange Server üzerinde yapılan tüm hareketleri merkezi bir noktadan son derece kolay bir şekilde raporlayabileceğinizi görmüş olduk. Rapor bölümünde aşağıdaki gibi pek çok farklı raporu yine yukarıdaki gibi istediğiniz zaman dilimi ve filtrelere göre alabilirsiniz;

Yine ürün ile gelen ve en çok aslında merak edilen konulardan biriside kim benim posta kutuma erişmiş veya neler yapmış, yada kim benim posta kutuma erişim için yetki vermiş. Önce hızlı bir şekilde bu yetkilendirmeyi görelim.

Bildiğiniz gibi Exchange Server üzerinde yönetici haklarına sahip olan bir kullanıcı herhangi bir posta kutusuna full erişim hakkını kendine veya istediği bir kullanıcıya verebilir, böyle bir durum ise lepide raporlarına aşağıdaki gibi yansıyacaktır;

Bunun isterseniz hızlı bir şekilde Alert olarak tanımlayabilirsiniz, bu sayede böyle bir değişiklik olduğu zaman aşağıdaki gibi size bir bilgilendirme mali gelecektir;

Sistemin mail attığını yine Alert ekranından görebiliyoruz

Gelen mail ise aşağıdaki gibidir;

Not: Alert oluşturmayı aşağıdaki makalemde detaylı anlatmıştım, eğer ilgilenirseniz buradan takip edebilirsiniz.

https://www.cozumpark.com/blogs/3party/archive/2016/06/12/lepide-auditor-suite-ile-active-directory-auditing-active-directory-degisiklik-izleme.aspx

Peki bu yetki bir şekilde verilmiş yada verilmesi gerekiyor ( örneğin özel kalem veya sekreteri için üst düzey yöneticiler genellikle ajanda başta olmak üzere bazı klasörleri paylaşırlar) ise bundan sonraki hareketlerinde izlenmesi gerekebilir. Yaşanmış gerçek bir hikâye;

Üst düzey bir yöneticinin özel kalemi kritik toplantılardan birini yanlışlıkla ajandasından siliyor, daha sonra buraya yine önemli bir toplantı isteği alıyor, aynı gün aynı saatte iki önemli misafiri gelen üst düzey yönetici ise çok zor durumda kalıyor ve anında IT yi arayıp bunun nasıl olabileceğini soruyor. IT takımında bu konularda tecrübeli bir uzman olduğu için bu tür paylaşımda bulunan posta kutuları için Audit özelliğini açmıştı, yani varsayılan olarak Admin Audit açık gelir ancak Mailbox Audit yani posta kutusu seviyesindeki değişiklikler izlenmez. Çünkü bunlar mevcut pota kutularına ek disk boyutu olarak yük getirir. Genel olarak buradaki politika yukarıdaki örnekte olduğu için hali hazırda paylaşımlı posta kutusu kullanan kullanıcılar, üst düzey kullanıcılar, kritik öneme sahip ve yine ortak kullanılan posta kutularında açılması gereklidir. Uzun lafın kısası Mailbox Audit bu üst düzey yöneticide açık olduğu için anında özel kalemi tarafından yapılan bu silme işlemini raporluyorlar.

Tabiki Exchange üzerinden bunu raporlamak bir hayli zor olabiliyor, ancak Lepide üzerinden bunun için aşağıda gördüğünüz gibi 3 ayrı hazır rapor bulunmaktadır;

Owner bölümünde, eğer ilgili posta kutusu için Audit açılırken kullanıcının kendi hareketleri de izlensin diye ayar yapılmış ise kendi hareketlerinin dökümünü aldığımız bölümdür.

Delegated Users ise yine yukarıdaki örnekte olduğu için yetki verilmiş kullanıcı tarafından ilgili posta kutusu üzerindeki değişikliklerin raporunu aldığımız bölümdür.

Administrators ise yönetici olarak full erişim hakkı aldığımı ilgili posta kutusu üzerinde yaptığımız değişiklerin raporunu verir.

Non Owner bir kavram olup, Owner dışındaki tüm erişimleri tek bir raporda görmek için kullanılır.

Ancak hali hazırda bu raporları alamayabilirsiniz, çünkü yine makalemde de bahsettiğim gibi bu özellik varsayılan olarak açık değildir. İsterseniz bunu aşağıdaki makalede olduğu gibi Exchange Server üzerinden kendiniz kullanıcı bazlı açabilirsiniz

Exchange Server 2013 Mailbox Audit Logging

Yada Lepide bunun sizin yerinize yapacaktır. Lepide ile yapmak için öncelikle konsol üzerinde sol tarafta yer alan menüden settings bölümüne geliyoruz.

Burada eklediğiniz domain üzerine sağ tıklayarak özellikler penceresini açınız

Daha sonra Advanced Domain Configuration linkine tıklayınız

Burada sağ üst köşedeki “Non-owner Mailbox Auditing” kutucuğunu işaretlemeniz gereklidir. Daha sonra hemen yanındaki anahtar sembolüne tıklayınız.

Not: bu raporu alabilmek için Lepide Auditor Suite ürününün ajanlı kurulması gereklidir.

Açılan menüden istediğiniz posta kutularını seçiyorsunuz, bir sonraki ekranda ise bu kullanıcılar için hangi izleme özelliklerini aktif edeceğinizi seçiyorsunuz.

Bu bölümün detayları için ÇözümPark üzerindeki makaleyi incelemenizi öneririm.

Son olarak yapacağı değişikliği sizler ile paylaşıyor ve onaylıyoruz.

Artık mailbox erişim loglarını görebiliriz. Hemen hızlıca birkaç tanesini inceleyelim

Not: bu özellik açıldıktan sonra birkaç saat beklemeniz gerekmekte olup bu Exchange server mimarisi ile ilgili bir gereksinimdir.

Yukarıda gördüğünüz gibi sistemde bir arşivleme yazılımı olan Enterprise Vault tarafından posta kutusunda yapılan tüm değişiklikleri görebiliyoruz.

Dikkatinizi çekmek istediğim önemli bir bölüm var, malum makalenin bu bölümüne kadar hep değişiklik izleme konusuna odaklandık ancak ISO 270001 gibi regülasyonlara tabi olan kurumlar için genel AD ve Exchange Server organizasyonlarının bir takım güvenlik standartlarına göre ne kadar uygun olduğunu da raporlayabiliyoruz. ( Satın aldığınız lisansa göre AD, Exchange, File Server vb )

Yani hemen rapor aldığımız menüde alt bölümde Audit yerine örneğin “Compliance Reports” bölümüne tıklayarak bu konuda Dünya standartlarını belirleyen kurumların raporlarına erişebilirsiniz;

İsterseniz bu standartlara göre rapor alabilir isterseniz hepsi için ortak raporları çekebilirsiniz

Aslında ürünün en değerli bölümlerinden biriside bu alandır, tabi ki bunu kullanan ve ihtiyaç duyan firmalar için.

Bir diğer bölüm ise izinler üzerindeki değişikliklerin karşılaştırıldığı “Permission Analysis” bölümüdür.

Bu bölümde File Server, Exchange Server veya Active Directory üzerindeki objeler üzerinde yapılan izin değişikliklerini görüntüleyebilir ve yine onları karşılaştırabilirsiniz.

Son 24 saat içerisinde “Herkes” isimli bir grup üzerinde izin değişikliği yapılmış, bu izinleri ise alt menüden görüntüleyebiliyoruz

Mavi olan izinler hali hazırda yukarıdan gelen yani varsayılan izinler olmasına karşın Admin bu grup için siyah ile işaretli olan kullanıcılara yetki vermiştir. Aslında bu yetkiyi en üstteki Hakan Uzuner kullanıcısına vermiş, diğerleri varsayılan ACL listesidir.

Eğer ürün ile beraber gelen AD backup özelliğini de ayarlarsanız istediğiniz aralıklar ile AD’ nin yapılandırma bilgisini yedeklediği için aşağıdaki gibi izinleri bu yedeklere göre karşılaştırma da yapabilirsiniz

Not: bende hiç yedek olmadığı için şu anda karşılaştırma yapamıyorum.

Eğer yedeğiniz var ise aşağıdaki gibi silinen objeleri de geri getirebilirsiniz

Audit özelliğinin yanında yine AD için sunduğu sağlık izleme hizmetini de ücretsiz olarak sunmaktadır. Yani temel anlamda Exchange sunucularınız için CPU, RAM kullanımı, erişilebilirlik raporu, servislerin durumu, alınan gönderilen mailler, erişim gecikmeleri, kritik loglar gibi bilgileri aşağıdaki gibi görüntüleyebiliyorsunuz.

Ürün hakkında aslında yazılacak çok fazla özellik var ancak diğer özellikleri de sizlere bırakıyorum, hızlı bir şekilde aşağıdaki adres üzerinden trial olarak ürünü indirebilir ve 15 gün boyunca kullanmaya başlayabilirsiniz.

http://www.lepide.com/audittrial/

Umarım faydalı bir makale olmuştur, bir sonraki makalemde görüşmek üzere.

(133)

Microsoft Exchange Server 2007, 2010, 2013 ve 2016 için güncel yamalarını yayınladı. Özellikle Exchange Server 2013 ve 2016 için yayınlanan bir önceki yamalardaki sorunların giderilmesi açısından bu yeni yamalar çok önemli.

• Cumulative Update 4 for Exchange Server 2016 (download)
• Cumulative Update 15 for Exchange Server 2013 (download)
• Update Rollup 16 for Exchange Server 2010 SP3 (download)
• Update Rollup 22 for Exchange Server 2007 SP3 (download)

(94)

Her geçen gün mail sistemleri spam maillere karşı daha korunaklı olmak için yeni teknolojiler veya çözümler kullanmaya başlamaktadır. Bu teknolojilerin pek çoğunu alında biliyoruz. En temel MX kayıtlarını kontrol ile başlayan süreç içerisinde Reverse DNS (PTR), SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) gibi yeni kavramlar ile tanışmış ve bunlara alışmış olduk. Ancak yine de bazı durumlarda her ne kadar bilinen bu gereksinimleri yerine getirsek bile mail sistemlerimiz bazı diğer mail sistemleri tarafından spam mail gönderen bir sistem olarak algılanabilir, yani aslında buradaki esas değişken karşılıklı olarak sistemlerin neleri kontrol ettiğidir. Örneğin SPF ilk yaygınlaşmaya başladığında pek çok mail sistemi SPF kaydını sorgulamıyordu veya sorgulasa bile eğer kendisine mail atan sistemin SPF kaydı yok ise yine de maillerin geçmesine izin veriyoruz, çünkü aksi halde pek çok iletişim problemi yaşama riski vardı. Ancak artık herkes SPF kullandığı için nerede ise tüm anti spam sistemlerinde SPF kaydı artık zorunluluk gibi. Tabiki yine bir sistem admin olarak siz kendi sahip olduğunuz mail sistemi üzerindeki ayarlarsan veya mail sistemini koruyan Anti Spam gateway yazılımındaki ayarlardan bunu değiştirebilirsiniz.

Yukarıdaki şekilde DKIM için bir çalışma şeması paylaşılmıştır.

Günümüzde ise mail sistemleri daha farklı teknolojiler kullanarak gelen mailin gerçekten sizin domain’ e ait olan mail sunucusundan geldiğini doğrulamaktadır. Benzer şekilde şu an itibari ile tüm mail sistemleri bunu yapmamak ile beraber makalemizin konusu olan SMTP Reverse DNS uyuşmazlığı aslında pek çok sistemcinin başına gelmiştir. Malum günde yüzlerce belki binlerce hatta banka ve benzeri bir kurum ise milyonlarca mail gönderiyor olabilir ve bunların içlerinde mutlaka birkaç veya daha fazla sistem için bu hatayı alıyor olabilirsiniz. Öncelikle Reverse DNS kısmını biliyoruz diye düşünüyorum eğer bu konuda bilgiye ihtiyacınız var ise aşağıdaki temel tanımı kullanabilirsiniz;

http://sozluk.cozumpark.com/goster.aspx?id=1684&kelime=rdns-Reverse-DNS

Bir diğer kavram olan SMTP banner, mail sunucunuz 25 nolu port üzerinden karşı mail sistemlerine cevap verirken kullanıldığı text içeriğidir. Yani bir mail sunucusu sizin mail sunucunuza 25 nolu port üzerinden (veya 587) bağlantı kurmak istediğinde mail sunucunuz cevabı bu banner ile beraber verir ve bu banner aslında temel bilgiler içerir. Aslında bu bilgileri de biz sistem adminleri değiştirebiliyoruz. Örneğin varsayılan olarak burada sunucu ismi gelirken biz güvenlik nedeni ile bunu domain ismi ile değiştirebiliriz ki makaledeki uygulama noktamızda bu olacak.

Bunu hızlı bir şekilde internet üzerinden veya telnet ile kontrol edebilirsiniz

SMTP Banner da mail sunucum için ismi “postaci.cozumpark.local” olarak görüyorum.

Veya aşağıdaki adres üzerinden kontrol edebilirsiniz

https://mxtoolbox.com/diagnostic.aspx

Tabiki bu adres daha detaylı bilgiler vermektedir.

Peki gelelim asıl konumuza. Sorun burada başlıyor, yani örneğin cozumpark.com gibi sizin bir domain adınız var ve bunun için bir MX ve yine PTR kayıtları var, ama PTR kaydı içerisindeki isim ile SMTP banner içerisindeki isim eşleşmiyor ise eğer bazı mail sistemleri sizin maillerinizi kabul etmiyor. Peki bu durumda ne yapmamız gerekiyor?

Bunun için öncelikle Exchange Server 2010, 2013 veya 2016 sistemlerinde yapacaklarımız aynı. Yani iste ara yüz olsun istek komut seti çok benzer bir değişiklik yapacağız.

Öncelikle varsayılan olarak 25 nolu portu dinleyen receive connector üzerindeki izinleri değiştirmemiz gerekiyor. Bunun için aşağıdaki yolu izleyebilirsiniz

Mail flow – receive connectors – Default Frontend üzerine çift tıklıyoruz

İzinler bölümüne geliyoruz

Burada “Exchange Server authentication” kutucuğunu kaldırıyoruz. Yani bu connector e bir başka Exchange server bağlanırken kendi sunucu kimlik bilgisini kullanmayacak. Ancak zaten normal şartlarda bu connector için gerekli bir durum değildir. Bu konuyu yani özellikle birden çok sunucu olan ortamlarda iç mesajlaşma için hangi connectorler kullanılır ve yapılan değişikliler nasıl sonuçlar doğurur noktasında aşağıdaki ücretli eğitimimi inceleyebilirsiniz

https://www.udemy.com/exchange-server-2016-egitimi-bolum3/learn/v4/overview

Eğer connector konusuna hakimseniz devam edebiliriz.

Bu işlemi yaptıktan sonra scoping bölümüne geliyoruz

Alt bölümde yer alan FQDN alanını DNS kayıtlarınızdaki PTR ile eşitliyoruz. Örneğin benim için bu kayıt mail.cozumpark.com

Not: Eğer security sekmesindeki değişikliği yapmayı unutur iseniz aşağıdaki gibi bir hata alırsınız

If the AuthMechanism attribute on a Receive connector contains the value ExchangeServer, you must set the FQDN parameter on the Receive connector to one of the following values: the FQDN of the transport server “OX-Exch1.ad.oxfordsbsguy.com”, the NetBIOS name of the transport server “postaci.cozumpark.local”, or $null.

Benzer şekilde bunu komut seti ile de yapmamız mümkün, öncelikle mevcut connector’ leri listeleyelim

Get-ReceiveConnector

Daha sonra değişiklik yapacağımız connector’ ü seçiyoruz

Get-ReceiveConnector -Identity “POSTACI\Default Frontend postaci” | fl FQDN

Gördüğünüz gibi mevcut FQDN bilgisi geliyor, daha sonra izinleri değiştirmemiz gerekiyor

Set-ReceiveConnector -identity “POSTACI\Default Frontend POSTACI” -AuthMechanism Tls, Integrated, BasicAuth, BasicAuthRequireTLS

Son olarak ise FQDN i değiştirebilirsiniz

Set-ReceiveConnector -identity “POSTACI\Default Frontend POSTACI” -Fqdn mail.cozumpark.com

Ve kontrol ediyoruz

Hepsi bu kadar. Umarım faydalı bir makale olmuştur. Bu konu ile ilgili sorularınız için ÇözümPark Bilişim Portalı forumlarını kullanabilirsiniz, bu konuda pek çok kez bilgi paylaşımında bulundum, arama yapmanız yeterli olacaktır.

(81)

Exchange Server üzerinde kullanıcı bağlantıları için kullanılan pek çok farklı protokol ve istemci yazılımı vardır. Outlook bunlardan en çok tercih edileni olmasına karşın Outlook on the Web yani eski ismi ile OWA yine çok tercih edilen istemci erişim yöntemlerinden birisidir. Hayatımızın vazgeçilmez bir parçası olan mobil aygıtlar ise tabi ki Active Sync kullanmaya devam ediyor. Ancak Microsoft son kullanıcıyı deneyimini arttırmak için sürekli olarak çalışıyor. Özellikle Outlook programının masa üstü sürümüne çok benzeyen ve mobil aygıtlarda da çalışan Outlook for iOS ve Outlook for Android ürünlerini kullanıma sundu. Hepsi tabi ki bu kadar değil, son olarak Microsoft OWA for iPhone, OWA for iPad, ve OWA for Android uygulamasını duyurunca kafalar sistem yöneticileri için biraz karıştı. Öncelikle Outlook dışında Outlook on the web, Outlook mobile uygulaması, yine Outlook on the web’ in mobile bir aygıt üzerindeki browser’ dan açılması ki bunu ayarları da farklı olduğu için yazıyorum ve son nokta OWA mobil uygulaması! Gelelim asıl konumuza. Bu kadar çok istemci bağlantı seçeneği varken bizde Exchange Server’ ı yönetirken bazen tam olarak hangi ayarın hangi istemci için olduğunu karıştırabiliyoruz. Forumlarda çok sorulan bir konu olması üzerine bende kısa bir yazı ile bu konuyu aydınlatmak istedim. Klasik olarak bir kullanıcının OWA erişimini kapatmak istiyorsanız, yani web üzerinden posta kutusuna erişmesin bu durumda aşağıdaki kırmızı ile işaretli olan ayarı Disable yapmanız yeterli olacaktır.

Bu durumda kullanıcı Outlook on the Web kullanmaz. Ek olarak Active Sync bağlantısını da kapabilirsiniz. Bunun için ise mavi kutucuk içerisindeki ilk seçenek olan “Disable Exchange ActiveSync” linkine tıklayabilirsiniz. Peki Disable OWA for Devices nedir? Bu seçenek Microsoft OWA for iPhone, OWA for iPad ve OWA for Android bağlantısını kapatmak için vardır. Örneğin Outlook on the Web ve Active Sync’ i kapatıp bunu açık bırakırsanız kullanıcı bu programı bir mobil aygıt’ a yükleyerek postalarına hala erişebilir. Özetle Outlook on the Web erişimi ve “Owa for” uygulaması farklı bağlantı yöntemleri kullandığı için bunları ayrı ayrı yasaklamak gerekmektedir. Tabiki konumuz olmasa da aklınıza geliyordur, peki son Outlook kaldı bari onu da yaz tam olsun, kullanıcılar dışarıdan maillerine bağlanamasın. Eğer Exchange 2016 kullanıyorsanız o da kolay, aşağıdaki powershell ile bunu yasaklayabilirsiniz

Set-CasMailbox -Identity mailbox –MapiBlockOutlookExternalConnectivity $true

Umarım faydalı olmuştur, bir sonraki paylaşımımda görüşmek dileği ile.

https://www.microsoft.com/en-us/download/details.aspx?id=54935

Read More…

Merhaba, aslında çok yeni bir bilgi değil ancak bazen Technet üzerindeki port bilgisine bakınca kafa karıştıran bir konu olduğu için hızlıca paylaşmak istiyorum. Eğer Exchange server 2010 ve sonraki sürümlerden herhangi biri için DAG kurulumu yaptınız ve replikasyon için bir veri tabanının kopyasını gönderdikten sonra ( eğer farklı site içerisinde ise veya aynı site ama banka gibi yerlerde VLAN ların arasında da firewall olduğu için bu port bilgileri önemlidir) SMB trafiğinin çok yoğun kullanıldığını görebilirsiniz. Technet e bakınca replikasyon portunun 64327 olduğunu göreceksiniz. Ancak bu port ilk seeding işleminden sonraki log kopyaları için kullanılır. İlk seeding işleminde ise edb yani hazır veri tabanı örneğin 100GB ise smb üzerinden kopyalanır ve bu nedenle burada yoğun bir trafik görebilirsiniz.

Buna ek olarak SMB olayını çözdük, replikasyon postunuda biliyoruz peki 3875 nolu port nedir ki bu kadar trafik yapıyor derseniz, o da content index replikasyonu için kullanılır ki malum 100GB’ lık bir veri tabanı için 15GB veya 40GB content index olabilir ( içeriğe göre değişkenlik gösterir). Doğal olarak network tarafını kontrol ettiğiniz de hele ki WAN hattı ise dikkatinizi çekebilir. Ama panik yapmaya gerek yok, bunlar DAG network yapısının sorunlu olduğunu göstermez. Herşey normal ve kontrol altındadır yani.

Umarım projelerinde bu kadar detaylı trafik izleyen bilişim uzmanları için yararlı bir bilgi olur.

En sık kullanılan performans counterları ve değerlerini aşağıdaki tablodan edinebilirsiniz;

Burada size tavsiyem bu değerleri tek tek elemek biraz zahmetlidir. Bir sunucuda ekledikten sonra perfmon aracından bu değerleri save settings as diyerek html olarak kayıt edebilirsiniz. Daha sonra bu html dosyasını diğer sunucularınıza kopyalayıp perfmon içerisine sürükle bırak yöntemi ile taşıyabilir ve bu sayede hepsine benzer değerleri takip edebilirsiniz. Tabiki yine en iyi yöntem bir izleme ürünü kullanmak olacaktır. SCOM ilk tercihim olmak ile beraber farklı ürünler kullanabilirsiniz.

Kaynak;

Exchange 2013 – Performance counters and their thresholds

Exchange Server pek çok şirket organizasyonu içerisinde mail server olarak kullanılmaktadır. Son kullanıcıların mail alması ve göndermesi kadar önemi bir konuda pek çok şirket için uygulamaların mail alıp gönderebilmesidir. Kritik uygulamaların mail göndermesi için çoğu kez ayrı receive connector tanımlanır ve bunun üzerinden şirket içine veya dış dünyaya mail gönderimi sağlanır. Bu connectorler’ de Relay kavramı yani maili iletme kimi zaman kullanıcı kimlik doğrulaması ile kimi zaman ise anonim olarak sağlanır. Anonim kimlik doğrulamalarında bir sunucudan mail gitmemesi durumunda çok basit bir şekilde anonim relay izni verilen sunucuya login olunur veya Linux bir sunucu ise putty ile bağlanılır ve telnet testi yapılır.

Bu konuda aşağıdaki makalemi inceleyebilirsiniz

https://www.cozumpark.com/forums/thread/249461.aspx

Fakat bazen şirketler relay için kimlik doğrulama ile izin verir bu durumda ise yukarıdaki kodlar yerine aşağıdaki gibi farklı bir kod bütünü ile bu testi yapabilirsiniz.

telnet <SMTP Server name or IP> 25

İlk olarak telnet için ilgili sunucu ip adresini yazıyoruz. Telnet oturumu açıldıktan sonra aşağıdaki gibi EHLO komutunu çalıştırıyoruz.

EHLO

sunucu cevap verdikten sonra aşağıdaki komutu giriyoruz;
AUTH LOGIN
VXNlcm5hbWU6
Bunu yazdıktan sonra sunucu bir cevap verir ama Base64 olarak yani burada sunucu tarafından verilen cevap aslında “VXNlcm5hbWU6” bu “username:” demektir. Bizde user name sorusuna karşılık olan “hakan” “administrator” veya “info” yu base64 olarak yazmalıyız. Bunun için aşağıdaki web sitesini kullanabilirsiniz;

http://www.webpan.com/Customers/Email/base64_conversion.htm

örnek administrator için code

YWRtaW5pc3RyYXRvcg==

info için

aW5mbw==

sonra bize bu şekilde cevap veriyor yine sunucu;

UGFzc3dvcmQ6

Bu da “Password:” demektir. Bizde yine ayni siteden şifremizin base64 kodunu alıp yapıştırıyoruz;

örnek bir çalışma aşağıdaki gibidir;

Conversation in Base64
AUTH LOGIN
334 VXNlcm5hbWU6
YWRtaW5pc3RyYXRvcg==
334 UGFzc3dvcmQ6
cGFzc3dvcmQ=
235 2.7.0 Authentication successful

Translated back to plain text
AUTH LOGIN
334 Username:
administrator
334 Password:
password

sonra klasik devam

Send the test email
mail from:administrator@cozumpark.com
250 2.1.0 Sender OK
rcpt to:hakan@hakanuzuner.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
This is a test email
.
250 2.6.0 <XXXXX@Exch01.cozumpark.local> Queued mail for delivery

Umarım faydalı olur.

Merhaba arkadaşlar, bu konu son dönemde çok fazla ÇözümPark Bilişim Portalı forumlarında tartışıldığı için bir blog postu ile işi özetlemek istiyorum.

Öncelikle çok eskiden beri outlook indeks sorunları nedeni ile arama sonuçlarında bir takım sorunlar yaşanabilir. Bunu 2012 yılında paylaştığım aşağıdaki post ile çözebilirsiniz.

outlook index içeriğinin hızlı bir şekilde oluşturulması indexing speed is reduced due to user activity

Bu sorunun temeli, masa üstü bilgisayarlarından laptop’ lara geçiş döneminde özellikle 5400rpm disklerin kullanılması, verilerin büyük olması yani özetle büyüyen verilere karşılık kullanılan bilgisayar sabit disklerinin yavaş olması, belirli aralıklar ile bu indekslerin bozulmasına ve bunun sonucu olarak aramaların başarılı bir şekilde sonuçlanmamasına neden oluyor. Özetle hızlı diskleriniz var ise bu sorunu pek yaşamazsınız. Yaşasanız bile yukarıdaki çözüm işinizi görecektir.

Birde özellikle Haziran 2017 yamasından sonra outlook programlarında arama dışında ekler ile ilgilide sorun oldu.

Bu sorunun çözümü ise aşağıdaki linkte yer alıyor.

Haziran 2017 Güvenlik Güncelleştirmesi Sonrasında Yaşanan Outlook Arama ve Ekli Mail Sorunları Hakkında

Özetle bu iki post her şekilde işinizi çözecektir.

Aslında bu yazıyı ÇözümPark üzerinden paylaştım ancak kendi blog sayfam üzerinde arama yapanlar için buraya da eklemek istiyorum. Bilginin orijinal linki aşağıdaki gibidir;

http://www.cozumpark.com/forums/510254/ShowThread.aspx#510254

Exchange Server varsayılan olarak bir kaynaktan 1dk içerisinde 5 adet mail alır. Eğer toplu mail gönderimi ve benzeri programlar ile daha fazla mail almak istiyorsanız bunu değiştirmeniz gereklidir.

Öncelikle sizdeki durumu öğrenmek için aşağıdaki PS komutunu çalıştırın

get-receiveconnector | ft name, server, messageratelimit

Name                                    Server                                  MessageRateLimit
—-                                    ——                                  —————-
Default POSTACI                         POSTACI                                 Unlimited
Client Proxy POSTACI                    POSTACI                                 5
Default Frontend POSTACI                POSTACI                                 Unlimited
Outbound Proxy Frontend POSTACI         POSTACI                                 Unlimited
Client Frontend POSTACI                 POSTACI                                 5

Varsayılan olan bu 5 değerini aşağıdaki komut ile değiştirebilirsiniz

set-receiveconnector -identity “Client FrontEnd POSTACI” -MessageRateLimit 200

Yada limitsiz olsun isterseniz aşağıdaki komutu kullanabilirsiniz

set-receiveconnector -identity “Client Frontend POSTACI” -MessageRateLimit Unlimited

Buna ek olarak eğer relay yapan uygulama yine çok fazla mail göndermek ister ise tarpit interval değerine takılacaktır. Bu da kimlik doğrulamadan mail göndermek isteyen sistemler için bir yavaşlatma özelliğidir.

Get-ReceiveConnector | Format-List Name,Connection*,MaxInbound*,MessageRate*,TarpitInterval

Yukarıdaki komut ile TarpitInterval değerinin varsayılan olarak 5sn olduğunu göreceksiniz.

Bunu da sıfır yaparsanız sorunsuz bir şekilde relay yapabilirsiniz

Set-ReceiveConnector “Client FrontEnd POSTACI” -TarpitInterval 00.00:00:00

Not: Komutlardaki POSTACI benim sunucu ismim olup ortamınızdaki sunucu ismi ile değiştiriniz

TarpitInterval değeri authenticated sunucu, kullanıcı için kullanılmaz. Yani kullanıcı kendisini doğruluyor ise bu yavaşlatmaya tabi tutulmaz. Bu daha çok kimlik doğrlamadan gelen relay sunucularında olur.